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
EE
Message boxes popping up when a page is loading is something that I find
annoying. I think it would drive some people to distraction fairly quickly.
EE
That is the kind of information that I want. You would then need to
have some explanation handy to explain what all the colours meant. That
sounds like increasing the complication rather than just making it easy
to see where the problem is.
EE
> 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.
>
> 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.).
>
If the text information area could be part of Firefox that could be
turned on to appear in the status bar if desired, that would be
workable. It could then function just as the status bar does now. It
is the best suggestion I have seen in this thread so far.
EE
> 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?
>
After looking at the image, I see what was meant. I think it would be
better to make the text for the link easier to read than using light
grey. Blue or green would be easier to read and would still be
different from the URL of the page.
Ron Hunter
Recall the my first suggestion is to leave the status bar alone, and
solve all these problems.
Asa Dotzler
> On 17.09.2010 18:57, Hasse wrote:
>> In article<mailman.3670.1284669980.19132.dev-apps-
>> fir...@lists.mozilla.org>, Alex Faaborg wrote...
>>
>>> 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.
>
> 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.
You may know that because you know how to decipher the messages in the
status bar but no one I know outside of the business has any idea what
those messages really mean. For them it's all just "progress" or "no
progress".
You use it as a debugging tool. Most people don't debug their internet
experience. Even if they did understand those status messages and so
they did know where the failure was, there's no reasonable action they
can take to make things better when there's a failure so it's
un-actionable information for most people. The only actionable
information for most people in the failure case is "we haven't connected
in a long time" and "we've connected but the bits of the page we're
getting are taking a long time". That distinction is something a user
could digest and make a decision based on it (to keep waiting or not)
And, there's an even better debugging tool included in Firefox 4, the
Web Console, which has even better messages for someone like you or me
who know what to make of those 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.
None of this has any meaning to the overwhelming majority of Firefox
users and all of this should be available to those that care in the Web
Console or through some addon like live http headers.
> 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.
That would be a nice feature. How do we tell when it's an ad server and
not the critical piece of content on a page like a video at youtube?
> 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.
What would this information allow the user to do differently?
- A
Ron Hunter
I think even the most novice of users understands what 'waiting for...'
means, and 'transferring data from...' is pretty obvious. Some of the
other messages, like 'looking up...' may not tell him much, but it does
tell the more informed something is amiss with DNS access, which IS
useful information.
Information on slow DNS lookup is something that would benefit the user
by telling him that his ISP is in need of cajoling to improve their
service, or perhaps he should look for another internet source.
I suppose FF could just display a message 'It didn't work.' after a
while, but I don't think that would help anyone. More information is
good, less is not good.
Dao
> 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.
It lacks help for migrating code accessing the UI element as if it were
always there. This is very add-on specific, so you actually can't be
concrete. You should say something like: Audit your code carefully, make
sure to never expect "myBox" to exist or to remain when it exists (e.g.
don't hold a reference on it forever); where appropriate, bail out if it
doesn't exist.
There are events that will help you keep track of your item:
beforecustomization
customizationchange
aftercustomization
They are dispatched on the toolbox(!).
It should probably also be mentioned that XBL bindings are
re-constructed when the items are wrapped for customization.
Last but not least, it's good that we're going to have a guide, but let
me reiterate that we should not force add-on authors to do this.
flying sheep
- keeping or removing the old statusbar
- breaking or retaining the old way of adding "statusbar" widgets
if there would be a way to let addon developers retain their
behaviours AND give the users customizable addon buttons/widgets, then
we should do it.
but if addons written in the old way lead to a container with
unorderable fixed-size widgets, BREAK IT!
let the old way die. it is a normal process of software evolution to
break obsolete behavior in order to enforce a new, better practice.
and it surely is a better practice to make the widgets draggable.
-----------------------
idea:
- keep & hide the statusbar _and_ rename/re-id it to break old addons.
- instead make it able to contain the new draggable widgets.
pro:
- statusbar still there for statusbar-lovers
- no inflexible fixed-height unmovable widgets possible anymore
contra:
- statusbar fans have to drag the widgets into the bar
- lazy addon devs may whine about their addons needing to be migrated
![alta88[nntp]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjUA6LqwHL3TKsLebE5-SwXQqtAZJOkobIl_A9x06nUxOiTLww=s40-c)
alta88[nntp]
---On 2010.Sep.18 8:06 AM, flying sheep wrote:
> this discussion is about two things:
> - keeping or removing the old statusbar
> - breaking or retaining the old way of adding "statusbar" widgets
>
> if there would be a way to let addon developers retain their
> behaviours AND give the users customizable addon buttons/widgets, then
> we should do it.
this, of course, is possible. the TotalToolbar extension reuses the
exact same dnd ergonomic and customization code in Fx toolkit to achieve
this for statusbar. as dao has said, statusbar items hold references,
receive events, etc and cannot physically be removed from the DOM, but
must instead be hidden, to achieve your goal of simulating toolbar
customization.
imo, this would be a hack and should *not* be supported.
>
> but if addons written in the old way lead to a container with
> unorderable fixed-size widgets, BREAK IT!
>
> let the old way die. it is a normal process of software evolution to
> break obsolete behavior in order to enforce a new, better practice.
> and it surely is a better practice to make the widgets draggable.
>
this is exactly correct. things have moved on (statusbar as toolbar is
long overdue), and addon devs need to adapt. arguments for 'it takes
time', 'it requires work' etc are to my mind quite invalid.
it's not too hard to find all extensions using <statusbar> in amo and
notify their devs of the trivial changes required per dietrich's guide.
nothing whatsoever need change from the user's perspective, and now
they get reorder functionality.
no effort (hack) should be made to make this change backwards compatible.
(statusbar messages are a different issue and as this is still a wip, it
remains to be seen how well that is solved. they could easily be
packaged in a <toolbaritem> in the addon toolbar to retain the former look.)
> -----------------------
>
> idea:
> - keep& hide the statusbar _and_ rename/re-id it to break old addons.
Herrmann Hofer
> 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?
And this is IMHO the biggest problem: Not that we have to migrate our
code (we're used to that), but that we have to maintain two different
versions of the code or at least two different branches within a module.
This will continue for quite a while, as statics show. Asking admins to
switch to a new version of the browser on their whole network, just
because one add-on requires it, may be asking a little bit too much.
EE
I had another thought. Why not make that new text in the address bar
unvisited-link-blue? That would make the connection between it and the
hovered link more obvious.
EE
of the least knowledgeable or least intelligent browser user? I do not
think so.
If there is a server hostname listed which is not the one serving the
page, and it is causing a serious delay, one could take steps to block
contact with that server.
Asa Dotzler
>
> I think even the most novice of users understands what 'waiting for...'
> means, and 'transferring data from...' is pretty obvious. Some of the
> other messages, like 'looking up...' may not tell him much, but it does
> tell the more informed something is amiss with DNS access, which IS
> useful information.
> Information on slow DNS lookup is something that would benefit the user
> by telling him that his ISP is in need of cajoling to improve their
> service, or perhaps he should look for another internet source.
> I suppose FF could just display a message 'It didn't work.' after a
> while, but I don't think that would help anyone. More information is
> good, less is not good.
>
Firefox will have visual progress indicators that are distinct for the
"trying to connect" and the "transferring data" and that covers what
most regular (not "novice") users need. See how Chrome does it with the
clockwise and anti-clockwise spinning circle effects in its tabs. Ours
isn't a circle, but the concept is similar.
While "my dns sucks, I should contact my ISP" makes sense to you, it
doesn't to most people. Most people have no idea what DNS is or that
it's controlled by the ISP rather than the browser or the server they're
trying to connect to. This is all magic to most people. For even
long-time Web users, there's "trying to connect and succeeding or
failing" and there's "connected and downloading content and succeeding
of failing" and that's sufficient to make a decision about whether to
try again, leave, or wait longer.
And again, for those who are really troubleshooting a bad ISP, we have
far more sophisticated tools than the flashing text in the statusbar.
- A
Asa Dotzler
> And all that means that the interface should be dumbed down to the level
> of the least knowledgeable or least intelligent browser user?
Absolutely not. Nowhere did I say lowest common denominator of least
knowledgeable. Please don't put words in my mouth. I am talking about
the normal people who are neither novices or geeks like us. Most people
fall in the middle of the curve and it's the largest possible audience
we should be targeting with our default feature set.
The Web gets ~100 million new users every year. The Web has about 1.5
billion people today. That means that well over 90% of the people on the
Web are not "new" or "novice" or "least knowledgeable". I think we
should be building a browser that's approachable by the newest users but
that's focused on being kick ass and capable for the vast majority of
users who are not unintelligent or unknowledgeable.
> If there is a server hostname listed which is not the one serving the
> page, and it is causing a serious delay, one could take steps to block
> contact with that server.
I'm honestly interested in what percentage of the 1.5 billion people on
the Web that you think would both understand that issue, and be willing
to take action to improve the situation.
- A
Ron Hunter
Actually, I have no objection to educating users a bit as we go along.
It really doesn't take much to do this.
Ron Hunter
information than is needed by the average user will just be ignored but
will be useful for us 'geeks'.
Asa Dotzler
Actually no. Firefox has about 400 million users worldwide, which is
well over 1/3rd of the people on the Web. But that's not even relevant.
> More information than is needed by the average user will just be
ignored but
> will be useful for us 'geeks'.
Two problems here.
One, ignoring it isn't ideal. If we simplify it to the parts that large
numbers of users can understand "trying to connect" and "trying to
download page" and indicate that in a visually compelling way that users
won't just ignore, that's an improvement even the not-geeks can benefit
from.
Second problem is that just saying "ignore it" doesn't really work. If
ignoring worked, we'd add every possible feature to the GUI and just
tell folks to ingnore the ones they don't use.
- A
Ron Hunter
enough tabs to make it useful. I am ignoring several other of the new
features because they have no application for my needs, such as 'app
tabs'. NO ONE uses every feature of ANY browser, or any other complex
program. We all use a subset of the features that help us do what we
need/want to do, and ignore the rest. Sure, everyone uses SOME of the
features, such as the URL bar, and the scroll bars, but many of us never
point our mouse pointer to the scroll bar, and a lot of us never point
to the back or forward buttons. That renders some of the UI choices
made in FF4 moot for those users. I am sure that some users turn off
the status bar and are quite unperturbed by it not being there. Others,
like myself, use it a lot for getting information, and having a handy
place to place things that I don't often use, but might need available.
I suspect that the screaming will be heard around the world when FF4
comes out with no status bar.
Asa Dotzler
> On 9/18/2010 4:29 PM, Asa Dotzler wrote:
>> Second problem is that just saying "ignore it" doesn't really work. If
>> ignoring worked, we'd add every possible feature to the GUI and just
>> tell folks to ingnore the ones they don't use.
> But we DO.
We absolutely DO NOT have every possible feature in the GUI. What kind
of bugs response is that.
No feature is used or used the same way by all users, but that doesn't
mean we throw up our hands. We can make educated guesses where we have
the education and the experience to do so. We can also use science* to
find out how many users engage with each of our features and make
decisions based on that science. We can add, remove, or alter features
and test and retest so that the features we do have provide the most
value to the largest number of users.
- A
Philip Chee
> idea:
> - keep & hide the statusbar _and_ rename/re-id it to break old addons.
> - instead make it able to contain the new draggable widgets.
>
> pro:
> - statusbar still there for statusbar-lovers
> - no inflexible fixed-height unmovable widgets possible anymore
> contra:
> - statusbar fans have to drag the widgets into the bar
> - lazy addon devs may whine about their addons needing to be migrated
Stupid idea:
1) Teach the toolbar customization code to recognize <statusbaritem> as
an alias for <toolbaritem>. Optionally selectively turn this on for
<statusbaritem removable="true">.
2) Give the addons-bar the same id as the old "status-bar" so extension
overlays will still work.
This will still break extensions that implicitly assume that their
statusbar items are always in the DOM. Firefox can adopt the SeaMonkey
habit of keeping toolbaritems/toolbarbuttons always in the DOM even when
in the palette. A side benefit is that a lot of code in /browser.js that
exists only to do null checking for elements can go away.
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.
Ben Bucksch
suggestions exactly how to interpret the messages for normal users. (But
somehow you managed to criticize those, too.)
On 18.09.2010 03:11, Asa Dotzler wrote:
> You may know that because you know how to decipher the messages in the
> status bar but no one I know outside of the business has any idea what
> those messages really mean. For them it's all just "progress" or "no
> progress".
Good. That means: "it works" as-is. Normal people get the right message,
and others get the detail information. So, leave it alone.
Compare Flash and co: "An error occurred". Great. Useless piece of
software. You must not dumb down the software to remove useful
information just because 80% of people don't understand it, because the
20% are still relevant. 'People in the IT business' are not ballast, but
there to *fix* things. Remove that information and nobody can fix things
anymore.
I don't think "Looking up foobar.com..." is too technical, in fact
regular newspapers explain how DNS works, due to phishing. (Phishing is
why I like the current domain display outside the URLbar.)
Also note that diagnose very often happens via telephone (user on
computer, hotline or friend on phone), so "install extension" is a
no-go. It would considerably complicate diagnosis.
Classifying the world in "IT experts", "normal users" and "novice/dumb"
and making the software work *only* for one of them is too simple.
Nobody falls entirely in one category.
>> 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.
>
> That would be a nice feature. How do we tell when it's an ad server
> and not the critical piece of content on a page like a video at youtube?
By comparing the domain, for example.
Even if the browser can't: The user can always press "Reload" (it's what
I do in these situations anyway), if the important content was missing.
Ben
Ben Bucksch
>> Why not just replace the whole address when the cursor is over a link?
>
> Phishing concerns
Granted. But isn't that what the new domain display is for? Remember
that you can also do
http://www.microsoft.com.softwar...@example.com *
, so the URL display has never been reliable, that's the whole point. (*
yes, we have other phishing protections against this particular case
IIRC, but let's ignore that for a second.)
If we fear that people ignore the new domain display, could we maybe
just leave the original http+domain in the URLbar and show the new URL
afterwards? That would, in my case (900px wide) allow to see most of the
target URL, while I currently don't see enough of it.
----
Also, please note that the current flickering effect was the more
serious problem.
Ben Bucksch
> I think we should be building a browser that's approachable by the
> newest users but that's focused on being kick ass and capable for the
> vast majority of users who are not unintelligent or unknowledgeable.
I agree with that. However, there's a difference between "focus" and
"lock out others".
Removing "Locking up foobar.com" and replacing it with generic
"progress" (or "lookup" without domain) doesn't make it much more
understandable for normal users (they already understand "progress"),
but removes critical clues for knowledgeable users.
Dao
> This will still break extensions that implicitly assume that their
> statusbar items are always in the DOM. Firefox can adopt the SeaMonkey
> habit of keeping toolbaritems/toolbarbuttons always in the DOM even when
> in the palette. A side benefit is that a lot of code in /browser.js that
> exists only to do null checking for elements can go away.
This sounds good in terms of being more developer friendly. On the other
hand, it seems to me that in many cases you will actually want to bail
out when the item isn't on a toolbar in order to avoid unnecessary work
load. I guess the toolbar customization code could support this by
setting an attribute on the items when they're gone... Removing the
nodes from the DOM would still be more explicit, though.
Ron Hunter
And what science determined that eliminating the statusbar was a good move?
Dao
> 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.
Another option might be to just overlay the toolbar. The item should be
permanent in that case as long as you don't add removable="true".
Compared to the empty <statusbar id="status-bar"/> container this would
arguably have the downside of mixing permanent and movable items.
Philip Chee
This is getting off-topic, but for that use case we borrowed
isElementVisible() from Firefox. Also I see a bunch of code in
Thunderbird (and perhaps Firefox) that basically does:
Oops, removing foo from the DOM and then reinserting it breaks our XBL;
must remember to reinitialize our widget whenever we reinsert our button
into the toolbar. Which needless to say we have avoided in SeaMonkey.
Philip Chee
Perhaps this is an acceptable compromise? Old style statusbar items get
put in a ghetto is some corner of the addons bar so they still work, but
this slightly sub-optimal solution would encourage users to complain to
the extension authors. The Borg will slowly assimilate these into the
new paradigm as extension developers get more comfortable developing for
Firefox 4.0.
flying sheep
no, it is not.
dave told us, why:
http://groups.google.com/group/mozilla.dev.apps.firefox/msg/6742b2b69c8721f8
and several others (of course including me) agree. please respect that
and don’t try to push a quick solution you are comfy with.
i have made a proposal, too. tell me what’s wrong with that:
>idea:
>- keep & hide the statusbar _and_ rename/re-id it to break old addons.
>- instead make it able to contain the new draggable widgets.
i think this is clearly superior to any compatibility hacks which will
likely be there until firefox is replaced by a hologram-above-your-
wrist-browser in 2060. and more importantly: which suggests that is a
accepted way to add toolbar-widgets.
whatever solution you propose, keep in mind that each one not
including the feature depicted below is not acceptable.
http://jboriss.files.wordpress.com/2010/04/as_moveableobjects1.png
why should there be more than one way of adding the same functionality
(toolbar-widgets) in two different ways?
remember: there is no better time than _now_ to make breaking changes.
every old inconsistent ui choice which naturalized along the way
should be extinguished now. i’m not talking about the statusbar, but
about adding inflexible widgets to it.
flying sheep
doing it in the first place)
>- keep & hide the statusbar _and_ rename/re-id it to break old addons.
>- instead make it able to contain the new draggable widgets.
hidden) statusbar into a regular toolbar, so that everyone preferring
it over the addon bar can simply move the widgets they want to be on
the bottom from the addon bar to the reenabled statusbar.
this has the clear advantage that (as soon as the addons are updated
for this behavior) everyone can move the buttons where they want them:
addons bar, tab bar, title bar, bookmark bar, navigation bar and of
course the reenabled statusbar. or a mix of all these
johnjbarton
> On 17.09.2010 23:28, John J Barton wrote:
>> 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.
>
> Another option might be to just overlay the toolbar. The item should be
> permanent in that case as long as you don't add removable="true".
Ah ok, thanks. At first I don't understand what distinction you are
making. Assuming the goal was to replicate the status bar, I did not
read carefully. I just assumed the XUL code overlayed the toolbar. Now
I realize that Dietrich's example shows how create an addon button as a
customization element. That is not equivalent to how we use the
statusbar. For us the status bar icon is like the "Firefox" menu in FF4,
the Start button in Windows, or the command prompt in linux. We want its
position to be constant. The potential costs of customization of the
start button exceed the potential benefits.
I guess we still need the bit were addonBar.collapsed = false is set.
jjb
Asa Dotzler
Did you miss that part of my comment in your rush to challenge a change
you personally don't like?
- A
Asa Dotzler
It does make it more understandable for normal users. Today normal users
probably mostly ignore any of that text and just consider any flashing
text or the progress bar as their indication of progress. By making two
states, the trying to connect, and the connected and downloading, we're
trying to help in increasing understandability for a huge number of
people. For the few who do know what all that flashing text means, this
may be a sort of regression and I expect they'll want to start checking
the Web console for exceptional cases or find an extension that exposes
all of this information for all their navigation if it just makes them
more comfortable.
- A
Asa Dotzler
> First off, please read a message in full before replying. I made
> suggestions exactly how to interpret the messages for normal users. (But
> somehow you managed to criticize those, too.)
>
> On 18.09.2010 03:11, Asa Dotzler wrote:
>> You may know that because you know how to decipher the messages in the
>> status bar but no one I know outside of the business has any idea what
>> those messages really mean. For them it's all just "progress" or "no
>> progress".
>
> Good. That means: "it works" as-is. Normal people get the right message,
> and others get the detail information. So, leave it alone.
I disagree. That's a pretty elitist view. We get it, so what if no one
else does. Leave it as it is.
I think we should change it until most people get value from it, even if
that means sacrificing some of the secret code we can decipher with our
super-geek powers. Our super-geek powers will help us to use the Web
console or find an add-on that restores things for us.
> Compare Flash and co: "An error occurred". Great. Useless piece of
> software. You must not dumb down the software to remove useful
> information just because 80% of people don't understand it, because the
> 20% are still relevant. 'People in the IT business' are not ballast, but
> there to *fix* things. Remove that information and nobody can fix things
> anymore.
Strawman. No one is talking about replacing actionable information with
a completely unactionable messages here. We're talking about distilling
a lot of fine grained information that's mostly meaningless to most
people into a couple of categories and displaying those in a way that
most people can get actionable information from.
> I don't think "Looking up foobar.com..." is too technical, in fact
> regular newspapers explain how DNS works, due to phishing. (Phishing is
> why I like the current domain display outside the URLbar.)
Some real science would help here. I say it's not actionable for regular
people. You say it is. We're not going to get anywhere here because we
have intuitions that disagree.
> Also note that diagnose very often happens via telephone (user on
> computer, hotline or friend on phone), so "install extension" is a
> no-go. It would considerably complicate diagnosis.
Open the Web Console is much better for debugging. The messages don't
flash and disappear in fractions of a second. They can be copied and
pasted and sent in email. They can be dropped into a bug report. Sorry,
debugging is a failed argument for this feature when we have much better
tools. I'm also not particularly thrilled about your view of what should
be in primary browser UI if you think that debugging is the case we
should be optimizing for.
> Classifying the world in "IT experts", "normal users" and "novice/dumb"
> and making the software work *only* for one of them is too simple.
> Nobody falls entirely in one category.
I agree completely. I've never made that classification and I've never
said the software should only work for one of them. I've only spoken
about "regular people" and "us geeks that make browsers and so know a
whole shitload about how browsers and the Internet work." and I believe
that if we're optimizing the primary default UI (the stuff not buried
under a menu) that we should be optimizing for the group that isn't us
browser makers.
- A
EE
That is still a useful tool, and why take that away from those who can
use it by gutting the interface?
Asa Dotzler
We're not gutting the interface. We're actually improving it hugely. See
the Web Console at Ctrl/Command+Shift+k. For those who do understand and
can get value from messing with servers and blocking and whatnot, the
Web Console is lightyears ahead of the statusbar.
- A
EE
The kind of situation that I meant (and probably some of the others did)
is not just a bad ISP, but for example:
I am trying to load a web page, which is taking a long time, and I
notice in the status bar that it says, "Waiting for johndoe.com". I
then think I can speed things up by blocking johndoe.com. When I do
that, I see that the page now loads much faster, there are no missing
images, and it works the same as ever. Blocking johndoe.com did no
harm, and in fact it was beneficial, so I keep doing it.
If I had not seen that message, I would not know what host to block.
Ron Hunter
> On 9/18/2010 11:40 PM, Ben Bucksch wrote:
>> First off, please read a message in full before replying. I made
>> suggestions exactly how to interpret the messages for normal users. (But
>> somehow you managed to criticize those, too.)
>>
>> On 18.09.2010 03:11, Asa Dotzler wrote:
>>> You may know that because you know how to decipher the messages in the
>>> status bar but no one I know outside of the business has any idea what
>>> those messages really mean. For them it's all just "progress" or "no
>>> progress".
>>
>> Good. That means: "it works" as-is. Normal people get the right message,
>> and others get the detail information. So, leave it alone.
>
> I disagree. That's a pretty elitist view. We get it, so what if no one
> else does. Leave it as it is.
>
> I think we should change it until most people get value from it, even if
> that means sacrificing some of the secret code we can decipher with our
> super-geek powers. Our super-geek powers will help us to use the Web
> console or find an add-on that restores things for us.
>
>
But, isn't that what is called 'dumbing down' the UI? Why can't we all
be made happy. Another option?
>> Compare Flash and co: "An error occurred". Great. Useless piece of
>> software. You must not dumb down the software to remove useful
>> information just because 80% of people don't understand it, because the
>> 20% are still relevant. 'People in the IT business' are not ballast, but
>> there to *fix* things. Remove that information and nobody can fix things
>> anymore.
>
> Strawman. No one is talking about replacing actionable information with
> a completely unactionable messages here. We're talking about distilling
> a lot of fine grained information that's mostly meaningless to most
> people into a couple of categories and displaying those in a way that
> most people can get actionable information from.
>
You mean like "It didn't work" and "Done" Sigh.
Of course, you still need a place to display this....
Ron Hunter
suffer, until someone fills in the gaps. If you will promise to read
the firefox support newsgroup daily for the week after the release, I
will not say another word about the subject.
Ron Hunter
When I read that, I can't help thinking of the original version of
Microsoft Basic that came out on the original IBM PC. If a error was
made in a BASIC program, good old MS produced a message:
"Error in line xxxx".
Now wasn't that helpful?
Ron Hunter
True, there were not errors, but then there wasn't any status
information either.
Ben Bucksch
> Today normal users probably mostly ignore any of that text and just
> consider any flashing text or the progress bar as their indication of
> progress. By making two states, the trying to connect, and the
> connected and downloading, we're trying to help in increasing
> understandability for a huge number of people.
Yes, a visual information that allows average people to understand
what's going on, would be great. I'm in full support of that.
But you can have both: whatever new UI you have in mind, plus the old
"Looking up ad.admotion.com...." messages somewhere subtly at the
bottom, using a layer, taking no extra UI space.
As you say yourself, average users would ignore it, so it cannot hurt
them. That makes both group happy and is thus the better approach.
Removing it (or moving it to an extra window that I have to keep open
just to see what's going on, and associate it with my window, costing a
lot of mental burden and screen space) would hurt educated users
notably, so that's the worse choice.
Ben
Ben Bucksch
>> Classifying the world in "IT experts", "normal users" and "novice/dumb"
>> and making the software work *only* for one of them is too simple.
>> Nobody falls entirely in one category.
>
> I agree completely. I've never made that classification and I've never
> said the software should only work for one of them. I've only spoken
> about "regular people" and "us geeks that make browsers and so know a
> whole shitload about how browsers and the Internet work."
OK, maybe we're starting from different premises. You talked about "bell
curve" and 20%, so I assumed you talked about these classifications.
FWIW, I am sure that not only browser developers know what a DNS lookup
is, and not only us can act upon it. Tech support people (also at
companies) will not only understand, but need it.
I think most technical people and some educated normal people will or
can easily understand it. The concept is not *that* difficult, it can
(and has been in newspapers) explained to average people in 3 sentences.
Anybody who used a (paper) phone book can understand it.
On 19.09.2010 20:36, Asa Dotzler wrote:
> On 9/18/2010 11:40 PM, Ben Bucksch wrote:
>> First off, please read a message in full before replying.
>>
>> On 18.09.2010 03:11, Asa Dotzler wrote:
>>> For them it's all just "progress" or "no progress".
>> Good. That means: "it works" as-is. Normal people get the right message,
>> and others get the detail information. So, leave it alone.
>
> I disagree. That's a pretty elitist view.
Again, please read to the end (and before replying to *this* part,
please read to the end of my post). Below I said we need this
information to help the normal users, and we need it in their browser,
not in ours. That's the opposite of "elitist".
Second, that "we" is the educated 20% minority. Since when it is cool to
remove the basis for the educated people to work?
Third, the left 20% of the bell curve is still a big group that you
alienate *needlessly* here. That needlessness was the key in my sentence.
> I think we should change it until most people get value from it
No. We have proven that it's useful. Now the burden is on you to prove
that it hurts, actually hurts. (You have asked me about "science"...) I
question that the sentence at the bottom hurts anyone (significantly).
>> 'People in the IT business' are not ballast, but there to *fix*
>> things. Remove that information and nobody can fix things anymore.
>
> Strawman. No one is talking about replacing actionable information
> with a completely unactionable messages here.
So, what exactly are you suggesting? From what I understood, you're
suggesting some "progress" thing which visually conveys whether it's DNS
lookup or server connection setup or transfer. What's missing is *which*
address and server is being contacted. As I said, it's very common that
the ad server is the problem, for example, and you can see that clearly
from the hostname (e.g. ad.admotion.com). (I think even average users
can understand what's going on here when they read that message.)
> Open the Web Console is much better for debugging.
These messages are not there, and would flood the console if they were.
> I'm also not particularly thrilled about your view of what should be
> in primary browser UI
The user is *waiting*. It's his primary focus, and I think it's fair to
tell him *why* he waits. It doesn't make the UI much nicer to have only
a dancing icon than also showing "Looking up ad.admoiton.com..." subtly
somewhere. It doesn't need to use more static UI space either - Google
Chrome shows how: just layer it over the bottom of the page or "addons bar".
In other words, you can have a car with a single "failure, go to garage"
light or a "oil is about to be depleted, please refill" light. Even
without being a car mechanic, and without wanting to chance oil myself,
I'd rather have the latter.
> We're talking about distilling a lot of fine grained information
> that's mostly meaningless to most people into a couple of categories
> and displaying those in a way that most people can get actionable
> information from.
Yes, that's what I suggested as alternative, and made very concrete
suggestions.
Asa Dotzler
> As you say yourself, average users would ignore it, so it cannot hurt
> them. That makes both group happy and is thus the better approach.
> Removing it (or moving it to an extra window that I have to keep open
> just to see what's going on, and associate it with my window, costing a
> lot of mental burden and screen space) would hurt educated users
> notably, so that's the worse choice.
I think it's not as simple as ignoring it. There's a real cost to extra
toolbars that take up space that could be used by other features or be
used to display more web content. There's a cost to features that cover
Web content or come in and out of view leading to distraction.
I also think that you're confusing the issue some by suggesting that
this is important to "educated users". I've been on the Web since it was
born and I've been working on browsers for more than a decade. Yet I've
never taken steps to block a slow ad host. Am I not an educated user? I
think that's the wrong label and it implies a larger number of people
that would really ever do anything with the knowledge that they can get
from status messages that won't be covered by the new status indicator.
Getting data on this is hard though so I won't contest that some number
of people, even a larger number than those arguing in this forum,do find
the information currently in the statusbar more actionable than the
proposed replacement. But I don't think the number is nearly as
significant as some are arguing here and I do think that those people
will find other ways to expose the information they want.
- A
Nils Maier
> 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.
>
Honestly, the "firstRun" code is just plain bad. Up until now you talked
about "API", but doing string manipulation and manual attribute
peristing is hardly an API! The Jetpack stuff is not a replacement for a
real API, btw.
I'd like to see something in the spirit of the following:
* No first run code required; should be relatively easy to implement,
using some persisted list of "known" removed ids.
<toolbaritem id="myAddonItem" defaultVisible="addon-bar"/>
* Real API:
if (!$('addon-bar').contains($('myAddonItem')))
$('addon-bar').add($('myAddonItem'));
else
$('addon-bar').remove($('myAddonItem'));
* You, as the implementor of the addon-bar, need to figure out correct
styles depending on the location in the UI to make using toolbaritems
painless, less error-prone and useful. (see chrome classes remarks below).
Furthermore your example is incomplete/incorrect:
* You need to specify the correct chrome classes.
The required classes might depend on where the item is shown ("real"
toolbar, customizeToolar.xul, addon-bar), e.g.
chromeclass-toolbar-additional toolbarbutton-1 for main toolbar items.
* You don't style the chrome://global/content/customizeToolbar.xul, so
most of the toolbar items, i.e. those that don't use inline styles but
use icons, will look broken.
* Existence-checking using |indexOf| on a comma-separated list? Seriously?
The toolbar XUL/XBL/JS APIs (I usually refer to it as "the toolbar mess,
that is driving me nuts") are pretty nasty to work with, with a lot of
things to consider, and even more things to get wrong, and I worked with
them a lot.
I'm pretty much opposed to introduce a breaking change like this so late
in the betas, and without offering a developer friendly replacement.
I'm part of amo-editors, and experience tells me that a lot of addon
authors aren't skilled enough to use the toolbar API correctly with all
the caveats.
So either stop this mess right now, or come up with a decent API and
migration strategy the sooner the better. I'd personally like to see it
postponed to the time after FX4.
Cheers
Nils
Barry van Oudtshoorn
When it comes to showing information regarding page loading, why don't
we compromise? What I would propose is that by default, we don't show
any information (as the UX team propose). When, however, a page takes
longer than a certain threshold to load (perhaps make this threshold a
couple of standard deviations above the mean loading time on the user's
machine), present the information to the user -- maybe using a
Chrome-esque slide-in status bar. This would mean that the 95% (I'm just
making these numbers up, of course) of users who don't use or need this
information would reap the benefits of the UX team's proposal, and the
5% who do experience problems and want to know what's going on without
necessarily firing up the debugging tools would benefit as well.
Far from dumbing-down the interface, this would, in my opinion, make it
more intelligent, as we optimise for the most common scenario, and still
provide a workable, elegant solution for the uncommon.
--
Barry van Oudtshoorn
www.barryvan.com.au
Not sent from my Apple πPhone.
Thomas Stache
> ... Now I
> realize that Dietrich's example shows how create an addon button as a
> customization element. That is not equivalent to how we use the
> statusbar. For us the status bar icon is like the "Firefox" menu in FF4,
> the Start button in Windows, or the command prompt in linux. We want its
> position to be constant. The potential costs of customization of the
> start button exceed the potential benefits.
Why do you want to force a whole toolbar on everybody's windows, just to
have a Open/Close Firebug Panel button? A customizable toolbar button is
sufficient, and the recommended implementation in the Addon-Bar-World.
To me this attitude seems a *bit* arrogant and user-hostile...
Ben Bucksch
> There's a real cost to extra toolbars that take up space that could be
> used by other features or be used to display more web content.
I covered that, it can be on top of the bottom of the webpage. See
latest Google Chrome, it does exactly that.
> I've never taken steps to block a slow ad host. Am I not an educated user?
Manually blocking an ad host is not the only option. You can also
mentally register in your mind "this website makes me wait considerably
just to show me ads", and the action could be to go to another site
instead which doesn't make you wait needlessly. Also, you know it's not
your internet connection that's slow, you cannot make it faster by
getting a faster internet connection - that *is* important information.
And this is just one case. It's also important when diagnosing intranet
host access (a lot of different things can go wrong there, from DNS over
routing and firewall to VPN) and many other cases.
> find the information currently in the statusbar more actionable than
> the proposed replacement
My point is that it's not either-or. I support making this more
accessible by adding a visual clue showing average users what we're
currently doing.
I have not seen "science" (your word) saying that a subtle message at
the bottom hurts them significantly. We have shown why it hurts others
significantly to remove it. There is no need for a tradeoff here.
Dietrich Ayala
I'll compile all the approaches/issues, and will file bugs, update the migration guide, etc.
----- Original Message -----
> On 17.09.2010 22:26, Dietrich Ayala wrote:
> > 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.
>
> It lacks help for migrating code accessing the UI element as if it
> were
> always there. This is very add-on specific, so you actually can't be
> concrete. You should say something like: Audit your code carefully,
> make
> sure to never expect "myBox" to exist or to remain when it exists
> (e.g.
> don't hold a reference on it forever); where appropriate, bail out if
> it
> doesn't exist.
>
> There are events that will help you keep track of your item:
> beforecustomization
> customizationchange
> aftercustomization
> They are dispatched on the toolbox(!).
>
> It should probably also be mentioned that XBL bindings are
> re-constructed when the items are wrapped for customization.
>
> Last but not least, it's good that we're going to have a guide, but
> let
> me reiterate that we should not force add-on authors to do this.
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
flying sheep
> there is no real API, the toolbar api is difficult and the jetpack api doesn’t replace it
>
> make styling of the element in different toolbars easy and consistent
>
> I'd like to see something in the spirit of the following:
> * No first run code required
> * using some persisted list of "known" removed ids.
first of all: sorry for shorting it down, nils, but i mostly wanted to
distill your main arguments. correct me if i misunderstood sth.
Nils is the only one that really came up with reasons why right now
_might_ not be the best time to make this change, but noone really has
arguments against the change per se, so i think the breaking change is
still needed. i totally agree that a simple api to add a button is
needed. widgets could be similar, but without the convenience
functions described below:
workflow of adding a button should be like:
*create button
*specify if it should spawn a drop-down-menu (fly-up-menu if it is on
the bottom of the screen), a speech bubble-like panel (which is
currently being developed), or run a custom function (e.g. pop up
firebug, open new tab, …)
*if it is a menu, or a speech bubble panel, you should be able to
access and populate it now
*specify where it initially goes (addon bar, title bar, tab bar,
navigation bar or bookmark bar)
*specify big and small icon and optionally custom styling
*done, firefox should care about the default positioning and styling
(button-like or not, big or small icon)
i don’t know it is even possible to add it once and let firefox handle
the rest, but that would be how my favourite api for this specific
purpose should look like.
btw: technically speaking, the repeated betas are not really to be
considered traditional betas. a traditional beta is used after all the
new features are introduced in the alphas. fx’s current dev model is
different, introducing a small amount of features at a time and using
multiple betas to fix their bugs. so we are now still in the alpha
stage where new features can still be added.
Nils Maier
> btw: technically speaking, the repeated betas are not really to be
> considered traditional betas. a traditional beta is used after all the
> new features are introduced in the alphas. fx’s current dev model is
> different, introducing a small amount of features at a time and using
> multiple betas to fix their bugs. so we are now still in the alpha
> stage where new features can still be added.
[amo-editors:
bug: https://bugzilla.mozilla.org/show_bug.cgi?id=574688
discuss:
http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/9f91bd1618339b6a
]
I couldn't care less.
amo-editors officially has begun to ask authors to update their stuff to
fx4 betas months ago, which I still think was a mistake... But now it's
too late to tell the authors that betas so far cannot be considered
"traditional" betas, and that major breaking changes are still coming.
Other breaking changes - like explicit component registration, no-unpack
by default (simple opt-out), Firefox menu or the new addon manager - not
only seemed far more reasonable and justified, but they were also
announced far earlier.
"addon-bar" however was just "progressively" discussed by a few blog
posts, without any real announcements up until now (actually not even now).
addon-bar is furthermore a "feature" directly targeting addon developers
with no real added bonus to them, almost no added usability for regular
users (the majority of users doesn't even know that you can customize
stuff). Even the "screen real estate" promise is debatable; nobody
really reads stuff that far at the bottom, the impact might be
psychological at best.
But it adds major pain for the developers because the toolbar "API" as
is simply sucks, and it's a damn late change.
Another suggestion (which came up already, I guess):
* Use a regular statusbar, but "empty" per default
* Hide it by default (when empty)
* Either auto-hide it when populated
- Maybe: allow easy pinning
* Or always show it
- Maybe: allow easy hiding via some X-Close-button
- Maybe: consider this a pinned auto-hide bar (from above), i.e.
default is pinned/visible; when "closed", it is auto-hide instead of
really closed.
* Postpone the "customization" bits and required migration to
toolbarbuttons to after Firefox 4
Moreover there was a lot of talk via blogs telling folks that Firefox 4
Beta 6 (now pushed to beta 7) would be feature complete, e.g. on addon
developer's main information channel:
http://blog.mozilla.com/addons/2010/09/14/add-ons-review-update-17/
I don't really see how a though-through implementation incl. a
convenient API, sane migration paths and figuring out the style/class
stuff can be done before beta 7 and communicated properly before fx4 stable.
Cheers
Nils
EE
What is this icon that has a constant position in the status bar? I
have never seen such a thing. All the icons I have on Firefox's status
bar can be displaced if I add another extension which produces a status
bar icon.