Open Bug 994954 Opened 6 years ago Updated 2 years ago

[UX] Improve the design of loading throbbers

Categories

(Firefox :: Theme, defect)

defect
Not set
Points:
8

Tracking

()

REOPENED

People

(Reporter: zfang, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: [ux])

Attachments

(1 file)

Improve the design of loading throbber
Flags: firefox-backlog+
Whiteboard: [ux] p=0
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Whiteboard: [ux] p=0 → [ux] p=8 s=it-32c-31a-30b.1 [qa-]
This uses some of Stephens new loading indicators. It also standardizes the graphics across all platforms.
Attachment #8415531 - Flags: review?(mak77)
Does this patch also resolve bug 750054 ?
(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.
Can you please make an effort to file bugs in the right component? Thanks.
Component: General → Theme
Summary: [UX] Improve the design of loading throbbers → Improve the design of loading throbbers
Hardware: x86 → All
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.
Attachment #8415531 - Flags: review?(mak77) → review+
(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.
Keywords: checkin-needed
https://hg.mozilla.org/integration/fx-team/rev/b77de3bb419e
Keywords: checkin-needed
Whiteboard: [ux] p=8 s=it-32c-31a-30b.1 [qa-] → [ux] p=8 s=it-32c-31a-30b.1 [qa-][fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/b77de3bb419e
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [ux] p=8 s=it-32c-31a-30b.1 [qa-][fixed-in-fx-team] → [ux] p=8 s=it-32c-31a-30b.1 [qa-]
Target Milestone: --- → Firefox 32
Status: RESOLVED → VERIFIED
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 :/
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
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.
(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).
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.
(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
(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.
Backed out based on the discussion in bug 1008324:

https://hg.mozilla.org/integration/fx-team/rev/c04b92e48540
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Whiteboard: [ux] p=8 s=it-32c-31a-30b.1 [qa-] → [ux] p=8 s=it-32c-31a-30b.2 [qa-]
(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.
Blocks: 750054
(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.
(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
Target Milestone: Firefox 32 → ---
Bug 958480 is a dupe of this I think.
Marco: we need to remove this from the current iteration because it's blocked by platform work.
Depends on: omtagif
Flags: needinfo?(mmucci)
Whiteboard: [ux] p=8 s=it-32c-31a-30b.2 [qa-] → p=8 [qa-]
Removed from Iteration.
Flags: needinfo?(mmucci)
> 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.
Depends on: 1009573
Does bug 759252 change the approach here ?
(In reply to Guillaume C. [:ge3k0s] from comment #25)
> Does bug 759252 change the approach here ?

Yes, we'll have to revisit the design.
Unassigning for now. Other work might require us to take a different approach here (especially the experiment in bug 990556).
Assignee: philipp → nobody
Points: --- → 8
QA Whiteboard: [qa-]
Whiteboard: p=8 [qa-]
Summary: Improve the design of loading throbbers → [UX] Improve the design of loading throbbers
Whiteboard: [ux]
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?
(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.
(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?
Flags: needinfo?(dolske)
I assume so at this point?
Flags: needinfo?(dolske)
You need to log in before you can comment on or make changes to this bug.