Offshoot of bug 602964 which has already become a bit loud. See original mockup: attachment 481900 [details] > 1: start event -> CCW rotation throbber > 2: DNS + request -> CW double rotation throbber (small inside large) > 3: receive data -> CW wide blue progress indicator circle > 4: completion -> favicon Our current implementation merges states 1 & 2 there. We have the CCW single circle throbber up until we receive data and switch to the wide blue CW throbber. See bug 602964 13 - 18. As to implementation issues. The question for this bug is what should be done with the state 1+2 combination: a) Leave it as is: proposed state 1 animation stays for states 1+2 b) Change the animation: change to proposed state 2 animation for states 1+2 c) Come up with a way to split these two up as initially proposed or otherwise The initial idea for the backwards (counter-clockwise) spinning throbber was that it was for an initial "nothing" state, after which point we'd have a forwards (clockwise) spinning "hollow" throbber for the request, then lastly the blue progress one once there's data coming down. In practice, there's usually not enough time between 1, 2 and 3 to have all those states shown. If (a) then just close this as WORKSFORME and we'll just keep what we have. If (b) then we may be agreeing that the rotation change under normal circumstances is distracting, at which point we could either switch to the proposed state 2 or just reverse the current state 1 spin direction. If (c) then my guess is we'd need to go with (b), a "hollow" CW throbber (initially proposed state 2), to start but then show the simple CCW throbber during wait times when there's no request and no data; i.e. use it as a stalled indicator somehow.

From bug 602964, comment 84 make the whole anymation spin clockwise no matter the step (1-3)

If we think of connecting to a web page as roughly analogous to making a telephone call, states 1 and 2 would be the part where the line is ringing. Now of course the telephone network is doing all sorts of complex things during that time period (or at least I assume it is, I'm not really familiar with how modern telephone networks work, but I would imagine it's probably pretty complicated.) But the user doesn't really care how the network operates, just that the call hasn't connected yet. Sometimes the feedback isn't this simple, for instance a phone ringing is in pretty stark contrast to the audible sound that modems make. Now of course we are talking about visual feedback instead of auditory, but I think we should just ring, and avoid making something that might resemble the graphical equivalent of a dial up modem connecting.

To continue that analogy, using a third state for a stalled indicator would be the equivalent of a busy signal. My suggestion is to keep the original proposed 1st and 2nd states mixed but possibly with a different animation, and have a different animation state for when it's waiting on the server and not receiving data. So, the ideal route would be: 1: connecting (CW hollow throbber) 2: downloading (CW blue throbber) 3: loaded (favicon) In the event that the client stops receiving and stalls loading for whatever reason for some minimum amount of time, the route would be: 1: connecting (CW hollow throbber) 2a: downloading (CW blue throbber) 2b: stalled (CCW simple throbber circle) (rinse/repeat for 2a/2b as needed) 3: loaded (favicon) The gist is to not show the downloading indicator if it's not downloading. It would also sync up rotation direction with progress; CW for progress, CCW for waiting. You could of course also still have 3 states but only two animations and use the same animation for both connecting and stalled states. For example, if I load up planet.mozilla.org and pull the plug half way through downloading, it still goes on with the spinning blue throbber even though clearly it's not loading anymore. I'm suggesting that the loading indicator indicate when it's not currently loading.

>1: connecting (CW hollow throbber) >2a: downloading (CW blue throbber) >2b: stalled (CCW simple throbber circle) Ok, I misunderstood the proposal (thought you wanted an additional state between 1 and 2, as opposed to between 2 and 3). If we transition too quickly between multiple states, I don't think users will be able to really understand the meaning of each. So I think the only way a "busy signal" might conceptually make sense is if we had a reasonably long timer between 2a and 2b, and only entered 2b when things a very stalled as opposed to just very momentarily stalled.

Yes exactly. I'm not sure what the minimum amount of time before switching to it would be. Three seconds of no activity sounds like a good starting point.

Taking. I'm going to be working up a state transition chart that illustrates what we want.

(In reply to comment #4) > Ok, I misunderstood the proposal (thought you wanted an additional state > between 1 and 2, as opposed to between 2 and 3). Ah, probably because in comment 0 for option (c) I first said "split these two up as initially proposed or otherwise" by which I meant split up the two states we have now either with another state before load start as Mike initially proposed or a new state after load start as I proposed in the (c) part at the end and better explained in comment 3. (seeing as Mike is now making a new mockup, I'll remove that part from the title to make things more clear) If we agree on the flow of states, the question becomes what we want for animations. An alternate proposal for the stalled indicator might be to not have any rotation (as that might be misconstrued with progress) and instead have a pulsating indicator, i.e. some sort of small circle that fades out to a larger circle. Either this or the CCW thin circle could work, though.

From my duplicate bug #614549 (somewhat reworded): I'm proposing that the connection throbber should change visually after the main document has been loaded (excluding referenced objects), so that the user can see when the browser is finished loading the main document and is now loading the objects that are referenced from the document. Suppose you have two pages loading in your browser, one which loads very slowly and one which loads quickly but references some object that loads very slowly. Looking at the connection throbber for each of these pages, you can not tell one case from the other, which is a shame, since the cases are quite different. A typical example is a newspaper site, which in itself may be fairly responsive, containing links to external advertising servers that may be slower or even not responding at all. But sometimes the newspaper site itself may be unusually slow or not responding, and it would be desirable if the connection throbber could differentiate between those cases. Continuing the newspaper site example, suppose you have the main page loaded in your browser and you refresh the page. If the throbber doesn't stop throbbing, is that because the main document is still loading, or is it some referenced object being slow to load? You cannot really tell. How to reproduce: 1) Load http://www.autark.se/slow_gif_page.html in one browser tab. This simulates the case where a referenced object loads slowly. 2) Load http://www.autark.se/slowpage.pl in another browser tab. This simulates the case when the main document loads slowly. 3) Compare the visual feedback from loading the two tabs. Actual outcome: There is no difference in the feedback. Desired outcome: There should be a clear difference in the feedback.

Have there been any suggestions outside of this bug for replacing the throbber with some less busy animation? Being on a slow network and having many tabs open can be quite an unpleasant experience looking at the tab bar, http://i.imgur.com/XgRcC.gif Being daily on a slow network during my commute, I see the spinning animations up to one hour straight, reading other loaded tabs while trying to not be bothered by the still loading tabs.

I am definitely not the droid this bug is looking for.