Firefox 3.1 Proposal: Tabs in the Awesome Bar
At the end of my last post on tabs, I mentioned Madhava’s concept for putting tabs into the Awesome Bar.
It’s a scalable and elegant solution. It has the hallmark of a good interface: it’s almost invisible, with no training required to gain the benefits of the feature. In one fell swoop it solves the twin problem of (1) it being easier to open a new page than it is to find an existing tab (2) the cognitive overload (and Hick’s Law penalty) of being required to think about whether something is already open in a tab, or whether I need to open it in a new tab.
I simply type where I want to go, and Firefox does the right thing.
After getting some insightful comments from Jenny Boris, who has been leading the charge in good thinking about tabs, we think it’s a feature we should try to get into Firefox 3.1. In particular, she asked me to try my hand at some mockups.
Here are three ideas on a theme; my preference is for the last. Although not pictured well, matching tabs should be ranked above plain URLs.
In terms of interaction there is only one complication: What happens if you want to open a new tab to a location that’s already open in another tab?
There are two solutions. The first is to make explicit a behavior that already exists in Firefox; holding down option while selecting a URL from the location bar opens it in a new tab. That’s the type of solution I’ve included in the mockups.
The second solution, proposed by Alex Faaborg, is much more subtle. If the user has opened a new tab, and then entered a URL, they probably mean to start a new navigation task instead of switching. Note that this solution can be used in conjunction with the first. While we both like how unobtrusive this solution, we worry that it might make Firefox feel too “magic”, or unreliable — not knowing why your browser has done something is unsettling.
Luckily, this is an edge-case that won’t happen often and any of the solutions will work well enough to be quickly polished to perfection with user testing.
My hunch is that adding tabs to the awesome bar will drastically simplify the day-to-day hunt-and-peck for tabs with a minimal change to Firefox. It’s a huge win. Another benefit is that it can work seamlessly with Weave in the future—which will be especially useful for calling up information that you were just looking at on your desktop, on your mobile device. What does everyone else think? This feature is still in fledgling mockup stage—although we hope to move it forward quickly. Madhava proposed a couple other sketch ideas for how a tab-awesome bar integration could look. We’d love other sketches if you think there are other directions to explore.
RT @azaaza Firefox 3.1 Proposal: Tabs in the Awesome Bar | Follow @azaaza on Twitter | All blog posts
Boriss
Hey Aza – awesome mockups. Just for clarification – when you say “open in new tab,” do you mean “open in existing tab?” As far as I know, the default awesomebar behavior is opening in the current tab unless Cmd is held down.
Christopher Finke
I prefer the first mockup for two reasons:
1. It’s visually similar to the current AwesomeBar behavior.
2. It has the simplest key combination for all cases: Down Enter, or Down-Down Enter. In my experience, typical users would rather not hold down Ctrl, Shift, Command, etc. if they don’t have to.
Boriss
My gut reaction is the first option is best. The icon in the right would be a subtle indicator that fits in with Firefox’s current system of having favorite and tag icons here.
Questions I’m wondering about are:
- Would having two redundant items for each match in a tab make the awesomebar less awesome because fewer results are shown?
- Would going to an open tab or making a new item be a vastly-more-used action? If one or the other is much more used, we can make it the default and have the other be a click on the icon or at a target, therefore not having the redundant two links.
Here’s an example of an icon from awhile ago – obviously it’s not quite like the first one in the page because it shows the item only once.
http://people.mozilla.com/%7Ejboriss/blog/short_icon.png
Screwtape
The tricky thing about tab-switching from the URL bar is that if you are in tab A, delete the URL from the URL bar, search for and then select tab B, what happens to tab A? Normally when you delete the URL from a tab and type something else, the new page replaces the old, but there’s no ‘new’ content here, just existing content that’s currently in a different tab.
- You could copy the contents of tab B into tab A, replacing the existing contents, but then you’d wind up with two tab Bs which could get confusing.
- You could leave tab A alone and just switch to tab B, but that’s totally contrary to the usual behaviour of replacing the contents of the URL bar and hitting Enter.
- You could close tab A and switch to tab B, but this would make it difficult to switch back and forth between tabs.
Personally, I’d normally use this for the documentation-searching use-case: “I remember reading something about this – is it in a tab or in my browser-history?” I’d hit Ctrl-T before typing anything so that if I picked a history item, I wouldn’t be clobbering an existing tab of useful information, and thus I’d prefer my new tab to be closed if I wound up switching to a different one.
For other people, I suspect the second behaviour (“leave the original tab alone, switch to the new tab”) would be best. Perhaps it could automagically Do The Right Thing based on whether the current tab is displaying about:blank?
Shawn Wilsher
One of the big complaints about the Firefox 3 location bar is that each row result is much bigger than it was before. Now you are making it even bigger. I can see the same crowd that complained before complain even louder now (and possibly get more support).
I’m not sure I like the idea that existing tabs are on top automatically too (at least, it seems that way per the mock-up). If I have a few mxr tabs open, and want to open another one by searching for a filename (the ns prefix happens to be pretty common in our codebase, and that’s what you start with), a lot of those first results are going to be useless, so you have to type more to get useful results back.
If we could somehow tie those results into frecency, I think it could work out.
Percy Cabello
I as well prefer option 3 because it defaults to the most probable course of action (switch) while exposing the Ctrl/Cmd link modifier which is a plus in itself.
To make it more subtle there should be a minimum number of tabs opened before including tabs in autocomplete results. I guess with something around 5 tabs after tab overflow it’s still easier to reach a tab by just scrolling to it.
Boriss’ tab icon definitely makes it easier to spot tabs.
ilya
I think that site preview thumbnail is useless. It is too small to be informative. BTW, this mockups looks more like some type of “launcher”, instead of location bar.
Marco Zehe
I like the combined idea of Jenny and Aza very much. Obviously we’d have to come up with good keystrokes when focused on the result which is both in bookmarks or history AND already open in a new tab. Should ENTER switch to the tab? And what should we use to explicitly reopen the same thing in another tab?
But I think if we go downn this path, this combined search result should be what we do, to not give those who don’t like the new display even more arguments, as Shawn said.
For screen reader users, this would also be the best solution: They wouldn’t have to learn a new control or panel, access is quick (blind people usually are fast typists), and right now, the new tab switching will be disabled for screen reader users anyway since it interferes with their keyboard hooking mechanisms and is obviously a complete waste on blind users. :-)
Looking forward to see how this discussion unfolds even more!
Marco
voracity
If anything, I prefer 3. I find 1&2 confusing, and that’s only with one matching tab (I’d frequently have two or more matching tabs).
My main preference would be to have the tabs show as thumbnails (plus labels) in a column on the right of the drop down. Hitting the ‘right’ arrow key would then shift me into this column, instead of history. I will frequently have many more than one matching open tab and, as Shawn Wilsher said, proposals 1,2&3 will push the real matches too far away from the top.
Blair McBride
My preference is for the last mockup too. It doesn’t provide redundant information, and it also complies with the current open-new-tab action that the location bar uses (ctrl-enter to open new tab).
Regarding the second solution to the new-tab problem (“If the user has opened a new tab, and then entered a URL, they probably mean to start a new navigation task instead of switching.”) – I’d argue that this is simply because there currently is no way to switch tabs via the location bar. If the user does have such a tab already open, they’re probably already manually searched for it. Adding this functionality to the location bar would allow the user to skip that manual search.
Chris
Currently there are four very different interfaces in Firefox for searching: search in this page, search open tabs, search favourites / history, search the web. We must consolidate.
Philipp
First of all, I want to say that I like the idea of searching the current tabs very much.
I’d prefer the last mock-up, as well. Because it’s the most compact one.
But I think the thumbnails are useless. They are too tiny and in my opinion a tab icon (as mentioned above) would make more sense.
Additionally I would suggest to add a restrict key for searching the tabs. So you would have more control about the searching manner. (Maybe there should also be an indication about the searching behaviour since there are so many (hard to memo-rize) restriction keys.)
PS: Sorry for my poor English :( (I’m a 16 years old German)
cbeard
Also of note is that once we have Weave up and running, it will be possible to have the Awesome Bar index and offer up open tabs from your other Firefox instances, e.g. home computer, work computer, mobile phone, etc.
xeen
I like the idea, too.
As said before, the thumb isn’t too useful to inform about the /webpage/. All it does is inform that this /suggestion/ is different. If someone gets updated to 3.1 and sees one of the above approaches, the first thing he’ll notice is the thumb. However, what does that mean? Only by looking at “Switch to this tab” which is barely readable in the mockups the users knows what’s so special about that suggestion.
There’s more to this: All but the first approach don’t fit into the default Awesome Bar style because of their different heights. While the third might be acceptable, it will make the Awesomebar look unorderly.
The 2nd approach however is unacceptable: It’s barely noticeable that these are actually two entries (down, down, enter, WTF?!) plus there’s the “highlight problem”. Highlighting only the latter and there’s no hint on what will open in a new tab, highlight both and there’s no hint what will happen. Selecting two items at once also means “do stuff for ALL of them” (i.e. copy, delete, load) and it’s certainly not native.
Oh, and why does it say “open in a new tab”. It’s always been “this tab” for the URL/Awesome Bar and that certainly shouldn’t change just because there’s already another tab with this URL open.
The 1st approach has the downside of duplicate entries, not sure that’s wanted.
I prefer the 3rd approach, but the “Cmd+Click” hint is fair at best – the Cmd+Click applies to all suggestions, not just the “tab” one. Maybe there’s a meaningful enough icon that can combine “switch to this tab” and the thumb preview to act both as identifier that this is a tab suggestion and what will happen.
Greetings
xeen
Scott
Option 3 has the better layout with least clutter, so I would opt for that. I would however have the default behaviour as “Open in a new tab”, with the command key press for “Switch to this tab” as I would guestimate that most people will remember that they have web site x already open in a tab and are deliberately using the Awesome Bar to open another copy of the web page.
One potential problem I could see, in my case, if this was implemented is that the titles for some of my bookmarks for various forums and threads would be too long to fit in the Awesome Bar with the layouts above because of the placement of the “switch to this tab” prompt and the thumbnail. This could be a serious problem for people running lower screen resolutions which renders the Awesome Bar useless. As I have never had a title too long to fit before I do not know if there is already an implemented solution, so apologies if this is a redundant point.
Personally I would leave the Awesome Bar layout as is, and instead make the “List all tabs” button flash/highlight, with the list itself indicating which Tabs match the user’s search should the user click on it. The Awesome Bar results could remain open in the background whilst the user is viewing the Tab List so that they user can return to them if they decided not to switch to one of the Tabs.
Nathan
I think this is a great idea. I like the third option best because opening another tab to the same page as an already open tab seems like such an unlikely desideratum. (Occasionally I do duplicate a tab, e.g. to switch quickly between viewing two parts of a long page, or to keep the current page open for later so I can hit Back to go to a previous page. In both cases, though, I am already viewing the tab I want to duplicate.)
I would stress, however, that there should still be interfaces providing two other types of multi-tab functionality:
1. Switching quickly between two tabs. This is already available in the current Ctrl+Tab. Having an option in the Awesome Bar to go to the most recent tab is fine, but it’s not necessarily as fast as Ctrl+Tab.
2. Browsing open tabs—especially if there are a lot of them, or several from the same site (in which cases the tab bar’s favicons and truncated title text may be less than helpful). I think the Awesome Bar could be very useful here (e.g. type “tabs” to see a list of all open tabs), and a visual alternative with thumbnails might be useful as well.
One issue this raises: What if there are multiple browser windows open? Should the tab browsing interface display only tabs from the current window, or all tabs? Or should there be ways to do both? I rarely use tabs in multiple browser windows, so I don’t know the best answer here.
Aza Raskin
@ Boriss’s First Comment: Thanks for catching that. It’s fixed now.
@ Shawn & Boriss: The second mockup was design to walk the line between showing redundant information (like in #1) and requiring holding down a key (like in #3) without taking up much more space. The way I imagined it working was that you could switch between the different options with the arrow keys.
@ The Tab Icon: There were two reasons I went for a thumbnail + icon hint instead of just an icon. The first is that while small, it still does provide useful information about the contents of the tab. It acts as a visual reminder. The second is that it’s much closer to direct manipulation. It’s obvious what you’ll be switching back to with a thumbnail because you’ve seen it before. An icon hides that behind a layer of abstraction. We can make the icon more iconic, but I’d always include the thumbnail too. Remember the recall versus recognition distinction!
@ Boriss, Voracity, Shawn, et al: “Would having two redundant items for each match in a tab make the awesomebar less awesome because fewer results are shown?” The answer is yes. We should be trying to combine as much as possible. I like Shawn’s idea of using left/right to expand tab interaction, but I wasn’t able to come up with a compelling layout. If anyone else wants to give it a shot, I’m all ears.
@ All: There seems to be some question as to whether people will switch to a tab more often than going to new URL in the same tab. My gut feeling is that when a tab matches, the user will more often want to switch to that tab. Unfortunately, we don’t have data either way. Luckily, this kind of behavior is easy to tweak, and we’ll quickly find the answer with some user testing.
Mark Sutherlin
I’ve intentionally avoided reading the previous comments so I wouldn’t void my opinion in my mind by seeing that it may already be present (and my vote can be counted).
My first thought is that I do not think there should be an Open in this Tab option. I’m afraid that this option could encourage poor behavior among users, ultimately making the browser less usable.
It may not necessarily be the case, so please don’t take offense, but when I read “What happens if you want to…?” I was immediately taken back to the days of the kitchen sink Mozilla Suite, where programmers made decisions based on similar logic.
Again, sorry, that’s just where my mind went.
I don’t think we should give the user the option to easily create duplicate tabs from the awesome bar. I fear that it will lead to more “messy” sessions for our users.
On a separate note, I’m not a fan of having the tab option on top. When I go to use the awesome bar, I’m looking to go somewhere else. Usually the top hit is a function of it’s wonderful heuristic for guessing where I want to go and I can just hit down and hit enter after typing a few letters.
I don’t often have the need to go searching for tabs. I tend to have many tabs open. As I’ve observed, it seems that others (less technical than me, the vast majority of our user-base) tend to have much fewer tabs open than me.
I’m afraid that by attempting to solve a problem that isn’t that great, we would be hurting our other strong solutions.
Hangfromthefloor
On the whole, this is a great idea. Personally, I do not think that opening an already opened tab in the current tab will be a heavily used feature, so it should be miniaturized.
However, in my opinion, compactness is the key. Having two fundamentally equivalent options (switch to this tab/open in this tab) as in the first mock-up is redundant. The second mock-up is too pleonastic, and the small text under the row in the third mock-up is too verbose. (Pardon my finicky observations, but it would look more tactful to change “open this page in this tab” to “open in this tab” in the third mock-up.)
Patrick
I don’t think there needs to be a visual option to open duplicate information in the current tab. Go with option 1, but get rid of the “open in this tab” option. If a user is not going to switch to a tab that is already open, there is no reason to add a feature to the Awesome bar that just duplicates a tab. Users can just type out the URL or scroll through the Awesome Bar’s list to get to a web page (just as they do now).
I do think the tab option should be on top.
Patrick
One more thing: what if a user wants to switch to a tab they already have open and close the current tab?
k5
Relevant k5 post:
http://www.kuro5hin.org/story/2008/8/21/14222/7694
User
But, please, don’t remove the tab toolbar. Its main benefit is that I can locate a tab by its position.
Don’t underestimate the power of the tab position.
What would be more useful is a way to group related tabs next one to other. For example, if I open 2 links from your blog in a new tab, those tabs should be next to your blog’s tab. Later, if I open a link from another tab, say, my leftmost tab, which now happens to be Techmeme, that tabs should open next to Techmeme’s tab.
And those groups, Techmeme and Your blog’s, should be easily located through the use of color or contrast.
This will create groups inside groups. For example, I came to your blog via Techmeme, so your group would be inside Techmeme’s group.
If I open a blank tab, that would create a new group…
David
I don’t think the instructions in the third option are necessary. When you move down the location bar’s list of results, pressing Enter immediately activates that item. However, pressing → hides the result list, leaving the location bar’s contents replaced with highlighted item’s URL. So, there’s already a perfectly consistent way of opening up a second copy of an already-opened page, whether in the current tab or a new tab. If the drop-down is shown, switch tabs. If it has been hidden, load a fresh copy of that page (in the current tab or in a new tab, depending on whether Alt was used).
I wonder, however, how many people actually discover the ability to hide the location bar drop-down with the keyboard. Note that this would probably require the least amount of code, and the least amount of “magic”.
Danielle Fong
Hi there,
I’ve been thinking about tab navigation a lot, and I think I’ve developed a pretty good and interesting solution. I wrote a blog post to make a case for it.
http://einfall.wordpress.com/2008/08/24/enhance-multitasking-improve-our-minds/
I thought that I should post this now, in the interest of being part of the conversation, but I do not, of yet, have a (computer) drawing or mockup, though I’m working on one. If there’s interest, I’ll find a way to scan my paper mockups, and put them up.
Jordan
Two thoughts:
- Mark Sutherlin’s comment on kitchen-sink Mozilla Suite made me think about the possible overloading of the awesomebar. Right now it’s great because it’s an understandable and intuitive interface that matches to titles and URLs. Already in 3.1 there is some slight overloading going on by adding keywords (good b/c you need to be an advanced user to use keywords anyway) limiting searches by using characters (bad because it is totally undiscoverable which characters do what and doesn’t give any feedback about having limited the search). It is soooooooo tempting to overload it because it is so easy to use, something everyone uses, provides great feedback, etc.but when there is too much functionality stuffed in it will be harder and take longer to use. (Now it’s simple and so it is easy to process/scan the results). Is tabs going too far? I don’t know, but it is a giant line to cross between the current single use case of ‘open website’ to ‘find website already open’. (But what a ridiculously fantastic extension!)
- This could be used for finding duplicate tabs that are open with some thought – it seems ready made for that and it’s something that you’d have to figure out how to display anyway.
Tim
I often will open several tabs from links, then when I’m finished with a tab, I close it (or ctrl+tab, technically my mouse does this with a button) and see what else I had brought up, without specifically remembering what I was looking for. With how you described this new system, I can’t do that any more. Please make sure that it won’t make this much more difficult for someone that browses like me! This system would only work when you’re looking to go to a specific place you know the name of, not just a link you opened earlier.
Jigar Shah
Looks good to me but i have serious concerns about its usability.
When awsome bar was introduced it was really good to have it. Especially for geeks like us. But look at oldbar[link]https://addons.mozilla.org/en-US/firefox/addon/6227[/link] addon statistics. Some people really didn’t like it at all. And might be few of thm all together dumped FF3. Might be more reviews and usability test is required. And disabling option is must. :)
Derrin
Why is the FF team so intent on ramming an awesome bar down everyone’s throat? And now to make it even more cluttery clumpy and kludgy it needs tabs?
Seriously, are you guys hiring folks from Microsoft to do the design and marketing? Because ramming things down users throats without option is an artform at M$, and you all seem to be eager art students here.
Danielle Fong
Okay, my paper mockup is up!
http://einfall.wordpress.com/2008/08/24/enhance-multitasking-improve-our-minds/
Ryan Scott Scheel
I like the third and fourth options from madhava best (have it at the bottom, as one line with thumbnails to combine the two)
On a different note, since this is on the awesomebar, I have frequently tried right clicking on the results to do some action. Since that was impossible, I asked the guy who goes by ‘mzz’ on IRC to make an extension and he ran into a problem that the highlight state isn’t frozen as it goes through other results. Getting that fixed and then adding right click functionality would be awesome. Having the following actions would be minimalistic:
Open
Open in New Tab
Bookmark (and Remove Bookmark)
Remove From History (if not bookmarked)
Copy URL
Copy Title
That would increase usability for many people, including a method to bookmark a page without loading it!
Ken Saunders
This is actually a cross post reply from Mozilla Links with the exception that I’ve noticed an overwhelming majority of people on this page thinks that this should be moved forward but I wonder how many here represents the average Firefox user and how many are already involved with Mozilla in one way or another?
For me it really isn’t uncommon to have 25+ tabs open at a time but I can’t see an average user doing that. Using a great number of tabs is most definitely a choice that power users make and so an add-on or hack would be the most appropriate.
Just because Mozilla has the ability to cram even more data into the location bar doesn’t mean that it should be done. If it is to be done, then we start hearing the word bloat come up.
It is absolutely essential to the growth and retention of Firefox’s user base that Mozilla only implements new features and options that a very clear majority is calling for and that is certainly not the case when it comes to the location bar. I’ve seen more negative responses to Firefox 3’s Awesome Bar from all over the Internet that it has probably taken the place of the old Firefox memory usage complaints.
Microsoft dictates what its users get and the results from that have all of us reading this article and using another browser.
Please keep the average Joe (or Joanne) in mind while this is still an idea and not yet set in concrete.
Mike Beltzner
Before I forget to tell you anywhere else, whatever UI we choose, it’s imperative that we do a switch & refresh operation, not just a switch. Don’t worry about form data; that should stay the same. If we have to repost to get content, we can be smart and not do the refresh.
webmage
I like Alex’s proposed solution — and an option blended into the “awesome bar” to open in new tab.
Remember, while we may be firefox geeks, there are quite a lot of users out there who are scared and frightened by keyboard shortcuts. Part of usability is being able to capture these scared cats and make them comfortable with firefox. If no one else, they will be wowed by the magic.
Julien Couvreur
I love the basic idea and the variants. I’d vode for option 3 as well.
One question is how many tab entries would get included in the AwesomeBar results?
Also would there be a code to filter only on tabs (similar to the asterisk ‘*” to keep only bookmarks)?
PS: Overall, I see a lot of excitement for the interface design of Firefox, simplifying user tasks and saving time and cognitive energy. That’s really great. Thanks Aza, I think you’re being a terrific influence on Firefox and Mozilla Labs.
Philip
It’s a great idea. I would collapse designs 2 and 3 by placing “open in current tab (option+return)” in small font, directly under the “switch to this tab”. (By the way, “open in current tab” is less ambiguous than “open in this tab”.)
The advantages of offering both the option to switch and to open in current tab are that the user will know what happened, know how to duplicate a tab, and will not duplicate unintentionally. The drawbacks are that it grows the result list, clutters the display, requires different treatment of blank pages, and (possible drawback) is a new way to duplicate a tab.
That the Awersomebar takes so much vertical space, thereby shortening the list of matches, is its only reasonable critique, I think. For example, the “Oldbar [extension] only affects the presentation of the results.” That’s especially a problem for mobile displays, which are small. How about a 2-column result list or going back to one line per result?
Obviously, tabs should be searched in all windows, otherwise the user would have to know which window to search in, which defeats the purpose of automatic searching.
Also, there should be a way to show only results matching open tabs. A keyword like “tab:” or “tab” would be discoverable, but using a symbol like “^” would be shorter and be consistent with the default keywords “*”, “+”, “#” etc. There should also be a way to hide tab matches: “tab-”, “-tab” or “-^”.
Less related: Like Ryan, I have for a while wanted right clicking on list items. That’s direct manipulation.
And, a direct way to change the order of tabs, by time opened, parent website, time viewed (frecency), domain, etc. would be easier to implement and would require less computer memory than Danielle’s design.
Michael Jacobsen
I want idea 1, w/ tabs searchable using a tab:yourkeyword. I think that way, people that don’t want it don’t get it.
Mike Lazfsh
Do the first mock-up but drop the instructions to “open in this tab” instruction from the second item.
You are either switching to a current tab or opening a URL from your history/frecency.
Why add another thing for people to read and understand?
Also drop the tab preview because if people want tab previews in their awesomebar they will find an extension that does that to all or some of their awesomebar stuff anyways.
Just use the “tab” icon from the users current options menu.
Faraannuape
unprecedented [url=http://www.oneview.co.uk/url/details.jsf?urlId=114905]cialis[/url] forged
gezjip
The toilet and this wasdifferent. Like this katty perry naked worked.
Paradiesstaub
To open an existing tab: text -> down -> enter
To create a copy of an existing tab: text -> down -> right arrow -> enter (needs optical feedback)
This solution is easy and would fit the goal.
stories
gay military stories
Zayıflama Lida Fx15 Ve Biber Hapı Zlfvbh
For other people, I suspect the second behaviour (“leave the original tab alone, switch to the new tab”) would be best. Perhaps it could automagically Do The Right Thing based on whether the current tab is displaying about:blank?