

UI Anti-Pattern: Website Loading Bars - thierryrietsch
https://medium.com/because-we-love-software/126cfe0fa698

======
runmyrun
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....](https://www.google.com/search?&q=cognitive+load+site:medium.com)

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
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
But this is the very definition of speculative :(

~~~
thierryrietsch
So a one man research during 4 months of university is more worth than real
life experience?

~~~
jonahx
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.

------
Pinckney
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
It is 2013, you are not supposed to use noscript.

~~~
venomsnake
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
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.

------
simonsarris
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.

~~~
tzs
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
<5k arcade games with download progress increasing the difficulty might be
good for some sites.

~~~
chrisballinger
Unfortunately, this was patented by Namco in 1995:
[http://www.google.com/patents/US5718632](http://www.google.com/patents/US5718632)

~~~
mistercow
So sad, it would have expired last year if it had been filed only 6 months
earlier.

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

------
jonahx
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
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
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
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).

~~~
jonahx
> But shouldn't come usability before design?

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.

~~~
thierryrietsch
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.

Agree on that one.

------
processyellow
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
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.

------
peterhunt
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
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.

------
twiceaday
> duplicates existing functionality

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

------
gfosco
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
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.

------
lnanek2
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
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.

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

------
pearjuice
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
I stopped visiting medium.com. It is always perfect "HN bait" with fluff. I
realised it was wasting my time.

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

------
static_typed
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.

