6 ms·

UI Anti-Pattern: Website Loading Bars

30 points by thierryrietsch 13y ago

twiceaday 13y ago
> duplicates existing functionality Depends on the browser. Chrome has long removed the loading bar for an almost unnoticeable "something-is-happening" spinner.
anonymoushn 13y ago
I loosed my context by being forced to pay attention to typos :(
nickporter 13y ago
Ehh show me the data and we'll talk. I'm pretty sure youtube did some serious usability testing before deploying the loading bars.
processyellow 13y ago
I can't say I disagree or agree with the concept of these newer loading bars yet, but I'd really like to see citations or any references for just about everything in this article. Is this all just based on your assumptions of what confuses users? Or is this an area you've done research in?
- thierryrietsch 13y ago
  This blog entry is based on my personal experience in the field of user experience. I have not done research on a university level. I do have a lot of discussions regarding the distractions of user interface with non-technical users which exactly get confused by such behaviors. That is why I can't link any citations and studies.
gfosco 13y ago
I don't see how looking at the old status bar was any less of a context switch. Worse yet, now most modern browsers hide the damn status bar so it's no longer a static fixture. Chrome's status bar is a hover-popup with a delayed fade-in-and-out animation, if you want to talk about anti-patterns.
- thierryrietsch 13y ago
  I have not written (or at least I have not intended to write) that using the existing status bar is a better approach to show that progress is going on. At the end of the article I stated clearly that the progress indication should happen at the point where I execute the action.
simonsarris 13y ago
I agree with the conclusion, but have different premises. "Time is an illusion, lunchtime doubly so." -Douglas Adams Progress bars were invented to give users an indication of how much time remains relative to how much has elapsed. This is problematic, because: 1. Progress bars have a linear appearance mapping to a discrete value, yet they often represent progress that occurs at an erratic, non-linear pace. A progress bar telling you the minutes remaining in a video is useful. Seconds are always the same. A progress bar telling you seconds remaining until the page loads is not. HTTP/XML requests are fickle things. 2. Even if a progress bar does accurately measure the relative time of a task, the utlitity of the bar is further confounded by the fact that people tend to have a non-linear perception of time. After all, users are much more forgiving in the first 10 seconds of a wait than the last 10 seconds. If a user simply feels that a task with a progress bar is taking too long, they might simply quit the task. 3. UI researchers at Carnegie Mellon found that arbitrarily accelerating the progress bar's movement toward the end of the task alone will make it appear to complete more quickly. So to make a progress bar that feels accurate and fair, lying to your users about the total relative time remaining is the right thing to do. Much of the utility of progress bars comes from telling the user that the page is still working and has not halted. So unless the users are in for a real wait, its probably best to stick to spinners.
- thierryrietsch 13y ago
  Good point and +1 for spinners. Anyway easier to implement most of the times.
- tzs 13y ago
  Progress bars driven by data transfer may indeed fail at showing how much time is remaining, but at least they actually tell me that things are progressing. All spinners usually tell me is that the client was at some point trying to get more data and that it has not finished. The former is generally much more useful when dealing with a very slow server.
  - moocowduckquack 13y ago
    <5k arcade games with download progress increasing the difficulty might be good for some sites.
runmyrun 13y ago
This is another Medium article about cognition and user interfaces that seems to be based on speculative assertions about user behavior. And they aren't convincing. https://www.google.com/search?&q=cognitive+load+site:medium.com https://www.google.com/search?&q=cognitive+load+site:medium.... Claims about UI/UX regarding 'cognitive load' based solely on conjecture sound like pure pseudoscience. The 'Hollow Icons' article was an egregious example: https://medium.com/design-ux/a93647e5a44b https://medium.com/design-ux/a93647e5a44b If you've accepted the premise that cognitive load theory is going to be a major part of your design/ui decisions, and you're going to invoke it, then I think some meaningful testing is necessary.
- thierryrietsch 13y ago
  Why should my statement be speculative? Ok, one could mention it that way because I have not done any research during any university in this field, but it reflects my personal experience and the experience I do have from past projects, when user tested certain pieces of software.
  - jonahx 13y ago
    But this is the very definition of speculative :(
    - thierryrietsch 13y ago
      So a one man research during 4 months of university is more worth than real life experience?
      - jonahx 13y ago
        If you want evidence you can trust, you need well executed scientific experiements, which in this case means well executed usability tests with controls and a decent sample size, and ideally those devices which can monitor where the eye is focused on the page as a user is interacting with it. Unfortunately we don't usually have that luxury or that data available, and we have to make do with our own experience and the advice of other professionals. But you should really take both of those things (especially our own experience) with a healthy dose of skepticism -- one of the primary goals of the scientific method is to put our own notoriously unreliable but deeply felt instincts in check. That doesn't mean "real life experience" is worthless, or shouldn't be considered. It just means you should draw a hard line between the truths of life experience and truths established through well conducted experiments.
peterhunt 13y ago
Hey, if the browser gave me an API to trigger the built-in spinners/loading bars on XHR I'd use it, but for those of us that need to block the UI on XHR this is kind of our only option. I think that this is less a UX issue and more of a browser API limitation issue.
- thierryrietsch 13y ago
  Using the existing status bar would be a better approach from my perspective, but still does not replace any status indication at the point, where the action is triggered.
pearjuice 13y ago
Another linkbaity title - calling something new and trendy a bad thing will always get a lot of people rustled - from the fine elitists blogging on Medium. The UI anti pattern described is not the loading bar (as the alternative in the conclusion IS a loading bar) but the placement of the loading bar. Then again, it is pure speculation with no further data or research to back the "cognitive load" theory up.
- hnha 13y ago
  I stopped visiting medium.com. It is always perfect "HN bait" with fluff. I realised it was wasting my time.
Pinckney 13y ago
You know what's worse than website loading bars? Breaking scrolling for your users. I'm running Firefox with Vimperator and noscript. All scripts are blocked on this page. When it loads, none of the "scroll page" commands work (Arrow keys, PgDn, Spacebar, Ctrl-D, j/k, etc). Even once I click the text, Vimperator's Ctrl-D still refuses to scroll (though all the other commands work, including j/k). And if I permit scripts, arrows, PgDn and j/k all work, while Spacebar and Ctrl-D don't, regardless of what I click. It is 2013. Twenty years ago we could serve plaintext without breaking shit. What happened?
- miguelrochefort 13y ago
  It is 2013, you are not supposed to use noscript.
  - venomsnake 13y ago
    Of course I may be behind the latest fads in web development but isn't the purpose of javascript to enhance the web pages and not to substitute/break functionality which the browser is perfectly capable to deliver with pure html. Like ... scrolling.
    - m_mueller 13y ago
      There is one essential use case of client side script being necessary for a better browsing experience: Endless scroll instead of pagination. Pages for query results is a big reason why older web apps feel much more restricted compared to their desktop counterparts. Being able to stream data however requires JS on the client, since it doesn't fit into the classic GET requests. Having to program a fallback pagination just for people with noscript is not worth it IMO.
  - Pinckney 13y ago
    Even with all scripts enabled, Spacebar (and Vimperator's Ctrl+D) are broken. Home/End and Vimperator's gg/G turn out to not work as well.
  - nsmartt 13y ago
jonahx 13y ago
This critique's central example is a straw man. The main discussion is about interacting with a small element (such a search bar) where, the article argues, it's better to keep the ajax UI indicator closer to the point of user interaction. While this may be true, many sites that use these loading bars (such as youtube) are using them when all (or a large portion) of the page is being entirely reloaded using ajax or pjax. So the critique given does not apply to one of the largest use cases.
- thierryrietsch 13y ago
  But even when the complete page is reloaded in an ajax/pjax manner, the loading bar is out of the visibility area. If one scrolls through the recommended videos on YouTube and pick one which is in the middle or below the list, one will not directly recognize the loading bar - why not showing the status indicator in a more prominent place?
  - jonahx 13y ago
    Personally I think it's pretty noticeable. My eye went right to it the first time I saw it. I suppose you could argue that they should have an overlay spinner (or something similar) across the entire page so it would be impossible to miss, but that's not as elegant. Also, why wouldn't your reasoning apply to the url progress bar in many browsers that you see for an ordinary http page load? It's up their at the top of the page, why not put a nice unmissable transparent loading bar across the middle of the page?
    - thierryrietsch 13y ago
      Cool :) I missed it totally :D But shouldn't come usability before design? The progress bar within does work, because the user enters the address right there and at the moment where he presses enter, his eyes are still in this area, so he recognizes the progress bar immediately. A unmissable loading bar would solve the problem, as long as it is unmissable (from my point of view).
      - 13y ago
imonkey 13y ago
Finally somebody pay attention on the stupid idea. It duplicates existing functionality - agree! Combined with cognitive distraction - agree!!
static_typed 13y ago
The real anti-pattern is building sites that get to the point of needing loading bar indicators. I loved web, when it was, you know, documents. With links to related and other relevant documents. There is a need for online forms, to replace the paper bound versions, and one day we may even develop an appropriate technology to achieve this. Until then, the layers of fresh sticky tape are sitting uneasily upon the aged, yellowing earlier layers of sticky tape, and the turtles-all-way-down "web app" continues to bloat. There is always talk of game changers, disrupting things here on HN, but the massive, obvious challenge goes missed every time. It is easier, maybe more fun, to punt yet another JS framework, bork the HTTP standards a bit more, increase the attack vector in the already humungous browser, than to think outside the box. Maybe instead of thinking outside the box, we should think outside the browser.
lnanek2 13y ago
Unfortunately, there isn't any choice. Even now mainstream frameworks like Rails are moving over to loading pages via JavaScript because it is so much faster than performing another large full page load, particularly on the growing segment of power limited mobile devices. Saying you shouldn't show a progress bar and should use the browser functionality is basically saying you have to go back to pages that take seconds to load on a mobile phone instead of milliseconds.
- thierryrietsch 13y ago
  I agree that a full page load is not required. Also I didn't intend to recommend to use the normal progress bar. It is just from a user perspective a duplication of the bar above. What I intended to say is, that the loading bar should not be used to show a progress is going on. Because the page stays more or less the same and the user is looking with a very high chance at a different area.

> duplicates existing functionality Depends on the browser. Chrome has long removed the loading bar for an almost unnoticeable "something-is-happening" spinner.

anonymoushn 13y ago

I loosed my context by being forced to pay attention to typos :(

nickporter 13y ago

Ehh show me the data and we'll talk. I'm pretty sure youtube did some serious usability testing before deploying the loading bars.

processyellow 13y ago

I can't say I disagree or agree with the concept of these newer loading bars yet, but I'd really like to see citations or any references for just about everything in this article. Is this all just based on your assumptions of what confuses users? Or is this an area you've done research in?

thierryrietsch 13y ago
This blog entry is based on my personal experience in the field of user experience. I have not done research on a university level. I do have a lot of discussions regarding the distractions of user interface with non-technical users which exactly get confused by such behaviors. That is why I can't link any citations and studies.

gfosco 13y ago

I don't see how looking at the old status bar was any less of a context switch. Worse yet, now most modern browsers hide the damn status bar so it's no longer a static fixture. Chrome's status bar is a hover-popup with a delayed fade-in-and-out animation, if you want to talk about anti-patterns.

thierryrietsch 13y ago
I have not written (or at least I have not intended to write) that using the existing status bar is a better approach to show that progress is going on. At the end of the article I stated clearly that the progress indication should happen at the point where I execute the action.

simonsarris 13y ago

I agree with the conclusion, but have different premises. "Time is an illusion, lunchtime doubly so." -Douglas Adams Progress bars were invented to give users an indication of how much time remains relative to how much has elapsed. This is problematic, because: 1. Progress bars have a linear appearance mapping to a discrete value, yet they often represent progress that occurs at an erratic, non-linear pace. A progress bar telling you the minutes remaining in a video is useful. Seconds are always the same. A progress bar telling you seconds remaining until the page loads is not. HTTP/XML requests are fickle things. 2. Even if a progress bar does accurately measure the relative time of a task, the utlitity of the bar is further confounded by the fact that people tend to have a non-linear perception of time. After all, users are much more forgiving in the first 10 seconds of a wait than the last 10 seconds. If a user simply feels that a task with a progress bar is taking too long, they might simply quit the task. 3. UI researchers at Carnegie Mellon found that arbitrarily accelerating the progress bar's movement toward the end of the task alone will make it appear to complete more quickly. So to make a progress bar that feels accurate and fair, lying to your users about the total relative time remaining is the right thing to do. Much of the utility of progress bars comes from telling the user that the page is still working and has not halted. So unless the users are in for a real wait, its probably best to stick to spinners.

thierryrietsch 13y ago
Good point and +1 for spinners. Anyway easier to implement most of the times.
tzs 13y ago
Progress bars driven by data transfer may indeed fail at showing how much time is remaining, but at least they actually tell me that things are progressing. All spinners usually tell me is that the client was at some point trying to get more data and that it has not finished. The former is generally much more useful when dealing with a very slow server.
- moocowduckquack 13y ago
  <5k arcade games with download progress increasing the difficulty might be good for some sites.

runmyrun 13y ago

This is another Medium article about cognition and user interfaces that seems to be based on speculative assertions about user behavior. And they aren't convincing. https://www.google.com/search?&q=cognitive+load+site:medium.com https://www.google.com/search?&q=cognitive+load+site:medium.... Claims about UI/UX regarding 'cognitive load' based solely on conjecture sound like pure pseudoscience. The 'Hollow Icons' article was an egregious example: https://medium.com/design-ux/a93647e5a44b https://medium.com/design-ux/a93647e5a44b If you've accepted the premise that cognitive load theory is going to be a major part of your design/ui decisions, and you're going to invoke it, then I think some meaningful testing is necessary.

thierryrietsch 13y ago
Why should my statement be speculative? Ok, one could mention it that way because I have not done any research during any university in this field, but it reflects my personal experience and the experience I do have from past projects, when user tested certain pieces of software.
- jonahx 13y ago
  But this is the very definition of speculative :(
  - thierryrietsch 13y ago
    So a one man research during 4 months of university is more worth than real life experience?
    - jonahx 13y ago
      If you want evidence you can trust, you need well executed scientific experiements, which in this case means well executed usability tests with controls and a decent sample size, and ideally those devices which can monitor where the eye is focused on the page as a user is interacting with it. Unfortunately we don't usually have that luxury or that data available, and we have to make do with our own experience and the advice of other professionals. But you should really take both of those things (especially our own experience) with a healthy dose of skepticism -- one of the primary goals of the scientific method is to put our own notoriously unreliable but deeply felt instincts in check. That doesn't mean "real life experience" is worthless, or shouldn't be considered. It just means you should draw a hard line between the truths of life experience and truths established through well conducted experiments.

peterhunt 13y ago

Hey, if the browser gave me an API to trigger the built-in spinners/loading bars on XHR I'd use it, but for those of us that need to block the UI on XHR this is kind of our only option. I think that this is less a UX issue and more of a browser API limitation issue.

thierryrietsch 13y ago
Using the existing status bar would be a better approach from my perspective, but still does not replace any status indication at the point, where the action is triggered.

pearjuice 13y ago

Another linkbaity title - calling something new and trendy a bad thing will always get a lot of people rustled - from the fine elitists blogging on Medium. The UI anti pattern described is not the loading bar (as the alternative in the conclusion IS a loading bar) but the placement of the loading bar. Then again, it is pure speculation with no further data or research to back the "cognitive load" theory up.

hnha 13y ago
I stopped visiting medium.com. It is always perfect "HN bait" with fluff. I realised it was wasting my time.

Pinckney 13y ago

You know what's worse than website loading bars? Breaking scrolling for your users. I'm running Firefox with Vimperator and noscript. All scripts are blocked on this page. When it loads, none of the "scroll page" commands work (Arrow keys, PgDn, Spacebar, Ctrl-D, j/k, etc). Even once I click the text, Vimperator's Ctrl-D still refuses to scroll (though all the other commands work, including j/k). And if I permit scripts, arrows, PgDn and j/k all work, while Spacebar and Ctrl-D don't, regardless of what I click. It is 2013. Twenty years ago we could serve plaintext without breaking shit. What happened?

miguelrochefort 13y ago
It is 2013, you are not supposed to use noscript.
- venomsnake 13y ago
  Of course I may be behind the latest fads in web development but isn't the purpose of javascript to enhance the web pages and not to substitute/break functionality which the browser is perfectly capable to deliver with pure html. Like ... scrolling.
  - m_mueller 13y ago
    There is one essential use case of client side script being necessary for a better browsing experience: Endless scroll instead of pagination. Pages for query results is a big reason why older web apps feel much more restricted compared to their desktop counterparts. Being able to stream data however requires JS on the client, since it doesn't fit into the classic GET requests. Having to program a fallback pagination just for people with noscript is not worth it IMO.
- Pinckney 13y ago
  Even with all scripts enabled, Spacebar (and Vimperator's Ctrl+D) are broken. Home/End and Vimperator's gg/G turn out to not work as well.
- nsmartt 13y ago

jonahx 13y ago

This critique's central example is a straw man. The main discussion is about interacting with a small element (such a search bar) where, the article argues, it's better to keep the ajax UI indicator closer to the point of user interaction. While this may be true, many sites that use these loading bars (such as youtube) are using them when all (or a large portion) of the page is being entirely reloaded using ajax or pjax. So the critique given does not apply to one of the largest use cases.

thierryrietsch 13y ago
But even when the complete page is reloaded in an ajax/pjax manner, the loading bar is out of the visibility area. If one scrolls through the recommended videos on YouTube and pick one which is in the middle or below the list, one will not directly recognize the loading bar - why not showing the status indicator in a more prominent place?
- jonahx 13y ago
  Personally I think it's pretty noticeable. My eye went right to it the first time I saw it. I suppose you could argue that they should have an overlay spinner (or something similar) across the entire page so it would be impossible to miss, but that's not as elegant. Also, why wouldn't your reasoning apply to the url progress bar in many browsers that you see for an ordinary http page load? It's up their at the top of the page, why not put a nice unmissable transparent loading bar across the middle of the page?
  - thierryrietsch 13y ago
    Cool :) I missed it totally :D But shouldn't come usability before design? The progress bar within does work, because the user enters the address right there and at the moment where he presses enter, his eyes are still in this area, so he recognizes the progress bar immediately. A unmissable loading bar would solve the problem, as long as it is unmissable (from my point of view).
    - 13y ago

imonkey 13y ago

Finally somebody pay attention on the stupid idea. It duplicates existing functionality - agree! Combined with cognitive distraction - agree!!

static_typed 13y ago

The real anti-pattern is building sites that get to the point of needing loading bar indicators. I loved web, when it was, you know, documents. With links to related and other relevant documents. There is a need for online forms, to replace the paper bound versions, and one day we may even develop an appropriate technology to achieve this. Until then, the layers of fresh sticky tape are sitting uneasily upon the aged, yellowing earlier layers of sticky tape, and the turtles-all-way-down "web app" continues to bloat. There is always talk of game changers, disrupting things here on HN, but the massive, obvious challenge goes missed every time. It is easier, maybe more fun, to punt yet another JS framework, bork the HTTP standards a bit more, increase the attack vector in the already humungous browser, than to think outside the box. Maybe instead of thinking outside the box, we should think outside the browser.

lnanek2 13y ago

Unfortunately, there isn't any choice. Even now mainstream frameworks like Rails are moving over to loading pages via JavaScript because it is so much faster than performing another large full page load, particularly on the growing segment of power limited mobile devices. Saying you shouldn't show a progress bar and should use the browser functionality is basically saying you have to go back to pages that take seconds to load on a mobile phone instead of milliseconds.

thierryrietsch 13y ago
I agree that a full page load is not required. Also I didn't intend to recommend to use the normal progress bar. It is just from a user perspective a duplication of the bar above. What I intended to say is, that the loading bar should not be used to show a progress is going on. Because the page stays more or less the same and the user is looking with a very high chance at a different area.