Status bar, again -- and beyond
Brendan Eich
Firefox UI changed significantly from all past releases, resulting in obvious user complaints:
http://support.mozilla.com/en-US/questions?sort=requested
The status bar removal was late in the beta cycle (we were trying to release last year at the time of the change, which meant within a month or no more than two due to the December holidays).
This change requires retraining. See Dao's point in the next-to-last paragraph of https://bugzilla.mozilla.org/show_bug.cgi?id=541656#c7 ("This could ... train users to eventually ignore the location bar more than they do already").
The subsequent drop-off in input and sumo complaints could be evidence of retraining, or of users giving up on complaining, or switching browsers, or some combination. We don't know.
We do know some obvious things. The other major browsers put certain progress status and hovered link status on the lower left, following the ancient Mosaic/Netscape design, so anyone who uses multiple browsers will feel some pain (I have; I use Chrome and Firefox). Users we hope to convert (back) will, too. Same goes for Firefox users accustomed to the status bar from Phoenix onward through Firefox 3.6.
On the plus side, one reason for getting rid of the status bar seems to have been liberating vertical real estate for the content area, or for add-ons. Unfortunately the Find bar often sticks around and takes up a whack of vertical space, and below it I now see the add-ons bar, which is both empty and always present (present because I have add-ons installed, empty because I have no jetpacks?). So there was no vertical space win AFAICT.
Limi mentioned to me in person a more complete design that would have made the add-ons bar better, or collapsed, or something, but this was not realized due to release time constraints. I've read bug 574688 (which is a nightmare we do not want to re-dream here) and the DAF newsgroup thread, FWIW (and: yikes).
This reminds me again of the Library design for Firefox 3 (see bug 400495), which *even though it was not realized*, was used to rationalize piecewise removal of longstanding UI (Clear List on the Download Manager dialog -- still with us even now).
The other echo is the "retrain users" phrase. In the case of 400495, it was to train users who managed downloads as a fairly short, somewhat curated "Inbox", and then moved downloaded files elsewhere using OS file management UI or cmd line gestures ending with a "Clear List" click, to instead use the Download Manager's search box. That retraining goal missed some obvious problems in the incomplete implementation of the Library design.
When we don't get a coherent design fully implemented, we need to back off to the last release's design, or at least to some coherent shippable state.
When we don't get a coherent design together by late betas, we can't use the full design (which is unproven) to justify interim user experience regressions or to dismiss user complaints.
We have neither backed off nor moved decisively forward to victory.
Vlad's point in https://bugzilla.mozilla.org/show_bug.cgi?id=628654#c70 about XHR popping up the revived status -- as in progress notification -- bar is a case in point. We're neither fish (fx3) nor fowl (fx4 as designed in full, at least as told to me). Chrome does not pop up its status bar all the time due to XHR, so perhaps this can be fixed.
But it's late.
That it is very late now does not necessarily mean we should stick with what was in b10. If it's too late to be fixing an incompletely-implemented design now, it was too late to be removing the status bar last October and replacing it with an incompletely-implemented design.
We might even be better off changing nothing from Firefox 3.6. But going back can be hard too, with all the other changes.
Anyway, it's not obviously too late to do something strictly better. That, we should all aspire to do. But what?
To decide, we might try to state our premises and argue forward from them to some kind of agreement. If we can't agree, someone is going to have to pick the premises and arguments to determine the design. This sounds hard.
Before we even try reasoning together, I have a question:
Why are we trying to "retrain" our users according to novel (in the history of browsers) theories about the URL bar, or intuitions or heat-maps that could be interpreted to suggest overloading it further?
I don't know, but any retraining that engenders the user complaints we heard is hard and risky, and it should be imposed only for a big win. If the win were big enough, then I think that users would gladly retrain. (Chrome's Omnibox, ignoring the not-ignorable privacy problem, is having this effect on me: I am no longer as careful in Firefox about cmd-K vs. cmd-L as I once was.)
Was the retraining due to status bar removal worthwhile? Opinions vary, as some have testified in bug 628654 and in bug 541656. Some have retrained and now like at least the hovered link URL on the upper right. Others are not happy at all. In any event, it wasn't a big, obvious win. It's still controversial.
As with bug 400495 and many other bugs (going back to Netscape/AOL days when Mitchell went to bat for Ben Goodger on Mozilla-1.0/Netscape-6.2-era UI changes, to her detriment within the company), I'm getting mail about this and getting dragged in as would-be mozilla.org buck-stopper. But no one, least of all me, wants *me* deciding what to do here.
So I would appreciate hearing from the relevant peers. Not just in reply to any points I've made above, but with ideas for the future.
As we move to a faster release cycle, it'll be critical to get awesome designs implemented quickly and completely, with user testing and positive feedback.
This could be used to justify sticking with the status bar removal for Firefox 4, a la b10, and restoring some kind of status bar in Firefox 5, but doing that ignores the negative user feedback, and anyway it is just kicking the can down the road a few months, for a big fight next time if the principals do not agree on the right plan.
So we need to come to agreement now.
/be
Dao
> Vlad's point in https://bugzilla.mozilla.org/show_bug.cgi?id=628654#c70 about XHR popping up the revived status -- as in progress notification -- bar is a case in point. We're neither fish (fx3) nor fowl (fx4 as designed in full, at least as told to me). Chrome does not pop up its status bar all the time due to XHR, so perhaps this can be fixed.
The patch in bug 629969 roughly addresses this.
I think while the goal of cutting down the UI was noble, the design
process and how we dealt with feedback(*) was broken, so I won't
complain about the late change of course. Maybe bug 603777 (status
messages in the location bar) would have prevented most of the outcry,
but I still would have had a hard time defending the Firefox 4 UI
against IE 9's and Chrome's. This prospect troubled me quite a bit in
the last few months.
*: The "Status-4-Evar" extension partly absorbed the shock during the
beta phase, but that's an awful solution.
sabret00the
I find it ludicrous that in this current culture where there are mass comparisons once again between browsers, we'd adopt the behavioural models of Chrome. Are we saying Chrome is a better browser than Mozilla? Is the UX Team there more capable or better skilled than ours? If that's not the belief, why are we following their UX Design over our own?
And how is it possible that we've struggled so much to implement features properly. A lot of shortcuts have been taken, far too many and we're talking about shorter release cycles and version bumping in another bid to keep up with Chrome. Mozilla are known by users as a company that takes it time and releases a complete fully working product in Firefox. How did we deviate so far from that.
We somehow managed to build a lot of expectation for Firefox 4, perhaps more than we could manage. But things like the papercuts series were important and should've remained so, it was direct user feedback on what feels broken and what is required to win users back, so where is the success rate? Of all the papercut bugs filed, why is the percentage of fixed bugs so low?
The Status Bar change was unorthodox and ultimately geared towards a small userbase (Netbook users), but some decisions ultimately felt right. Was there things we could've done to make the transition easier? of course. We could've pref'd the link target placement for example. The status message is another thing we could've been more creative with. But ultimately I am wholly opposed to mimicking Chrome. Using bug 628654 to build support for bug 541656 and then claiming bug 603594 fixed is beyond wrong. A much more logical decision would've been to use Firefox 4 as the point in which we phase out tab-less browsing. I know it's long annoyed me when I accidentally create a new tab in popup.
I was in full support of the goals we had set for this browser, they were clear. Ultimately Firefox 4 was UI redesign, speed parity and fixing the long standing user frustrations/desires (papercuts). Why these goals changed is beyond me.
Robert Kaiser
> Firefox UI changed significantly from all past releases, resulting in obvious user complaints
I've also seen another significant uptick of people heralding
SeaMonkey's UI for being conservative - a lot of time with people
comparing against the many changes in FF4 that need a lot of relearning
for them. With a SeaMonkey hat on, I like that, of course - but putting
a Firefox hat on, this sounds somewhat alerting.
Now I know, all those redesigns have well-meant and well-argued goals,
and I'm fully for taking steps into the future, improving user
experience overall and fitting today's form factors (we need to live
with most screens being way wider than high these days, the 3:4 or 4:5
dimensions are becoming a minority very fast) - in fact, I think we're
far from the ideal state and need to innovate and experiment even more
in the post-FF4 game.
I'm not sure what's best at this state, as we are _very_ late in the FF4
cycle now and actually have wanted to be in RC by now, but maybe we need
to sit back for an hour or two and think about if it's right to go in RC
with what we have at this moment or can or even need to augment it in
some ways that make those more comfortable who have a hard time living
with the current state of FF4 UI.
And still, I feel bad about every day we delay this FF4 release, as we
are shipping such a big load of awesomeness along with the changes
discussed here that every single delay hurts, esp. as the competition
isn't sleeping.
Unfortunately, I don't have solutions, but perhaps we can come up with
some here.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
Jeremy Morton
[...]
> On the plus side, one reason for getting rid of the status bar seems to have been liberating vertical real estate for the content area, or for add-ons. Unfortunately the Find bar often sticks around and takes up a whack of vertical space
I know I'm extremely late in the day to this discussion, but I'll say
this. Why are some people so obsessed with so-called 'real estate' for
a web page? It sounds like you're talking about a mobile browser.
Fine, I can see the benefit in liberating a breathtaking 23px of
vertical space for a small mobile screen, but I have a 1280x1024
resolution. Even on 800x600, 23px isn't much. This has to be weighed
against the functionality that this 'ancient design' (doesn't
necessarily mean it's bad) provides. Many users think it provides very
useful functionality. It seems to me that this argument is being swept
aside in the apparently dogmatic obsession with web page 'real estate'.
I ask that you at least bear in mind that some of use don't mind a
chunk of our real estate being taken up with browser functionality; and,
in fact, want it to be.
--
Best regards,
Jeremy Morton (Jez)
speedevil
Ease of reading.
A statusbar, in a predictable, known position, not overlaid over any content in a distracting manner, can be much easier to read, and less distracting than a balloon appearing over content.
Ron Hunter
Status-bar-4Evar with the release? This will give everyone a simple option.
EE
much space by replacing it with something even bigger does not sound
like logic to me. It seems more like revenge. "To heck with you. Just
for that, we'll replace it with something that takes up even more space."
EE
being installed, that would be fantastic. Changing it for the sake of
eye candy is not important. You cannot please everyone with a new
appearance anyway. What I think is gorgeous, someone else thinks is ugly.
Alex Faaborg
I would appreciate hearing from the relevant peers. Not just in reply to any
> points I've made above, but with ideas for the future.
>
Sure thing. You made a considerable number of points, so I'm going to group
my response into three sections: what I think we should do with the status
bar in Firefox 4 (this is of course the immediately actionable part),
exactly what our plan was and how we got into the current state (at this
point this is kind of academic), and how we can streamline and improve our
workflow in the future.
== What I think we should quickly do for Firefox 4 ==
The link hover area in the location bar currently does not display loading
status for third party servers, which the status bar used to display. The
reason for this is that the information often appears so quickly that users
have no chance of actually reading it, and placing this flashing text in a
more dominate place in the UI (along with a higher level of contrast since
it is on a white background), makes the interface as a whole feel rather
spastic and technical, like a robot that shouts code at you so quickly that
you can't understand it.
The best way to very quickly reintroduce loading status for third party
servers (without any other change to the speed of messages being relayed),
is to move it out into the user's low resolution peripheral version (similar
to previous versions of Firefox, Chrome, and IE9). Since we no longer have
a bar taking up vertical screen space, we can use a tooltip (IE9).
Alternatively, if we were to re-introduce the loading status for third party
servers into the location bar, I believe this would introduce more
complaints than it addressed. Additionally, the subset of users who rely on
third party server loading status will expect it to appear in the same
location as link hover, so it's important that these two pieces of
information appear in the same place no matter what we do.
== What our plan was and how we got into the current state ==
We weren't intending to remove loading status for third party servers
entirely, but simply to introduce a timer so that messages were only
displayed in extreme cases where the user would actually wonder why part of
their page hadn't loaded (or why the throbber was still active even though
it seems like the entire page has loaded). As previously noted on
dev.apps.firefox, even mainstream Farmville users will occasionally rely on
third party server loading status in more extreme cases. Introducing a
short timer would significantly improve the signal to noise ratio, and would
also reduce the extent to which Firefox came off as a jargony spastic URL
shouting robot :)
This change requires retraining.
>
This is a good question, why did we move the link hover (and delayed
loading) information away from the location that it has previously been,
knowing that this would both require a change to existing eye muscle memory,
and also make it harder for users to transition between products currently
in the market place? Our objectives were:
1) Increase how self describing the UI is
Placing the link target to the right of the current location with the >
symbol very directly communicates "you are about to travel from A > B", it
also even bootstraps an understanding of "A is where you currently are" (in
case you haven't picked that part up yet). Someone who is intelligent but
uninformed can understand the purpose of the location bar very quickly if it
describes navigation and current location in a simple LTR (or RTL) A>B
fashion. Similarly, placing the third party server loading status directly
next to the stop button visually communicates "this is what you are
literally going to stop." If we were building a browser in isolation these
would all be 100% logical decisions.
2) Increase the percent of mainstream users who take advantage of these
features
But we aren't building a browser in isolation, there are other browsers in
the market that place this information in other places, and older versions
of our product that do the same. There's a cost, and input.mozilla.com can
now show this cost to us. But what input.mozilla.com can't show us (and
neither can Test Pilot unfortunately), is the number of users who don't
really know what the Location bar is (aside from some jargony text they
don't understand), and also haven't really paid any attention to the status
bar before. These users didn't read the manual, and aren't curious enough
to ask someone else. These users aren't complaining, and they probably
don't know what beta means. It's mainstream dark matter, and it's what we
spend most of our time thinking about.
The reason why we are ok with landing the A>B design (even though we didn't
get the timer for third party servers loading), is that it both makes the UI
more self describing, and can make a more advanced feature (in this case
link hover) useful to a mainstream audience.
I know this sounds silly, but a lot of users believe that Firefox 4 is the
first version to include a password manager, because it now displays a 64x64
key icon, and they had previously never paid attention to the very slim
notification bar. So in some respects, moving link hover above the fold and
next to dominate controls like stop/reload, introduces the feature that had
previously failed to exist because it simply flew under the user's radar.
== How we can streamline and improve our workflow in the future ==
(note that this answer is purely my personal views, and not those of the
entire team).
The UX team is often called on to clearly justify every decision we are
making. Often this is because people are seeing half finished work, and
sometimes this is because people are seeing completely finished work that
isn't targeted at them. And, I honestly love writing these explanations.
By justifying a feature and responding to every dissent you can teach people
the fundamentals of interface design, show people how principles are applied
(ux-* in bugzilla), and generally justify to the world that you actually are
exceedingly educated and pretty consistently correct. It's fun.
However, there are a few downsides to having to comprehensively justify
every change. The first is that this can create an environment where a
trained user experience designers might anticipate that their work won't
make it, so they hold back on suggesting more radical (but nonetheless
correct) changes. The second, is that even if the designer does decide to
push hard for a change, this takes a tremendous amount of effort, at a time
when when need to be moving faster. And the third downside is that even if
they decide to push for a change, and put in the significant amount of
effort to convince even some of their strongest detractors, the environment
may have become so conservative that the design is still scrapped due to
simply the existence of dissent.
So while I feel that explaining the full rationale for an interface is often
illuminating, and I personally even find it fun, I don't think it creates an
environment that is conducive to quickly shipping the best interface.
But what we definitely need to do, (and will also help us move quickly), is
give people the full picture of what we are planning. Not necessarily
always the "why" but rather the "what." We've started publishing
comprehensive mockups annotated with live updating bug data, to help people
understand how a single bug fits into a larger whole. Here are some
examples:
http://areweprettyyet.com/4/syncJpake/
http://areweprettyyet.com/4/notifications/
These types of mockups help to make it clear what parts of a comprehensive
design are complete, and what parts are still pending. Currently the
majority of the confusion related to UI changes comes down to understanding
if something is finished yet or not.
A few remaining answers:
I now see the add-ons bar, which is both empty and always present
>
This should never happen, although I believe (from a quick review of the
bugs) that we might have implemented only automatically displaying the
add-ons bar if it contained an item, but failed to implement hiding it if it
later became empty again.
Unfortunately the Find bar often sticks around and takes up a whack of
> vertical space
>
This is bug 628179, it's not blocking but the patch is complete and it is
waiting on code review.
-Alex
On Sun, Jan 30, 2011 at 1:17 AM, Brendan Eich <bre...@mozilla.org> wrote:
> Something is wrong in https://bugzilla.mozilla.org/show_bug.cgi?id=628654(please do not spam that resolved bug; reply here instead) and
> Vlad's point in https://bugzilla.mozilla.org/show_bug.cgi?id=628654#c70about XHR popping up the revived status -- as in progress notification --
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
Brendan Eich
> == What I think we should quickly do for Firefox 4 ==
>
> The link hover area in the location bar currently does not display loading
> status for third party servers, which the status bar used to display.
We lost all server feedback, second party (if that's the origin server hosting the page or app whose URL was resolved from input to the awesomebar, or from a clicked link or equivalent), and not just third party servers.
(Te browser must be the first party -- cue "A Night at the Opera", the party of the first part scene. :-P)
In Firefox 3.6.7 using a slow proxy, I load aintitcool.com and see
Waiting for aintitcool.com...
Transferring data from aintitcool.com...
and then some later transfers from amazonaws, googleanalytics, doubleclick, and edge-cache URLs. Finally, "Done."
With Firefox 4 b10 I see nothing of the kind, either down where the status bar used to be, or in the URL bar up top. Just the (easy to miss, kind of muted) blue tornado spinning. What am I missing?
> reason for this is that the information often appears so quickly that users
> have no chance of actually reading it,
True, until there's a slow server or proxy, or a congested net, and then the information becomes more useful -- it may even be critical for non-expert troubleshooting (e.g. with one's ISP's help desk over the phone).
> and placing this flashing text in a
> more dominate place in the UI (along with a higher level of contrast since
> it is on a white background), makes the interface as a whole feel rather
> spastic and technical, like a robot that shouts code at you so quickly that
> you can't understand it.
Right, so this information should *not* go somewhere more prominent. This argues for peripheral vision location (I just had mine tested, still good and it's important around computers -- and kids ;-).
But when you need to look, the information is there (in 3.6 and earlier), especially when a server is not responding.
Again I'm not making absolute arguments for or against. But it seems the distinction between progress information that usually flies by and is not needed (and should not be prominent) and progress info when there's a network or server slowdown or loss of service is important, possibly crucial. And that distinction is not made in your words above.
> The best way to very quickly reintroduce loading status for third party
> servers (without any other change to the speed of messages being relayed),
> is to move it out into the user's low resolution peripheral version (similar
> to previous versions of Firefox, Chrome, and IE9).
But that's where it was when we had the status bar, so it's not obvious it needs to move (net-net from 3.6). The status bar being like a tooltip, popped up when presenting data, is secondary.
My main point is that this information is peripheral until it's not, and then it is important both to have the stalled host's name not go away or pop down, and important not to move the place it shows up (since you're looking for trouble there and only there).
If you're on the phone with the helpdesk and the server is not responding, you need that last progress message to stay put and visible.
> Since we no longer have
> a bar taking up vertical screen space, we can use a tooltip (IE9).
Right. If we had the status bar, we wouldn't need a tooltip. But a tooltip requiring mouse-over to be shown must not be what you mean. (I may have a stale or simplistic definition of tooltip.)
A popup, as now has been brought back, is more like it. I hope it stays up when there's a stall loading the main page and its assets, or my helpdesk buddy will be hearing some cursing.
> Alternatively, if we were to re-introduce the loading status for third party
> servers into the location bar,
Yeah, that doesn't make sense per above. The data is peripheral, too technical for most users and (we hope) unnecessary most of the time with fast and reliable connections and servers.
> I believe this would introduce more
> complaints than it addressed. Additionally, the subset of users who rely on
> third party server loading status will expect it to appear in the same
> location as link hover, so it's important that these two pieces of
> information appear in the same place no matter what we do.
Agreed.
> == What our plan was and how we got into the current state ==
>
> We weren't intending to remove loading status for third party servers
Again one of us must be missing something. I see no progress status for the second party in Firefox 4b10 or thereabouts (my tm tip build; we haven't pulled Dao's work to bring back a popup status bar yet from m-c to tm).
> entirely, but simply to introduce a timer so that messages were only
> displayed in extreme cases where the user would actually wonder why part of
> their page hadn't loaded (or why the throbber was still active even though
> it seems like the entire page has loaded). As previously noted on
> dev.apps.firefox, even mainstream Farmville users will occasionally rely on
> third party server loading status in more extreme cases. Introducing a
> short timer would significantly improve the signal to noise ratio, and would
> also reduce the extent to which Firefox came off as a jargony spastic URL
> shouting robot :)
But I don't see why any progress information should go in the URL bar. That is not a progress bar, it's the combined URL/search-my-corpus awesomebar. Overloading it, even with a timer to suppress the short-burst-till-success transfer progress, not only requires retraining, it risks degrading the primary use-case usability of the awesomebar by injecting mostly-happy-noise, instead of leaving the mostly-happy-noise in the periphery.
> This change requires retraining.
At the least. It also has a ragged left margin over time, as Erunno noted in
https://groups.google.com/group/mozilla.dev.apps.firefox/msg/6a3200d1490b1e32
People have complained about the eye/brain workout required to find the left end (starting point at some random position depending on URL length and cropping) of the hovered URL. The same goes for progress status in the awesomebar, unless I'm missing something.
I don't see how you can train for a random starting point for the URL scheme, domain name, or other left-heavy important parts of the hovered or progress-stalled URL.
> This is a good question, why did we move the link hover (and delayed
> loading) information away from the location that it has previously been,
> knowing that this would both require a change to existing eye muscle memory,
> and also make it harder for users to transition between products currently
> in the market place? Our objectives were:
>
> 1) Increase how self describing the UI is
Why is this a good thing?
UI exists to help users to do things. Users who know about the status bar missed it, and did not have any second or third party progress status AFAICS. Users who don't know about the status bar might learn about it by the move of one of its uses to the awesomebar, or as Dao pointed out in the bug, they might just see ragged-left noise on the awesomebar and pay less attention to that whole thing.
It's really hard to say without user-testing studies. Were any conducted?
But anyway, I don't agree it's desirable to make UI self-describing at the expense of the UI's primary purpose, which is to do discrete user-level tasks that differ in kind and dynamics. The awesome bar is awesome for its task. The status bar, precisely because it is in the periphery, is if not awesome, then traditional and better than nothing at holding the mostly transient-till-"Done" but occasionally-crucial-when-things-hang progress status.
We don't need to make everything equally self-describing or discoverable, because the use-cases for various UI elements differ in frequency of use and dynamic importance. Specifically, you don't need to read the fast progress status happy-noise chit-chat, although it has some "progress is happening" positive reinforcement, until something goes wrong on the net or with the other host -- and then due to this dynamic shift, you need that mostly-peripheral information (and in the same place).
> Placing the link target to the right of the current location with the >
> symbol very directly communicates "you are about to travel from A > B", it
> also even bootstraps an understanding of "A is where you currently are" (in
> case you haven't picked that part up yet).
Is there any evidence people don't understand this?
The ragged-middle margin problem Erunno raises still hurts usability.
The people who knew to look down when link-hovering all had to retrain.
(And the progress-status for second and third parties was removed.)
So again, I have no idea what the absolute best presentation for hovered-link URLs is, but overloading the right end of the awesomebar to hold it is novel and questionable (I'm questioning it here), and it caused notable complaints. It has usability problems due to the length needing cropping and starting the URL at a varying position. And it's not at all clear that users who didn't know to look in the statusbar cared and needed to be taught.
Again if I've missed some user-testing results, apologies -- please lay them on me.
> Someone who is intelligent but
> uninformed can understand the purpose of the location bar very quickly if it
> describes navigation and current location in a simple LTR (or RTL) A>B
> fashion. Similarly, placing the third party server loading status directly
> next to the stop button visually communicates "this is what you are
> literally going to stop." If we were building a browser in isolation these
> would all be 100% logical decisions.
I wonder. Besides the issues I raise above, and ignoring tradition, it's not clear that the [X] (once a Stop Sign) apples to some (possibly cropped) URL flickering to its left in the awesomebar. At least, with a clean slate I can imagine many different approaches that do not overload the one and only text-input awesomebar.
This isn't a quibble. If we want to do some clean-slate designs and test them, great. That does not sound like Firefox 4 b7 or later, though.
> 2) Increase the percent of mainstream users who take advantage of these
> features
It's important to "do no harm". We can't tell what the exact trade-off will be, how many will be helped and how many hurt. But between taking away something that users who *did* know to look to the status bar actually made good use of, and being different from other browsers, and overloading the awesomebar, possibly degrading its primary use-case usability or just confusing users more, I suspect we did more harm than good with the changes that were made.
I know some here like the changes and can make technical arguments for them. I even got used to the change (retraining lab-rat me!) while I stuck with Firefox. But cross-training with Chrome (I recommend everyone reading this do the same), I was in a lot of frustrating eye and brain pain.
> But we aren't building a browser in isolation, there are other browsers in
> the market that place this information in other places, and older versions
> of our product that do the same. There's a cost, and input.mozilla.com can
> now show this cost to us. But what input.mozilla.com can't show us (and
> neither can Test Pilot unfortunately), is the number of users who don't
> really know what the Location bar is (aside from some jargony text they
> don't understand), and also haven't really paid any attention to the status
> bar before. These users didn't read the manual, and aren't curious enough
> to ask someone else. These users aren't complaining, and they probably
> don't know what beta means. It's mainstream dark matter, and it's what we
> spend most of our time thinking about.
Sorry, these users have to lump it. They are strictly lower priority than (a) awesomebar non-overloading and (b) statusbar-savvy users on the phone with their ISP helpdesks.
> The reason why we are ok with landing the A>B design (even though we didn't
> get the timer for third party servers loading), is that it both makes the UI
> more self describing, and can make a more advanced feature (in this case
> link hover) useful to a mainstream audience.
I still be missing something. I don't see the second party (after the browser's first party) get any progress status in the awesomebar, on the right or anywhere up there. I see only the blue tornado on the left corner of the tab.
> I know this sounds silly, but a lot of users believe that Firefox 4 is the
> first version to include a password manager, because it now displays a 64x64
> key icon, and they had previously never paid attention to the very slim
> notification bar. So in some respects, moving link hover above the fold and
> next to dominate controls like stop/reload, introduces the feature that had
> previously failed to exist because it simply flew under the user's radar.
This analogy is interesting but the two UIs and use-cases are quite different. Anyway, as I wrote above I don't think we should be trying to educate users at the expense of extant UI primary use-case usability.
[snip]
> So while I feel that explaining the full rationale for an interface is often
> illuminating, and I personally even find it fun, I don't think it creates an
> environment that is conducive to quickly shipping the best interface.
I agree, but it would be better yet to promulgate UI that doesn't require such analogical or not-clear (or shaky) arguments, and that does not result in such complaints. Or if there has to be retraining but it is worth it, make the change very early in a release cycle.
But I bet we're going to go wrong if we try to educate users through self-describing UI too much. In the current case I think we did go wrong.
The ideas of educating users about URLs and progress vs. the stop [X], the current -> next URL idea, all seem like good motivation for experiments, without obvious winners yet (and room to innovate well beyond the current UI or b10's).
And clearly we lost information that could be critical when status dynamics shifted in a way that needed troubleshooting, or just reassuring albeit peripheral happy chatter that quickly ended with "Done."
> But what we definitely need to do, (and will also help us move quickly), is
> give people the full picture of what we are planning. Not necessarily
> always the "why" but rather the "what." We've started publishing
> comprehensive mockups annotated with live updating bug data, to help people
> understand how a single bug fits into a larger whole. Here are some
> examples:
>
> http://areweprettyyet.com/4/syncJpake/
> http://areweprettyyet.com/4/notifications/
>
> These types of mockups help to make it clear what parts of a comprehensive
> design are complete, and what parts are still pending. Currently the
> majority of the confusion related to UI changes comes down to understanding
> if something is finished yet or not.
Cool, will look at these tomorrow when I have more time. Great to see AWPY ;-).
> A few remaining answers:
>
> I now see the add-ons bar, which is both empty and always present
> >
>
> This should never happen, although I believe (from a quick review of the
> bugs) that we might have implemented only automatically displaying the
> add-ons bar if it contained an item, but failed to implement hiding it if it
> later became empty again.
What item did I have that is gone now? I don't even know. Is this because add-on compatibility checks disabled some of my add-ons (I run my own nightly build)?
This looks like deadwood exactly where the status bar used to be. Is it going to be deadwood for most users of Firefox 4?
/be
Bill Barry
> *: The "Status-4-Evar" extension partly absorbed the shock during the
> beta phase, but that's an awful solution.
Are there any good statistics on what percentage of the beta/nightly
install base is using this extension?
Mike Beltzner
> On 1/30/2011 3:15 AM, Dao wrote:
>> beta phase, but that's an awful solution.
>
> install base is using this extension?
Yes, actually! You can see the usage statistics here:
https://addons.mozilla.org/en-US/statistics/addon/235283
The Add-On has had approximately 45,000 downloads, and enjoys an average
active daily user count of 10,000 or so. The average active daily user
account of beta users is about 2.1M, so we're looking at about 0.4% of
our testing audience*
cheers,
mike
(* while it hasn't been repeated in a while, the previous demographic
study via Test Pilot showed our beta audience to be skewed to be
predominantly male, technical users)
Alexander Limi
> > We weren't intending to remove loading status for third party servers
>
> Again one of us must be missing something. I see no progress status for the
> second party in Firefox 4b10 or thereabouts (my tm tip build; we haven't
> pulled Dao's work to bring back a popup status bar yet from m-c to tm).
The work was done in
https://bugzilla.mozilla.org/show_bug.cgi?id=603777before the
direction on this was suddenly changed by people outside the UX
team, so it never got the chance to land.
--
Alexander Limi · Firefox UX Team · @limi <http://twitter.com/limi> ·
limi.net
Alex Faaborg
> In Firefox 3.6.7 using a slow proxy, I load aintitcool.com and see
>
> Waiting for aintitcool.com...
> Transferring data from aintitcool.com...
>
> and then some later transfers from amazonaws, googleanalytics, doubleclick,
> and edge-cache URLs. Finally, "Done."
>
We have reduced loading down to three distinct states:
-Trying to connect to the server (grey throbber, "connecting")
-Successfully loading the page (colorful throbber spinning forwards)
-Done (favicon)
This is the level of complexity that we believe most users will understand.
In many ways it's similar to making a telephone call (dial tone, ringing,
person picks up). Removing references to sites like "amazonaws,
googleanalytics, doubleclick" was intentional, with the caveat that we
wanted them to show up when the load was taking more than a certain
threshold of time (like 3 seconds). This would satisfy the case of someone
making a support call, and also provide users information only when it is
actually useful.
> Placing the link target to the right of the current location with the >
> > symbol very directly communicates "you are about to travel from A > B",
> it
> > also even bootstraps an understanding of "A is where you currently are"
> (in
> > case you haven't picked that part up yet).
>
> Is there any evidence people don't understand this?
>
Definitely not amongst the people who would comment in bugzilla, use a beta
build, or send you a personal email. However our own market research (which
is unfortunately all marked propriety and I can't start directly quoting
here) shows very significant confusion between the concepts of Web browser,
search engine, and ISP. So given that level of understanding I think it's a
reasonable conclusion that a lot of our users haven't figured out that the
URL represents the current page they are on yet.
And clearly we lost information that could be critical when status dynamics
> shifted in a way that needed troubleshooting, or just reassuring albeit
> peripheral happy chatter that quickly ended with "Done."
>
Yes, and since we didn't get the time threshold for messages landed (which
was a prerequisite for placing loading states with a natural mapping to the
control that would stop activity), I think we now all agree that we should
backpedal and go with a persistent tooltip styled panel in the peripheral
lower left hand corner of the page.
-Alex
On Sun, Jan 30, 2011 at 6:05 PM, Mike Beltzner <belt...@mozilla.com> wrote:
> On 1/30/2011 8:40 PM, Bill Barry wrote:
>
>> On 1/30/2011 3:15 AM, Dao wrote:
>>
>>> *: The "Status-4-Evar" extension partly absorbed the shock during the
>>> beta phase, but that's an awful solution.
>>>
>>
>> Are there any good statistics on what percentage of the beta/nightly
>> install base is using this extension?
>>
>
> Yes, actually! You can see the usage statistics here:
>
> https://addons.mozilla.org/en-US/statistics/addon/235283
>
> The Add-On has had approximately 45,000 downloads, and enjoys an average
> active daily user count of 10,000 or so. The average active daily user
> account of beta users is about 2.1M, so we're looking at about 0.4% of our
> testing audience*
>
> cheers,
> mike
>
> (* while it hasn't been repeated in a while, the previous demographic study
> via Test Pilot showed our beta audience to be skewed to be predominantly
> male, technical users)
>
Brendan Eich
> On Sun, Jan 30, 2011 at 5:29 PM, Brendan Eich
>
> > > We weren't intending to remove loading status for third party servers
> >
> > Again one of us must be missing something. I see no progress status for the
> > second party in Firefox 4b10 or thereabouts (my tm tip build; we haven't
> > pulled Dao's work to bring back a popup status bar yet from m-c to tm).
>
>
> The work was done in
> direction on this was suddenly changed by people outside the UX
> team, so it never got the chance to land.
If we shipped last year or any time sooner than last week, this would have gone unfixed? The status bar was removed in Sept. nightlies, shipped in b7 in early November.
The idea of putting time-filtered progress status on the right in the awesomebar never occurred to me. I didn't see this coming. It doesn't sound like a good idea. Imagine comcastic.net's helpdesk interacting with a hypothetical user of a browser that did what this bug proposes.
The benefit of educating some users about progress status seems not worth the hassle of changing the location where this information goes (and filtering it). Maybe it was a good idea, but it can't be a big win almost by definition -- and it blew up among enough users that it wasn't a big win in reality.
Messing with it for b7 was one thing. Not fixing this bug till last week, then blaming people outside the UX team, says to me this bug was not all that important. Right?
/be
Alex Faaborg
exists was previously set as a blocker, and the alternative plan of
displaying it in the lower left hand corner has now landed. In terms of
priority though, a number of other blockers have been getting the majority
of our attention recently. Either way, it was going to be addressed (in
some form) before we shipped, and has now already been addressed.
-Alex
Brendan Eich
> The original plan of showing loading status where link hover currently
> exists was previously set as a blocker, and the alternative plan of
> displaying it in the lower left hand corner has now landed.
Yes, all's well that ends (has almost ended) well, let's hope.
But I'm still goggling at the delay between removing the status bar and then almost fixing the bug that proposed to put filtered progress status in the right of the awesomebar. We knew we had complaints. The design intended to make up for part of the regression (the progress-status messages going away without any replacement; not link-hovering) was never shipped in 4 betas (b7-b10). How did we know that would suffice to address the use-case?
Anway, just from the point of view of a Martian, that progress-status-in-right-of-awesomebar bug could not have been that important given how it went unfixed.
/be
Alex Faaborg
> that progress-status-in-right-of-awesomebar bug could not have been that
> important given how it went unfixed
>
Generally speaking, most users don't know that Web pages contain a mix of
content from different servers, so in that regard failing to give them
extended information about something that they already don't understand
wasn't the largest usability issue in Firefox. But I certainly share your
desire for a set of comprehensive interface changes to land in their
entirety (insert plug for AWPY :). Unfortunately our triage process
sometimes (for better or worse) shifts engineering effort away from a
project that is in progress and towards another set of bugs that are viewed
as being more important.
-Alex
Alexander Limi
> Messing with it for b7 was one thing. Not fixing this bug till last week,
> then blaming people outside the UX team, says to me this bug was not all
> that important. Right?
>
The bug itself was a follow-up bug from
https://bugzilla.mozilla.org/show_bug.cgi?id=613390, which was filed on
November 18th. We shipped beta 7 (where it landed) 8 days prior. I don't
think that's an unreasonable lag between the two.
The specific bug was marked as a hardblocker for the release on 2011-01-19,
which means it was on the list of things to fix.
If we could have landed everything together, that would obviously have been
ideal, but that's not generally how development happens in the current
Bugzilla-driven development process. Things get fixed incrementally (which
you argue for earlier in this thread yourself!), and then follow-up bugs get
filed.
Brendan Eich
/be
Brendan Eich
> On Sun, Jan 30, 2011 at 7:37 PM, Brendan Eich
>
> > Messing with it for b7 was one thing. Not fixing this bug till last week,
> > then blaming people outside the UX team, says to me this bug was not all
> > that important. Right?
> >
>
> The bug itself was a follow-up bug from
> https://bugzilla.mozilla.org/show_bug.cgi?id=613390, which was filed on
> November 18th.
That bug is an unfixed meta-bug. What am I missing?
> We shipped beta 7 (where it landed) 8 days prior. I don't
> think that's an unreasonable lag between the two.
And my point is that nothing, no "second party" or "third party" progress-status, was shown anywhere since the status bar removal. That meta-bug being filed does not help. It's great people wanted to finish the design but it was not in fact finished, ever, which means we had no idea if it would work as hoped.
So saying the cut within the last week was a sudden reversal seems a bit off. In terms of intentions, ok. In terms of what landed in b7-b10, and diminishing odds of landing in b11, not ok.
> The specific bug was marked as a hardblocker for the release on 2011-01-19,
> which means it was on the list of things to fix.
Lots of things on the list of things to fix are being waved off, because they aren't really hardblockers. But true hardblockers have to get attention, or they're not really hard, or we are so shorthanded we're triaging the battlefield. In the last case, again the odds were never good for this bug, intentions aside.
> If we could have landed everything together, that would obviously have been
> ideal, but that's not generally how development happens in the current
> Bugzilla-driven development process.
We don't let SunSpider or V8 regress at all. If we screw up (AWFY went down for four days and we missed a regression), it's a p1 to fix. I'm not bragging, we screw up too. I don't think anyone screwed up as I have at my worst. But I repeat that this bug couldn't have been that important, and (more to the current thread's point) we must have been pretty sure it would address the four-beta-long lack of progress status, or else been willing to ship without a fix to restore progress-status.
> Things get fixed incrementally (which
> you argue for earlier in this thread yourself!),
My argumented cited gal's patch to make the Find bar collapse on page navigation. That is not a regression or a regression-fix by any definition of regression.
Removing all progress-status messages from all UI (think of comcastic.net) did regress our UI. This was half of the complaints (not by count, by symptom -- the other "half" was link hovering URL moving so far away from where users with trained eyes expected it).
Incremental development has to make progress. Rarely can you justify one step backward, two steps forward. Often you risk just going sideways, if not backwards.
> and then follow-up bugs get filed.
I explicitly called out how larger designs get random chopped down by bugs, and Dao wrote about this too. I received private email about it too. It's not a matter of small positive changes along a path. It is more like big rush to meet a deadline, leaving a bunch of unfinished work and a few outright regressions, then bug roulette to see what else gets fixed.
I'm generalizing but I've seen and heard enough. This is a problem.
/be
Alexander Limi
> > The bug itself was a follow-up bug from
> > https://bugzilla.mozilla.org/show_bug.cgi?id=613390, which was filed on
> > November 18th.
>
> That bug is an unfixed meta-bug. What am I missing?
>
That it is handled in follow-up bug,
https://bugzilla.mozilla.org/show_bug.cgi?id=603777 a bit down the page? I
didn't initially file it as a meta-bug, for the very same reason (I wanted
all of it fixed at the same time, and land simultaneously), but eventually
we ended up doing smaller follow-ups instead, so I marked the bug as a
meta-bug later.
I explicitly called out how larger designs get random chopped down by bugs,
> and Dao wrote about this too. I received private email about it too. It's
> not a matter of small positive changes along a path. It is more like big
> rush to meet a deadline, leaving a bunch of unfinished work and a few
> outright regressions, then bug roulette to see what else gets fixed.
>
> I'm generalizing but I've seen and heard enough. This is a problem.
>
Yeah, I'm the first to agree with you on that.
Philip Chee
> I'm not sure what's best at this state, as we are _very_ late in the FF4
> cycle now and actually have wanted to be in RC by now, but maybe we need
> to sit back for an hour or two and think about if it's right to go in RC
> with what we have at this moment or can or even need to augment it in
> some ways that make those more comfortable who have a hard time living
> with the current state of FF4 UI.
>
> And still, I feel bad about every day we delay this FF4 release, as we
> are shipping such a big load of awesomeness along with the changes
> discussed here that every single delay hurts, esp. as the competition
> isn't sleeping.
>
> Unfortunately, I don't have solutions, but perhaps we can come up with
> some here.
I agree it's too late to switch back. What Firefox can do however to to
look at how Thunderbird tackled this issue. I believe that TB3 has an
upgrade wizard that offers users the option to download and install one
or more extensions to restore several aspects of the UI back to the TB2
look and feel. I think this might be doable for Firefox to offer the
Statsbar4Ever extension similarly and since this is not only a proven
system it is already coded all you need is to copy and adapt the code
from the TB tree.
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.
Blair McBride
> If we could have landed everything together, that would obviously have been
> ideal, but that's not generally how development happens in the current
> you argue for earlier in this thread yourself!), and then follow-up bugs get
> filed.
This should be something that feature-branches can address (to some degree).
- Blair
Dietrich Ayala
>
> > This should never happen, although I believe (from a quick review of the
> > bugs) that we might have implemented only automatically displaying the
> > add-ons bar if it contained an item, but failed to implement hiding it if it
> > later became empty again.
>
> What item did I have that is gone now? I don't even know. Is this because add-on compatibility checks disabled some of my add-ons (I run my own nightly build)?
>
> This looks like deadwood exactly where the status bar used to be. Is it going to be deadwood for most users of Firefox 4?
We implemented both show-on-install and hide-on-uninstall for
restartless add-ons. If you have a visible and empty add-on bar, then
either there is a bug or you flipped it on at some point.
I searched input.m.c and couldn't find reports of this happening, but
it's not super easy to search for. And non-technical users might not
think it's a bug at all, so might not report it.
Brendan Eich
> We implemented both show-on-install and hide-on-uninstall for
> restartless add-ons. If you have a visible and empty add-on bar, then
> either there is a bug or you flipped it on at some point.
I haven't but I did install Status-4-Evar. D'oh! Sorry, thought I had disabled it.
Andreas Gal has not installed S4E. He has installed AdBlockPlus. He testifies that the add-ons bar has a little red stop sign on the right, the rest wasted space. He also said something about clicking on the (x) to get rid of the bar, and like a bad penny, it keeps coming back.
> I searched input.m.c and couldn't find reports of this happening, but
> it's not super easy to search for. And non-technical users might not
> think it's a bug at all, so might not report it.
Exactly. It looks like ye olde status bar!
BTW Status-4-Evar makes me a bit nostalgic but it's too thick. Along with the Findbar thing-that-wouldn't-leave, too many pixels of vertical space are wasted. From my cross-training maximized Chrome and Firefox, the difference adds up.
/be
patrickjdempsey
the urlbar (which makes absolutely no sense IMO) or popups in the
bottom right (annoying and hides content and feels like copying
Chrome) are taken seriously while status message in tabs (the only
option that really makes logical sense to me) was never really
considered?
Am I the only person who thinks that status-text and hover-link text
really don't have to be in the same place? Am I the only person who
thinks it's somewhat old fashioned to only show status text for the
current tab? Am I the only one who find the methods suggested to be
overly complex solutions to something that has a very simple answer?
I just don't get why the entire Firefox interface has gone through so
much change over the years but tabs are still limited to: favicon,
title, close. Why after 4 releases with SSL verification don't
Firefox's tabs display that information? Why after all of these years
of trying to shift users away from single-tab interface to multi-tab
interface are the tabs not more than just placeholders? Why after 4
releases with the Library havn't any noticeable improvements been made
in something that I (can I be alone?) find virtually unusable? (And
the interface isn't even updated to match the new UI!) Why after 3
releases are Tab Previews still buried in a hidden pref that most
users will never find, despite the fact that they are obviously a
stepping stone towards Tab Groups UI? Why wasn't ANY form of a
Downloads indicator seriously considered for this release when your
competition provides both Downloads and Uploads indicators? Glaring
omissions in the primary UI don't look good, especially when products
take longer than expected to deliver. And really, this bottom-left
popup thing... it's one of the (many) things that I absolutely detest
and abhor about Chrome... I don't think it's clever or ground-
breaking... I think it's the absolutely most lazy way to make the
claim a more simple UI while in actuality having a more complex and
annoying UI, that doesn't actually save any screen space because it's
constantly appearing. And you guys can do better.
Dietrich Ayala
> Andreas Gal has not installed S4E. He has installed AdBlockPlus. He
> testifies that the add-ons bar has a little red stop sign on the
> right, the rest wasted space. He also said something about clicking on
> the (x) to get rid of the bar, and like a bad penny, it keeps coming
> back.
I installed ABP on the nightly in a new profile. The add-on bar did show up after restarting Firefox, and the red stop sign was there. I hid the add-on bar and restarted, and the bar didn't become visible again. I tried restarting a few different times and the bar stayed hidden. Andreas should file a bug.
Dao
We show/hide the add-on bar only for restartless add-ons, so Adblock
Plus is probably doing its own thing here and Andreas should file a bug
on https://www.mozdev.org/bugs/enter_bug.cgi?product=adblockplus
Asa Dotzler
Might be https://bugzilla.mozilla.org/show_bug.cgi?id=627484 which
plagues Add-on SDK built extensions and I read somewhere else that ABP
might be borrowing that faulty code or is suffering from a similar problem.
- A
Asa Dotzler
I'm sorry. I've confused ABP with Firebug which might be triggering the
same or similar problem.
- A
Jan Odvarko
> same or similar problem.
The way how Firebug is supposed to deal with the status-bar/addon-bar story
is following (some last commits made last week so, you need to get it from
SVN or wait for 1.7a10 - available in a 1-2 weeks):
- The well known 'Firebug status-bar icon' representing Firebug UI entry
point has an alternative - a toolbar button that comes from the "Customize
toolbar" dialog (the button was there for some time, but is refactored)
- This button is appended into the Firefox toolbar automatically after
Firebug is installed - to avoid surprises like "Ah, where is my Firebug
now?!". This is one time operation, if the user removes it, it stays
removed.
- The Navigation toolbar is also displayed after the button is appended, to
make sure the user actually sees it.
- The toolbar button has exactly the same functionality as the old status
bar icon (the same context menu, the icon reflects Firebug state i.e.
Firebug disabled == icon grayed, clicking on it opens Firebug, etc.)
- Firebug opens the addon-bar automatically after installation. This is one
time operation and it happens only once. Some Firebug users still prefers to
have the status bar icon since it's closed to the actual Firebug UI.
Honza
Boris Zbarsky
> We implemented both show-on-install and hide-on-uninstall for
> restartless add-ons. If you have a visible and empty add-on bar, then
> either there is a bug or you flipped it on at some point.
Then there's a bug. I never flipped it on, but I did have it present
(this conversation made me notice it), and it was quite empty. The only
addons I currently have installed are DOMi and the addon compatibility
reporter.
> I searched input.m.c and couldn't find reports of this happening, but
> it's not super easy to search for. And non-technical users might not
> think it's a bug at all, so might not report it.
s/non-technical//
-Boris
Boris Zbarsky
> On 1/31/11 2:07 AM, Dietrich Ayala wrote:
>> We implemented both show-on-install and hide-on-uninstall for
>> restartless add-ons. If you have a visible and empty add-on bar, then
>> either there is a bug or you flipped it on at some point.
>
> Then there's a bug. I never flipped it on, but I did have it present
> (this conversation made me notice it), and it was quite empty. The only
> addons I currently have installed are DOMi and the addon compatibility
> reporter.
To be clear, at one point I had installed, and then uninstalled, the
hardblocker counter add-on. I assume that's why the add-on bar was there.
-Boris
jag
> However our own market research (which is unfortunately all marked propriety
> and I can't start directly quoting here) shows very significant confusion
> between the concepts of Web browser, search engine, and ISP.
I see things (sadly) haven't changed all that much in the last 10 years.
I really like the minimalism of the recent betas. I hadn't actually noticed that the progress messages were missing except for a few times where I was trying to figure out whether a page was still loading (or loading at all). My retraining has reached the point where my eyes scan the top-right corner of the window (one guess what I'm looking for), shortly pausing there before moving on to the left to find the page's tab to look for a rotating thingy.
Also, I like having the preview URL in the URL bar (location bar, awesome bar, ...), and I don't think it and the progress messages necessarily need to be in the same place.
At this point (now that Dão has implemented and landed an only-when-needed minimally intrusive help-desk friendly status panel), I suggest we focus on fixing bug 596587, which could be as simple as moving the overLink.style.minWidth and .maxWidth assignments outside that |if| block. It might need a bit more love than that though, the unused space after short preview URLs looks weird, and the bookmark star shouldn't disappear when there's plenty of room for it.
And finally, just an idea for Firefox post-4: what would you say of making the status messages a door-hanger on the twisty (shown on click on a busy tab)?
Jean-Marc Desperrier
> The idea of putting time-filtered progress status on the right in the
> awesomebar never occurred to me.
I started a conversation here last september with a similar idea, that
might have influenced the UI team. Or not.
> I didn't see this coming. It doesn't sound like a good idea.
In the older Firefox, the target of a link is previewed in the status
bar, and just after clicking the loading status is shown *at* *the*
*exact* *same* *location*.
So the logic here is that if the status bar is removed and links preview
moves to the awesome bar, then the loading status should also move to
the awesome bar.
I've just seen the latest nightly with the loading status pop-up at the
bottom-left corner, and it probably does work better (more readable)
than inside the awesome bar.
*But* moving your eyes at the top right to see the link preview,
clicking, and at the next second having the loading status appear at the
bottom-left is broken IMO.
If the decision is that loading status moves to the bottom-left corner,
then I think that the link preview should also move there.
I'm still not fully convinced though : As the moving throbber appears
inside the tab bar, it trains the eye/brain system to look up, not down.
What about a pop-up at the top right ?
> Imagine comcastic.net's helpdesk interacting
> with a hypothetical user of a browser that did what this bug
> proposes.
Whether it's a pop-up in the bottom-left, or a status in the right of
the awesome bar, this use case will work only if the address stays
visible as long as the connexion is stalled.
It's certainly easier to read inside a pop-up.
Dao
> I'm still not fully convinced though : As the moving throbber appears
> inside the tab bar, it trains the eye/brain system to look up, not down.
This is in fact what we'd want. Most users won't normally need the
detailed information.
Jean-Marc Desperrier
But your peripheral vision catches the movement (that's the one thing
it's good at), and your brain concludes it should move it's fovea there
to see what it is in details. As it's a pop-up, it's more visible that
the old status bar update.
The best would be a usability study.
jag
> I'm still not fully convinced though : As the moving throbber appears
> inside the tab bar, it trains the eye/brain system to look up, not down.
> What about a pop-up at the top right ?
I've in fact hacked my local build to do exactly this, but that's 'coz I tend to look there anyway for the throbber (old habits etc.). I like it, but I can see how it'd annoy a lot of people.
Michael Kazmierczak
Having the status info overlay bottom-left is inconsistent with showing other important information in the top, therefore not an good idea to have it there.
To show status info helps the user to understand that something is going on and that the browser is actually doing something for you. Can also help the impression that it feels faster.
If and where to put UI is in the eye of beholder. Everyone has got an opinion. To make good UI and UX work is to be consistent and explain how it works. With consistency and ease of use Firefox shouldn't have any problems in retraining users to a new UX.
I like having preview links in locationbar, seems very logical to me. This is where I am now > this is where I can go next. Combined Reload/Stop/Go button to the right, perfect! That's my opinion.
The only thing that's annoying me right now is the status info overlay in the bottom-left, somehow it doesn't feel right. A bit out of place. Right now I would put it top of content, either left or right. To seek more consistency. Every other activity is in the top, so put status info in the top too. I acknowledge that more important content can be hidden by this, but status info overlay should only by visible when page is loading and on hover it will move and content/links will be accessible. At least it can be a good stepping stone to the original plan of the UX team.
I have submitted Bug 629915 to address this.
Keep up the good work!
Michael
Brendan Eich
> I think that consistency is very important. If there's have a throbber in the tabbar and preview links inside locationbar, then the status info should be as close as possible to these two.
Emerson said something about consistency once...
We can't use "consistency" as a blanket argument to group everything into UI mystery meat. It's not a unitary good with one dimension of measure. We have different consistencies to trade off, depending on UI element use-case particulars, and status dynamics (as noted). Not all status is equally important all the time.
The status bar historically being lower-left but also mostly happy-noise, until sad-non-responding-non-noise, is better than putting mostly-noise on the right of the awesomebar, then trying to filter (which may just make us slow, or suppress something important), fix random text alignment, and otherwise overload the awesomebar.
> Having the status info overlay bottom-left is inconsistent with showing other important information in the top, therefore not an good idea to have it there.
See above.
> To show status info helps the user to understand that something is going on and that the browser is actually doing something for you. Can also help the impression that it feels faster.
Well, we didn't get that effect by removing the statusbar. Instead users saw what looked a lot like a hang, especially if they were looking down not up. And it's a bit late to be experimenting now with progress-status overloading of the right end of the awesomebar.
> If and where to put UI is in the eye of beholder. Everyone has got an opinion. To make good UI and UX work is to be consistent and explain how it works.
See above -- you are using "consistency" as a magic wand. It won't work.
/be
Michael
----
If there's a time constraint to ship Firefox 4, maybe
https://bugzilla.mozilla.org/show_bug.cgi?id=629915 could be a
stepping stone towards UX teams plan of using location bar for status
information in the future. The suggestion in that bug is to put status
info overlay below the location bar to the right. More info in the
bug.
If this isn't the right place to come up with this kind of
suggestions, please let me know.
I have been following the developement of Firefox 4 since June 2010. I
really like where it is going with UI, UX, speed, etc. Bug 628654
triggered me submit my first bug!
I agree with the UX teams mockup of the location bar UX. I find it
logical. Thinking outside of the box. Innovative. Looking at a
solution for the future, not looking backwards or copying someone
else.
Asa Dotzler
> Having the status info overlay bottom-left is inconsistent with
> showing other important information in the top, therefore not an good
> idea to have it there.
Status information, beyond what's shown in the tab's progress indicator,
is _not_ important information most of the time for most of the people.
- A
Erunno
I disagree. Most of the users may not know the exact meaning of the
terms but the status information convey progress about page loading
(although not overall progress). It's simply reassuring to see that
the browser is slowly working through the list of resources and not
hanging. It may not be really noticeable if you are using a high-speed
Internet connection but it is very noticeable when having to deal with
slow connections (rural areas, tethering via mobile phone, third
world, etc.). Believe it or not, watching the status messages is a
nice distraction while waiting for enough elements of the site to pop
up to be usable.
Jeremy Morton
[...]
> http://areweprettyyet.com/4/syncJpake/
> http://areweprettyyet.com/4/notifications/
Hi Alex,
I'm gonna take this opportunity to ask. Why is it that every icon in
your designs is HUGE and colourful, except for the browser navigation
bar icons, which are minuscule and monochrome?
I think it's verging on the farcical that whilst the trend for every
other icon in OSes these days is for them to get very big and very
beautiful (look at that sync icon, and that globe icon, and that key
icon, and that questionmark icon, and.....), the trend in browser
navigation bar UI is for icons to become microscopic and black&white.
Those navbar icons feel like something that belongs on a CGA screen.
The Firefox 3 navbar icons were bigger, and colourful. I preferred
them. I'd really like it if the Firefox 4 default theme kept bigger,
more colourful navbar icons. At least, they should stay at 24x24 when
you deselect 'use small icons' when customizing the toolbar, even if
they are set to small by default.
As it is, you can't make them bigger than 18x18 (outside of Linux),
without hacking Firefox's CSS. I don't understand this trend in browser
UI, but it seems to me to be going in the wrong direction. My eyes most
definitely see FF4's small, bleak, black&white navbar as rather
miserable compared to FF3's bigger, more colourful one.
--
Best regards,
Jeremy Morton (Jez)
Alex Faaborg
> Why is it that every icon in your designs is HUGE and colourful, except
> for the browser navigation bar icons, which are minuscule and monochrome?
>
The larger more colorful icons are very transient, they only appear on
screen for a brief moment of time, and are usually meant to communicate
something the browser wants (or in the case of sync, to communicate
success). The navigation bar icons were toned down in this release so that
they wouldn't compete as strongly with the aesthetic design of the page
itself. But, I think we might want to experiment with giving the back
button more visual weight in Firefox 5. We toned it down significantly from
Firefox 3, and the lack of contrast is making harder to target. There's
pretty extended discussion of the size and contrast of the navigation
controls in 3 here:
http://blog.mozilla.com/faaborg/2008/10/24/firefox-themes-the-contention-between-visual-hierarchy-and-toolbar-customization/
-Alex
Ben Lerner
> ... He also said something about clicking on the (x) to get rid of the
in Fb1.7 final) Firebug issue? (For the dev-heavy folks in this list,
chances are good you have Firebug installed...)
http://groups.google.com/group/firebug/browse_thread/thread/59deaacd4ddf3fa8
and http://code.google.com/p/fbug/issues/detail?id=3556
Jeremy Morton
>>
>> Why is it that every icon in your designs is HUGE and colourful, except
>> for the browser navigation bar icons, which are minuscule and monochrome?
>>
>
> The larger more colorful icons are very transient, they only appear on
> screen for a brief moment of time, and are usually meant to communicate
> something the browser wants (or in the case of sync, to communicate
> success). The navigation bar icons were toned down in this release so that
> they wouldn't compete as strongly with the aesthetic design of the page
> itself. But, I think we might want to experiment with giving the back
> button more visual weight in Firefox 5. We toned it down significantly from
> Firefox 3, and the lack of contrast is making harder to target.
I can only speak for myself, of course, but I have no problem finding
buttons in Firefox 3, and I use large icons with text. They're all the
same size and shape - roughly square - and the icons are relatively big
and coloruful. I think you can take your visual design theories too
far, and with FF4, you have indeed taken them too far.
"The icons in FF3 had a few px difference in height between them. Also,
some of them had different colours. So, we have to make them all the
same height, 18px, and let's solve the colour issue by making them black
and white."
I just disagree. Maybe some people want small, black and white icons,
but I really fail to see why you had to do away with 24x24 as an option.
It seems like the UX team is trying to force its will upon everyone
else, and it's a shame. At least give some of us the option to get
bigger icons back. As for their colour... well, at least that can be
changed with a theme.
Ron Hunter
"Important" is a rather subjective issue. Obviously, what is not
important to one person (such as Panorama, which I will never use) is
very important to some others. Just for this user, the status
information is very important to me. It, for one thing, identifies
bottlenecks in routes, and redirections I really don't want. I rather
like knowing what sites may be slowing my throughput.
Ron Hunter
John Bird
indicator on the tab is usually more than enough. Adding a popup to show
the current status certainly addresses all other problems, eg finding which
site is taking long to provide content. Very nice.
The main question is where is best to display this status popup. Bottom
left is fine, as thats where most users are used to looking. Personally I
would recommend a status popup just below the addressbar, as its closer to
the URL and the Tab bar and the Stop/Reload button (ie all the other UI
elements that have to do with page loading). Disappears once page loaded.
That would have some elegance.
On the hover links:
To the right of the URL makes terrific sense - especially as most users are
on wide screens these days. However how does this fit if someone is on a
real small screen - eg a mobile device? How is it made usable then? In
many cases the hover link would have to almost totally cover/overwrite the
existing URL. Does it wrap if its still too long?
John Bird
Asa Dotzler
Sorry, I should have been clear. I meant in terms of relative (to other
items that were front and center) importance for most people (who have
no clue what any of it means actually means beyond "activity").
- A
Michael
You're right, consistency isn't a magic wand for everything. But it can be beacon to follow.
Robert O'Callahan
https://bugzilla.mozilla.org/show_bug.cgi?id=603777#c31
I have no idea who "the Mozilla module owner" refers to.
I deliberately don't care about UI issues (down with bikeshedding!), but this circumlocution bothers me. It's tremendously important that everyone who makes decisions be accountable. And in an open source project, having the identities of people making decisions be secret is absurd.
Rob
Brendan Eich
> Who are these mysterious people "outside the UX team"? "the Mozilla module owner and others" mentioned here?
> https://bugzilla.mozilla.org/show_bug.cgi?id=603777#c31
> I have no idea who "the Mozilla module owner" refers to.
I think that was intended to mean me.
> I deliberately don't care about UI issues (down with bikeshedding!), but this circumlocution bothers me. It's tremendously important that everyone who makes decisions be accountable. And in an open source project, having the identities of people making decisions be secret is absurd.
There are other people being accountable here. Dao made patches to restore lower-left status, and he also made a personal statement about what happened in this thread:
https://groups.google.com/d/msg/mozilla.dev.apps.firefox/1Rz8LO3qmpA/XITLDTXyZEoJ
You've read my exchange with Limi, too. The bug to restore primary ("second party", not just "third party") progress status, anywhere in the UI and specifically in the right of the awesomebar, was not fixed for four betas and was looking likely not to get fixed in Firefox 4 at all.
I don't find that lack of fixing to be particularly accountable design/implementation ownership (and I do not care about finger-pointing between design and front-end implementation people), unless the bug wasn't very important.
But the bug was important. We know because many of our users said so. Ignoring them, or dismissing them as beta users, techies, or otherwise, and not responding the particular use-cases that progress and link-hover status in the periphery served, was wrong. Where's the accountability for that?
It's way late to be fixing the bugs remaining in the full filtered-progress-status/hovered-link on the right in the awesomebar design. That design was never fully implemented in any beta. That design needs more beta testing, or some better way to prove itself. Or we need a yet better design before we get rid of the status bar.
A bunch of senior people in the project heard about this, including me. When conflicts rise to me, I stick my nose in. Believe me, I'd rather not. But I am accountable -- if you want to blame anyone among the many people who thought the status bar removal was a mistake and we needed to fix it to ship soon, you can blame me.
/be
Michael
> inside the tab bar, it trains the eye/brain system to look up, not down.
> What about a pop-up at the top right ?
See Bug 629915 (https://bugzilla.mozilla.org/show_bug.cgi?id=629915).
Paul [sabret00the]
>
> I don't find that lack of fixing to be particularly accountable design/implementation ownership (and I do not care about finger-pointing between design and front-end implementation people), unless the bug wasn't very important.
Paul [sabret00the]
>
> I don't find that lack of fixing to be particularly accountable design/implementation ownership (and I do not care about finger-pointing between design and front-end implementation people), unless the bug wasn't very important.
Brendan Eich
> > You've read my exchange with Limi, too. The bug to restore primary ("second party", not just "third party") progress status, anywhere in the UI and specifically in the right of the awesomebar, was not fixed for four betas and was looking likely not to get fixed in Firefox 4 at all.
> >
> > I don't find that lack of fixing to be particularly accountable design/implementation ownership (and I do not care about finger-pointing between design and front-end implementation people), unless the bug wasn't very important.
See also Alex Faaborg's post here, where he agreed we should put back lower-left status (both progress and link-hover):
https://groups.google.com/d/msg/mozilla.dev.apps.firefox/1Rz8LO3qmpA/S0DL7LCr_y4J
Good to have Alex's agreement.
> I don't get this,
What don't you get? Why things went wrong last fall? Well, I didn't notice (busy with JS stuff), but reading the bugs and talking to people (including here, for you to read as well), it's clear enough what went wrong.
Not liking it != not getting it. I suspect you get it, but don't like it ;-).
> the design was laid out, the relevant bugs created, at which point surely the product manager has to be the one designating bugs to the paid staff?
It's too late! It is way past time to be designating bugs to the paid staff to be implemented before more than one beta release of Firefox 4. We are going to ship very soon, after as few betas as it takes to drive the beta hardblocker list to zarro and then ship confirming RCs.
> If there was a solution filed relatively closely to the removal of the functionality and it didn't get designated to the point that the lack of movement on it was used to implement non-signed off (by the UX team bugs), surely that in itself is a problem?
I can't parse this sentence. If you mean was it a big problem that the status bar was removed without implementing the replacement design fully and then promptly user-testing it last fall, you're right!
It is even moreso too late to fix that problem now. We're shipping soon. We need to get Firefox 4 out to all the people using 3.6 or even 3.5, which are no longer competitive browsers compared to the latest from other vendors.
/be
Gervase Markham
> Definitely not amongst the people who would comment in bugzilla, use a beta
> build, or send you a personal email. However our own market research (which
> is unfortunately all marked propriety and I can't start directly quoting
> here)
Only tangentially related, but: whose ear do I bend to make sure this
doesn't happen again?
I refuse to believe we can't find a market research company who will do
research for us and then let us <gasp> tell other people what they found
out. Having to keep it confidential does not lead to communal decisions;
it leads to a split between the paid and not-paid bits of our community.
Gerv
Mike Shaver
> I refuse to believe we can't find a market research company who will do
> research for us and then let us <gasp> tell other people what they found
> out.
That is not what Alex said; he said that he can't quote from it
directly. If you can find a good market research firm that will let
us share their work product verbatim, that would be great to know. I
don't know enough about market research firms to make such
recommendations myself.
(I don't know why your mail wasn't a private reply either, but maybe
because it would lead to a gap between thread members and not.)
Mike
Foteos Macrides
news:a9edb8e1-7fcd-4e82...@glegroupsg2000goo.googlegroups.com...
> [snip]
> See also Alex Faaborg's post here, where he agreed we should put back
> lower-left status (both progress and link-hover):
>
> https://groups.google.com/d/msg/mozilla.dev.apps.firefox/1Rz8LO3qmpA/S0DL7LCr_y4J
>
> Good to have Alex's agreement.
I suspect you will avoid unnecessary discontent among one or another set of
Firefox users by making the handling of "link-hover" and "progress" via a
lower-left "tooltip-like popup" (basically like the Chrome browser), versus
at right within the location bar, an option. I am among those who pay
careful attention to that messaging, and do find the shifting of the "start
position" within the location bar for the ltr strings extremely bothersome.
Also I have not experienced a "training effect" but rather am becoming more
and more bothered by that design. I can, however, see how users who don't
pay close attention to that messaging might prefer it there, never obscuring
any document content.
So, IMHO, indeed proceed with making it a lower-left "tooltip-like popup"
for a prompt 4.0 release, and plan on a "within the location bar" option
(not forced change) if full feasibility is established thereafter.
If a "time threshold" implementation is successfully developed for a within
the location bar option, which would be desirable to minimize the problem of
shifting left start positions for ltr strings, it should not be used for the
lower-left "tooltip-like popup" option, or the time should be configurable.
Fote
--
Michael
Michael
Dao
> Is it correct that the status info overlay should display in pop ups? Is it intended?
Yes, see bug 603594.
Michael
Something I have been wondering about is if we could have the reload/stop button inside the locationbar in pop-ups? If you have it in the locationbar in the main window, maybe it should also appear in the locationbar in a pop-up?
Is this something which can easily be put it in?
Michael
Even though I really liked having the URL preview in the location bar, I want to move on and think about solutions. This is not about a questioning a current bug, more of an new idea or enhancement.
By the way, I consider myself an experienced user with knowledge and practice in web design and web development.
With having URL preview in location bar between Firefox b7-b10 and from b11pre having status info overlay in content area, there was an separation between considering opening a URL (hover/preview) and page loading state (connecting, loading etc), this information was displayed to the user in two different places. Which was a good thing as an indicator what is going on and what activity browser is doing.
Having preview and status in same place is maybe hard to understand for a non-experienced user in regards to what is happening and what browser is doing. Firefox 3.6 had status bar with this functionality, I'm trying to see beyond that. There is no status bar anymore and that is moved to status info overlay and add-on bar.
Too display a difference between preview URL when hovering a link and status info during page loading, I think is something good and it could help non-experienced users to understand better what she/he is doing and then what is happening or browser is doing.
Therefore I would like to suggest an idea! To have different background color for preview URL and status info. For example have a green background (maybe same color as go button in location bar or lighter than that) and for status info keep the grey background or use an light yellow color background. Main thing would be to display a different color depending on preview or status.
Question to UX team, what do think about this idea?
Michael
Daniel Cater
Firstly I'll comment on this particular change, and then on the more systemic influence of the design team.
I initially commented (https://bugzilla.mozilla.org/show_bug.cgi?id=587908#c141) on the basis that now less of the target URL was visible than before, and also that less of the _current_ URL was visible than before. It was also possible to permanently obscure part of the current location (I just un-obsoleted a couple of testcases in that bug).
The muscle memory was difficult to shift, but eventually it did (I use nightlies for most of my browsing), and although I didn't like the new design, I got used to it. I then commented a few months later (#c161). This is because I started working for a new company and starting using Fx 3.6 daily. The pain was almost physical between using the nightlies at home, and 3.6 at work. For the first 10 minutes of browsing at each place, I would be stuck in the previous muscle memory mode. At work, I'd be looking for link destinations in the location bar. When I got home, I'd be looking for them in the status bar area until I re-wrote my memory again.
I am in favour of giving content more screen space (to an extent), but I really couldn't see the advantages of this approach over all of the disadvantages. A weak "the location bar should be for all location information" argument didn't sway me.
What annoys me is how much time and effort was spent on this without this kind of discussion happening first. Obviously you don't want every bug to be a bikeshed story, but this is a fundamental change in a behaviour that has been fairly constant across browsers and versions for over a decade. Just look at the amount of dependencies, regressions and follow-ups filed against the relevant bugs!
I said: "In general I feel that the amount of effort required by a long term user to adapt to UI/UX changes has been underestimated for the sake of idealistic design," to which Limi replied: "The thing is, you could say the same about the [...] AwesomeBar" (#c163). I think this shows a lack of in-depth analysis. The awesomebar had concrete advantages as well as, crucially, being _adaptive_. If you wanted the old behaviour, you could have it in a couple of clicks (#c164).
The prime example of what you mentioned about bugs not being fixed for the sake of the bigger picture is bug 451833 (https://bugzilla.mozilla.org/show_bug.cgi?id=451833) for the sake of bug 588270 (https://bugzilla.mozilla.org/show_bug.cgi?id=588270). Dão initially patched it over 4 years ago! The idea has also had testing as an extension and in an alpha, and has since been successfully implemented by IE, Chrome and Opera. It's better than the status quo and I think it's better than the mirage of the future. I believe that there has since been a hint of NIH about it, wanting to come up with a novel way of displaying the information rather than be seen to be copying Chrome (despite having prior art).
Other problem bugs include bug 461184 (https://bugzilla.mozilla.org/show_bug.cgi?id=461184) where useful text was removed to solve a non-existent problem. The location bar used to mention that you could search your bookmarks and history which was a nice way to learn about the awesomebar and to explain its, perhaps unexpected, behaviour if you have moved from a browser which didn't have such a feature. It now says "Go to a Web Site"... This is to cater for the people who didn't know that the location bar could be used for that purpose. This text appears when a new blank tab appears. If a user doesn't know how to use the location bar what are the chances of them opening a new blank tab? People don't tend to self-learn in their very first computer experience. Someone shows them how to get started. Maybe this will change as time goes on, but it hasn't yet so these kinds of changes shouldn't be made.
It seems likely that bug 465086 (https://bugzilla.mozilla.org/show_bug.cgi?id=465086) and bug 455694 (https://bugzilla.mozilla.org/show_bug.cgi?id=455694), both big usability wins, will miss the boat despite having initial patches over 6 months ago. They may be quite complex technically, but like domain highlighting, they're fairly unanimous wins which should have been prioritised over more controversial changes.
I think it's a shame when the "benevolent dictator" rule has to come in to play (although clearly it's necessary). It's there for when other levels in the hierarchy fail, but they shouldn't have failed to come to a solution. At worst, I think this particularly change should have stayed in for one beta cycle at most. At best, it should have remained a concept.
I should say that many of the UI changes for Firefox 4 are great. I like tabs on top, replacing the bookmarks toolbar with the bookmarks button, replacing the menu bar with the Firefox button, and the bi-directional throbber with a state for "connecting".
Thanks.
Foteos Macrides
news:2baed5ad-9b3f-4f5c...@glegroupsg2000goo.googlegroups.com...
> [snip]
> have different background color for preview URL and status info.
Colors could raise issues in this context but perhaps it would be desirable
to have a small arrow icon for the statuspanel, homologous to the arrow that
demarked the start of the preview URL for the within-location-bar design.
If so, perhaps a small icon for indicating status info also might be
desirable so that both types of strings have the same start position in the
statuspanel. The icon positioning would be full-left or full-right in
conjunction with the left or right positioning of the statuspanel for ltr or
rtl strings.
My main concern about the within-location-bar design was that it violated
basic principles for handing ltr, as opposed to rtl, strings (and I suspect
others who deal with both types of strings would not easily develop a
"training effect" for that design). Because the changes occur in
conjunction with intentional activity of the user after the current document
has loaded, and are more-or-less transient, it seem likely to me that fully
replacing/restoring the icon and URL for the current document with
presentations of the other icon+string pairs using the same positioning
principles as for the statuspanel in current nightlies would be fine (though
one might need to see that in action to be certain).
Also, I personally would not consider it a problem to do that for the
preview URLs but still use the statuspanel for status info if efforts to
deal with the issues concerning status info within the location bar don't
eventually work out. But when the location bar is absent, as in full-screen
mode, the preview URLs should be displayed in the statuspanel. Not
encouraging users to pay attention to the targets of links is inadvertently
encourage them to make themselves more vulnerable to viruses and other
mischief, IMHO.
Fote
--
Jeremy Morton
Why do you presume to know how much of a 'clue' 'most people' have about
what appears in their browser? Have you done studies? Links please?
Asa Dotzler
As a matter of fact, yes. I've sat in on more Web browser usability
studies than most people participating in this group (6 over 10 years. 5
at Netscape and 1 at Google.) None of those are published so you'll
either have to trust my wisdom or not. It's up to you.
- A
Asa Dotzler
Oops, and I left off the many sessions where I sat and listened in on
browser support tech calls and I left off the the years of reading
browser support forums and I left off the decade of actually making
browsers. Those are each also quite informative, though not as carefully
sampled as the usability studies.
So yes, I feel comfortable that I have a clue how most people understand
their browsers. It's certainly more of a clue than most.
- A
Michael
Michael
Philip Chee
The lurkers support you in <s>email</s> private usability studies?
Didn't Brendan say something earlier about dividing the community into
those with access to these secret studies and those that don't?
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.
Asa Dotzler
> On Mon, 07 Feb 2011 15:36:18 -0800, Asa Dotzler wrote:
>> On 2/7/2011 11:59 AM, Jeremy Morton wrote:
>>> On 31/01/2011 22:52, Asa Dotzler wrote:
>>>> Sorry, I should have been clear. I meant in terms of relative (to other
>>>> items that were front and center) importance for most people (who have
>>>> no clue what any of it means actually means beyond "activity").
>>>>
>>>> - A
>>>
>>> Why do you presume to know how much of a 'clue' 'most people' have about
>>> what appears in their browser? Have you done studies? Links please?
>>
>>
>> As a matter of fact, yes. I've sat in on more Web browser usability
>> studies than most people participating in this group (6 over 10 years. 5
>> at Netscape and 1 at Google.) None of those are published so you'll
>> either have to trust my wisdom or not. It's up to you.
>
> The lurkers support you in<s>email</s> private usability studies?
>
> Didn't Brendan say something earlier about dividing the community into
> those with access to these secret studies and those that don't?
>
> Phil
Phil, there's nothing "secret" about anything I've referenced here.
Unless you're going to publish accounts of all of your life's
experiences then take your trolling elsewhere.
- A
EE
responsible for the delay.
Daniel Cater
> Yes, actually! You can see the usage statistics here:
>
> https://addons.mozilla.org/en-US/statistics/addon/235283
>
> The Add-On has had approximately 45,000 downloads, and enjoys an average
> active daily user count of 10,000 or so. The average active daily user
> account of beta users is about 2.1M, so we're looking at about 0.4% of
> our testing audience*
Are there publicly available data for the ADU of Firefox 4 Beta itself? I would like to see the drop-off rate for each beta. My guess is that the ADU for that extension is lower than expected due to: a) people just giving up on the beta program, and b) people not being aware that the extension exists.
Obviously you cannot infer from the data above that 99.6% of users accept the change.
Daniel Cater
Ron Hunter
Many users probably just assume it is gone, and won't seek the replace
it. Others will look, but not find it because of less than stellar
features on the add-ons pages for searching. Many probably won't care.
However, I suspect that if the program were released without the
changes that are in the current nightlies, there would be a lot of
unhappy users. Just my feelings as there is no way to really tell if a
user is looking at the URL target display, or the status monitoring.
Sometimes you just have to guess.
Albert Albs
What type of agreement you are talking here? Do you guys put agreement with big companies to remove the STATUS Bar?!!!
Whatever you say using the additional addon will consume more memory and process. And it will take down the Firefox’s market share. I’m suspecting this issue with big boys in the Browser market.
Anybody really loving Default “STATUS Bar” in Firefox, Please vote here:
http://firefox.uservoice.com/forums/57440-firefox-4-beta/suggestions/1476773-bring-back-full-status-bar-functionality
Keep on Knock the door until they realize its necessity.
Glottis
> Yes, actually! You can see the usage statistics here:
>
> https://addons.mozilla.org/en-US/statistics/addon/235283
>
> The Add-On has had approximately 45,000 downloads, and enjoys an average
> active daily user count of 10,000 or so. The average active daily user
> account of beta users is about 2.1M, so we're looking at about 0.4% of
> our testing audience*
I'm one of the guys who misses and wants back the status bar. And I
don't use the status-4evar addon, just because I want to see what
changes are being done in the beta phases/nightlies. So these
statistics aren't 100% accurate.
In FF4 beta now I have the addon bar, plus an overlay/popup for links
and status messages. Remind me please, why was the status bar removed?