994954 - [UX] Improve the design of loading throbbers

Status: REOPENED

(Firefox :: Theme, defect)

Description

[Zhenshuo Fang (:fang) - Firefox UX Team]

Improve the design of loading throbber

Comment 1

[u428464]

http://people.mozilla.org/~shorlander/mockups-interactive/australis-spinner-updates-i02/australis-spinner-updates-02.html

Comment 2

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

Attachment: new-loading-throbbers

This uses some of Stephens new loading indicators. It also standardizes the graphics across all platforms.

Comment 3

[u428464]

Does this patch also resolve bug 750054 ?

Comment 4

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

(In reply to Guillaume C. [:ge3k0s] from comment #3)
> Does this patch also resolve bug 750054 ?

No, it doesn't. I'm putting that one up for the backlog.

Comment 5

[Dão Gottwald [:dao]]

Can you please make an effort to file bugs in the right component? Thanks.

Comment 6

[Marco Bonardo [:mak]]

Comment on attachment 8415531 [details] [diff] [review]
new-loading-throbbers

Review of attachment 8415531 [details] [diff] [review]:
-----------------------------------------------------------------

The only slightly negative change I see, is that connecting.png is 8KB larger than the old image, not a big deal, but I wonder if with some slight optimization to the frames, or by having a fainter trail, the difference could be reduced. All of the other images are smaller, that's nice! This is definitely not a blocking issue though.

One thing yet, did you check if on Windows with 1.25 and 1.5 hidpi settings, the scaled up 1x throbber looks better than the scaled down 2x throbber? The throbber is a pretty high visible item, so it may be worth evaluating hidpi issues even if most of the UI is not ready for it yet.

Comment 7

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

(In reply to Marco Bonardo [:mak] from comment #6)
> Comment on attachment 8415531 [details] [diff] [review]
> new-loading-throbbers
> 
> Review of attachment 8415531 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> The only slightly negative change I see, is that connecting.png is 8KB
> larger than the old image, not a big deal, but I wonder if with some slight
> optimization to the frames, or by having a fainter trail, the difference
> could be reduced. All of the other images are smaller, that's nice! This is
> definitely not a blocking issue though.
I tried a couple of PNG minimizers, but most of them don't work on animated PNGs. Manually tweaking the frames might be an option, but I'm wondering whether the result is worth the effort.

> One thing yet, did you check if on Windows with 1.25 and 1.5 hidpi settings,
> the scaled up 1x throbber looks better than the scaled down 2x throbber? The
> throbber is a pretty high visible item, so it may be worth evaluating hidpi
> issues even if most of the UI is not ready for it yet.
Scaling them down would certainly be better. I'll file a follow-up bug for this.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/fx-team/rev/b77de3bb419e

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/b77de3bb419e

Comment 10

[Tim Nguyen :ntim]

I seem to have a weird bug happening on my computer.
The loading throbber can sometimes turn blurry after this bug. I still haven't figured any specific STR though :/

Comment 11

[Willy_ Foo_Foo]

sorry if this is not the right bug

the new Throbbers comsume a load of CPU & GPU usage
12-14% CPU @Intel Atom N450
throbbers consume 4-10% CPU @Intel i7
do you cache it or not, and could you guys convert it to SVG,
you can make them be hardware acceleration and reducing the CPU usage.
As the e10s is not enabled+stable yet,
so I guess reducing CPU usage while page loading is important for now.

I guess it should not show performance impact as it an animation.
but too bad, Firefox is not taking much time into the FPS(responsiveness)
like IE11 or Chrome dev tools, that can showing about responsiveness...


So far I am feeling a bit slow because the throbber is having a attractive color(might be also slowing rolling speed to hit 360°), it is stutter because of 30FPS, and more stutter because the Firefox is easy to hung while loading page, causing it drop to 15FPS

Comment 12

[Mike de Boer [:mikedeboer]]

I'd recommend to first, at least, optimize each individual frame/PNG before putting 'em back together. This should greatly reduce the size and potentially improve animation performance.

Comment 13

[Marco Bonardo [:mak]]

(In reply to Mike de Boer [:mikedeboer] from comment #12)
> I'd recommend to first, at least, optimize each individual frame/PNG before
> putting 'em back together. This should greatly reduce the size and
> potentially improve animation performance.

regardless, bug 1008324 is going to change this. Just as a side note, the images are smaller than the old ones (apart a couple exceptions), they just "look" slower when in the product (that's a issue by itself, but not due to the size).

Comment 14

[Paul [pwd]]

Is there a wiki page for this? Like a design spec? What was the goal of the new throbbers? There are now more states, whereas before there was simply connecting and loading, there's now a bunch of new states, what do they mean. As this bug is presented, it seems to be redesign for redesign sakes.

Comment 15

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

(In reply to Paul [pwd] from comment #14)
> Is there a wiki page for this? Like a design spec? What was the goal of the
> new throbbers? There are now more states, whereas before there was simply
> connecting and loading, there's now a bunch of new states, what do they
> mean. As this bug is presented, it seems to be redesign for redesign sakes.

The intention was unification across platforms and visual refresh. This bug only exchanged the images, so there shouldn't be any new states.
It is interesting that you interpreted the new animation as having more states – that is valuable feedback!
Note that this patch will get backed out following the discussion in bug 1008324

Comment 16

[Paul [pwd]]

(In reply to Philipp Sackl [:phlsa] from comment #15)
> (In reply to Paul [pwd] from comment #14)
> > Is there a wiki page for this? Like a design spec? What was the goal of the
> > new throbbers? There are now more states, whereas before there was simply
> > connecting and loading, there's now a bunch of new states, what do they
> > mean. As this bug is presented, it seems to be redesign for redesign sakes.
> 
> The intention was unification across platforms and visual refresh. This bug
> only exchanged the images, so there shouldn't be any new states.
> It is interesting that you interpreted the new animation as having more
> states – that is valuable feedback!
> Note that this patch will get backed out following the discussion in bug
> 1008324

Which platforms are being unified here that weren't already unified? Even on the mailing list, it was like "what do you think of the new spinners" minus the "we had a design goal of X, Y and Z because research showed A, B and C" so you can understand my bewilderment here.

Comment 17

[Tim Taubert [:ttaubert] (inactive)]

Backed out based on the discussion in bug 1008324:

https://hg.mozilla.org/integration/fx-team/rev/c04b92e48540

Comment 18

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

(In reply to Paul [pwd] from comment #16)
> Which platforms are being unified here that weren't already unified?

The color was different on Win/Mac/Linux and the Hidpi graphics used a different style altogether.

Comment 19

[Paul [pwd]]

(In reply to Philipp Sackl [:phlsa] from comment #18)
> (In reply to Paul [pwd] from comment #16)
> > Which platforms are being unified here that weren't already unified?
> 
> The color was different on Win/Mac/Linux and the Hidpi graphics used a
> different style altogether.

Thanks for the clarification.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

(In reply to Tim Taubert [:ttaubert] from comment #17)
> Backed out based on the discussion in bug 1008324:
> 
> https://hg.mozilla.org/integration/fx-team/rev/c04b92e48540

Merge of backout:
https://hg.mozilla.org/mozilla-central/rev/c04b92e48540

Comment 21

[u428464]

Bug 958480 is a dupe of this I think.

Comment 22

[:Gavin Sharp [email: [e-mail]]]

Marco: we need to remove this from the current iteration because it's blocked by platform work.

Comment 23

[Marco Mucci [:MarcoM]]

Removed from Iteration.

Comment 24

[Tim Babych]

> It is interesting that you interpreted the new animation as having more
> states – that is valuable feedback!

I second that impression. Only after finding the bug and checking out proposed change did I realize that only thing changed was images. Initially I thought inner circle on the first animation was meant to indicate some state of loading process.

Comment 25

[u428464]

Does bug 759252 change the approach here ?

Comment 26

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

(In reply to Guillaume C. [:ge3k0s] from comment #25)
> Does bug 759252 change the approach here ?

Yes, we'll have to revisit the design.

Comment 27

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

Unassigning for now. Other work might require us to take a different approach here (especially the experiment in bug 990556).

Comment 28

[Stephen Horlander [:shorlander]]

Is this something we can do now that bug 980770 is fixed?

Comment 29

[Justin Dolske [:Dolske]]

It sounds from that bug that platform _thinks_ OMTA is ready to ride the trains, but I'm hesitant to rely upon it until it actually ships. Otherwise we'd need to be ready to keep reverting throbber changes until OMTA does actually ship. :/

And then there's bug 1008324, which seems to have argued against the new throbber in favor of something that's animated by CSS? Which direction does UX want to do?

Comment 30

[Stephen Horlander [:shorlander]]

(In reply to Justin Dolske [:Dolske] from comment #29)
> It sounds from that bug that platform _thinks_ OMTA is ready to ride the
> trains, but I'm hesitant to rely upon it until it actually ships. Otherwise
> we'd need to be ready to keep reverting throbber changes until OMTA does
> actually ship. :/
> 
> And then there's bug 1008324, which seems to have argued against the new
> throbber in favor of something that's animated by CSS? Which direction does
> UX want to do?

I thought we would have to convert to using CSS animations to take advantage of that. AIUI OMTA doesn't help with GIF or APNG.

I have been playing with using CSS animations on an image here: http://people.mozilla.org/~shorlander/mockups-interactive/spinner-test/spinner-01.html

One drawback is that using CSS animations on an image tends to make them a little blurry compared to a frame by frame animation.

Comment 31

[Stephen Horlander [:shorlander]]

(In reply to Justin Dolske [:Dolske] from comment #29)
> It sounds from that bug that platform _thinks_ OMTA is ready to ride the
> trains, but I'm hesitant to rely upon it until it actually ships. Otherwise
> we'd need to be ready to keep reverting throbber changes until OMTA does
> actually ship. :/
> 
> And then there's bug 1008324, which seems to have argued against the new
> throbber in favor of something that's animated by CSS? Which direction does
> UX want to do?

Does OMTA look sticky enough?

Comment 32

[Justin Dolske [:Dolske]]

I assume so at this point?