MozillaWiki

Firefox/Projects/3.7 and 4.0 Theme and UI Revamp/Direction and Feedback: Difference between revisions

Page Discussion

Firefox/Projects/3.7 and 4.0 Theme and UI Revamp/Direction and Feedback (view source)

Revision as of 00:05, 4 February 2010

2,718 bytes removed ,  4 February 2010
no edit summary
No edit summary
Line 1: Line 1:
{{Restricted}}
{{Restricted}}


= Firefox 3.7 Theme/UI Proposed Direction =
= Firefox Theme/UI Proposed Direction =


[[File:Fx-3.7-Direction-Phase-01.png]]
[[File:Fx-Next-Direction-i05.png]]


The original goals of the [[Firefox/Projects/Windows Theme Revamp|Windows Theme Revamp Sprint/Project]] were to identify problems with the current Firefox UI and propose solutions to those problems. Initially emphasis has been placed on Firefox's visual appearance on Windows. Particularly [[Firefox/3.0 Windows Default Theme Issues|Windows 7 and Vista]] (i.e. the future). Going forward we are going to look into the best ways to carry these ideas over to Mac and Linux as well.
The original goals of the [[Firefox/Projects/3.7 and 4.0 Theme and UI Revamp|Theme/UI Revamp Project]] were to identify problems with the current Firefox UI and propose solutions to those problems. Strong emphasis has been placed on Firefox's visual appearance on Windows. Particularly [[Firefox/3.0 Windows Default Theme Issues|Windows 7 and Vista]] (i.e. the future). We are also looking into ways to carry some of these ideas over to [[Firefox/Projects/3.7 and 4.0 Theme and UI Revamp/Mac Specific Visual Refresh|Mac]] and [[Firefox/Projects/3.7 and 4.0 Theme and UI Revamp/Linux Specific Visual Refresh|Linux]].


Since restructuring the theme touches and depends on so many other elements the project has expanded slightly in scope. It now encompasses not just the current visual style, but also how best to handle UI placement, arrangement and also the evolution of some new features.
Since restructuring the theme touches and depends on so many other elements the project has expanded slightly in scope. It now encompasses not just the current visual style, but also how best to handle UI placement, arrangement and also the evolution of some new features.


After [[Firefox/3.7 Windows Theme Mockups|a few iterations]], and a lot of discussion, the UX team has settled on a firm initial direction to be implemented in Firefox 3.7. <span style="color: #7b1344">''This direction is at the UX team proposal stage, to be approve by drivers and '''subject for constructive community feedback'''''</span>.
After [[Firefox/4.0 Windows Theme Mockups|a few iterations]], and a lot of discussion, the UX team has settled on a firm initial direction to be implemented in a future version of Firefox.




== Update to Visual Styling ==
== Update to Visual Styling and Resulting UI Changes ==
As noted on the [[Firefox/3.0 Windows Default Theme Issues|3.0 Windows Default Theme Issues Wikipage]], Firefox feels dated and behind on Windows. Especially Vista and Windows 7. These issues include absence of Glass, anemic purple toolbar color on Vista, tall and bulky UI footprint, element overload, inconsistent toolbar icon usage/style, lack of a tactile look & feel and perhaps too great of a divergence between the look on XP and Vista/7.
As noted on the [[Firefox/3.0 Windows Default Theme Issues|3.0 Windows Default Theme Issues Wikipage]], Firefox feels dated and behind on Windows. Especially Vista and Windows 7. These issues include absence of Glass, anemic purple toolbar color on Vista, tall and bulky UI footprint, element overload, inconsistent toolbar icon usage/style, lack of a tactile look & feel and perhaps too great of a divergence between the look on XP and Vista/7.


The proposed direction to correct these shortcomings includes:
The proposed direction to correct these shortcomings includes:
* '''Embracing Glass''': Toolbar and Tabs using Glass. Raised translucent buttons that are slightly glossy to meld with the toolbar. Raised 3D look to achieve tactile "feel".
* '''Embracing Glass''': Toolbar and Tabs using Glass. Raised translucent buttons that are slightly glossy to meld with the toolbar. Raised 3D look to achieve tactile "feel"
* '''Neutral Tones''': Overall neutral color scheme that can transition among platforms. Can remain attractive and slick without fighting for focus from web content.
* '''Neutral Tones''': Overall neutral color scheme that can transition among platforms. Can remain attractive and slick without fighting for focus from web content
* '''[[Firefox/Sprints/Windows Theme Revamp/Direction and Feedback#Hiding_of_the_Menubar|Hiding the Menu Bar]]''': Hiding the menubar by default(on Vista/7) allows us to use Glass, free up vertical space and retain platform consistency.
* '''[[Firefox/Sprints/Windows Theme Revamp/Direction and Feedback#Placing_Tabs_on_Top|Placing Tabs-on-Top]]''': Create default placement of tabs-on-top with the option to have tabs-on-bottom
* '''[[Firefox/Sprints/Windows Theme Revamp/Direction and Feedback#Hiding_of_the_Menubar|Page and Tools Buttons]]''': Condense and trim existing menu structure into two buttons "Page" and "Tools". Similar to Safari and Chrome.
* '''[[Firefox/Sprints/Windows Theme Revamp/Direction and Feedback#Hiding_of_the_Menubar|Hiding the Menu Bar]]''': Hiding the menubar by default(on Vista/7) allows us to use Glass, free up vertical space and retain platform consistency
* '''[[Firefox/Sprints/Windows Theme Revamp/Direction and Feedback#Combine/Stop_and_Reload|Combine Stop/Reload]]''': Combine Stop and Reload into one button. Reduces visual "clutter" and combines two buttons that have mutually exclusive functionality.
* '''[[Firefox/Sprints/Windows Theme Revamp/Direction and Feedback#Hiding_of_the_Menubar|App Button and App Menu]]''': Condense and trim existing menu structure into a single button App Button labeled "Firefox"
* '''[[Firefox/Sprints/Windows Theme Revamp/Direction and Feedback#Create_Simple_Home_Tab|Home Button/Tab]]''': Remove "Home" Button from default toolbar. Move functionality to a "Home Tab" containing your homepage.
* '''[[Firefox/Sprints/Windows Theme Revamp/Direction and Feedback#Combine/Combine Stop, Reload and Go Into One Button|Combine Stop/Reload/Go]]''': Combine Stop, Reload and Go into one button attached to the location bar. Reduces visual "clutter" and combines three buttons that have connected functionality
* '''[[Firefox/Sprints/Windows Theme Revamp/Direction and Feedback#Create_Simple_Home_Tab|Home Button/Tab]]''': Remove "Home" Button from default toolbar. Move functionality to a "Home Tab" containing your homepage
* '''[[Firefox/Sprints/Windows Theme Revamp/Direction and Feedback#Create_Simple_Home_Tab|Introduction of App Tabs (or Persistent Tabs)]]''': Ability to create persistent "App Tabs" for web apps
 
 
== Placing Tabs-on-Top ==
Placing tabs-on-top would allow:
* Firefox to have a correct UI hierarchy where the controls are tab specific.
* Fix a redundancy in having both a titlebar with page title as well as a tab with the page title. Still titlebars can have the whole title instead of a truncated one.
* A Fitt's Law win if the window is maximized.
* A small vertical space saving allowing more room for content.
 
''Retain the option to have have tabs-on-bottom. Also potentially tabs on the left or right side in a thumbnail or list style view''.




== Hiding of the Menubar ==
== Hiding of the Menubar ==
[[File:Fx-3.7-Page-Menu-Phase-01.png|150px|left|thumb|Page Button Menu]]
[[File:Fx-Next-Direction-AppButton-i05.png|right|thumb|App Button]]
[[File:Fx-3.7-Tools-Menu-Phase-01.png|150px|left|thumb|Tools Button Menu]]
 
<br style="clear:both" />
The menubar as a UI is pretty good at one thing: hiding complexity. The general purpose of the menubar is to contain all of the things that you want your program to do but you can't(or shouldn't) cram into the main UI. So the menubar generally ends up with a lot of stuff that isn't used very often, if at all, and yet is reproduced on every window and takes up a significant amount of real estate. It also has the tendency to become a dumping ground for new or hardly used features. This experience can be made worse with sub-menus, or even sub-sub-menus, which are hard to find and hard to target.


Starting with Vista, and continuing with Windows 7, the menubar has been systematically removed from Windows applications built by Microsoft and other vendors. It has been replaced with alternatives like the Windows Explorer contextual strip or the Ribbon found in Office 2007. The Ribbon UI is now also used in Paint and Wordpad for Windows 7. Many apps still retain the menubar as an option to be pinned or to be shown briefly by holding the Alt key.
Starting with Vista, and continuing with Windows 7, the menubar has been systematically removed from Windows applications built by Microsoft and other vendors. It has been replaced with alternatives like the Windows Explorer contextual strip or the Ribbon found in Office 2007. The Ribbon UI is now also used in Paint and Wordpad for Windows 7. Many apps still retain the menubar as an option to be pinned or to be shown briefly by holding the Alt key.


Firefox isn't the type of application that necessarily has contextual actions in the same way Windows Explorer does. So how to handle the functionality of the menubar if it is hidden? Chrome and Safari (and to a lesser extent IE7 & 8) have solved this by sorting, trimming and collecting the menubar functionality into two separate buttons. One of these buttons has items that apply to the webpage and another to the application itself. Now they don't always agree on which item should go in which menu, but the general principal is sound. This is a good solution.
One of the more challenging, not to mention contentious, aspects of the Firefox UI update has been how to handle the MenuBar. On our first pass we were informed by how Safari and Chrome had handled this problem by paring down all menu items into two separate Page and Tools buttons. This approach has a few advantages but also some disadvantages. The new proposed approach to this problem is an App Button which is similar to the single menu approach taken by Windows 7 native applications (Paint, WordPad) and by MS Office.
 
The UX team feels this approach has several advantages over the previous idea:
* It is less complex
* Takes up less space
* Instead of two potentially conflicting locations for menu items, there is now only one unified location
* Can be placed in the upper left analogous to the Menubar paradigm it is replacing
* Similar to the far more ubiquitous Office 2008/2010 + Windows 7 application menu
* Reduces clutter on the Navigation Toolbar
* It also creates a more flexible and rich canvas for perhaps doing some decidedly non-menu-esque things


The menubar as a UI is pretty good at one thing: hiding complexity. The general purpose of the menubar is to contain all of the things that you want your program to do but you can't(or shouldn't) cram into the main UI. So the menubar generally ends up with a lot of stuff that isn't used very often, if at all, and yet is reproduced on every window and takes up a significant amount of real estate. It also has the tendency to become a dumping ground for new or hardly used features. This experience can be made worse with sub-menus, or even sub-sub-menus, which are hard to find and hard to target.
[[File:Fx-Next-Direction-AppMenu-Sketch.jpg|172px|right|thumb|App Menu Sketch]]
 
The App Menu could look something like this early sketch. The actual contents of the menu are still being decided on and tracked in [[Menu cleanup|Menu Cleanup]] wikipage.


The approach applied to this problem has been to:
The approach applied to this problem has been to:
* Dissect the menubar and menu bar items.
* Dissect the menubar and menu bar items.
* Categorize items based on function/theme.
* Categorize items based on function/theme.
* Categorize items based on whether they should be expected to affect the Page or the Application.
* Trim items that duplicate functionality in the default UI.
* Trim items that duplicate functionality in the default UI.
* Remove some items that don't make sense.
* Remove some items that don't make sense.
* Expose some items in the UI that weren't previously.
* Expose some items in the UI that weren't previously.


This is being documented on the [[Menu cleanup|Menu Cleanup]] wikipage.
This process will also be informed by data collected from the [https://testpilot.mozillalabs.com/testcases/menu-item-usage.html Menu Item Usage Test Pilot study].


The main goal here was to achieve parity with Vista and Windows 7. Secondary goals were to cleanup the menu, reduce space taken by the menubar and make way for future UI options like tab-on-top. Less UI space = more content space.
The main goal here was to achieve parity with Vista and Windows 7. Secondary goals were to cleanup the menu, reduce space taken by the menubar and make way for future UI options like tab-on-top. Less UI space = more content space.


A goal going forward is a smarter placement/discoverability of features so that they don't have to be hidden away in a menu. Population of the Page and Tools buttons should be considered carefully.
A goal going forward is a smarter placement/discoverability of features so that they don't have to be hidden away in a menu. Population of the App Menu should be considered carefully.


''Hiding of the menubar by default would only occur on Vista and Windows 7. Windows XP would retain the menubar by default as would Linux and of course Mac. Holding Alt on Vista/7 would show the menu (which can also be toggled on)''.
''Hiding of the menubar by default would only occur on Windows and potentially Linux. Mac would retain the menubar by default. Holding Alt on Vista/7 would show the menu (which can also be toggled on)''.


== Bookmarks Changes ==
== Bookmarks Changes ==
Line 68: Line 90:
The proposed solution for this is to make the bookmarks toolbar the place for bookmarks. Create a bookmarks "widget" that replicates the bookmark menu functionality and place that on the bookmarks toolbar. This could be moved to the main navigation toolbar as well.
The proposed solution for this is to make the bookmarks toolbar the place for bookmarks. Create a bookmarks "widget" that replicates the bookmark menu functionality and place that on the bookmarks toolbar. This could be moved to the main navigation toolbar as well.


[[Firefox/Sprints/Windows Theme Revamp/Direction and Feedback#Hiding_Bookmarks_Bar|There are additional suggestions for this in 4.0]].
If a user hasn't altered the bookmarks bar past the default, it will be hidden and the bookmarks widget moved to the navigation bar. If they have it will remain the same.


This will free up some more vertical space for content and remove visual clutter of an element that isn't being used.


== Combine/Stop and Reload ==
''The bookmarks bar could of course be turned back on''.
The Stop and Reload buttons have mutually exclusive functionality. Yet we have a separate button for each.


Merging stop and reload would free up more toolbar space and reduce the amount of buttons on by default.  This is particularly important because of shifting functionality caused by the hiding of the menubar.


A common complaint about this is the use case where someone might go to hit the stop button on a seemingly hung page as it just finishes loading only to hit refresh again instead. To solve this there would be a slight delay between when a page is finished loading and available for refresh again. Accompanied by a crossfade between the Stop and Refresh icons.
== Combine Stop, Reload and Go Into One Button ==
Merging these into one button and attaching them to the location bar gives them context. A secondary benefit is that it combines like functionality and removes another toolbar button.  


''In the Customize page there would be an option to add a separate Stop and Reload buttons.''
A common concern about this is that it would increase targeting time by moving the refresh/stop buttons so far away from the back/forward buttons. That really depends on where you are moving your mouse from however. If you are typing in the URL bar and moving to hit the go button then you are already in the right spot to hit stop if you change your mind. However if you are hitting back or forward and then want to hit stop/refresh it is far away.
 
This is a legitimate concern but it's hard to say how it will work out without observing it.
 
''In the Customize page there would be an option to add a separate Stop, Reload and Go buttons''.




Line 84: Line 110:
The home button at present functions pretty much exactly like a bookmark. Yet it has its own dedicated place in the default set of toolbar buttons. It's not entirely useful and takes up prime real estate.
The home button at present functions pretty much exactly like a bookmark. Yet it has its own dedicated place in the default set of toolbar buttons. It's not entirely useful and takes up prime real estate.


For 3.7 we would like to create a "Home Tab". Moving the functionality of the home button to a persistent "mini-tab". This tab, for 3.7, would just take you to your homepage. Any links clicked on this page would spawn a new tab. This would serve as a good introduction to tabs for users not accustomed to them.
We would like to create a "Home Tab" moving the functionality of the home button to a persistent tab. This tab initially would just take you to your home page. Any links clicked on this page would spawn a new tab. This would serve as a good introduction to tabs for users not accustomed to them.


[[Firefox/Sprints/Windows Theme Revamp/Direction and Feedback#Introduction_of_App_Tabs|There are further plans for this as well as "App Tabs" which will be discussed for 4.0]].
=== Future Expanded Home Tab Functionality ===
Eventually the Home Tab will start to be slightly more than just a link to your home page. It could turn into a dashboard like page which could potentially have your top bookmarks, about:me stats, history timeline, recently closed tabs, change styling on major local holidays, or more.  


This is currently being explored in [http://design-challenge.mozillalabs.com/winter09/submissions.php The Home Tab Design Challenge].


== Progress "Line" ==
A progress bar can make waiting seem slightly less painful and let you know if something might be hung-up or not. It won't actually make things faster, but it might make them feel faster.


Instead of the indeterminate progress indicator in use now, we would like add a progress "line" under the location bar on the active tab and at the top of each background tab. This will let people know about how much longer their background tabs have until they load and it also looks cool.
== Introduction of App Tabs (or Persistent Tabs) ==
The idea behind "App Tabs" is that some web apps are more like applications than web pages. For example, Google Docs, Gmail, Acrobat.com, MobileMe, 280 Slides, etc. Things you would want to have open all the time and they could potentially be chromeless since you don't navigate through them with back/forward. Sort of like built in [http://labs.mozilla.com/blog/2007/10/prism/ Prism]. If, say, you wanted Gmail open all the time without chrome you could drag it to the left and pin it thus making it an App Tab.


There would also be some other way to make an app tab besides drag/pinning it to the left. For instance a contextual menu item.


== New Notification UI  ==
An [http://groups.google.com/group/mozilla.dev.apps.firefox/browse_frm/thread/be7413a3f28d69bd# intermediary step] in the redesign of the notification system is also planned for 3.7.


This [http://people.mozilla.com/~faaborg/files/20090821-notification/notificationNamoroka-i1.png intermediary design] will leave all browser level notifications as Notification ''Bars''. This includes:
== Progress "Line" ==
* Rights Notification
[[File:Fx-Next-Direction-i05-ProgressLine.png]]
* Disabled third party plugin
* Locked Profile


Page level notifications will be integrated into the Site Button (currently home to Larry). As well as floating "panel" notifications.
A progress bar can make waiting seem slightly less painful and let you know if something might be hung-up or not. It won't actually make things faster, but it might make them feel faster.  


[[Firefox/Sprints/Windows Theme Revamp/Direction and Feedback#New_Notification_UI_2|A more full implementation planned for 4.0]].
Instead of the indeterminate progress indicator in use now, we would like add a progress "line" under the location bar on the active tab and at the top of each background tab. This will let people know about how much longer their background tabs have until they load and it also looks cool.




Line 115: Line 139:


'''Other applications don't hide the menu bar so how is this maintaining external consistency?'''<br />
'''Other applications don't hide the menu bar so how is this maintaining external consistency?'''<br />
Maybe it would be better phrased as "emerging external consistency". As of Windows 7 the most popular user facing prepackaged applications (and Office) ship with the menubar off by default. If it has one at all. Whether Photoshop or AutoCAD ship with menubars isn't necessarily relevant. For one they are different types of applications and for another they don't have a ubiquitous competitor ship with the OS (IE).
Maybe it would be better phrased as "emerging external consistency". As of Windows 7 the most popular user facing prepackaged applications (and Office) ship with the menubar off by default. If it has one at all. Whether Photoshop or AutoCAD ship with menubars isn't necessarily relevant. For one they are different types of applications and for another they don't have a ubiquitous competitor shipping with the OS (IE).
 
 
 
= Firefox 4.0 Theme/UI Direction =
 
[[File:Fx-4.0-Direction-Phase-01.png]]


While thinking about UI changes for Firefox 3.7 we simultaneously thought about where we wanted to take 4.0. These designs are envisioned as evolutionary steps. This serves two purposes: easing the transition and allowing adequate development time for platform capabilities.
This is a tentative direction of things we would like to see happen in 4.0. <span style="color: #7b1344">''These directions are still in early brainstorming and proposal phase, and '''broader suggestions and ideation is welcome'''''</span>. 
== Visual Styling ==
A primary goal of the 3.7 update is to improve how Firefox looks on Windows. This will be carried forward to 4.0 with refinements but no major changes.
== Major UI Change in 4.0 ==
Several major additions and changes are being discussed to the UI for 4.0. Keep in mind these changes are farther out and therefore more in flux than ideas for 3.7.
* Merging the LocationBar and SearchBar
* [[Firefox/4.0 Windows Theme Mockups#Combo Stop/Refresh/Go Button|Merging Stop/Refresh/Go Into One Button]]
* Adding a Tab-on-Top Option
* Introduction of App Tabs
* Expanded Home Tab Functionality
* Hiding Bookmarks Bar
* Profile Stuff
* Removal of Status Bar


= Future Posiblities =


== Merging the LocationBar and SearchBar ==
== Merging the LocationBar and SearchBar ==
Line 148: Line 148:




== [[Firefox/4.0 Windows Theme Mockups#Combo Stop/Refresh/Go Button|Merging Stop/Refresh/Go Into One Button]] ==
== Status Bar Evolution ==
Merging these into one button and attaching them to the location bar gives them context. A secondary benefit is that it combines like functionality and removes another toolbar button.
The status bar currently takes up a lot of space on every window. The full link description is used by some but not all. The progress bar can be duplicated elsewhere. It is also currently a catch-all for a great many extensions. As well as being at the bottom of the window away from the rest of the UI.  
 
A common concern about this is that it would increase targeting time by moving the refresh/stop buttons so far away from the back/forward buttons. That really depends on where you are moving your mouse from however. If you are typing in the URL bar and moving to hit the go button then you are already in the right spot to hit stop if you change your mind. However if you are hitting back or forward and then want to hit stop/refresh it is far away.
 
This is a legitimate concern but it's hard to say how it will work out without observing it.
 
''In the Customize page there would be an option to add a separate Stop, Reload and Go buttons''.
 
 
== Adding a Tab-on-Top Option ==
The tabs-on-top option would allow:
* Firefox to have a correct UI hierarchy where the controls are tab specific.
* Fix a redundancy in having both a titlebar with page title as well as a tab with the page title. Still titlebars can have the whole title instead of a truncated one.
* A Fitt's Law win if the window is maximized.
* A small vertical space saving allowing more room for content.
 
'' retain the option to have have tabs-on-bottom. Also potentially tabs on the left or right side in a thumbnail or list style view''.
 


== Introduction of App Tabs ==
Finding better placement for download notifications, progress (see [[Firefox/Sprints/Windows Theme Revamp/Direction and Feedback#Progress_.22Line.22|Progress "Line"]]) and link URLs would allow us to hide the status bar by default. It could then be used solely for extensions perhaps becoming the ExtensionsBar instead of the status bar. Installing an extention that made use of this space would then enable it. It could then be further enhanced to be slightly taller and enable extra functionality such as panels.
The idea behind "App Tabs" is that some web apps are more like applications than web pages. For example, Google Docs, Gmail, Acrobat.com, MobileMe, 280 Slides, etc. Things you would want to have open all the time and they could potentially be chromeless since you don't navigate through them with back/forward. Sort of like built in [http://labs.mozilla.com/blog/2007/10/prism/ Prism]. If, say, you wanted Gmail open all the time without chrome you could drag it to the left and pin it thus making it an App Tab.
 
There would also be some other way to make an app tab besides drag/pinning it to the left. For instance a contextual menu item.
 
 
== Expanded Home Tab Functionality ==
The Home Tab introduced in 3.7 will start to be slightly more than just a link to your home page. It turns into a dashboard like page. It could potentially have your top bookmarks, about:me stats, history timeline, recently closed tabs, change styling on major local holidays, or more.
 
 
== Hiding Bookmarks Bar ==
If a user hasn't altered the bookmarks bar past the default, it will be hidden and the bookmarks widget moved to the navigation bar. If they have it will remain the same.
 
This will free up some more vertical space for content and remove visual clutter of an element that isn't being used.
 
''The bookmarks bar could of course be turned back on''.




== New Notification UI  ==
== New Notification UI  ==
A [http://groups.google.com/group/mozilla.dev.apps.firefox/browse_frm/thread/be7413a3f28d69bd# redesign of the notification system] is planned for 4.0.
A [http://groups.google.com/group/mozilla.dev.apps.firefox/browse_frm/thread/be7413a3f28d69bd# redesign of the notification system] is planned.


[http://people.mozilla.com/~faaborg/files/20090821-notification/newNotification-i1.png This design] will remove notifications bars. Integrating persistent notifications into the Page and Tools buttons. As well as notification panels and activity indicator panels.
[http://people.mozilla.com/~faaborg/files/20090821-notification/newNotification-i1.png This design] will remove notifications bars. Integrating persistent notifications as well as notification panels and activity indicator panels.




== Profile Stuff ==
== Profile Stuff ==
Introduction of User Profiles. Uses could include different sets of bookmarks, individual histories, different settings, password/login manager, bookmark syncing(similar to [http://labs.mozilla.com/weave Weave]).
Introduction of User Profiles. Uses could include different sets of bookmarks, individual histories, different settings, password/login manager, bookmark syncing(similar to [http://labs.mozilla.com/weave Weave]).
== Removal of Status Bar ==
The status bar currently takes up a lot of space on every window. The full link description is used by some but not all. The progress bar can be duplicated elsewhere. It is also currently a catch-all for a great many extensions. As well as being at the bottom of the window away from the rest of the UI.
If the status bar was removed the functionality could be relocated and streamlined to other parts of the UI:
* '''Extensions Point''': Create a place in the navigation bar for extensions. They could then make use of new UI structures like panels developed for notifications. They would also be collected in a centralized and visible location.
** '''Problems''':
*** '''Not a lot of room''': Installing a lot of extensions will quickly fill the space. How to handle overflow?
*** '''How to handle extensions that aren't just an icon''': Some status bar extensions have text or horizontal widgets.
** '''Full Link Text''': A proposed way to handle this would be to put it in the location bar. It would have unique styling to indicate "This is where you will go". It would have the perceived performance effect of making navigation feel faster. It would also continue to keep UI in the same location at the top of the window.
* '''Progress Bar''': Will be added to background tabs and under the location bar of the active tab.
An alternative proposal would be to turn the status bar off by default. Move the existing functionality away and only turn it back on if an extension that uses it is installed.
Shorlander
canmove, Confirmed users
455

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/199596"