Navigation indication in nightlies
Benjamin Smedberg
doesn't bother me in itself, but it does cause me problems in some
particular cases:
1) When I click a link, it's really hard to figure out whether Firefox is
actually navigating to the next page. This is especially important when
submitting forms, since dual-submit can be bad.
There is a progress indicator in the URL bar, but that is really subtle and
really, I don't care *how much* the page is loaded: just that it's actually
loading something. The blue progress bar doesn't start showing anything
until data is received, which makes it almost useless for my case.
2) Per-tab progress info disappears when you switch to a tab. Non-current
tabs show progress indicators on top, but when you switch to them the
progress info goes away. This had me really confused for a while, until I
figured out that the blue progress strip was in the location bar. I really
don't like that info disappearing like that.
--BDS
Alexander Limi
<benj...@smedbergs.us>wrote:
> Newer nightly builds don't have any spinny page-loading indicators. This
> doesn't bother me in itself, but it does cause me problems in some
> particular cases:
>
> 1) When I click a link, it's really hard to figure out whether Firefox is
> actually navigating to the next page. This is especially important when
> submitting forms, since dual-submit can be bad.
>
> There is a progress indicator in the URL bar, but that is really subtle and
> really, I don't care *how much* the page is loaded: just that it's actually
> loading something. The blue progress bar doesn't start showing anything
> until data is received, which makes it almost useless for my case.
>
Yes, it's currently not visible enough. It's a known issue, and we're
working on making it better. There's also more data coming to this bar, like
the "Connecting" state.
> 2) Per-tab progress info disappears when you switch to a tab. Non-current
> tabs show progress indicators on top, but when you switch to them the
> progress info goes away. This had me really confused for a while, until I
> figured out that the blue progress strip was in the location bar. I really
> don't like that info disappearing like that.
>
Same issue, it's not obvious where the current progress is.
UX team agrees, and we're working on improving it. :)
--
Alexander Limi · Firefox UX Team · http://twitter.com/limi · http://limi.net
Nickolay Ponomarev
> On Tue, Sep 21, 2010 at 11:16 AM, Benjamin Smedberg
> <benj...@smedbergs.us>wrote:
>
> > Newer nightly builds don't have any spinny page-loading indicators. This
> > doesn't bother me in itself, but it does cause me problems in some
> > particular cases:
>
Could you point to the rationale behind removing the spinny indicators?
Nickolay
Alex Faaborg
>
There a few different things in play here:
-Show two states (trying, and trying and being successful). This can be
done with either design. with the spinney throbbers the flashing indicated
trying, and the pie filling indicated being successful. With the lines we
are planning on having a single glow bounce from one side to another to
indicate trying (visually conveys a notion of searching, or radar), and the
line filling indicating a notion of progress.
-Natural mapping to stop and reload. The goal here is to make it visually
clear that the stop button will stop the page loading. By visually grouping
both into the location bar, they have a clear mapping to each other.
-Appear light and fast. This is purely perceptual, but something that
travels a farther distance in the same amount of time has to travel faster.
By placing the progress bar in the rather long location bar, it ends up
traveling more distance and should convey speed. However, at the moment
this effect is being undermined by the fact that we only seem to be drawing
three or four frames for the entire animation, usually it is frozen at a
particular amount of progress. The thinness of the line is meant to make it
feel light and sleek.
-Provide an obvious indication of progress. As limi noted, we are trying to
make the lines easier to see (I think removing the track that they are in
will help with the contrast), but overall the goal is to make progress
obvious to the user. In general this is easier if we go outside of the
bounds of a 16x16 icon.
Alex
On Tue, Sep 21, 2010 at 11:58 AM, Nickolay Ponomarev <asqu...@gmail.com>wrote:
> On Tue, Sep 21, 2010 at 10:43 PM, Alexander Limi <li...@mozilla.com> wrote:
>
> > On Tue, Sep 21, 2010 at 11:16 AM, Benjamin Smedberg
> > <benj...@smedbergs.us>wrote:
> >
> > > Newer nightly builds don't have any spinny page-loading indicators.
> This
> > > doesn't bother me in itself, but it does cause me problems in some
> > > particular cases:
> >
>
> Could you point to the rationale behind removing the spinny indicators?
>
> Nickolay
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
Boris Zbarsky
> The thinness of the line is meant to make it feel light and sleek.
Fwiw, for me it mostly makes it completely invisible.... I look forward
to the more contrast solution, but I suspect it might still be
effectively invisible over here. :(
-Boris
Ron Hunter
redundant, but the visual jolt of it disappearing from the tab is
disconcerting, and requires refocusing ones attention to a different place.
Ron Hunter
>> Could you point to the rationale behind removing the spinny indicators?
>>
>
> There a few different things in play here:
>
> -Show two states (trying, and trying and being successful). This can be
> done with either design. with the spinney throbbers the flashing indicated
> trying, and the pie filling indicated being successful. With the lines we
> are planning on having a single glow bounce from one side to another to
> indicate trying (visually conveys a notion of searching, or radar), and the
> line filling indicating a notion of progress.
>
> -Natural mapping to stop and reload. The goal here is to make it visually
> clear that the stop button will stop the page loading. By visually grouping
> both into the location bar, they have a clear mapping to each other.
>
> -Appear light and fast. This is purely perceptual, but something that
> travels a farther distance in the same amount of time has to travel faster.
> By placing the progress bar in the rather long location bar, it ends up
> traveling more distance and should convey speed. However, at the moment
> this effect is being undermined by the fact that we only seem to be drawing
> three or four frames for the entire animation, usually it is frozen at a
> particular amount of progress. The thinness of the line is meant to make it
> feel light and sleek.
>
REALLY hard to see on my Netbook screen, and almost unnoticeable on my
20 LCD monitor. Maybe a bit more luminosity would help.
> -Provide an obvious indication of progress. As limi noted, we are trying to
> make the lines easier to see (I think removing the track that they are in
> will help with the contrast), but overall the goal is to make progress
> obvious to the user. In general this is easier if we go outside of the
> bounds of a 16x16 icon.
>
Definitely separate it from the bottom outline of the text area by at
least a pixel or two.
John Bird
I see the latest nightly has replaced the clock/pie loading with a small
copy of the blue progress bar on each tab. When one switches to that tab
the progress indicator for that tab is seen instead under the address bar.
Its good, I like it.
There is a bug -
If a website starts loading in the current tab, I switch away to another
tab, then the progress bar on that tab moves as the page loads. If I
switch back to that tab the progress bar on the address bar does not reflect
where the tab progress bar is now up to - not until it next moves. It does
not get repainted from the previous tabs progress value until then.
I am guessing there is a repaint on "tab progress event" but not on "Tab
switch event". (You will need both, as if the network connection drops the
progress bar will never be updated to the correct value and will show
information for another tab)
Thanks to a dialup connection I can see this happening very clearly in slow
motion!
John Bird
Shawn Wilsher
> If a website starts loading in the current tab, I switch away to another
> tab, then the progress bar on that tab moves as the page loads. If I
> switch back to that tab the progress bar on the address bar does not
> reflect where the tab progress bar is now up to - not until it next
> moves. It does not get repainted from the previous tabs progress value
> until then.
Cheers,
Shawn
wmarcello
> > dev-apps-firefox mailing list
> > dev-apps-fire...@lists.mozilla.org
> >https://lists.mozilla.org/listinfo/dev-apps-firefox
I must be the only one who loves the pie loader. :(
Judging from the current nightlies, I am not a fan at all of having
progress bars on each of the tabs. IMO the pie loader is far superior
for being able to decipher load progress at a glance, especially with
many background tabs loading. It also doesn't make sense to have a
progress bar on app tabs since the tabs are so narrow. The pie
indicator worked perfectly on those app tabs, so I don't understand
why we wouldn't want to be consistent. A full-height progress
indicator for the CURRENT tab in the URL bar is fine with me, but
those little thin progress bars on each background tab are terrible
IMO.
John Bird
>>Not being
able to track the activities during website access really leaves me with
a feeling of being in the dark. I don't like that at all.
What's wrong with putting that information where the link is being
displayed on mouseover?
John Bird
kamathln
took me a while to realize it was actually the desired effect.
I think it should be a bit thicker and go around the location bar. It
can keep changing its colors to indicate different states. Pulsing red
for looking up, saffron for connectiing, pulsing green for waiting,
and green for connecting and recieving.
A progress bar above the locationbar for "post data upload" status
would be nice if post data exceeds a limit.
Jean-Marc Desperrier
>> able to track the activities during website access really leaves me with
>> a feeling of being in the dark. I don't like that at all.
>> What's wrong with putting that information where the link is being
>> displayed on mouseover?
John Bird wrote:
> I second that idea, simple and consistent
What do you call "activities during website access", exactly ? Is it
something else than the load status ?
Currently the load status is represented by the progress bar, I believe
quite a few people don't like it as it is, it's small and it doesn't
integrate well with the elements.
My suggestion :
- For tabs : Wouldn't it better to use the whole surface of the tab to
show progress indication ?
=> Show the tab background initially as white and then, as the content
loads, it fills with it's normal grey color, from left to right.
- For URL : Here's a quite new idea.
Currently on move-over, the future URL appear on the right of the URL
bar, in grey, separated by an arrow.
Let *that* be the base for the load indicator !
=> After the click, invert the colors, the next URL on the right becomes
black on white, the current URL on the left becomes grey.
=> As the next page loads, the separation arrow slides to the left, it
progressively erases what the current URL was, until the part on the
right reaches the left end and becomes the new URL
Ron Hunter
No my computers, the background below the URLbar is blue, and the
progress indicator becomes completely lost in the background, rendering
it almost invisible. Perhaps let the user specify the color, or make it
large enough to be easily distinguished. I don't subscribe to the
'smaller looks faster' theory at all.
I REALLY miss the old text information.
Ron Hunter
Interesting idea. It would aptly indicate what is happening, but still
doesn't tell me anything about what is loading and from where. Perhaps
that is the intention, to cover the fact that sites like quantserv and
doubleclick, and others are being visited?
John Bird
showed it was over 75% loaded. So I clicked on it.
Now the progress bar is on the address bar and showed 0% loaded (ie just 1-2
pixels wide). I clicked back to another tab, and sure enough it (Site A)
was now 75% loaded again on the tab.
Is this like the "bug" I mentioned earlier, where the progress bar only
updates when it alters value, not when the user changes tabs. It is quite
possible no more of the tab loaded while I was doing all this. Joys of
dial-up.
John Bird
Jean-Marc Desperrier
> Perhaps that is the intention, to cover the fact that sites like
> quantserv and doubleclick, and others are being visited?
Well ... yes. To the average users, it means nothing and they have never
actually noticed those string that temporarily appear in the status bar
during the load. For advanced users, it's not very convenient and
various web developer tools will give them a much more accurate result.
Still it could be done within the fram of my previous suggestion.
=> After the click, invert the colors, the next URL on the right becomes
black on white, the current URL on the left becomes grey.
=> the left part is replaced by "resolving" when resolving the DNS name
=> then replace by "connecting" when opening the IP connexion
=> then replace by "loading" when starting to load the page
=> then replace by "loading: doubleclick.com" when starting to load the
advertisements.
Ron Hunter
Great idea! Now to just convince someone to DO that, rather than an
almost invisible blue line over a blue background just below the
location bar/URL bar (or whatever they are calling it these days).
John Bird
the current status bar.
As I have mentioned before, on a slow site timing out (eg bugzilla) the web
console gives no actual hint what went wrong. The status bar actually says
more ie "finding bugzilla.mozilla.org" or something like that followed by
"waiting for bugzilla.mozilla.org" . When it times out I have at least a
hint it might be a DNS issue or a slow site depending on which message was
last.
Nothing lost by putting this information somewhere briefly in the UI is my
vote.
>From: Jean-Marc Desperrier
>Well ... yes. To the average users, it means nothing and they have never
actually noticed those string that temporarily appear in the status bar
during the load. For advanced users, it's not very convenient and
various web developer tools will give them a much more accurate result.
John Bird
John Bird
true specifically changes the sense of the CTRL+TAB keys, to a recently
viewed order. Its a terrific addition that lots like me use all the time.
In case you did not know, the sequential order of switching tabs is still
there - CTRL+PageUp and CTRL+PageDown (Windows)
I agree it was inconvenient to relearn what CTRL+Tab does, but the trade off
is that having two ways to switch tabs - sequentially or chronologically is
worth it.
re ps - The list all tabs works for me. It lists all tabs in the current
group.
John Bird
> Please, add a preference for that, I'm really tired that ctrl-tab
tabs' activating order is not sequential. I use
browser.ctrlTab.previews = true and it makes using ctrl-tab absolutely
inconvenient with the current order based on the recency of viewed
tabs.
p.s.: and please, fix the "List all tabs" button which got broken
recently and it isn't in the list of the beta-blockers bugs in
Bugzilla.
Jean-Marc Desperrier
> I am interested in finding out which tools are in fact more informative
> the web console gives no actual hint what went wrong
OK. I was replying to, and therefore much more focused on, the point of
showing from which external sites the resources are loaded.
That's where the web console, and page info/media tab, are much more
useful than the current status bar. (BTW, there's no way to access page
info from the Firefox button ? Page info is something I for one use
quite frequently). Also, the network tab of Firebug can tell you in real
time where your download is stuck.
And in my answer, I did suggest to put some info about
resolving/connecting/loading/loading:external_xxx in the URL bar, that
could reply to your concern.
I'm interested to know if people think it's worth pursuing my "no
progress bar"/"sliding separation arrow+url text update" suggestion by
submitting some sketch, opening a bug.
EE
a message that the browser is "waiting for" some server that is taking a
long time. You then know exactly what is causing the delay, and it was
easy to get that information. All you had to do was use your eyes on
the browser window.
Kirk M
I've been following this thread for awhile now and find myself needing
to comment.
As an advanced user of Windows and Linux distros and as someone who
has always helped the so called "average user" over the years I have
found that the loading status of any website that is currently
displayed at the far left of the Status bar is indeed used by average
and advanced users alike, especially in the case of the average user
that makes use of the popular social sites. A good example (and hardly
the only one) is Facebook users who dabble in games such as Super Poke
Pets, Farmville and the like. I found it rather surprising that
researching the Facebook posts and game related forums, how much these
players and just regular Facebook users depend on the Status bar
loading updates as they get very concerned as to what is holding up
any particular page load. The updates seen on the status bar tells
what is causing the delay.
It seems the viewpoint of the "average"e user here, their capabilities
and needs, is significantly outdated. Today's avaerage user is often
very savvy indeed and shouldn't be underestimated.
As far as the advanced user is concerned, I've found that the overall
point is too get things done as efficiently and quickly as possible
and to use the best tool available to accomplish this. Why use a
backhoe to dig a 2 foot deep hole for 6" round post when a shovel will
do? If I just want to make a quick note what might be holding up a
page load and nothing more, which happens quite often, I don't need a
full powered web console or Firebug to accomplish this. I want to
make a quick note, not analyze the entire website.
My point in all this is simple. These page loading updates as seen in
the current status bar should not be taken away. Their presence is too
valuable to too many users. It doesn't matter where or how these page
loading updates end up being displayed in 4.0, just as long as the
user can view them if they wish.
Mike Shaver
That's very interesting information, thanks for sharing it. Could you share
some links to such threads? I'd be quite interested in learning more about
how that data is used by those sorts of users.
Thanks again,
Mike
Kirk M
Mike,
Would that I could. The problem with sharing links is that the
majority of these forums/games/social sites require having an account
such as the case of Facebook itself and the related popular 3rd party
games like those I mentioned. Even in the case of Slide (Super Poke
Pets) and Zynga (Farmville) that have their own websites, you still
require an account in order to access these forums.
The other reason of course is I can't possible refer you to a personal/
professional conversation I had with a person or a client that
happened sometime in the past. This is why I've held back posting a
comment on this particular "mozilla.dev.apps.firefox" thread in that
I'm unable to provide links and such to back up my statement. It's
extremely frustrating to say the least.
In short, when the replacement of the current status bar was first
being discussed and the fate of the page loading status updates being
up in the air, the last few years of ongoing research came immediately
to mind and it actually surprised me how many times I had heard/read
or about how these "average users" mentioned using these page loading
status updates in various ways and for various reasons, no matter what
browser they were using. Unfortunately, at present, I only have my
word to give that what I stated in my previous comment is true. It's
also getting rather late in the Firefox 4.0 schedule to be taking
polls and such so my only suggestion at this point is if the page
loading status updates do get removed at least leave the ability for a
possible future add-on that will turn them back on.
custom.firefox.lady
"Kirk M" <tbep...@gmail.com> wrote in message
<snip> It's
> also getting rather late in the Firefox 4.0 schedule to be taking
> polls and such so my only suggestion at this point is if the page
> loading status updates do get removed at least leave the ability for a
> possible future add-on that will turn them back on.
FWIW, There already is at least one:
https://addons.mozilla.org/en-US/firefox/addon/235283/
David McRitchie
"Mike Shaver" wrote in
> Kirk wrote:,
>
> That's very interesting information, thanks for sharing it. Could you share
> some links to such threads? I'd be quite interested in learning more about
> how that data is used by those sorts of users.
Although Kirk responded to your request, he did say at the beginning...
"As an advanced user of Windows and Linux distros and as someone who
has always helped the so called "average user" over the years I have
found..." does that even imply that there are threads.
Asa Dotzler
Did you read the sentences that follow that? He went on to say:
> I found it rather surprising that
> researching the Facebook posts and game related forums, how much these
> players and just regular Facebook users depend on the Status bar
> loading updates as they get very concerned as to what is holding up
> any particular page load.
I think the "researching the Facebook posts and game related forums,"
implies that there are threads.
- A
Chris Ilias
> Newer nightly builds don't have any spinny page-loading indicators. This
> doesn't bother me in itself, but it does cause me problems in some
> particular cases:
>
> is actually navigating to the next page. This is especially important
> when submitting forms, since dual-submit can be bad.
>
> There is a progress indicator in the URL bar, but that is really subtle
> and really, I don't care *how much* the page is loaded: just that it's
> actually loading something. The blue progress bar doesn't start showing
> anything until data is received, which makes it almost useless for my case.
>
> 2) Per-tab progress info disappears when you switch to a tab.
> Non-current tabs show progress indicators on top, but when you switch to
> them the progress info goes away. This had me really confused for a
> while, until I figured out that the blue progress strip was in the
> location bar. I really don't like that info disappearing like that.
Was there as resolution to this, or a bug filed?
Ron Hunter
Current nightlies seem to have settled on a rotating activity indicator.
It doesn't give much information about what is happening, but does
indicate that some kind of activity is taking place, and the direction
of the rotation changes at some point. Now if someone would just tell
us what the rotation direction, and the color changes MEAN.....
It is better, in my opinion, than the tiny thin blue line in the URL
bar. May not be the best solution, yet.
Boris Zbarsky
> Now if someone would just tell us
> what the rotation direction, and the color changes MEAN.....
CCW and gray: we have sent the request and are waiting for the server to
respond.
CW and blue: we have started getting data back from the server and are
working on rendering the page.
-Boris
Philip Chee
Amazingly intuitive!
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Ron Hunter
Great! Thanks. I had assumed (but you know about that) that. Good to
know my thoughts are in parallel with the devs. for a change.
John Bird
what they mean too. Turning from grey to blue once Firefox is doing
something is a nice metaphor, technically useful, and nice to look at. Good
design: minimal, informative and pretty.
Other versions were less ideal:
-The progress bars - never got going at the beginning, so there was no
information at the start about connecting etc. Hard to see.
-The older pie/clock throbber was actually quite useful. It was also
butt-ugly (thats a technical term).
The only thing missing is some progress indicators, how about either a
progress bar moving over the whole face of the tab (like on the taskbar
tab), or the middle of the spinning wheel filling in with blue like the old
pie throbber, but coloured this time.
I know Mike B said earlier that Firefox really guesses at it progresses
through a page load, (his phrase was "we lie") rather than having a real
measure but I would like a rough Firefox measure rather than my own guess!
John Bird
broccauley
on some modern "web 2.0" AJAX-heavy sites where they often use the status
bar to relay custom information on the status of the XMLHTTPRequest
operation. e.g. on some comment forums.
Stanimir Stamenkov
Modern sites should not rely on the status-bar to convey important
information. The status-bar is specific client UI detail web
applications should not have access to. I don't allow content
scripts to write to the status bar as it gets abused too much, for
example:
--
Stanimir