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.
Claims about UI/UX regarding 'cognitive load' based solely on conjecture sound like pure pseudoscience. The 'Hollow Icons' article was an egregious example:
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.
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.
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.
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?
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.
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.
I use NoScript and Ghostery to prevent tracking. There are certainly legitimate use-cases.
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 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.
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.
The claims in that patent are in terms of main games and auxiliary games. If your main site content is not a game, but you just use a very simple arcade game while loading, I am not sure this would apply.
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.
I think spinners are absolutely worthless on the internet, they tell me next to nothing. I could be looking at it for another second or it may keep going indefinitely. A progress bar, no matter how bad, can tell me there is progress being made.
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.
A progress bar, no matter how bad, can tell me there is progress being made.
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().
It doesn't have to be percentage, just seeing "x many bytes downloaded (out of unknown maximum)" increase is seeing progress. Seeing a spinner spin around may mean x is going up, or x is exactly where it was 30 seconds ago, but the spinner is made to always spin anyway.
That's not a progress bar though; the visual metaphor of a progress bar is a container/tank that goes from 0% 'full' to 100% 'full'.
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'.
This is why progress bars shouldn't try to reflect actual processing (unless they can measure it in a way that maps close to linearly) and instead should be based on estimation. A progress bar should be a way of telling to the user how much longer you think a task will take so that their time perception doesn't slow down. Using it to indicate wait times accurately or precisely is, at best, a waste of time.
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.
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?
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?
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.
Being skeptical on things that get written on the internet is always a good idea ;) And I am thankful to everyone who brings constructive criticism. Unfortunately I haven't seen any information regarding research from sites that use those approach. Would be interesting to see them.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.