Do we need a loading animation all the time?

(Brandon Rampersad) #1

Every link shows the Loading animation which could have a somewhere mild psychological effect on the user thinking the website is slow. No animation could make the website seem faster than an animation where the user didn’t expect one.

(altchen) #2

only show loading when request time more than some value, like 2 second ?

(Brandon Rampersad) #3

Or only when ember needs to load a heavy resource.

(Jeff Atwood) #5

This is a complex topic, I recommend reading

for details and background. In general we found that the loading animation is preferred so that the user knows something is happening, and doesn’t stare at a partially loaded page for half a second, wondering what will happen next…

(Anton) #6

When I hit F5 in my browser I still see “Loading…” which is nonsense.

The problem is not that it is loading.
The problem is that when I click on the link or hit F5 etc - I usually expect my screen to change only once,
but with “Loading…” my screen updates twice - first time everything gets hidden and loading shown… just for second or two! - then the whole screen changes again. This definitely irritating to the eyes.

Lets find a way to fix double-updating screen. The “loading…” itself looks very reasonable, but not implemented in such a way. What do you think?

(David Murdoch) #7

Another study to take into consideration regarding loading spinners and perceived performance: Improving perceived site performance with spinners, published after the study referenced in @codinghorror’s post.

The conclusion is that by delaying the display of the spinner
slightly, users perceive things to be happening quicker. But wait too
long and they start to think something’s broken — 0.4s seemed to be
the optimal delay, from the survey results. And it may be worth
thinking about other indicators if things take longer — add a
“loading…” text overlay after 1 sec, perhaps.

Steve Souders (Head Performance Engineer at Google) recently wrote about perceived performance on his blog that is more inline with this double screen refresh issue here on Discourse: clear current page UX | High Performance Web Sites and The Perception of Speed | High Performance Web Sites.

(C Copeland) #8

What would you say to the negative impact that a user is perceiving that the ‘loading’ image or text is

  1. misrepresenting the actual time to load
  2. actually indicative of possible problems that the loading image is hiding due to the complex interactions that are taking place behind the scenes
e.g. I am particularly disgusted by the 'ajax' loading widget icon that I get with regards to the latest update to the facebook mobile app for my HTC incredible 2 on both the wireless and 3G networks. This *wasn't* happening until a few weeks ago, or least that is what I perceived. I thought, **what** is **wrong** with *me*, and then I researched that yah, a lot of other people were having similar behaviors. I have then succumbed that the poor developers at facebook, and I say poor, because I can relate, and probably
  1. they really were trying to make something better
  2. they really are trying to reuse code, and not make it suck
  3. they really did break something and now are feverishly working to repair it

Basically, where is the line between users of software that we do not have any (theoretical) control over, yet know of the problems that underlie complex distributed computing problems, and the multitude of supporting browsers (ahem, IE 8 and the lessors) and the layman, i.e. not slipping into getting angry because you can’t see your friends extended posts and comment on them on your mobile, a poor user experience.

(Historiopode) #9

I agree that displaying a loading animation is desirable from an UX perspective. However, I dislike the current behaviour: having the starting page be cleared almost entirely to display the spinner before finally drawing the destination is, to my eyes, very jarring. The stark visual contrast between the three transition phases (wall of content -> wall of solid color -> wall of content) also leaves me with the impression of a longer waiting time.
Perhaps it would be better to overlay the spinner over a blurred starting page rather than removing the content entirely? The transition should feel smoother.

(Jeff Atwood) #10

How so? The topic has to load the posts inside, so at some point you must see a topic header with no posts.

This is very standard for Internet content:

  • the top of the page loads
  • then the next bit of content under the top loads
  • then the next but under the previous bit of content loads

… and so on downward until the full page is loaded.

I’m just not clear how top-down loading could possibly be jarring given that’s how web pages have loaded on the Internet since Mosaic.

(Historiopode) #11

A good example of the behaviour I was suggesting would be Twitter. (The vanilla web client at
When you switch context, a spinner appears on the top bar, but the content of the current page doesn’t disappear. It’s instead replaced by the target content as soon as it’s ready.
Other web apps with a behaviour that’s similar to Discourse’s often seem to feature many UI elements that stay on the page while the new content loads and/or update a smaller region of the page, preventing the “wall of solid color” effect. In the absence of these reference elements and for changes that affect very large regions, I think that Twitter-like behaviour is much more pleasant.

It’s true that pages load top-down anyway, but they either do so gradually or faster. My Discourse experience on Meta or Try is full page -> spinner on wall (1 second) -> full new page. It’s a bit like watching a TV doing black-frame insertion in slow-mo. Perhaps, with my latency, it would be better to watch the new page load element by element rather than wait one second and then see the full content appear instantaneously.
Admittedly, this might be a problem on my end, due to the distance to the servers. The transition might appear smoother with lower load times.

(Anton) #12

To me, “wall of solid color” effect is very reasonable. I’m not a big fun of that blinking, too. Keeping old content until new is loaded will end up with one page refresh, while the “wall of solid color” actually makes two visual refreshes, which on my opinion is just blinking and shakes reader’s tranquility.

(Sam Saffron) #13

I would rather we spend time focusing on the root problem.

On this laptop it takes 166ms to turn the json for this particular topic to usable html on the page. If you were to do this in vanilla handlebars it would probably be around 10ms, maybe less. That is the root issue we should be attacking.

That said I am open to any effects that make Discourse feel more responsive by eliminating cut-scenes etc. however this is very complex work that is very deep in Ember.

The standard web paradigm is

  1. Click link
  2. Display loading indicator in tab on favicon
  3. Render page

I am not sure I agree with the additional cut-scene we introduce but changing this so its a better experience than we have now is fairly complex work.

(Sam Saffron) #14

We depart from the mosaic style rendering by “amending” content. We don’t do a straight top-down render.

  1. You click on unread
  2. We switch you to the unread tab
  3. We render a “loading indicator”
  4. We replace the “loading indicator” with the actual content

I think something that probably makes sense is eliminating loading indicators unless a certain duration elapses.

Show the “Loading …” only if stuff is taking longer than say 2 seconds, that way we still give users a loading indicator for times that they need it.

Another open question is if we should remove the old content from the screen while preparing the new content.