Is it okay to put a minimum delay on UI changes?

Question

I’ve been writing mobile and web applications for a while. I mainly use async tasks, two way data binding etc. I’m updating / changing UI as data arrives from server or internal services. I have a problem here.

For example, for the case of login:

I have an Android app, and a login screen in it. When user clicks on the Log In button, I’m hiding the keyboard and showing a dialog which is saying ‘logging in, please wait’.

Sometimes the login process takes maybe less than 1/5 second. Sometimes it takes much more, for slow connections or other heavy web requests.

Again, for the devices which has good processing power and internet connection, at that really short time, I’m

1. Hiding the keyboard,
2. Showing a wait dialog,
3. When response arrives, removing the wait dialog
4. Changing the whole page.

That makes the UI look very confusing to me. I can’t remove the loading dialog or put a delay since there will be slow connections. Since I don’t know what kind of response I’ll get, I couldn’t find a way to use animations to prevent this confusion.

Similar thing for web (Angular) apps too. I’m loading a page. Then the arriving data is just changing UI in front of user. Even though there is a loading dialog, the showing/hiding of elements moves the whole page around in the background.

I’ve been thinking about dimming the page completely and adding a loading message with a minimum fixed wait time (like maybe 1.5 seconds). Is that a good approach for this kind of situation or did I totally misunderstood UI update stuff? Any alternative recommendations are welcome.

Answer 1

Based on the ideas in Response Times: The 3 Important Limits by Jakob Nielsen, yes, it makes sense to delay showing the progress dialog. The article says that showing too much information too quickly “would violate the principle of display inertia (flashing changes on the screen so rapidly that the user cannot keep pace or feels stressed)”. This problem is what your solution is avoiding.

In addition to delaying your UI changes, you can keep to the principle of display inertia by changing your “logging in, please wait” dialog to modify the UI less. Instead of popping up a new window over the login form, you could show the message below the Log In button, within the form. Or you could put the message in a transparent overlay on top of the login form, centered within it.

How long should the delay be? According to Nielsen’s article, the user’s “flow of thought” will last until 1 second after the user’s action. “Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second”. So that suggests that during the first second, you should only have a subtle indication that the user’s click of the Log In button was received, such as by disabling the Log In button. After one second, you can change the UI more and display something like “Logging in…” text with a spinner.

There is another technique you can use if the UI change you are delaying is putting a transparent overlay on top of your interface. Instead of making the overlay appear instantly after one second, make it gradually fade in from the very start. Thus, if the action happens within 0.2s, the overlay won’t have faded in enough for the user to notice it. If the action takes 5s, the overlay will fade in and stay there, and the user won’t see any sudden jump of the message appearing.

I saw that technique used in the pivot table interface of ActiveUI. When you execute a query that takes a long time to calculate, a transparent white overlay with “Loading…” and a spinner slowly fades in to cover the current values in the table. The overlay disappears immediately as soon as the new values have been loaded.