Open Bug 634560 (BookmarksTop) Opened 13 years ago Updated 2 years ago

Move default bookmarks toolbar position above Tabs bar

Categories

(Firefox :: Toolbars and Customization, enhancement)

x86
Windows XP
enhancement

Tracking

()

UNCONFIRMED

People

(Reporter: realRaven, Unassigned)

Details

(Whiteboard: wontfix? why?)

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13

Please move the bookmarks toolbar above the personal tabs toolbar. If moving the URL bar closer to the browser area is an important improvement of FX4 then the personal bookmarks toolbar should not be underneath it, as it has no page specific elements. Also, during navigation, the tab bar is used a lot more than the bookmarks toolbar, and it has a stronger relationship to the current page.

That's why propose the following default order of toolbars, from top to bottom:

Menu Bar
Personal Bookmarks
<========>
Tab bar
URL (Navigation Bar)

Also additional (User defined) toolbars should be inserted between Bookmarks and Tab bar - the tab bar should never move away from the URL bar!


Reproducible: Always
How would this handle the "Tabs on Top" option that puts tabs in the titlebar? Not sure how you'd put bookmarks above the titlebar..
I probably should add that bookmarklets are all about page specific elements, but that's just how I use the bookmarks toolbar personally.
This shows a mockup screen shot (based on the Fx4 Theme bloomind fx graphic glow) that shows how the toolbar positions should be by default (menu always on top). This makes a lot more sense than the current model, which has the bookmarks stuck between navigation bar and page.
(In reply to comment #1)
> How would this handle the "Tabs on Top" option that puts tabs in the titlebar?
> Not sure how you'd put bookmarks above the titlebar..

no it doesn't on my system. "Tabs on Top" moves the tab bar between the menubar and navigation bar. If the menu bar is hidden, "Tabs on Top" moves the tab bar between Titlebar and navigation bar.

I would much prefer an option of "move navigation bar into page" that left all the other toolbars at their current position, because this is really what this is trying to do. I find it a glaring oversight on behalf of Mozilla that they didn't think of this. Of course you can argue that Navigation and bookmarks are related, but you can equally argue that navigation and tabs are related. I often open multiple tabs on the same domain to have them open simultaneously, and so the tabs can also be viewed as a means of navigation. Definitely more related to the current page (as there is a current tab as well) than the bookmarks.

As regards the "how": the only thing I can say that some of the Themes I have recently reviewed (I am AMO Editor) successfully changed the order of bookmarks. If people chose to show tabs in the (window's) caption bar, then this should obviously override this behavior. 

Also, how to you handle multiple rows of tabs in the titlebar? I usually have 2 or 3 rows of tabs open, using Tabmix Plus. Also, the titlebar is hidden in fullscreen mode, does this mean there are no tabs visible in fullscreen mode? 

In my personal opinion the tabs are currently in a really awkward position, and I am constantly confused as to which tab is currently open - it is just too far away from the page I am viewing. So when Mozilla proposed to move the navigation closer to the page, they actually didn't do this, but they removed the tab bar and put it to the top. Which is IMHO a very bad way to treat a feature that made all the difference when we migrated from Netscape to Firefox.
Alias: NavigationBarToPage
this would kill the possibility to blindly click on top of the screen to change tab, that is the main reason for tabs on top.  To preserve this you can't move anything above tabs.
Component: General → Toolbars
Whiteboard: wontfix?
(In reply to comment #5)
> this would kill the possibility to blindly click on top of the screen to change
> tab, that is the main reason for tabs on top.  To preserve this you can't move
> anything above tabs.

Not true. First of all, this only applies to Fullscreen mode, (I hardly ever use it) in that mode you normally have no bookmarks visible. The only things visible are tab bar and navigation bar (when dropped down). If you look closer, I do NOT propose to change this behavior as it is valuable.

All I am saying is that in normal usage (not full screen mode), the position of the bookmarks toolbar is a distraction and moving up to the tabs over 3 or more toolbars is much more difficult than in the model I am proposing. THe navigation bar becomes a "page element" as in the design brief and the tabs will be perceived as sticking to the top of the active page again. Much cleaner, easier to use and less fugly.
Whiteboard: wontfix? → wontfix? why?
Alias: NavigationBarToPage → Think!
Summary: FX4: Move default bookmarks toolbar above Tabs bar → FX4: Move default bookmarks toolbar position above Tabs bar
(In reply to comment #6)
> (In reply to comment #5)
> > this would kill the possibility to blindly click on top of the screen to change
> > tab, that is the main reason for tabs on top.  To preserve this you can't move
> > anything above tabs.
> 
> Not true. First of all, this only applies to Fullscreen mode, (I hardly ever
> use it) in that mode you normally have no bookmarks visible.

These conclusions are based on your preferences and your habits, they don't necessarily apply cleanly to hundred millions of users. The first thing can probably be said of the other approach as well, but the difference is that the it has a tradition in browsers design.

> All I am saying is that in normal usage (not full screen mode), the position of
> the bookmarks toolbar is a distraction and moving up to the tabs over 3 or more
> toolbars is much more difficult than in the model I am proposing.

Fine, but then you have a toolbar that changes positioning based on the window mode, that would be suprising to most of the users. would not this force the user to recall two different positions for the same stuff? I would have to recall in which mode I am and where te toolbar is before blindly pointing at it.

While there is a design problem to solve, I don't think having a toolbar that changes position would help the user.
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > this would kill the possibility to blindly click on top of the screen to change
> > > tab, that is the main reason for tabs on top.  To preserve this you can't move
> > > anything above tabs.
> > 
> > Not true. First of all, this only applies to Fullscreen mode, (I hardly ever
> > use it) in that mode you normally have no bookmarks visible.
> 

> While there is a design problem to solve, I don't think having a toolbar that
> changes position would help the user.

Well I would like to argue that it changes position in your model, not in mine.
As in: 

1. the position during full screen mode is above the navigation bar. Since it is fullscreen mode you get the added benefit of mile-wide-above, which is what the user expects in full screen mode.

2. the position during normal mode is above the navigation bar. It is as close to the page as it is during fullscreen mode, you only loose the ability to move the mouse all the way to the top of the screen (but the same happens in your mode). Apart from that in both the current behavior and the one I propose, (on windows and linux systems) the position is BELOW the menu bar (as currently!) and BELOW the title bar of the window. (IF the menu is invisible then is it BELOW the title bar and firefox button, even with "tabs on top" enabled). Am I missing something?

but more to the point: when switching from fullscreen mode to normal mode, the bookmarks toolbar causes the _navigation toolbar_ to be in a different place (removed from the page) so that is a much bigger surprise, and an outright distraction, in my opinion.
Just to illustrate my point I have added some toolbars to my Fx4b11 in tabs on top mode. If you look at the rationale of moving the URL bar closer to the content window as one of the reasons for having tabs on top (I would argue, on top of the Navigation Bar not on top of all toolbars except menu bar) this is a clear fail. At the same time I would also not propose to move them between tab bar and Navigation bar as they break up the work flow (navigate . next . new page from bookmark) - move them above the tab bar and everything is fine. 

In FULLSCREEN mode, these are not visible anyway so your tab bar will remain at the top (and allow you to "blindly click" them)
I agree with the proposal, the suggested format flows well:  stuff that doesn’t change, followed by the tabs, followed by the URL for the page, followed by the page. I enabled the bookmarks toolbar and it really looks ugly for it to appear between the URL and the page.

I haven't experimented with tabs on the title bar, but it would still make sense for me to not place anything between the URL and the page.
QA Contact: general → toolbars
Version: unspecified → Trunk
First, a quick solution for users until something better comes along (though it does prevent the use of the new orange "Firefox" menu  button in favor of the old menu bar):
With all toolbar visible, view>toolbars>customize, drag the "Bookmarks Toolbar Items" placeholder from the bookmarks toolbar to the right of the menu bar, close the customize window, then hide the bookmarks toolbar.

Additionally you should be able to remove the nav bar icons for addons like AdBlockPlus in favor of the smaller "addon bar" icons where the status bar used to be, so the nav bar is free of all un-page-related clutter.

Screenshot of result:
http://hphotos-ash4.fbcdn.net/240046_2023948762003_1342520487_32414771_7558192_o.jpg 
(I added the FS button between the menu and bookmarks as a convenient separator)


That said, I think the obvious and far superior solution would be to simply have the entire section above the page container as an auto-variable-height "bars container" and have ALL of the bars themselves draggable within that container... a concept anyone who has used MS Word (before 2007 edition changed everything), should be familiar with.
Attached image bookmarks in add-on bar
Though I used to advocate for the repositioning of the bookmark toolbar from below the tabs bar, I had problems with every method I used to achieve that. The problems with placing it above or along side the tabs have been well described here and in other bugs.

The best solution I have found is to move the bookmark bar to the newly customizable add-on bar at the bottom of the window.
@Ian:
essentially the easiest way to implement this would be to move the address bar below everything else (which is really what the whole idea of "tabs on top" is about). The main objective of tabs on top according to all the advertisement videos is to have the address bar closer to the page, where ever they emphasize this, they show a screen shot with any other tool bars (including bookmarks) invisible. It is such a glaring oversight that I am really quite astonished that nobody caught it early on. 

Personally I do not care too much for the bookmarks at the bottom, as it makes navigating the drop downs (ups?) for my bookmark hierarchy much harder and increases the strain when dragging a bookmark from the address bar into the bookmarks. I would usually drag from the addressbar icon or from the tab icon into the personal bookmarks toolbar, thereby expanding categories and subcategories (such as Development / mozilla / User Interface). Since the menu is multi-dimensional, and usually does not require scrolling, this was always my biggest advantage over IE, from Netscape 4.x onwards, long before tabs came along.
The Bookmarks toolbar is off by default, I assume people turn it on and use it because want to have their bookmarks at their fingertips, not to hop over loops to get to a bookmark. If moved, please at least make it customizable, so it can be put anywhere.
I think this is good idea but only in "classic" mode, when tabs aren't on top. In other case all should be as is or at bottom.
Sorry, not when tabs aren't on top, but when menu is shown. And when tabs aren't on top - bookmarks bar should be above navigation toolbar.
I have been on MozCamp Europe (had been invited as AMO Editor) and saw some previews of Fx10 which is going to have a context-sensitive toolbar under the integrated URL bar, integrated into the page. So again this seems to go into the same direction, surely a bookmarks bar _below_ this would be distraction from this user experience? 

From a UI design perspective I think anything that distracts from the connection between tabs / URL-bar and page content (and isn't related to frequently used tasks) must be above them. Also URL-bar will be a lesser important part of the interface in the future; but I cannot use Firefox without the tab experience.

If Mozilla could provide some statistical measurements about _how_ _often_ tabs are clicked (if multiple tabs are used at all) and juxtapose this to the amount of clicks on URL bar, toolbar buttons and bookmark items, it would bring some clarity about the importance of these UI elements. IMHO, what is used most must be closest to the page in order to minimize mouse movement and maximize the work flow.

Findings might well indicate the opposite (e.g. that most users use keyboard shortcuts to toggle tabs) but we need some hard figures in order to understand this problem.
There are some metrics for this, eg here: http://blog.mozilla.com/metrics/2011/08/03/test-pilot-new-tab-study-results/

The bookmarks toolbar seems to be quite popular for loading pages in new tabs. Personally I have Menu Bar on and all my bookmarks in the Menu Bar, it took a while to get used to have them on top of the address field, but now it feels more natural to have them above actually.
Alias: Think! → BookmarksTop
Summary: FX4: Move default bookmarks toolbar position above Tabs bar → Move default bookmarks toolbar position above Tabs bar
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: