Mike Beltzner [:beltzner, not reading bugmail] Reporter
	Description • 19 years ago

Visual indication of page load progress is currently split across two locations in the browser. The throbber indicates that some type of network loading is going on, and the horizontal progress bar gives a SWAG of the overall progress of that load. 
To get a full picture, a user must look in both places. Additionally, there is no equivalent of the horizontal progress meter on background pages.

One way of combining both the throbber and the progress meter would be to use a pie chart inside the throbber ring that progressively fills in until the load is complete.

Art to follow.

	Mike Beltzner [:beltzner, not reading bugmail] Reporter
	Comment 1 • 19 years ago

Picture something like this, inside the throbber ring.

	Mike Beltzner [:beltzner, not reading bugmail] Reporter
	Comment 2 • 19 years ago

Also, might be useful to take the code in attachment 145734 [details] [diff] [review] which makes the progress meter move in 10% increments, port that over, and use it to move the pie chart.

	Gary van der Merwe
	Comment 3 • 18 years ago

Possible image

	Gary van der Merwe
	Comment 4 • 18 years ago

How the previous attachment will look with the throber on top and against a windows xp toolbar background color. (I found it difficult to choose a color to fill the pie with)

	Simon Bünzli
	Comment 5 • 18 years ago

Add this code to your userChrome.js (see [1]) to see the a live combination of the above attachment and the current (small) throbber.

After some experimenting I have to conclude that I prefer a Safari style progress bar (as implemented by [2]). Has this ever been considered as an alternative to the suggestion of this bug?

[1] http://forums.mozillazine.org/viewtopic.php?t=397735
[2] http://forums.mozillazine.org/viewtopic.php?t=370248

	Ben Goodger (use ben at mozilla dot org for email)
	Comment 6 • 18 years ago

Be careful with PLT here.

The code in the browser that does stuff during page load is very heavily optimized to avoid doing stuff in js where possible. We need to watch the tinderboxen closely when checking in something like this.

	Bryan
	Comment 7 • 18 years ago

Can we give the throbber some life with a little bit of color?

~B

	Bryan
	Comment 8 • 18 years ago

(In reply to comment #4)
> Created an attachment (id=219216) [edit]
> How the previous attachment will look
> 
> How the previous attachment will look with the throber on top and against a
> windows xp toolbar background color. (I found it difficult to choose a color to
> fill the pie with)

Please let's not keep both.  It looks messed up IMO.

~B

	Andrés Delfino
	Comment 9 • 17 years ago

Could Firefox please include this in 3.0?

A user shouldn't need to understand the difference between the progress bar and the throbber.

Plus, the current throbbe is kind of ugly, polishing it would be polishing an always seen (if the user does not remove it) part of the Firefox UI.

Both usability and aesthetics would be a win here.

	Mike Beltzner [:beltzner, not reading bugmail] Reporter
	Comment 10 • 17 years ago

There are other bugs on improving the throbber for Firefox 3, some of which also include ideas for showing progress in addition to activity.

This does not block Firefox 3.

	Dão Gottwald [:dao] Assignee
	Comment 12 • 15 years ago

Tryserver build with that patch:
http://build.mozilla.org/tryserver-builds/dgottwald@mozilla.com-try-9da5210166f0

Beltzner's initial response: bug 437829 comment 48

	Dão Gottwald [:dao] Assignee
	Comment 13 • 15 years ago

this is an attempt to address the tinderbox log use case from bug 437829 comment 48 by making the initial state pulse (with less frames and less fps than the current throbbers, so this should still be cheaper)

	Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)
	Comment 14 • 15 years ago

This looks ok, though I don't like the use of -moz-img-region; we still don't have good support for that on the gfx side, and it does a slow copy of the image sometimes.  Another issue is that the setting of the attribute seems fragile, especially with the floating point math.  I'd much prefer something like:

var states = [ "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "10" ];
var state = states[Math.floor(states.length * progressPercentage)];

or similar.  That way the numbers aren't magic, and we can add/remove animation states as necessary.

	Dão Gottwald [:dao] Assignee
	Comment 15 • 15 years ago

(In reply to comment #14)
> This looks ok, though I don't like the use of -moz-img-region; we still don't
> have good support for that on the gfx side, and it does a slow copy of the
> image sometimes.

But again, we'll only change it a few times. The alternative would be to use separate images, which doesn't seem more efficient to me.

	Justin Dolske [:Dolske]
	Comment 17 • 15 years ago

(In reply to comment #13)

> this is an attempt to address the tinderbox log use case from bug 437829
> comment 48 by making the initial state pulse (with less frames and less fps
> than the current throbbers, so this should still be cheaper)

The problem is more general than that, since the load could stall at any point. So I'd think all the progress states should have some sort of animation to indicate that things are still waiting and not locked up.

One approach might be use a simple pie-chart with (w/o animation), and if there's no progress for N seconds replace it or overlay it with some animated indicator. Maybe just stick a throbbing circle underneath, so that the remaining-wedge appears to throb? [That has the nice side effect of making the degree of throb proportional to the amount remaining to load.]

Also, are we sure we want to replace the OS X throbber? That's a fairly standard icon/animation for the platform, so we're losing some OS native feel by not using it.

	Justin Dolske [:Dolske]
	Comment 18 • 15 years ago

(In reply to comment #17)
> Maybe just stick a throbbing circle underneath, so that the
> remaining-wedge appears to throb?

...If the wedge was transparent, which it's not in your current progress.png.

	Dão Gottwald [:dao] Assignee
	Comment 19 • 15 years ago

ok, this makes all states pulse. I've also fixed a bug in the tabbrowser code.

	Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)
	Comment 20 • 15 years ago

Comment on attachment 399645 [details] [diff] [review]
patch v4

Let's try it on m-c and see how it feels?

	Dão Gottwald [:dao] Assignee
	Comment 21 • 15 years ago

I've been thinking about dolske's idea to animate only if there was no progress for some time. This makes sense --- there's no need to pulse if the chart is moving anyway, and it has the nice side effect of using a static PNG in most cases, which should bring back the performance win I was originally aiming for.

I'm not quite happy with the graphics, probably needs attention from shorlander at some point. I think it's good enough to land on mozilla-central in the meantime, though.

	Dão Gottwald [:dao] Assignee
	Comment 22 • 15 years ago

> I've been thinking about dolske's idea to animate only if there was no progress
> for some time. This makes sense --- there's no need to pulse if the chart is
> moving anyway,

except that I didn't implement it correctly.

I've started a new tryserver build.

	Dão Gottwald [:dao] Assignee
	Comment 23 • 15 years ago

http://build.mozilla.org/tryserver-builds/dgottwald@mozilla.com-try-87575439a082

	Grey Nicholson (they/them)
	Comment 24 • 15 years ago

(In reply to comment #23)
> http://build.mozilla.org/tryserver-builds/dgottwald@mozilla.com-try-87575439a082

I've run this build for several days (on Ubuntu karmic) with no obvious problems. Certainly seems good enough for mozilla-central.

	Mike Beltzner [:beltzner, not reading bugmail] Reporter
	Comment 25 • 15 years ago

I think we should try this on mozilla-central to shake out any further bugs; cc'ing Alex and Alex and Boriss and Stephen who might have ideas on the visualization.

What I'm giving ui-r+ to here is the idea of a throbber that shows progress; the UX folks reserve the right to tweak this as needed! :)

	Dão Gottwald [:dao] Assignee
	Comment 26 • 15 years ago

http://hg.mozilla.org/mozilla-central/rev/7a75cd337fda

(In reply to comment #25)
> I think we should try this on mozilla-central to shake out any further bugs;
> cc'ing Alex and Alex and Boriss and Stephen who might have ideas on the
> visualization.

Please file new bugs on visualization ideas as well as actual bugs.

	Bobby Holley (:bholley)
	Comment 27 • 15 years ago

Looks like this had a pretty serious (41%) Ts Shutdown impact on leopard. Thoughts?

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 28 • 15 years ago

I think the progress bar attached to each tab shown in some of the 3.7 and 4 mockups might feel a little faster and provide more obvious visual feedback.

In terms of this design, perhaps hollow out the center, kind of like the awesome bar throbber but without the breaks?  Although this might end up looking too much like Chrome.

The pie chart itself just isn't feeling right visually for me, for some reason it feels dated, or perhaps kind of powerpoint presentation-ish, hard to really describe.

I'm sure Stephen will have plenty of ideas as well :)

	James May [:fowl2]
	Comment 29 • 15 years ago

Perhaps it could start as a point and "grow" instead of fill around?

	Dão Gottwald [:dao] Assignee
	Comment 30 • 15 years ago

These are the relevant files:
http://hg.mozilla.org/mozilla-central/raw-file/7a75cd337fda/browser/themes/winstripe/browser/tabbrowser/progress.png
http://hg.mozilla.org/mozilla-central/raw-file/7a75cd337fda/browser/themes/winstripe/browser/tabbrowser/progress-pulsing.png

Same for Mac and Linux. You should definitely play with them and see if you can come up with something better. File new bugs for concrete suggestions.

(In reply to comment #27)
> Looks like this had a pretty serious (41%) Ts Shutdown impact on leopard.
> Thoughts?

I'm going to back this out temporarily to see if that fixes the regression.

	Markus Stange [:mstange]
	Comment 31 • 15 years ago

The shutdown regression of this fix is caused by the same phenomenon as the shutdown regression I'm fighting in bug 517804: Unreasonable amounts of time are spent during painting. I'm tracking my investigation in bug 519893.

	Dão Gottwald [:dao] Assignee
	Comment 32 • 15 years ago

Ok, thanks for letting me know.

	Ashley Bischoff (blog at handcoding.com)
	Comment 33 • 15 years ago

(In reply to comment #28)
> The pie chart itself just isn't feeling right visually for me, for some reason
> it feels dated, or perhaps kind of powerpoint presentation-ish, hard to really
> describe.

From my perspective, the pie-chart seems to quickly get to 1/8 full, wait, race ahead to 7/8 full, and then complete.

Alex, as you postulated in bug 513826 (and in particular that post from codinghorror [*]), perhaps the perceived performance may be more satisfying if the progress were more consistent in its completion rate?

[*] http://www.codinghorror.com/blog/archives/001058.html

	hhh
	Comment 34 • 15 years ago

This bug was filed under branch, but has only been landed on trunk, correct?

	Bryan
	Comment 35 • 15 years ago

I'd also add that at times the lines defining the edges of the "pie" are jagged and not clean.  Take a look at the 25 mark (what would be 25 on a clock).

~B

	Dão Gottwald [:dao] Assignee
	Comment 36 • 15 years ago

attaching this here so that I can remove it from my desktop

	Siddhartha Dugar [:sdrocking]
	Comment 37 • 14 years ago

Please release this as an add-on, when you are free.