What are best practices for blocking UI when application is busy

Question

I'm writing a web app using Twitter Bootstrap with PHP on server side. My app makes regular ajax requests via jQuery and i want to disable certain parts of the UI until the server completes processing and hands back the control to Client-Side.

I wonder what would be best practices for the same?

Answer 1

Here are some that came across my mind:

• The best practice ever is not letting your system freeze at all. Consider better, more efficient serverside. Of course this cannot be done in some situations, but is a good thing to check at the beginning, because no matter how you tell the user the system is busy, it's always better to show that it just works.

• If you cannot go for the forementioned option, then try to at least limit these times.

• If it's possible to process in background - do it. It may be not possible because of the system's logic, though. But if user can operate on something in the meantime, let him do so.

• If it's not possible to process in background, though (due to system's logic) you will need to block user controls.

• You will need to communicate it properly, e.g. by dimming the interface, displaying a proper text (e.g. "Wait for the system to process your query") and displaying some system busy icon. It needs to be animated, so that user does not have a feeling the system is frozen totally. After some time, s/he will get this feeling anyway, so more explanation may be necessary to excuse it, especially some information how much it can take to process it.

• Communicate progress if you can - I mean displaying a progress bar showing - in percents or time - how much of the processing is done or how much more it will take.

• If it's possible from the system's logic point of view, allow user to cancel processing to go back to fully responsive interface.

• Consider "amusing user" with some content. Take a look at Tiny Thief game in AppStore, for example. During the level loading, user is presented a story consisting of some images. When user goes through the story, the level loads, so actually user does not notice the loading at all. You can do it even in totally different systems than games - e.g. by displaying "Did you know?" tips during processing.

Answer 2

Honestly, it depends on the context.

Sometimes, it makes sense to disable specific UI elements. This happens regularly with ecommerce websites. Once you submit an order, most ecommerce websites worth their salt disable the "Order Now" button (visually still there, but grayed out, user's cursor changes, loading animation appears in the button, etc) to help prevent users from inadvertently ordering multiple times.

For further reading, check out "Users Continue To Double-Click Online" from Baymard Institute.

Sometimes though, queuing actions up in the background and never disabling the UI is a better approach. This has become an interesting approach with mobile apps. Within Instagram, for example, if you like a photo, the app automatically visually changes the heart/like button to a selected state. It may have communicated with the server or it may not have. But it assumes that eventually that state will be true. So it keeps a local queue of actions and eventually syncs it up with the server. This makes the app feel quicker than it actually is. It also drives engagement further because you don't feel like you're waiting around for actions to complete.

For more information, read Luke Wroblewski's article on "Mobile Design Details: Performing Actions Optimistically"

Answer 3

I recently worked on an application with this particular issue.

We designed the interface so that the actions that would be disabled for a particular action would be grouped together in a section. Once the user triggered an action that we knew would take more than a few ms, we grayed out the area that was unusable during the operation and showed a message indicating that the system was doing what the user requested.

I think there are few keys here:

• Make sure that you only disable the area that is affected by the backend process. If a number of controls are disabled, overlay with a box. If it's just a button, change the button text reflect that an action is taking place.
• Let the user know exactly what's happening and that you are processing their request (or getting the freshest data for them if it's something that isn't triggered by their actions). The user needs to know why you're blocking access to functionality and what's in it for them.
• Use animation so they know the system hasn't frozen.
• Let them know roughly how long it will take. Progress bars are great, but often can't be used because you just don't know how long a process might take (API calls for example).
• Set timeouts on all operations. If you know something should finish in 60 seconds, kill the process and let the user know there was an error.