Indeed. Elucidation on the plan of record would help. Also, knowing what pieces are underway and which are OMGWHAT? underresourced would help a ton a ton.
I want to start a quick thread with everyone cc'd so that we can make sure everyone is on the same page with the status bar. My impression from Myk and Dietrich is that the status bar is being replaced with an extension bar (which jetpacks add themselves to), and the extension bar is an entirely new piece of UI (different id, doesn't contain any Firefox specific UI, possibly different styling to account for an option of having larger icons). So while the extension bar, containing jetpacks, can be enabled and disabled by the user, the status bar as it exists today would no longer be available in Firefox 4. We've been working on integrating existing status bar functionality into other parts of the UI to accommodate this change.
Myk and Dietrich: please let us know if that is incorrect, since this will effect which changes are mandatory or not (like providing the ability for the user to see a link target on hover).
> I want to start a quick thread with everyone cc'd so that we can make sure > everyone is on the same page with the status bar. My impression from Myk > and Dietrich is that the status bar is being replaced with an extension bar > (which jetpacks add themselves to), and the extension bar is an entirely new > piece of UI (different id, doesn't contain any Firefox specific UI, possibly > different styling to account for an option of having larger icons). So > while the extension bar, containing jetpacks, can be enabled and disabled by > the user, the status bar as it exists today would no longer be available in > Firefox 4. We've been working on integrating existing status bar > functionality into other parts of the UI to accommodate this change.
> Myk and Dietrich: please let us know if that is incorrect, since this will > effect which changes are mandatory or not (like providing the ability for > the user to see a link target on hover).
> -Alex
Not happy with this decision. Will break many of my current extensions.
In the sort term, but in the long term we believe people will really like this change. Giving each Jetpack a panel to contain its UI drastically increases the number of extensions you can have easy access to. There are a lot of current toolbars that I would consider running if it didn't mean giving up 1/3 or 1/2 of my screen space because they currently each mandate persistent primary UI. Obviously making significant changes like this means some things need to be updated, but it will also position us to have a much better interface going forward. Jetpacks, the extension bar, and arrowpanels will create a glorious future of simplistic access to complex functionality :)
On Tue, Aug 24, 2010 at 4:57 PM, Ron Hunter <rphun...@charter.net> wrote: > On 8/24/2010 5:34 PM, Alex Faaborg wrote:
>> I want to start a quick thread with everyone cc'd so that we can make sure >> everyone is on the same page with the status bar. My impression from Myk >> and Dietrich is that the status bar is being replaced with an extension >> bar >> (which jetpacks add themselves to), and the extension bar is an entirely >> new >> piece of UI (different id, doesn't contain any Firefox specific UI, >> possibly >> different styling to account for an option of having larger icons). So >> while the extension bar, containing jetpacks, can be enabled and disabled >> by >> the user, the status bar as it exists today would no longer be available >> in >> Firefox 4. We've been working on integrating existing status bar >> functionality into other parts of the UI to accommodate this change.
>> Myk and Dietrich: please let us know if that is incorrect, since this will >> effect which changes are mandatory or not (like providing the ability for >> the user to see a link target on hover).
>> -Alex
> Not happy with this decision. Will break many of my current extensions.
> I want to start a quick thread with everyone cc'd so that we can make sure > everyone is on the same page with the status bar. My impression from Myk > and Dietrich is that the status bar is being replaced with an extension bar > (which jetpacks add themselves to), and the extension bar is an entirely new > piece of UI (different id, doesn't contain any Firefox specific UI, possibly > different styling to account for an option of having larger icons). So > while the extension bar, containing jetpacks, can be enabled and disabled by > the user, the status bar as it exists today would no longer be available in > Firefox 4. We've been working on integrating existing status bar > functionality into other parts of the UI to accommodate this change.
Bit of a side issue, which I tried to point out in a bug comment somewhere, is the sync UI. The docs about sync seem to assert that the sync icon will continue to appear in the lower right corner (on some kind of bar). Prior to this thread, someone from Mozilla asserted that the sync icon wouldn't be in the main UI (I'm afraid I don't have the bug comment link to hand).
Clearly it can't be on the status bar if it's going away (by default?). Will it be built-in UI on the "extension" bar? Move somewhere else? Not be in the main UI? Maybe it's happened somewhere that I didn't see, but if different people are asserting different things about the same feature, it seems to me there should be some discussion...
> In the sort term, but in the long term we believe people will really like > this change. Giving each Jetpack a panel to contain its UI drastically > increases the number of extensions you can have easy access to. There are a > lot of current toolbars that I would consider running if it didn't mean > giving up 1/3 or 1/2 of my screen space because they currently each mandate > persistent primary UI. Obviously making significant changes like this means > some things need to be updated, but it will also position us to have a much > better interface going forward. Jetpacks, the extension bar, and > arrowpanels will create a glorious future of simplistic access to complex > functionality :)
> -Alex
I will wait and see, particularly how the mouse-over link thing is done. It is, in my opinion, a critical security issue. So much is going into Firefox 4 that it boggles the mind thinking how it will all go together.
On Tue, Aug 24, 2010 at 6:00 PM, Ron Hunter <rphun...@charter.net> wrote: > I will wait and see, particularly how the mouse-over link thing is done. > It is, in my opinion, a critical security issue.
The sync team is working on that this week, although it likely won't appear super polished at first. (we're also likely going to make some changes so that it ultimately looks better than that proposal, things are a bit rough on XP at the moment).
We've gone back and forth a few times on how much we really want to have this in primary UI. There are really two totally different issues being considered:
1) Providing a control for the user to manually initiate a sync since we won't have real time sync set up at first, and you may be about to switch to a mobile device 2) providing a visual cue that everything you do with this computer (history, create an account at a web site, remember a password) is not just being remembered, but is being uploaded and saved across multiple machines, kind of the total opposite of private browsing. This becomes increasingly problematic when account manager lands, since it will allow people to easily create new accounts at web sites (complete with randomly generated passwords). If you use a friend's computer, you may accidentally give them exclusive access to the account you just created. sync+account manager is pretty fertile ground for mode errors (but is also really powerful and useful when used correctly).
When we were just considering point 1 I was in favor of doing everything we could to increase the sync interval, and otherwise moving the ability to do a manual sync to secondary UI. However, now that we have point 2 to consider as well, I've switched back to now advocating that we can provide a strong visual cue that you are using another person's sync account.
In the future we may want to go even farther than the proposal in that bug, and have selecting a persona (or on windows 7 alternately a favorite color) part of the sync account creation process. This way we could set the Firefox button to the user's favorite color (or apply the persona), and provide a very strong ambient cue that you are logged into Firefox as a specific user. (you expect the Firefox button to be blue and have your name next to it, but on this computer it is hot pink and says "Leela", so you are less likely to create an account at the latest social network until you switch to a guest account). That of course is well beyond Firefox 4, and is based on some new platform capabilities to be able to modify color values (to get the gradient right, etc.)
-Alex
On Tue, Aug 24, 2010 at 5:45 PM, Michael Lefevre <n...@michaellefevre.com>wrote:
>> I want to start a quick thread with everyone cc'd so that we can make sure >> everyone is on the same page with the status bar. My impression from Myk >> and Dietrich is that the status bar is being replaced with an extension >> bar >> (which jetpacks add themselves to), and the extension bar is an entirely >> new >> piece of UI (different id, doesn't contain any Firefox specific UI, >> possibly >> different styling to account for an option of having larger icons). So >> while the extension bar, containing jetpacks, can be enabled and disabled >> by >> the user, the status bar as it exists today would no longer be available >> in >> Firefox 4. We've been working on integrating existing status bar >> functionality into other parts of the UI to accommodate this change.
> Bit of a side issue, which I tried to point out in a bug comment somewhere, > is the sync UI. The docs about sync seem to assert that the sync icon will > continue to appear in the lower right corner (on some kind of bar). Prior to > this thread, someone from Mozilla asserted that the sync icon wouldn't be in > the main UI (I'm afraid I don't have the bug comment link to hand).
> Clearly it can't be on the status bar if it's going away (by default?). > Will it be built-in UI on the "extension" bar? Move somewhere else? Not be > in the main UI? Maybe it's happened somewhere that I didn't see, but if > different people are asserting different things about the same feature, it > seems to me there should be some discussion...
I notice that in the "alternative" implementation of this (showing the URL as a pop-in status bar à la Chrome), it's pointed out that showing the URL in the address bar is infeasible when in full-screen mode. What's going to happen when the user's in this mode, or when they're using a dynamically-created window that doesn't have the address bar? (I seem to recall, though, that one of the papercut bugs was about preventing these sorts of windows, so maybe that's not relevant.)
Now, after reading here and looking at the proposals on where you're proposing to put sync I just think that the idea of removing the status bar just keeps getting worse and worse. That large sync icon is just cluttering prime *non-peripheral* space that should be used for extra tabs. Sync is also a *status* that is better suited to an area of *peripheral* vision like the status bar.
This *is* FASHION over logical design. It's merely an attempt to get a one-up over Google in the current game to see who can be the most minimal, and to attempt to make-up for the fact that Mozilla were late to the game. Comments like the following from A. Limi on Bugzilla (https://bugzilla.mozilla.org/show_bug.cgi?id=572160) only re-enforce my opinion on this:
"... our UI is actually *more* space-efficient than Chrome on Windows. In itself, that's not a goal, but it does send the right message, that we do care about browsing screen real estate."
I think you'll already have sent that message that you care about space-efficiency by rightfully putting the tabs in the title bar (as A. Limi rightfully suggests) - removing the status bar by default, however, is a step too far. There comes a saturation point where minimization becomes inversely proportional to functionality - Opera 10.6 gets the balance just right. Both Chrome, and now Firefox, look to be passing that point; Firefox even more so than Chrome! All for the sake of a mere 20 *peripheral* vertical pixels?!
> In the sort term, but in the long term we believe people will really like > this change. Giving each Jetpack a panel to contain its UI drastically > increases the number of extensions you can have easy access to. There are a
I suppose the previous post meant by "my current extensions", "my not-jetpack-extensions". Consequently any number of fabulous features for jetpacks will not help them.
> lot of current toolbars that I would consider running if it didn't mean > giving up 1/3 or 1/2 of my screen space because they currently each mandate > persistent primary UI. Obviously making significant changes like this means
Alex, could explain this a bit more? Why does the statusbar take up 1/3 of your screen?
> some things need to be updated, but it will also position us to have a much > better interface going forward. Jetpacks, the extension bar, and > arrowpanels will create a glorious future of simplistic access to complex > functionality :)
Wouldn't removing the Firefox features from the status bar, making it's visibility user-controllable, it's width flexible, and embedding it in the extension bar or vice-versa accomplish the same goals? (Not a big deal for us FWIW).
> could explain this a bit more? Why does the statusbar take up 1/3 of your > screen?
Current extension toolbars could end up taking 1/3 of my screen, this is a problem that we are hoping to solve with the extension bar (which is being worked on as part of Jetpack).
Right now we have two common ways for extensions to modify the UI, a persistent toolbar (yahoo toolbar, etc.) and small controls placed across the status bar (weather forecast, audio player controls, etc.) The new Jetpack model is to use an icon in the extension bar that when clicked displays an arrowpanel containing the extension's controls. So for instance, if I wanted to use the functionality of the following current toolbars:
-amazon wishlist -stumbleupon -google -facebook
I would be looking at about 1/3 of my screen covered in persistent toolbars. However, if these were implemented using Jetpack with arrowpanels, I would have 4 icons in my extension bar, each with their full functionality one click away. (and subsequently I could actually use all of them instead of being forced to choose, since the limits of available screen space currently force me to use just one or two). Jetpacks that do things like display the weather could still do so, just by making their part of the extension bar a bit wider.
The extension bar also helps set user expectations for where there Jetpacks are going to appear in the interface after install, and would (I believe) be a fully customizable toolbar, similar to the navigation toolbar.
-Alex
On Tue, Aug 24, 2010 at 8:51 PM, johnjbarton <johnjbar...@johnjbarton.com>wrote:
>> In the sort term, but in the long term we believe people will really like >> this change. Giving each Jetpack a panel to contain its UI drastically >> increases the number of extensions you can have easy access to. There are >> a
> I suppose the previous post meant by "my current extensions", "my > not-jetpack-extensions". Consequently any number of fabulous features for > jetpacks will not help them.
> lot of current toolbars that I would consider running if it didn't mean >> giving up 1/3 or 1/2 of my screen space because they currently each >> mandate >> persistent primary UI. Obviously making significant changes like this >> means
> Alex, could explain this a bit more? Why does the statusbar take up 1/3 of > your screen?
> some things need to be updated, but it will also position us to have a >> much >> better interface going forward. Jetpacks, the extension bar, and >> arrowpanels will create a glorious future of simplistic access to complex >> functionality :)
> Wouldn't removing the Firefox features from the status bar, making it's > visibility user-controllable, it's width flexible, and embedding it in the > extension bar or vice-versa accomplish the same goals? (Not a big deal for > us FWIW).
> However, if these were implemented using Jetpack with > arrowpanels, I would have 4 icons in my extension bar, each with their full > functionality one click away.
So, with only four icons present, why couldn't the rest of the bar function as a status bar?
The above bug contains all the dependencies. The wiki page above has those dependencies in list of the current UI pieces in the status bar, and UX's proposed solution (each linked to back to the bugs). The bugs for implementing the different parts of the new theme that replace used-to-be-on-the-status-bar features do not have owners. I signed up to do the add-on UI integration work, which lead to removing the status bar in favor of the add-on bar, after Boriss' design work concluded that way. It's my fault for not calling out sooner that in order to remove the status bar, each of those dependent bugs probably needs to block, and therefore needs an owner.
WRT to the design, it was my understanding after repeated talks with UX that the status bar would be hidden *and* that the user-facing UI for un-hiding it would be *removed* - replaced instead by the add-on bar. Boriss addressed the shortcomings of the status bar in her series of posts about add-on UI on her blog (http://jboriss.wordpress.com/). The driving reason behind the actual replacement of the elements in the implementation of that design, is that *the status bar is not customizable*. You cannot customize it the way that you can the other parts of primary UI. Customizing the status bar involves enabling/ disabling or install/uninstalling add-ons. Also, add-ons add to the statusbar via the DOM directly, or via overlays, and can put anything there. And because a discrete API is not used, we can't do magical things like wrapping existing items in elements that would make them properly customizable.
Instead the approach proposed in the bug is:
* Hide the status bar element, but leave it in the document. This prevents extensions from completely breaking, or breaking Firefox by not handling exceptions thrown by not checking to ensure they actually got an element for the status bar.
* Remove the option in the View menu to make it visible. Otherwise add- ons wouldn't need to update to the new functionality that allows user- control over what's visible in the bar at the bottom of the screen. Every story and blog post and tweet would say "Go to the View menu and re-enable it to get your add-ons back.", and users would be stuck forever with a status bar that *they cannot customize*. If you decide you don't want your music widget down there for today, too bad, you have to uninstall or disable the add-on. Replacing the statusbar with a toolbar means that they can add/remove at runtime. If add-ons want to be in the add-on bar, and don't want to use the widget API in Jetpack, they can use the same toolbar infrastructure they're familiar with.
* Provide the add-on bar in it's place, a new element that is a properly customizable toolbar. Much of the conversation is about the status bar being *gone*, where really the plan is to *replace* it with a similar bar that is far more friendly to users, and provides far more functionality and ease-of-use to add-on developers, whether the add-on is Jetpack-based or not.
On Aug 25, 5:53 am, Mike Beltzner <beltz...@mozilla.com> wrote:
> Indeed. Elucidation on the plan of record would help. Also, knowing what pieces are underway and which are OMGWHAT? underresourced would help a ton a ton.
> I want to start a quick thread with everyone cc'd so that we can make sure > everyone is on the same page with the status bar. My impression from Myk > and Dietrich is that the status bar is being replaced with an extension bar > (which jetpacks add themselves to), and the extension bar is an entirely new > piece of UI (different id, doesn't contain any Firefox specific UI, possibly > different styling to account for an option of having larger icons). So > while the extension bar, containing jetpacks, can be enabled and disabled by > the user, the status bar as it exists today would no longer be available in > Firefox 4. We've been working on integrating existing status bar > functionality into other parts of the UI to accommodate this change.
> Myk and Dietrich: please let us know if that is incorrect, since this will > effect which changes are mandatory or not (like providing the ability for > the user to see a link target on hover).
> I would be looking at about 1/3 of my screen covered in persistent > toolbars. However, if these were implemented using Jetpack with > arrowpanels, I would have 4 icons in my extension bar, each with their full > functionality one click away. (and subsequently I could actually use all of > them instead of being forced to choose, since the limits of available screen > space currently force me to use just one or two). Jetpacks that do things > like display the weather could still do so, just by making their part of the > extension bar a bit wider.
Have you talked to the developers of those toolbars, and have they promiced they would change their UI to a single button if Firefox renamed the status bar to extension bar, or is it just something you hope? I very much doubt they would do so.
No one is banning toolbars! The add-on bar, along with the widget API in Jetpack, is offering new UI options that give those developers the ability to be less obtrusive. Also, widgets on the add-on bar can be as wide as they'd like.
To repeat: Developers can still create UI-hogging toolbars if they want, and users can still install them.
----- Original Message ----- > Den 25-08-2010 07:40, Alex Faaborg skrev: > > I would be looking at about 1/3 of my screen covered in persistent > > toolbars. However, if these were implemented using Jetpack with > > arrowpanels, I would have 4 icons in my extension bar, each with > > their full > > functionality one click away. (and subsequently I could actually use > > all of > > them instead of being forced to choose, since the limits of > > available screen > > space currently force me to use just one or two). Jetpacks that do > > things > > like display the weather could still do so, just by making their > > part of the > > extension bar a bit wider.
> Have you talked to the developers of those toolbars, and have they > promiced they would change their UI to a single button if Firefox > renamed the status bar to extension bar, or is it just something you > hope? I very much doubt they would do so. > _______________________________________________ > dev-apps-firefox mailing list > dev-apps-fire...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-apps-firefox
> If you decide > you don't want your music widget down there for today, too bad, you > have to uninstall or disable the add-on. Replacing the statusbar with > a toolbar means that they can add/remove at runtime. If add-ons want > to be in the add-on bar, and don't want to use the widget API in > Jetpack, they can use the same toolbar infrastructure they're familiar > with.
The toolbar infrastructure is broken. Add-ons providing items for toolbars need to either manually inject them (which isn't straightforward at all, e.g. Adblock Plus gets it wrong) or tell users to look for the items in the customization UI, which isn't really the post-install experience you want. I'd argue that the current experience with the status bar is actually better.
The current experience with the status bar is that the user cannot change anything at all. I can't see how that's better.
Can you file bugs on how the toolbar customization infrastructure could be improved? Or throw your thoughts on an etherpad and I'll file the bugs?
Either way, we need to ensure our UI is customizable in a way that allows add-on developers control over their add-ons default appearance, but gives the user maximum ease and control over presence/absence and location.
----- Original Message ----- > On 25.08.2010 11:37, Dietrich Ayala wrote: > > If you decide > > you don't want your music widget down there for today, too bad, you > > have to uninstall or disable the add-on. Replacing the statusbar > > with > > a toolbar means that they can add/remove at runtime. If add-ons want > > to be in the add-on bar, and don't want to use the widget API in > > Jetpack, they can use the same toolbar infrastructure they're > > familiar > > with.
> The toolbar infrastructure is broken. Add-ons providing items for > toolbars need to either manually inject them (which isn't > straightforward at all, e.g. Adblock Plus gets it wrong) or tell users > to look for the items in the customization UI, which isn't really the > post-install experience you want. I'd argue that the current > experience > with the status bar is actually better. > _______________________________________________ > dev-apps-firefox mailing list > dev-apps-fire...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-apps-firefox
> * Provide the add-on bar in it's place, a new element that is a > properly customizable toolbar. Much of the conversation is about the > status bar being *gone*, where really the plan is to *replace* it with > a similar bar that is far more friendly to users, and provides far > more functionality and ease-of-use to add-on developers, whether the > add-on is Jetpack-based or not.
Would you please outline how your plan provides more functionality and ease-of-use for non-Jetpack addons? I'm not disputing your claim, I just don't see any thing about this in the previous posts.
Well actually I am skeptical. I don't care about more functionality and ease of use for the statusbar is 100% now because I don't have to do anything. But overall the UI plan sounds good, so helps us out here: outline a migration plan from statusbars.
>> could explain this a bit more? Why does the statusbar take up 1/3 of your >> screen?
> Current extension toolbars could end up taking 1/3 of my screen, this is a > problem that we are hoping to solve with the extension bar (which is being > worked on as part of Jetpack).
But we aren't talking about toolbars or jetpacks here. I want to know about statusbar icon buttons in non-jetpack extensions. All the rest of the story sounds great.
----- Original Message ----- > On 8/24/2010 10:40 PM, Alex Faaborg wrote:
> >> could explain this a bit more? Why does the statusbar take up 1/3 > >> of your > >> screen?
> > Current extension toolbars could end up taking 1/3 of my screen, > > this is a > > problem that we are hoping to solve with the extension bar (which is > > being > > worked on as part of Jetpack).
> But we aren't talking about toolbars or jetpacks here. I want to know > about statusbar icon buttons in non-jetpack extensions. All the rest > of > the story sounds great.
On Wed, 25 Aug 2010 17:00:21 +0200, Dao wrote: > On 25.08.2010 16:33, Dietrich Ayala wrote: >> The current experience with the status bar is that the user cannot change anything at all. I can't see how that's better.
> It works, predictably. A robust and fully customizable UI may be better > but isn't currently available.
It's pretty hacky (extends the toolbar bindings) but it essentially turns the status bar into a customizable toolbar.
> I also don't think the desire to move status bar items around is strong > enough to make this a priority.
Besides there is at least one extension (Statusable) that allows you to move statusbar items around, or at least reorder them.
>> Can you file bugs on how the toolbar customization infrastructure could be improved? Or throw your thoughts on an etherpad and I'll file the bugs?
> For Firefox 4?
> I was just throwing around issues I saw -- I don't have solutions at hand.
> I want to start a quick thread with everyone cc'd so that we can make sure > everyone is on the same page with the status bar. My impression from Myk > and Dietrich is that the status bar is being replaced with an extension bar
(Since I've already posted to this thread 4 more times than I'd wish, I don't want you to think that this statusbar change is all that alarming to me. These are just suggestions, don't blow a fuse.)
Because Firebug caught lots of grief in the past for waiting until late beta releases to update our users, we already released 1.6b1. We are done making changes; we plan to push our update along with your last beta. With 5 days left before your feature freeze, coming up with a surprise addon-breaking change like this makes our work more difficult.
I am sure if I read everything about mozilla I would know about this change, but then again Alex's post starts out from the assumption that in fact this is a surprise.
So again I will make my suggestion that the special character of this so-called beta phase be made explicit. You are changing your development practice (good!) for important reasons (good!) but you are naming new things with old names. This confuses people who work with you (not so good). We should have waited for Firebug 1.6b1 until after your feature freeze. I just did not notice that is was between b4 and b5 because based on past experience the difference between those numbers did not seem significant until I looked at your new beta procedure in detail.
As has been mentioned, I blogged about this topic last month but have not said anything about it since. Maybe I can sum up what's been going on, and Dietrich can chime in if I'm missing anything.
Progress bar/page status -> Tab status bar (see bug 578028) Link destination indicator -> URL bar (see bug 587908) Add-ons -> Add-on bar (bug bug 574688) Download progress -> unknown. Previously redesigned in bug 564934, but now looking unlikely for Firefox 4.0) Sync UI -> Top of toolbar (see bug 589981) The plan for the add-on bar is that it will span the entire width of the page. It would be summoned and dismissed via a small button, similar to this (imagine the add-ons bar spans the entire page).
Add-on authors who currently have an icon in the status bar would have to update their code in order to appear in this add-ons bar. Apparently this is trivial for add-ons not using Jetpack, and Dietrich offered to put up a blog post on how to achieve this. Dietrich says that it's fairly easy for add-ons that wish to use jetpack, but it requires more code changes for existing add-ons because they're likely using raw DOM.
The add-on bar will eventually allow for customizability, in which elements of the addons bar can be moved to different areas of Firefox that support customization (navigation bar, toolbar, addon bar, possibly more). Implementing this, Dietrich has says, would just use the current customization sheet which would then need to support customization of stuff below it: not just in the nav toolbox area. This is a big change to be starting now, and thus is considered a goal for Firefox 4.1, not Firefox 4.0.
WHAT'S LEFT TO BE DONE:
1. Implementing the actual add-on bar. Dietrich is working on this 2. Communicating to add-on authors with add-ons currently using the status bar how to utilize the add-on bar instead 3. Figuring out where to put the download indication that's currently in the status bar and implementing this. For instance, tabs may be prime candidates as downloads are linked to tabs and we currently show a status indicator here for page content already. 4. Finishing link preview. Shorlander is working on the design 5. Finishing Sync button shift, which will likely occur after feature freeze
> No one is banning toolbars! The add-on bar, along with the widget API in Jetpack, is offering new UI options that give those developers the ability to be less obtrusive. Also, widgets on the add-on bar can be as wide as they'd like.
> To repeat: Developers can still create UI-hogging toolbars if they want, and users can still install them.
>I think it would be inaccurate, and presumptuous, to conclude that
toolbar writers want to be inconspicuous, or frugal with user's screen space.
