Closed Bug 958480 Opened 6 years ago Closed 3 years ago

Update loading & connecting throbber design.

Categories

(Firefox :: Theme, defect)

defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1352119

People

(Reporter: fb+mozdev, Unassigned)

References

Details

(Whiteboard: p=0)

+++ 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)?
(Sorry, premature "enter".)
No longer depends on: 913249, 706179, 756601
Whiteboard: [Snappy]
Depends on: 750054
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
Blocks: 750054
No longer depends on: 750054
> > 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.
(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.
(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 …
Whiteboard: p=0
Depends on: 1013357
No longer blocks: fxdesktopbacklog
Flags: firefox-backlog+
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1352119
You need to log in before you can comment on or make changes to this bug.