UI Anti-Pattern: Website Loading Bars
medium.com
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
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.
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.
Argument #1: Forcing user to shift cognitive context is bad. Argument #2: In-built browser progress bars are good.
If you accept #1, #2 is wrong. If you accept #2, then #1 isn't as big a deal as you say it is.
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?
Your comment is difficult to comprehend, and low on information. Why should the year have any effect on whether users should use NoScript?
In the future, I would recommend going into detail rather than being dismissive.
Edit: ah, you were quoting the parent. I'm not convinced that excuses it. Sites should degrade gracefully, as users are becoming more aware of tracking technologies and taking steps to prevent it. Example: Tumblr actually fails to work with Ghostery enabled.
I brought it up with Medium on Twitter, and they seemed completely baffled. I haven't followed up though.
"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.
Also, the claims seem to be for the situation where the progress made in the auxiliary game is then reflected in the main game, if the loading game is merely a reflection of the loading process itself and is not related to the main content, then it would seem to be fine even if the main content is a game.
The spinners are more suitable for local apps like games and operating systems. If I see a spinner in a game, I know it hasn't frozen and should eventually finish loading.
Except it can't, really, because browsers don't expose any kind of "percentage complete" information to javascript code. Partly that's because the browser doesn't always know; if the response uses chunked encoding (common for anything that's not a static file), the initial headers don't indicate the length of the response, so the browser doesn't know what percentage of the response it's got until it's got the whole thing.
Basically, from the HTTP protocol up the stack is designed in a way that makes it really hard to know how much longer it's going to be before a request is complete. It's designed that way for good reasons, but the unfortunate side effect is that progress bars that have any degree of meaning are generally not possible for non-static content.
That's why we have spinners. They provide the user with feedback that says "yes, I saw that you clicked that, and I'm doing something about it", which is crucial, but they don't depend on knowing how long it'll take to do whatever is being done. Most of the time that's fine if the request completes within 10 seconds. Any longer than that and additional feedback is probably necessary, maybe using setTimeout().
What you described is a more general status indicator, bytes received, which I would display along with a transfer rate. That should not be shown as part of a progress bar because you don't know the percentage. However, I do agree that it's very useful information, and I always watch that kind of status indicator on FTP/SCP/torrent/copy+paste file transfers.
Unfortunately, browsers don't provide great feedback info to javascript even for that basic information about an ongoing request, if they provide any feedback at all. Usually you just get 'started' and then 'done'.
I'm currently working on a side project which is a library for driving progress bars using this principle. You give it an estimated amount of time, and your progress bar fills based on that (not linearly; my testing indicates that deceleration results in a shorter perceived time). If the estimate is way off, then it can switch to an indeterminate indicator instead of filling and stopping. To make the estimation process even easier (especially in the face of variation in user environments), it uses linear regression to adjust the estimates to be more accurate.
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.
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?
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).
Yes. If I saw data showing that 20% of youtube users didn't see the red bar, for example, I would agree with your point. But I have 1) my own experience showing otherwise (not worth that much) and 2) the logical argument that youtube probably did some usability tests with good results before releasing this. These 2 points are not a definitive argument, but they're enough for me to be skeptical of your critique.
> The progress bar within does work, because the user enters the address right there and at the moment where he presses enter,
But this is not the case when a user clicks a link at the bottom of the page, and a new page starts loading.
Agree on that one.
Depends on the browser. Chrome has long removed the loading bar for an almost unnoticeable "something-is-happening" spinner.
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.