Dao wrote: > On 16.09.2010 23:57, John J Barton wrote: >> 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.
I know this discussion is focused primarily on addon developers, but 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.
For what its worth I see the new hover on link UI and I most heartily 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?
>> 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 > john...@mozilla.com
What you mean is that this is a 'done deal', no matter WHAT Add-on 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.
----- 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).
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.
> ----- 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).
> 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.
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.
> ----- 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.
> 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).
Jumping into the fray at the request of Dão so he can reply to me 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.
In article <mailman.3670.1284669980.19132.dev-apps-
fire...@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.
> In article<mailman.3670.1284669980.19132.dev-apps- > fire...@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.
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.
On Fri, Sep 17, 2010 at 11:04 AM, Dietrich Ayala <dietr...@mozilla.com> wrote: > 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).
> ----- 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).
> 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.
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.
> On 16.09.2010 22:46, Alex Faaborg wrote: >> 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).
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.
> In article<mailman.3670.1284669980.19132.dev-apps- > fire...@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.
It can be done with colored progress bars, as long as everyone clearly understands what the color codes are, although those who are color-blind may be inconvenienced.
> On 17.09.2010 18:57, Hasse wrote: >> In article<mailman.3670.1284669980.19132.dev-apps- >> fire...@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.
> 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
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.
----- 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.
> 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). 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
> On Thu, Sep 16, 2010 at 12: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 >> was supposed to be a constructive proposal. It would kill the >> sledgehammer attitude of the change but not the change itself.
>> On 16.09.2010 21:31, Johnathan Nightingale wrote: >>> On 16-Sep-10, at 12:00 PM, Dao wrote:
>>>> 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 >>> john...@mozilla.com
Why would you want to remove the information in the status bar about 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?
> On 9/17/2010 10:36 AM, Ben Bucksch wrote: >> On 16.09.2010 22:46, Alex Faaborg wrote: >>> 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).
> 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.
Why not just replace the whole address when the cursor is over a link? It does not make much sense to divide the address bar into two pieces.
On Fri, Sep 17, 2010 at 2:06 PM, EE <nu...@bees.wax> wrote: > On 2010/09/17 12:21, Ron Hunter wrote:
>> On 9/17/2010 10:36 AM, Ben Bucksch wrote:
>>> On 16.09.2010 22:46, Alex Faaborg wrote:
>>>> 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).
>> 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.
>> Why not just replace the whole address when the cursor is over a link? It > does not make much sense to divide the address bar into two pieces.
> 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.
> ----- 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.
> On 17.09.2010 18:57, Hasse wrote: >> In article<mailman.3670.1284669980.19132.dev-apps- >> fire...@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.
> 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
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.
> On 9/17/2010 11:57 AM, Hasse wrote: >> In article<mailman.3670.1284669980.19132.dev-apps- >> fire...@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.
> It can be done with colored progress bars, as long as everyone clearly > understands what the color codes are, although those who are color-blind > may be inconvenienced.
How is that going to tell you that joeblow.com is causing the delay? 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.
> 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.).
> Gavin
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.
