UI Anti Pattern: Website Loading Bars
Website loading bars appear on more and more websites of all kind — unfortunately. The usage of this pattern is a really bad idea as it duplicates existing functionality combined with cognitive distraction.
Short Update: I got a lot of feedback and I would like to write a short note on the existing progress bar. I didn’t intend to recommend that one should use the existing progress bar rather than the new loading bars for e.g. triggering an action. The existing progress bar does work when the user enters a new URL address, as he already pays attention to the same area where the progress bar will appear. But in any case, the progress indicator must happen at the point the user executed the trigger.
I came across such a website loading bar first on one of my former projects. One of the web developers added it and it felt strange to me. On the one hand, I asked myself what this bar should indicate as I had no relation to the context and on the other hand I did not see the advantage of copying an existing feature (the good old status bar within the URL field of the browsers). Still I ignored this behavior until recently I saw a post with the title “New UI Pattern: Website Loading Bars”.
What is wrong with it?
A lot! First of all, status bars were more or less invented with the first browser application that was available. So people are used to that UI element. Whenever non-technical users open a website, they look at this bar. They expect it to show them the progress as soon as they have entered the website address and when the progress bar reaches the end and visually disappears, the users know that the loading of the website is done. So the website is ready to use. How this gets handled from a technical point is not interesting to the user and therefore he does not care if the data gets loaded as part of one request from the server or with the help of JavaScript that fetches only some data at a later point.
As the name indicates, loading bars display the progress of data loading, for example when a user presses a button and the website fetches some more data in the background, without reloading the whole page. The main idea (partial data loading) is not only excellent from a technical point of view but also from the user’s perspective. As the site does not reload, the content does also not change. Therefore, the user must neither analyze the view nor try to find out what has changed.
Unfortunately this advantage, at the same time, leads to a disadvantage: The user is not aware of what happens at the moment. When the user reloads a webpage, he recognizes that something is going on. If nothing happens when he presses a button (for example, when no indicator is shown), the user might think that the website is broken. Therefore the website must indicate that something is going on.
As mentioned above, one option used to show progress are those newly evolving loading bars. However, from my point of view, this is completely the wrong choice. And here’s why:
Every user unconsciously splits his field of vision into an active and an inactive area. When something happens in his active area, he recognizes immediately what happens. However, if something is happening in his inactive area, he only sees that something is going on, but he cannot see what. So to see what is going on, he needs to shift his gaze to the location where the action is happening. And by doing so, he focuses his attention on that action and no longer on the thing that he was previoiusly looking at. In short: he gets distracted.
The user loses the context by being forced to pay attention to a different area of the page.
Lets take an example to explain this in a real-life situation. Imagine a user is looking at a search field which is 3/4 down the page (so there is a gap between the top of the browser window and the search field/button). The user enters a search term and afterwards presses the search button. At this moment his eyes — and therefore his active field of vision — are residing on the search button. Now, as soon as the loading bar appears on the top of the page, the brain signals that there is something occuring outside of his active area. As the user is expecting that something must happen, he moves his eyes up to the loading bar. By doing so, he leaves his current cognitive context, which includes the search field, the search term, the button to trigger the search and some kind of expected behavior (the user knows that something should change now, because he started an action).
So the user is now focusing his attention on the loading bar. If he has not seen yet such a loading bar, the user will ask himself what that element should indicate. Remember: he lost the context of the search, that is why he needs to start orientating himself nearly from scratch. In the end, the user will mostly come to the conclusion that this element is related to the search action and realize that it shows the progress of the search. So the user is going to wait until the loading bar reaches a completed state. At this moment the user is lost because his eyes are still concentrating on the area where the loading bar was shown, but the search results appear nowhere near this area. So it’s up to him to come to the conclusion that he should look towards the area around the search field again. Once again, he needs to switch back to the previous cognitive context where he is required to orient himself again — “what was I searching again?” and, especially, “where are the results shown?”. The latter one is quite complicated to achieve, because his brain must evoke the view from before the search button had been triggered (which was part of an old context) and compare this view with the current view. This gives a huge cognitive overhead and is one of the worst things one can do from a user experience point of view.
To summarize the real-life example: The user was forced to change his context two times, figuring out himself what changed between the first time he looked at the search area and the time when he comes back from the loading bar area. And that is exactly why such loading bars are not a UI pattern. They are a UI anti-pattern!
Alternative ways to show progress
There are a lot of good ways to achieve this — as long as they are kept in the context of the active part from the user. For example, the text of the search button could change to ‘Loading…’ and a progress bar gets shown just below, i.e. in between the search field / button and the results area. That way, the user will have no trouble finding the search results as his active field of vision includes the change of the content that happens when the search result gets shown.
