replacing the status bar with the add-on bar
Dietrich Ayala
(In reply to comment #128)
>
> > It doesn't help
> > users at all - they're still stuck with add-ons in the bar that they can't move
> > or disable.
>
> Annoying add-on authors enough to drop their add-ons doesn't help users either.
As you say below, if users care enough, they'll ask the developers of
their add-ons to update. And we shouldn't coddle developers who care
so little about their users. That leads to an unhealthy ecosystem
where the development of Firefox slows because we don't ever want to
ask add-on developers to make any changes at all.
We're just moving to toolbar XUL/APIs, which have been around for a
very long time. We are generally very careful about not breaking
add-on code, but occasionally it's going to happen. We'll help as much
as we can, with blog posts and MDC pages and code samples, but yeah
sometimes they're going to have to do a little work. Luckily, it's
rare.
> > The XUL changes are not difficult.
>
> Customizable elements necessarily add complexity to code that currently assumes
> that the elements are always there. It's very often not going to be just a
> trivial XUL change. In fact, a XUL change will never enough if you want the
> customizable element to be in the UI as soon as the user installs the add-on.
Sorry, my mistake - yes script changes are likely required. I said
that earlier, and didn't intend to simplify it when answering you.
Regardless, the changes are absolutely not the lunatic fringe of
add-on development. Toolbar button development is very well-trodden
ground.
> > And we're at the breakingest place we've
> > been, or are going to be, for years. There's never a good time to make breaking
> > changes, but this is about the best it's going to get.
>
> I don't see a compelling reason to break things here at all. If an add-on
> doesn't want customizable elements, so be it. If users care enough about being
> able to move things around they'll complain to the authors or move to an add-on
> that offers this. We don't need to enforce this, just provide the tools.
You are not the target audience of this development, so whether you as
a user cares bears little weight here - as developers, we do not
adequately represent the majority of Firefox users. Also, your
argument works both ways: If users care, they'll prompt their add-on
developers to update to use the add-on bar.
With regard to enforcing vs providing the tools - I think it's our
responsibility to provide a development environment that encourages
add-on developers to do things in ways that are friendly to users. On
rare occasion we need to take painful steps to do this, in order to
re-orient for the next few years.
Also, the tools are still there for add-on devs to add a status bar
back for the themselves to be added to, if they really want to, and
they think it's the best thing for their users.
johnjbarton
> Moving conversation from bug 574688 to DAF for broader feedback.
>
> (In reply to comment #128)
>>
>>> It doesn't help
>>> users at all - they're still stuck with add-ons in the bar that they can't move
>>> or disable.
>>
>> Annoying add-on authors enough to drop their add-ons doesn't help users either.
>
> As you say below, if users care enough, they'll ask the developers of
> their add-ons to update. And we shouldn't coddle developers who care
> so little about their users. That leads to an unhealthy ecosystem
> where the development of Firefox slows because we don't ever want to
> ask add-on developers to make any changes at all.
What leads to an unhealthy ecosystem is gratuitous comments about how
much addon developers care about their users. I don't think you are in
any danger of coddling add-on developers so you don't need to worry
about that.
>
> We're just moving to toolbar XUL/APIs, which have been around for a
> very long time. We are generally very careful about not breaking
> add-on code, but occasionally it's going to happen. We'll help as much
> as we can, with blog posts and MDC pages and code samples, but yeah
> sometimes they're going to have to do a little work. Luckily, it's
> rare.
As pointed out on the bug, the issue here is not breaking changes, it's
making this change way late in the beta process. It does not help that
it seems to be an improvement of almost no consequence to users, since
the new addon tool bar will be in the same place and size as the statusbar.
Badgering add-on developers to update during the beta phase but making
breaking changes at b7 is the issue here. Going on the counter attack
does not help us feel better about it.
jjb
Dao
> As you say below, if users care enough, they'll ask the developers of
> their add-ons to update. And we shouldn't coddle developers who care
> so little about their users.
I find this almost offending. I'm an add-on developer myself and very
much care about my users. When they'll beg me to make my status bar item
customizable I will consider this, but right now this isn't worth my time.
> That leads to an unhealthy ecosystem
> where the development of Firefox slows because we don't ever want to
> ask add-on developers to make any changes at all.
This doesn't really have much to do with the topic. An empty <statusbar
id="status-bar"/> bears close to zero maintaining cost and wouldn't slow
development of Firefox down. The fact that we can and should ask add-on
developers to make changes from time to time doesn't justify each
particular case.
> We're just moving to toolbar XUL/APIs, which have been around for a
> very long time.
Doesn't make them less painful. The XUL overlay for the status-bar is
super easy, hard to beat.
> You are not the target audience of this development, so whether you as
> a user cares bears little weight here - as developers, we do not
> adequately represent the majority of Firefox users. Also, your
> argument works both ways: If users care, they'll prompt their add-on
> developers to update to use the add-on bar.
Right, that's exactly what I said. Users will do that when they feel
strongly about it, so we don't need to.
> With regard to enforcing vs providing the tools - I think it's our
> responsibility to provide a development environment that encourages
> add-on developers to do things in ways that are friendly to users. On
> rare occasion we need to take painful steps to do this, in order to
> re-orient for the next few years.
I'm all for encouraging them. As I understand it, "encouraging" would
mean to provide the tools (better versions of them, really) rather than
enforcing them.
> Also, the tools are still there for add-on devs to add a status bar
> back for the themselves to be added to, if they really want to, and
> they think it's the best thing for their users.
This misses the point. I'm not suggesting we put the status bar as we
know it in the add-on bar, which an add-on could do of course. I'm
suggesting we keep an empty <statusbar id="status-bar"/> as an overlay
target.
Dietrich Ayala
> What leads to an unhealthy ecosystem is gratuitous comments about how
> much addon developers care about their users. I don't think you are in
> any danger of coddling add-on developers so you don't need to worry
> about that.
It wasn't gratuitous at all. I was responding to Dao's assertion that
we will all just drop development of our add-ons because of this
change. To do that seems to me to not care very much.
> As pointed out on the bug, the issue here is not breaking changes, it's
> making this change way late in the beta process. It does not help that
> it seems to be an improvement of almost no consequence to users, since
> the new addon tool bar will be in the same place and size as the statusbar.
It's also collapsed by default, if there are no add-ons installed
there. Which is a difference for a lot of users.
> Badgering add-on developers to update during the beta phase but making
> breaking changes at b7 is the issue here. Going on the counter attack
> does not help us feel better about it.
We're all here working to make a better Firefox. No one is trying to
attack anyone. And I'm not on some personal crusade here. I'm working
on a bug that's part of the bigger plan for the Fx4 theme, that lots
of people put thought into, and Boriss blogged about a bunch of times.
al...@yahoo.com
1) Navigation progress messages
2) Navigation progress bar (still needed as tab bar can be hidden)
3) Link addresses
I take it these are not meant for the add-on bar? These are very useful and
should be retained. Why must the status bar be removed?
Dietrich Ayala
On Sep 16, 10:05 pm, Dao <d...@design-noir.de> wrote:
> I find this almost offending. I'm an add-on developer myself and very
> much care about my users. When they'll beg me to make my status bar item
> customizable I will consider this, but right now this isn't worth my time.
I'm an add-on developer too. You cut out the part I was responding to,
where you said add-on devs (you and me!) will drop all development of
their add-ons because of this change, which is pretty crappy to their
users. I'm glad you're not one of those people you were talking
about :)
> I'm all for encouraging them. As I understand it, "encouraging" would
> mean to provide the tools (better versions of them, really) rather than
> enforcing them.
The SDK makes it easy to build customizable add-ons. So does the
toolbar code. We're only changing the way add-ons get onto the bar.
It's not really that hard. You're acting like we making everyone
switch to Java or something.
> > Also, the tools are still there for add-on devs to add a status bar
> > back for the themselves to be added to, if they really want to, and
> > they think it's the best thing for their users.
>
> This misses the point. I'm not suggesting we put the status bar as we
> know it in the add-on bar, which an add-on could do of course. I'm
> suggesting we keep an empty <statusbar id="status-bar"/> as an overlay
> target.
I feel like we're still in the same situation, where it's a block of
things the user can't move around or change if they want to. Maybe if
we wrapped it in a toolbaritem. But then users are wondering why the
heck they can only move these unrelated add-ons as a block.
Dietrich Ayala
> What about native Fx status bar content:
>
> 1) Navigation progress messages
> 2) Navigation progress bar (still needed as tab bar can be hidden)
> 3) Link addresses
>
> I take it these are not meant for the add-on bar? These are very useful and
> should be retained.
They've all been moved to the navigation area in Firefox 4, where your
eyes are already spending time in those types of activities.
> Why must the status bar be removed?
The status bar is not being removed, it's being replaced by a toolbar
that's in the same location. There are previous threads in this list
about it.
Thomas Stache
> What about native Fx status bar content:
>
> 1) Navigation progress messages
I never felt these were helpful, nowadays they mostly notify about 3rd
party scripts and resources being loaded. The fraction-of-a-second
"Connecting" message is also not meaningful for most users.
> 2) Navigation progress bar (still needed as tab bar can be hidden)
Is in the Location Bar since last nightly.
> 3) Link addresses
Is in the Location Bar since last nightly.
>
> I take it these are not meant for the add-on bar? These are very useful and
> should be retained. Why must the status bar be removed?
Because the UX and visual designers and the product management decided
to have it. Firefox development is no democracy.
al...@yahoo.com
news:82a3746b-e747-4037...@g21g2000prn.googlegroups.com...
On Sep 16, 10:47 pm, <al...@yahoo.com> wrote:
> What about native Fx status bar content:
>
> 1) Navigation progress messages
> 2) Navigation progress bar (still needed as tab bar can be hidden)
> 3) Link addresses
>
> I take it these are not meant for the add-on bar? These are very useful
> and
> should be retained.
They've all been moved to the navigation area in Firefox 4, where your
eyes are already spending time in those types of activities.
_________________________________________________________
I just tried the latest minefield
1) Navigation progress messages are still in the status bar, if you remove
it, where are they going to go?
To answer another comment, they are absolutely useful, especially if there
is a problem/slowdown, you can tell at what stage it is: dns, connection,
retrieval
2) The new progress bar (thin blue line along the bottom border of the
urlbar) especially when it flashes quickly, looks more like a visual
glitch/artifact. It's too thin and too long, barely recognizable as a
progress bar.
Alexander Limi
> I just tried the latest minefield
>
> 1) Navigation progress messages are still in the status bar, if you remove
> it, where are they going to go?
>
> To answer another comment, they are absolutely useful, especially if there
> is a problem/slowdown, you can tell at what stage it is: dns, connection,
> retrieval
>
The progress bar will show these. Right now it doesn't show the DNS/server
lookup stage, but that's planned.
> 2) The new progress bar (thin blue line along the bottom border of the
> urlbar) especially when it flashes quickly, looks more like a visual
> glitch/artifact. It's too thin and too long, barely recognizable as a
> progress bar.
>
We're still experimenting with the look here, I agree that it's too subtle
and doesn't work the way we want it to, yet. This late in the betas we have
to land things gradually and add polish a bit later. There's a lot of visual
tweaks we can do to improve it significantly, and Stephen Horlander is
experimenting with some additional treatments.
--
Alexander Limi · Firefox UX Team · http://twitter.com/limi · http://limi.net
Alexander Limi
> The progress bar will show these. Right now it doesn't show the DNS/server
> lookup stage, but that's planned.
>
And here's an animation showing it:
http://www.stephenhorlander.com/pages/progress-bar-line-mockup/progress-bar-line-states.html
al...@yahoo.com
I am asking about the the textual progress messages currently shown in
the status bar. looking up, connecting, transferring, done, etc...
How can the thin progress line show them? This animation shows
different modes of progress line flashing
Are you trying to say that this obfuscated light show is supposed to
take their place?
Dao
> On Sep 16, 10:05 pm, Dao <d...@design-noir.de> wrote:
>> I find this almost offending. I'm an add-on developer myself and very
>> much care about my users. When they'll beg me to make my status bar item
>> customizable I will consider this, but right now this isn't worth my time.
>
> I'm an add-on developer too. You cut out the part I was responding to,
> where you said add-on devs (you and me!) will drop all development of
> their add-ons because of this change, which is pretty crappy to their
> users. I'm glad you're not one of those people you were talking
> about :)
Dropping is always going to be an option. I do want to support my users,
but there's only that much time I can invest. Even if I had the time it
would better be spent on features my users have asked me for. My users
haven't asked for the UI item to be movable yet, so the cost/benefit
ratio of making my add-on support this seems pretty bad.
>> I'm all for encouraging them. As I understand it, "encouraging" would
>> mean to provide the tools (better versions of them, really) rather than
>> enforcing them.
>
> The SDK makes it easy to build customizable add-ons. So does the
> toolbar code. We're only changing the way add-ons get onto the bar.
> It's not really that hard. You're acting like we making everyone
> switch to Java or something.
It seems like you're still underestimating the pain that's involved with
customizable toolbars. I keep minusing patches because our own
developers miss things related to that.
The SDK makes it easy to add the UI item but in my case it doesn't help
me much with the underlying code, so switching to that has a
non-neglectable cost similar to dealing with the customizable toolbar.
>>> Also, the tools are still there for add-on devs to add a status bar
>>> back for the themselves to be added to, if they really want to, and
>>> they think it's the best thing for their users.
>>
>> This misses the point. I'm not suggesting we put the status bar as we
>> know it in the add-on bar, which an add-on could do of course. I'm
>> suggesting we keep an empty <statusbar id="status-bar"/> as an overlay
>> target.
>
> I feel like we're still in the same situation, where it's a block of
> things the user can't move around or change if they want to.
It's not the same situation in that we offer customizability for the
add-on bar. Add-on developers can take advantage of this when the
benefit outweighs the cost for them. Meanwhile we should lower the cost,
i.e. work on a sane API for extending customizable toolbars, ideally as
trivial as XUL overlays.
EE
Are you saying that there will be no status bar? It is very useful to
be able to see where a link will go before you click it. Why destroy
that capability?
Johnathan Nightingale
> On 16.09.2010 17:59, Dietrich Ayala wrote:
>> I'm an add-on developer too. You cut out the part I was responding
>> to,
>> where you said add-on devs (you and me!) will drop all development of
>> their add-ons because of this change, which is pretty crappy to their
>> users. I'm glad you're not one of those people you were talking
>> about :)
>
> Dropping is always going to be an option. I do want to support my
> users,
> but there's only that much time I can invest. Even if I had the time
> it
> would better be spent on features my users have asked me for. My users
> haven't asked for the UI item to be movable yet, so the cost/benefit
> ratio of making my add-on support this seems pretty bad.
>
>> The SDK makes it easy to build customizable add-ons. So does the
>> toolbar code. We're only changing the way add-ons get onto the bar.
>> It's not really that hard. You're acting like we making everyone
>> switch to Java or something.
>
> It seems like you're still underestimating the pain that's involved
> with
> customizable toolbars. I keep minusing patches because our own
> developers miss things related to that.
> The SDK makes it easy to add the UI item but in my case it doesn't
> help
> me much with the underlying code, so switching to that has a
> non-neglectable cost similar to dealing with the customizable toolbar.
I love me some technical debate, but this feels like people gainsaying
each other. I hold these truths to be self-evident:
1) There is a cost for addons to migrate - it's not free. I don't
think it's likely to be *very* expensive for most addon authors, but
it's not free either.
2) This isn't a capricious nor a malicious change - it is a deliberate
attempt to put ourselves on better design footing long term, and the
pain that it involves has been part of that calculus.
I don't think the outcome of this thread where we feel grumpy or
defensive with each other is a good one. Here are some outcomes I
would dearly like more, I wonder how people feel about working towards
them?
Outcome: A pointer to clear migration guidelines that speak to the 80%
case(s) for addon authors just looking to get the minimum done.
Outcome: Alternate, constructive suggestions for how to preserve the
intent of Truth #2 while minimizing migration pain
I know the outcome that some people are working for in this thread is
to just kill the change altogether. We're not going to get to that
outcome by just dismissing the work of the people who have gotten us
this far, though.
Anyone feel like working on the constructive outcomes? Are they
perhaps already done and I haven't seen them?
J
---
Johnathan Nightingale
Director of Firefox Development
joh...@mozilla.com
Matthew Turnbull
https://bugzilla.mozilla.org/show_bug.cgi?id=587908
On 09/16/2010 03:12 PM, EE wrote:
> Are you saying that there will be no status bar? It is very useful to
> be able to see where a link will go before you click it. Why destroy
> that capability?
--
Bluefang-Logic Networks:
Scaled for your pleasure.
Dietrich Ayala
> case(s) for addon authors just looking to get the minimum done.
I've got this going, will try to finish it up tomorrow.
Dao
add-ons overlaying the statusbar would magically continue to work. This
was supposed to be a constructive proposal. It would kill the
sledgehammer attitude of the change but not the change itself.
al...@yahoo.com
> On Sep 16, 10:47 pm,<al...@yahoo.com> wrote:
>> What about native Fx status bar content:
>>
>> 1) Navigation progress messages
>> 2) Navigation progress bar (still needed as tab bar can be hidden)
>> 3) Link addresses
>>
>> I take it these are not meant for the add-on bar? These are very useful and
>> should be retained.
>
> They've all been moved to the navigation area in Firefox 4, where your
> eyes are already spending time in those types of activities.
>
Can you please clarify what are the plans for the textual navigation
progress messages? The answer that has been provided "The progress bar
will show these." is not clear.
Alex Faaborg
Firefox functionality from the status bar so that we can create a place that
add-on authors can call their own (and we can create an open area where
users can add a very large number of add-ons). Some of these changes have
landed already, and some are still coming, so here is a quick review just to
bring everyone up to speed:
1) progress bar: This has been moved to the location bar, so that it has a
close mapping to the controls that effect progress (stop, reload), and the
thing that the progress relates to (the URL)
2) hyperlink target on hover: This has been moved to the right side of the
location bar since so that it can visually convey to the user that they are
about to shift from location A to location B. This should also help to
reinforce to users that the location bar is the place for them to inspect
location information.
3) status text (trying to connect vs. trying and being successful): This
hasn't landed yet, but our plan is to visually convey a difference between
Firefox trying (and failing) and Firefox trying (and succeeding). An
example of this difference in another product is how the throbber in Chrome
spins backwards in grey, and then forwards in blue. There are a number of
ways for us to represent this difference visually, and we feel that in
general they make more sense than a blur of text that changes so quickly
it's impossible for a human to actually read.
4) popups blocked: Initially we will just be relying on the notification
bars to provide users with access to blocked pop-ups. We've found that
currently a lot of users don't actually realize that they also have access
to blocked popups from the status bar, so this redundant access isn't likely
to be extremely missed. Future work on our popup blocking interface can be
found in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=588317
5) lock icon: During development of Firefox 3 we decided to switch our SSL
interface away from being about "security" towards being about "identity."
The rationale was that users are interpreting the lock icon to mean "good"
when in reality it might just mean that you have an encrypted connection to
criminals. We switched to having the site identity block, and using
stronger but still neutral colors for SSL (blue). Having the lock icon
persist in the status bar was a somewhat strange compromise that didn't
really mesh with our overall strategy of wanting users to focus on who they
were actually communicating with, instead of relying on a potentially false
metaphor.
6) download status: This work is still in progress, but Limi has a good post
about our future plans for our downloading interface here:
http://limi.net/articles/improving-download-behaviors-web-browsers/
In the meantime, each OS provides an indicator of downloads being complete
(task bar item glowing, dock icon bouncing, panel notification appearing).
To monitor the progress of the download in real time, the user can view the
download progress bar in the separate downloads window. This information
does not really need to be redundant in our interface.
That should be everything, but if I missed any of the current functionality
of the status bar please let us know.
-Alex
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
gavin
> I proposed putting a stub <statusbar> element on the add-on bar so
> add-ons overlaying the statusbar would magically continue to work.
This sounds like a good proposal to me. It would mean that some addons
will continue to work without modification, while still allowing
addons to make use of the new system to offer additional
functionality. I'm not sure I understand the opposition to it - it
would mean that we're not "forcing" addons to implement the
customizability (by breaking them if they don't), but I don't think
the benefits to customizability are important enough to clearly and
obviously outweigh the costs of extensions breaking (for both users
and developers, at this stage in the release cycle, etc.).
Gavin
Peter Lairo
that I don't like it, at all. Before I explain why, here's what the URL
bar looks like in the current nightly build: You (often) have the
largish site identity area (taking up space - you'll see the
significance in a second), then you have the actual URL, and then - when
you hover over a link - the URL gets *truncated* and a right-pointing
triangle (">") (whose meaning is not clear enough to novices) appears
(BTW: often with too much empty space after the URL - aha, because it's
right-aligned = confusing), and after that is the URL of the link
target, which is in a *harder to see gray* and - more importantly -
which is *also truncated*. I think that too much stuff is being crammed
into the URL bar - all in a needless crusade to eliminate the Status
Bar, which has what, a "whopping" height of 20 pixels. And which can be
turned off by vertical-space-desirees.
I also think that *many* add-on developers (incl. prominent add-ons such
as AdBlockPlus, ForecastFox, etc.) will be making the (new) "Status Bar"
*visible* again, and thus making the impact of the problematic URL Bar
even less necessary.
Removing the Status Bar and putting the kitchen sink into the URL Bar
are nice *sounding* ideas, to be sure. But the inevitable implementation
is a confusing and less usable UI-mess. What normal user is supposed to
understand all that information crammed into one place? Especially if
their Status Bar is there, and empty, except for their favorite add-on.
BTW: Why was the (otherwise cool) page-loading-progress-bar but on the
*bottom* of the URL-Bar? I almost didn't notice it there (until I *read*
about it). Have you tried putting it on the *top* of the URL Bar for a
few days in the nightly builds, to *see* if that might be better?
On Thu. 16.09.2010 21:32, Matthew Turnbull wrote:
> Links targets will be shown in the location bar.
> https://bugzilla.mozilla.org/show_bug.cgi?id=587908
>
> On 09/16/2010 03:12 PM, EE wrote:
>> Are you saying that there will be no status bar? It is very useful to
>> be able to see where a link will go before you click it. Why destroy
>> that capability?
>
--
Regards,
Peter Lairo
Bugs I think are important:
https://bugzilla.mozilla.org/show_bug.cgi?id=250539
https://bugzilla.mozilla.org/show_bug.cgi?id=391057
https://bugzilla.mozilla.org/show_bug.cgi?id=436259
https://bugzilla.mozilla.org/show_bug.cgi?id=446444
Islam: http://www.jihadwatch.org/islam101/
Israel: http://www.jewishvirtuallibrary.org/jsource/myths2/
Church of the Flying Spaghetti Monster: http://www.venganza.org/
Anthropogenic Global Warming skepsis: http://tinyurl.com/AGW-Skepsis
al...@yahoo.com
news:mailman.3670.1284669980...@lists.mozilla.org...
> 3) status text (trying to connect vs. trying and being successful): This
> hasn't landed yet, but our plan is to visually convey a difference between
> Firefox trying (and failing) and Firefox trying (and succeeding). An
> example of this difference in another product is how the throbber in
> Chrome
> spins backwards in grey, and then forwards in blue. There are a number of
> ways for us to represent this difference visually, and we feel that in
> general they make more sense than a blur of text that changes so quickly
> it's impossible for a human to actually read.
>
Please do not kill this functionality. It shows precisely what stage the
connection is in (name lookup, connecting, transfer ...) which is most
useful when things are slow/timing out/failing. Then it's not a blur of
text but quite readable. A bunch of flashing lights can't come close to
this in utility and clarity. You could make the status text stream a
customization widget, draggable to the new add-on bar.
This seems to come up again and again. Simplifying/dumbing-down the
interface for default use should not necessitate killing the useful features
people had grown accustomed to.
John J Barton
>
> Outcome: A pointer to clear migration guidelines that speak to the 80%
> case(s) for addon authors just looking to get the minimum done.
(In the interest of maximum team work, perhaps you could just leave off
"...just looking to get the minimum done." We're talking about folks who
are just about as far from lazy as one can imagine).
In addition to migration we need to know how to deal with multiple
versions. What will happen in FF4 if we leave the statusbar XUL in place
(for FF3.6)? Maybe it's all fine? I don't know.
> Outcome: Alternate, constructive suggestions for how to preserve the
> intent of Truth #2 while minimizing migration pain
I don't know what you mean here, but here are some suggestions:
1) Ship FF with statusbar collapsed="true" and have the addon
manager remove that attribute.
2) Ship FF4.0 with statusbar collapsed="true" but copy any additions
into the addon toolbar.
3) Put the FF4.0 statusbar into the addon toolbar so simple overlays
just work.
The problem with #1 and #2 as well as Dao's suggestion: users with both
statusbar and addon toolbar addons get a bad experience, two partly
filled bars right?
>
> I know the outcome that some people are working for in this thread is to
> just kill the change altogether.
The outcomes I am looking for are 1) migration guidelines 2) process
changes to avoid breaking changes late in the beta phase. If this change
arrived with a7 I would have no issue, but it's b7.
jjb
Dao
> The problem with #1 and #2 as well as Dao's suggestion: users with both
> statusbar and addon toolbar addons get a bad experience, two partly
> filled bars right?
No, you got me wrong. <statusbar id="status-bar"/> would be a container
in the add-on bar, not actually distinguishable by the user.
John J Barton
Excellent, seems like a win to me.
jjb
miken32
can I just put in my two cents as a plain old user? (Well, a plain old
user who builds his own nightlies and posts on newsgroups about web
browsers.)
This is a 15-year old convention getting tossed out for the sake of 20
pixels. Obviously it's a decision that's been made and it's done -- as
a previous poster said, this isn't a democracy. But it seems to me
that you could implement this addon bar without affecting the status
bar for those of us that want it. Don't allow addons to use the old
status bar if you want, hide it by default even, but leave the code in
place for users that are accustomed to seeing it.
None of the 6 "average" users I asked were bothered by the status
bar's real estate usage, and all identified it as the place they look
at to see what link they are about to click on. With all the phishing
warnings going around these days, I'd imagine people are looking more
than ever at links before they click on them. I know, it's moving to
the navigation box. And I'm sure in time we'll get used to not looking
at the status bar, but in the meantime -- probably for the next year
-- I'm going to be cursing at my browser every time I look down at the
status bar and it isn't there.
I won't pull out that old internet chestnut "you better change this or
you'll lose me as a user!!" because you won't, you'll just annoy me.
John Bird
approve. Its unobtrusively in the right of the address bar and anyone can
immediately see what it means. If the rest of the ideas work as nicely as
this its great. I always thought it odd having to look at the status bar
for some information such as progress and a hover link - as others say its
away from the address bar. And the padlock there was probably never noticed
by most.
Question - While a site is loading, what will happen to the messages like
"waiting for www.xyz" etc I see its still in the status bar for now.
Useful for me, as I like seeing for example where the delays in loading are
coming from - eg on Roger Ebert film reviews there are advertising sites
taking quite a bit of time even though there are hardly any ads on the film
reviews. I bet thats important for web site developers.
On the progress bar, that is good. I notice on Windows 7 Aero with a
transparent window showing through the actual end of the progress bar can be
real hard to spot because it fades out....I presume you will alter that, or
it deliberate because its an inexact indicator anyway?
John Bird
Ron Hunter
developers, or users, think about it? Why not just say that?
I might have to avoid the support groups for a while when this takes
place as I really hate reading profane messages... sigh.
Dietrich Ayala
The resulting user experience is awkward and confusing:
There would be a chunk of add-ons on the bar that can't be moved around, and have a static order. Other add-ons you will install might show up to the left or right or both (depending on how we implement it - we could force it to the right).
If we wrap this stub in a <toolbaritem> then the set of statusbar add-ons can be customized as a set.. but there's no indication to the user why this block is an immutable whole.
johnjbarton
I disagree: the resulting user experience is reliable and predictable. I
don't want to support users moving the icon that opens our addon. This
kind of customization helps a tiny minority of users have a little fun
at the expense of a similar number of users accidentally mis-customizing
the UI. Its not worth it.
Do you want to support FF4 with both the addon toolbar and the statusbar
as it worked in FF3.6 so the user can have a highly customizable
browser? No, and for good reasons. Similarly I just want users to know
where to open Firebug and if the Firebug button is not there then it's
not installed.
jjb
Dao
> ----- Original Message -----
>> On Sep 16, 3:49 pm, Dao <d...@design-noir.de> wrote:
>>> I proposed putting a stub <statusbar> element on the add-on bar so
>>> add-ons overlaying the statusbar would magically continue to work.
>>
>> This sounds like a good proposal to me. It would mean that some addons
>> will continue to work without modification, while still allowing
>> addons to make use of the new system to offer additional
>> functionality. I'm not sure I understand the opposition to it - it
>> would mean that we're not "forcing" addons to implement the
>> customizability (by breaking them if they don't), but I don't think
>> the benefits to customizability are important enough to clearly and
>> obviously outweigh the costs of extensions breaking (for both users
>> and developers, at this stage in the release cycle, etc.).
>
> The resulting user experience is awkward and confusing:
>
> There would be a chunk of add-ons on the bar that can't be moved around, and have a static order. Other add-ons you will install might show up to the left or right or both (depending on how we implement it - we could force it to the right).
Yes, we could make it so that the group of unmovable items isn't in the
middle of movable ones. While customizing, the group of unmovable items
could be faded out. This is doable with relatively little effort. Yes, I
would volunteer to do it.
> If we wrap this stub in a <toolbaritem> then the set of statusbar add-ons can be customized as a set.. but there's no indication to the user why this block is an immutable whole.
This indeed sounds awkward and likely wouldn't work for many add-ons, as
they might break when the user removes a formerly permanent item rather
than just moving it. Some would even break as you move it around thanks
to XBL.
Ben Bucksch
> From a UX perspective we are in the process of migrating all existing
> Firefox functionality from the status bar so that we can create a place that
> add-on authors can call their own (and we can create an open area where
> users can add a very large number of add-ons).
I think you should not define the status bar to be the place, just that
there will be *a* place, and it's currently the status bar. Chrome feels
more lightweight in part because it has no status bar, so 3 of 4 window
borders around the page are just lines. It makes you feel that you see
*only* the page (not an app), with a bit of title bar stuff on the top.
> 2) hyperlink target on hover: This has been moved to the right side of the
> location bar since so that it can visually convey to the user that they are
> about to shift from location A to location B. This should also help to
> reinforce to users that the location bar is the place for them to inspect
> location information.
I like that idea a lot, it makes sense.
I don't particularly like the current implementation. trying to show
both URLs means you can't see either in full, and the background and
arrow changes result very nervous UI when I just move my mouse over the
page or click on a link. I don't think it's a good idea to desensitize
users by having flickering on every link click (even more so a mere
mouse move).
DaveG
here. I loathe the groups, generally speaking...
Copying from: https://bugzilla.mozilla.org/show_bug.cgi?id=574688#c133
--------------------------------------------------------------------------------------------------------------
The new addon bar is basically just a super status bar, but new and
not old.
Addons will need to be updated by their developers to handle this just
like the
oh so many other things which have broken stuff on the road to Firefox
4.0
final. Trust me, I'm the developer of Flagfox and I'll need to update
to handle
this too, just like the many other things that broke addons, including
another
one just recently (big time; full breakage from extractionless XPI
installation). It has to be done; please don't whine about it.
(In reply to Dão Gottwald in bug 574688 comment #125)
> Can we just put a non-removable <statusbar id="status-bar"/> on the add-on bar
> to ease the transition for add-ons?
Please, no compatibility hacks. The status bar is getting a nice
overhaul here,
and while the transition will take effort on the part of extension
developers
like myself, I'd much rather have a clean break here. The "status-bar"
ID
really needs to be completely gone forever or it'll just make the
transition
harder and messier. Extensions will need updates. It's best to make
them
crystal clear.
For what it's worth, part of the heightened sense of fear coming from
people
about changes came from a naming issue for the Firefox 4.0 development
cycle.
Generally speaking, the word "alpha" refers to development releases
with more
big changes to come and the word "beta" refers to development versions
that are
feature complete. Firefox 4.0 had some alphas before the version bump
from 3.7,
but all betas up until the 7th (unless there's another delay) are
really
alphas, technically speaking. If we get precise, Firefox 4.0 hasn't
had its
real first beta yet. That's why it ~feels~ like the rug is being
pulled out
from under some people, though it really isn't. All of this was planed
and
stated in advance. The naming and number of beta testers is just
confusing the
situation.
--------------------------------------------------------------------------------------------------------------
In the context of the bug the last paragraph above was off topic, but
here, I think it's the whole point.
DaveG
Hasse
fir...@lists.mozilla.org>, Alex Faaborg wrote...
> 3) status text (trying to connect vs. trying and being successful): This
> hasn't landed yet, but our plan is to visually convey a difference between
> Firefox trying (and failing) and Firefox trying (and succeeding). An
> example of this difference in another product is how the throbber in Chrome
> spins backwards in grey, and then forwards in blue. There are a number of
> ways for us to represent this difference visually, and we feel that in
> general they make more sense than a blur of text that changes so quickly
> it's impossible for a human to actually read.
It's not at all impossible to read when there is a problem with loading
the page and you want to know what is going on. Seeing that the problem
is in "Looking up..." rather than "Waiting for..." is a valuable piece
of information.
One idea would be to show the status to the right in the location bar
in the same place as the link target on hover text. Or perhaps be more
specific about the status on the tab header itself, instead of just
displaying "Loading..." like we do now. But that will obviously not
work for app tabs.
--
Hasse
sv-SE l10n team
Ben Bucksch
> In article<mailman.3670.1284669980.19132.dev-apps-
> fir...@lists.mozilla.org>, Alex Faaborg wrote...
>
>> it's impossible for a human to actually read.
> It's not at all impossible to read when there is a problem with loading
> the page and you want to know what is going on. Seeing that the problem
> is in "Looking up..." rather than "Waiting for..." is a valuable piece
> of information.
Yes, this is critical information that you can need almost every day,
both due to a broken Internet connection on your side or a broken
server, and in both cases various points where it can fail (it's not all
or nothing).
Very often, it's a page requisite like an advertising server that's
preventing the load of the page (I see no page at all), and I know that
because of these status bar messages.
I could see to replace these messages, but only when significantly
better error reporting is implemented first. I'm thinking of:
1. The timeout is reduced from 2 min currently to 20s. If we haven't
received data until then, show a message (not necessarily aborting
connection yet) prominently in the content area near chrome saying "DNS
lookup..." or "Waiting for the HTTP server's response..." "...took more
than 20s. There may be a problem with..." "... the website" or "...your
internet connection", the latter depending on whether the problem is
observed at entirely different sites, too.
2. When a page requisite (e.g. ad server) takes more than 10s and blocks
load finish, show warning and allow to abort this page requisite and
remove it from the page, and let page load finish. This will break some
pages, but with user confirmation, and it's better than not seeing the
page at all, as it's often the case for me.
3. Keeping statistics how long DNS lookups take (separating first and
cached lookups, and considering median and standard variation), and how
long HTTP connection open to first data reception takes, and warning the
user when this times are considerably higher than 1) typical for his
connection type 2) previous days.
Ben
Gavin Sharp
> There would be a chunk of add-ons on the bar that can't be moved around, and have a static order. Other add-ons you will install might show up to the left or right or both (depending on how we implement it - we could force it to the right).
This doesn't sound that bad to me. Users can make the case to addon
authors to update their addons to support customization, and in the
mean time they're no worse off than they were before (current status
bar icons aren't customizable).
Gavin
Ron Hunter
I have a cheap solution. Leave the status bar ALONE. That's MUCH less
confusing, requires no coding, and will not have thousands of users up
in arms about losing something they LIKE, not to mention a lot of add-on
developers complaining about having to change their add-ons.
Win-Win.
Ron Hunter
I have a 20 inch 1600x900 desktop, and I have lots of room for
displaying a long URL, even when wasting a lot of space repeating the
main domain for what (info)? But then I have a 1024x597 Netbook, and
there is barley room to display an average URL in the location bar.
Adding something else there isn't helpful, at all.
Ron Hunter
understands what the color codes are, although those who are color-blind
may be inconvenienced.
Ron Hunter
All very good ideas. I know that when I see 'looking up....' I have
lost my internet connection, or my DNS server is down.
Saves grief.
Dietrich Ayala
https://wiki.mozilla.org/User:Dietrich/Scratchpad
Let me know on the talk page if you have suggestions/improvements.
----- Original Message -----
> > Outcome: A pointer to clear migration guidelines that speak to the
> > 80%
> > case(s) for addon authors just looking to get the minimum done.
>
> I've got this going, will try to finish it up tomorrow.
EE
what server is uploading? If there is a problem or delay with loading
then that information becomes visible, and it is useful. If it is a
third party server such as google-analytics causing a delay, one can
simply block that connection to fix the problem.
I thought that information was displayed to make troubleshooting easier.
Now you want to remove that capability?
EE
It does not make much sense to divide the address bar into two pieces.
Alex Faaborg
> Why not just replace the whole address when the cursor is over a link?
Phishing concerns, it's important that users realize that the new link is
where they are about to go to, and not where they currently are.
-Alex
John J Barton
> Here's a draft, with an example add-on:
>
> https://wiki.mozilla.org/User:Dietrich/Scratchpad
>
> Let me know on the talk page if you have suggestions/improvements.
The example xpi file is not compatible with FF 3.6. Does this mean the
solution for FF4.0 does not work in FF 3.6? If not, how to make a
solution that works in both browsers?
I guess we can simply omit the 'firstrun' check and its corresponding
preference. Then if the user accidentally moves the button it will
return the next time they restart.
jjb