958480 - Update loading & connecting throbber design.

Status: RESOLVED DUPLICATE of bug 1352119

(Firefox :: Theme, defect)

Description

[Florian Bender]

+++ This bug was initially created as a clone of Bug #759252 +++

(In reply to Philipp Sackl [:phlsa] from bug 759252 comment #22)
> Dão is right, the technical part can be done without a spec.
> Nonetheless, here's a spec ;)
> http://phlsa.github.io/ff-loading-indicators/
> 
> The idea is that we can improve the perceived speed of the page load when we
> make the loading indicator dynamic. It makes sense to deal with this issue
> now to avoid a rewrite later on.

(In reply to Florian Bender from bug 759252 comment #23)
> For the scaling, I'd use an easing function (like ease-in), feels smoother
> that way.
> 
> As for a dynamic loading indicator, I don't feel much of a difference
> between 1 & 2 (apart from the dynamic indicator running irregularly
> sometimes, but I'm using Fx 27 Beta, maybe Nightly is better to test this
> with). How do you determine the run time for #1, though? That governs the
> timing function … do you want it get faster quickly and then run that fast
> for the rest of the loading time (which can be >10s in quite a few cases and
> regions)?

Comment 1

[Florian Bender]

(Sorry, premature "enter".)

Comment 2

[u428464]

The throbbers should also be updated in secondary UI (see bug 750054). 

Stephen Horlander also had a mockup for an Australis styling :  http://people.mozilla.org/~shorlander/mockups-interactive/australis-spinner-updates-i01/australis-spinner-updates-01.html

Comment 3

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

> > For the scaling, I'd use an easing function (like ease-in), feels smoother
> > that way.

It does use ease on both ends right now. I'll take a look if the transition can be improved with a custom animation curve.

> > As for a dynamic loading indicator, I don't feel much of a difference
> > between 1 & 2 (apart from the dynamic indicator running irregularly
> > sometimes, but I'm using Fx 27 Beta, maybe Nightly is better to test this
> > with). How do you determine the run time for #1, though? That governs the
> > timing function … do you want it get faster quickly and then run that fast
> > for the rest of the loading time (which can be >10s in quite a few cases and
> > regions)?

Currently it works like this: There is a ramp-up phase when the blue indicator becomes visible (3 seconds - perhaps this should be a little shorter). After that, the spinner runs at a constantly high speed until the page finishes loading. I've had troubles making sure that the two phases blend together smoothly, so that might be the irregularities you are seeing.

My (informal) user tests showed that this dynamic version feels a little faster. Oddly enough, it still felt faster when I biased the test to favor the static version. But again, take these results with a grain of salt. However, the implementation follows the cognitive theory.

The optimal implementation would be a little different: It would accelerate (for a shorter time), then run quite fast while loading and accelerate again towards the end. The problem with this is a) that it gets quite complex and b) that I don't think we have a way of knowing how long exactly it will take for the entire page to render.

Comment 4

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Guillaume C. [:ge3k0s] from comment #2)
> The throbbers should also be updated in secondary UI (see bug 750054). 
> 
> Stephen Horlander also had a mockup for an Australis styling : 
> http://people.mozilla.org/~shorlander/mockups-interactive/australis-spinner-
> updates-i01/australis-spinner-updates-01.html

I quite like the double spinner here, but I am not sure about the colorful ones. My concern is that their motion is very subtle which makes them look slower than they are. So from my perspective we should use the first and the last icon from the set.

Comment 5

[Florian Bender]

(In reply to Philipp Sackl [:phlsa] from comment #3)
> It does use ease on both ends right now. I'll take a look if the transition
> can be improved with a custom animation curve.

Yeah, I see that now. Sorry, I misread the source! Though "ease-in" looks slightly better than "ease". 

Also (as you said), it will probably look better if all animations could ease into each other, e.g. instead of switching the rotating direction immediately, the "ball" should decelerate & accelerate into the other direction. Though I assume this get's quite complex without WebAnimations … damn, my mind gets a bit "creative" now, so I may produce a different proposal (which is probably too computationally expensive to use) – though I really should work -.- let's see if I can control myself …