Is blocking the view when data is fetched, a good User Experience (UX )?
Is it a good UX, when the user cannot click on the UI when data is fetched ? Maybe yes, maybe no…
Introduction
At work, for some projects and modules in development, I noticed the use of a blocking view when data is being fetched. In other words, you cannot click anywhere on the screen until the application receives the data. I’ve not seen this behaviour anywhere else on the Web. In a way, that’s an innovative feature. But does it provide a good User Experience (UX)?
How is this option implemented?
You can implement this behaviour using the CSS pointer-events: none. When the page is loaded, you set the body of the page or the main container with this property. You remove it after the data is fetched. The user can continue working.
You can either, with the body or container element:
- define a css class with this property and add it dynamically and remove it when completed
- Or attach the style using JavaScript on fetching the data and removing it after being fetched
Similarly, you can add an overlay by using background-color: greyish colour to indicate the page contents are loading.
Why is this feature important?
I cannot think of a potential use case for this behaviour. I’ve yet to see it on any website. I’ve researched for similar keywords on google such as “block the view when content is being fetched”, or “user cannot click when data is fetched”; I see no related content. I think this behaviour has not been implemented anywhere commonly used.
What are the advantages?
- Provides a good visual feedback to the user that the data is being loaded, there is something happening, you don’t to wait endlessly.
- Prevents you from clicking anything or putting data that can disrupt the state such as modifying data that has not been loaded yet.
What are the drawbacks?
- Now imagine, due to an error, the server does not return the API data or part of it. The client side application keeps waiting for a response. The entire view is blocked. The user has to wait and cannot navigate to another page without first reloading it.
- If the latter clicked on the wrong page, he or she has to wait the current view to first load before navigating to the intended page — resulting in a waste of time. Compare this flow when you visit YouTube for example. When you click on a video thumbnail, as the page is loading — if you see a more interesting video, you can click on the link without having to wait for the page to completely load. The view does not block. The flow is asynchronous — which means you don’t need for the current operation to complete before attempting something else. The UX is intuitive providing a smooth experience.
- Similarly, as the page progressively loads the thumbnails before the actual video is loaded, you can click on another video or navigate elsewhere, without having to wait for all the content to be loaded.
This blocking feature defeats JavaScript’s asynchronous nature in the browser. One operation should not entirely block the page.
Alternatives:
- To avoid the user from clicking on faulty data, you can hide elements based on context or logic. For example, you can hide or disable the submit button until the form is valid.
- Instead of blocking the entire view when data is loading, only an element or group of is blocked or hidden
- Using good copy throughout the application is important — to clearly and concisely communicate to the user the application current state. For example, using Material Design guidelines, having a progress indicator at the top of the page or in the middle — when data loads — provides a smoother UX.
Resources:
