Control+Tab Discussion Thread
Boriss
about Control+Tab, a new feature for Firefox 3.1. I'd like to quickly
summarize where we are and make this the main thread of discussion so
we can move forward knowing what's been established and what's still
on the table.
WHAT LANDED IN THE FIRST VERSION OF CONTROL+TAB
On 7.17.08, part of Dão Gottwald's ctrl+tab add-on (
http://en.design-noir.de/mozilla/ctrl-tab/ ) landed in the Firefox
nightlies. It's described in my post here (
http://jboriss.wordpress.com/2008/07/16/control-tab-a-new-feature-for-firefox/
). In this version, pressing Control+Tab would reveal a filmstrip
view of the users' last three most recently used (MRU) tabs
(screenshot: http://people.mozilla.com/~jboriss/wiki/tab_preview/controltab.png
). Continued presses of tab would scroll the thumbnails back through
the users' tabs in MRU order with an animation similar to cover flow.
This landed, and people tried it out. A lot of the feedback was
positive - people generally liked the interface and the ability to
flip back and forth between tabs. There was agreement that the best
design would look native to the operating system. The keystroke
control+tab seemed to be a fairly good quick-key for visual
navigation, being similar to existing OS preview modes like alt+tab
(Linux, Windows) and cmd+tab (OSX).
...BUT THERE WERE CONCERNS WITH CONTROL+TAB
1. General consensus is that three thumbnail previews isn't enough.
This design is fine for flipping back and forth between two tabs, but
it shows too few of a user's overall tabs for practical visual
navigation. As Atul notes in this post ( http://www.toolness.com/wp/?p=127
), users will press Control+Tab until they get to what they want;
their focus is on the item they seek, not its location in MRU order.
So, without being able to see much of what's coming up, the process of
tabbing to a particular item takes longer and it's easy to overshoot
the goal.
So, how many thumbnails should be shown? Our options are to put a cap
at some number, or display all open tabs. The main benefit to
limiting the tabs is the optimization of browser performance and
maintaining a manageable display by not dealing with excess tabs.
Showing all tabs turns Control+Tab into a bit of a different animal -
a way to manage and navigate all tabs in a users' browser session. If
you're searching for that one missing tab, Control+Tab would be a
place you know you could find it. The main drawback of displaying all
tabs is that if the user has a ton of tabs open, either they would be
displayed too small to be useful or a scrolling/panning mechanism
would have to be implemented.
2. Should tabs be most-recently-used order, tab-order, or allow the
user to choose? This has been discussed in this bug (
https://bugzilla.mozilla.org/show_bug.cgi?id=445499 ), but once more
than three thumbnail previews are shown this could be much less of an
issue.
3. What information should be shown and what features should be
available in Control+Tab preview mode? There's general consensus that
showing a thumbnail preview and the title of a tab is useful, but what
about being able to close tabs? Showing favicons? Favorited or
tagged items?
4. Some found the cover flow animation distracting and time-consuming.
#1, I believe, is the main issue right now. The solutions to #2-#4
change based one #1 (eg. it's more important to be able to close tabs
if you're looking at more than three).
THE NEXT STEP
So what we need to do now is decide what our goal is and how exactly
Control+Tab should land in 3.1 as a result.
My own view is that we should display all tabs in the Control+Tab
preview. This is because I believe our goal should be for users to
have better overall navigation through and control of their browser
content. Right now, tabs and windows are created and thrown into a
pile in the corner of the room like your old socks (you slob).
They're all there, if you search long enough you can find the one you
want, but there's no way to quickly find the blue one (unless it's on
the top) or get a sense of what kind of socks are in the pile. I see
Control+Tab for Firefox as a first step for users to gain more control
over their online content, and I think that being able to view all
tabs is an important step towards this goal. Showing all tabs
addresses Atul's concerns, because users can employ multiple methods
to find a tab depending on how it is encoded to memory - visually,
textually, or in MRU order (see Jono's post:
http://jonoscript.wordpress.com/2008/08/21/more-questions-and-no-answers-about-tabs/
). It also allows for Dao's quick switching: if the tabs are in MRU
order, a quick Control+Tab and release still flips back to the last
used tab.
It's true that if the user has too many tabs, either shrinking down
tabs or giving a scrolling/panning mechanism will be needed. However,
I believe the gain of having all tabs viewable is well worth future
mechanisms to keep Control+Tab useful and its performance optimized.
Also, if we successfully design an intuitive way to view excess tabs,
its existence in Firefox wouldn't be a drawback.
More detailed reasons for showing all tabs are here (
http://jboriss.wordpress.com/2008/08/20/tabs-want-to-be-seen/ ) and
here ( http://jboriss.wordpress.com/2008/08/22/tab-view-vs-application-view/
). A screenshot of Control+Tab with all tabs is here (
http://people.mozilla.com/~jboriss/blog/with_quick_large.png ).
So, that's where the debate has gone, and I hope to continue it in
this thread. Please post your thoughts, and especially if you feel
the number of thumbnails should be capped. I think the issue's too
important to move forward without some form of consensus. Control+Tab
itself will likely go through many interesting iterations in the
future, possibly with various tab groupings, text search, gestures, or
ZUIs. However, let's keep the discussion here related to the goals
of Control+Tab and what can land in 3.1, as the clock does its ticking
thing and with some regularity.
- Boriss
Gordon Hemsley
> There's been a great deal of discussion in blogs, bugs, and threads
> about Control+Tab, a new feature for Firefox 3.1. I'd like to quickly
> summarize where we are and make this the main thread of discussion so
> we can move forward knowing what's been established and what's still
> on the table.
>
> WHAT LANDED IN THE FIRST VERSION OF CONTROL+TAB
>
> nightlies. It's described in my post here (http://jboriss.wordpress.com/2008/07/16/control-tab-a-new-feature-for...
> ). In this version, pressing Control+Tab would reveal a filmstrip
> view of the users' last three most recently used (MRU) tabs
> (screenshot:http://people.mozilla.com/~jboriss/wiki/tab_preview/controltab.png
> ). Continued presses of tab would scroll the thumbnails back through
> the users' tabs in MRU order with an animation similar to cover flow.
>
> This landed, and people tried it out. A lot of the feedback was
> positive - people generally liked the interface and the ability to
> flip back and forth between tabs. There was agreement that the best
> design would look native to the operating system. The keystroke
> control+tab seemed to be a fairly good quick-key for visual
> navigation, being similar to existing OS preview modes like alt+tab
> (Linux, Windows) and cmd+tab (OSX).
>
> ...BUT THERE WERE CONCERNS WITH CONTROL+TAB
>
> 1. General consensus is that three thumbnail previews isn't enough.
> This design is fine for flipping back and forth between two tabs, but
> it shows too few of a user's overall tabs for practical visual
> ), users will press Control+Tab until they get to what they want;
> their focus is on the item they seek, not its location in MRU order.
> So, without being able to see much of what's coming up, the process of
> tabbing to a particular item takes longer and it's easy to overshoot
> the goal.
>
> So, how many thumbnails should be shown? Our options are to put a cap
> at some number, or display all open tabs. The main benefit to
> limiting the tabs is the optimization of browser performance and
> maintaining a manageable display by not dealing with excess tabs.
> Showing all tabs turns Control+Tab into a bit of a different animal -
> a way to manage and navigate all tabs in a users' browser session. If
> you're searching for that one missing tab, Control+Tab would be a
> place you know you could find it. The main drawback of displaying all
> tabs is that if the user has a ton of tabs open, either they would be
> displayed too small to be useful or a scrolling/panning mechanism
> would have to be implemented.
>
> 2. Should tabs be most-recently-used order, tab-order, or allow the
> ). It also allows for Dao's quick switching: if the tabs are in MRU
> order, a quick Control+Tab and release still flips back to the last
> used tab.
>
> It's true that if the user has too many tabs, either shrinking down
> tabs or giving a scrolling/panning mechanism will be needed. However,
> I believe the gain of having all tabs viewable is well worth future
> mechanisms to keep Control+Tab useful and its performance optimized.
> Also, if we successfully design an intuitive way to view excess tabs,
> its existence in Firefox wouldn't be a drawback.
>
> More detailed reasons for showing all tabs are here (http://jboriss.wordpress.com/2008/08/20/tabs-want-to-be-seen/) and
> ). A screenshot of Control+Tab with all tabs is here (http://people.mozilla.com/~jboriss/blog/with_quick_large.png).
>
> So, that's where the debate has gone, and I hope to continue it in
> this thread. Please post your thoughts, and especially if you feel
> the number of thumbnails should be capped. I think the issue's too
> important to move forward without some form of consensus. Control+Tab
> itself will likely go through many interesting iterations in the
> future, possibly with various tab groupings, text search, gestures, or
> ZUIs. However, let's keep the discussion here related to the goals
> of Control+Tab and what can land in 3.1, as the clock does its ticking
> thing and with some regularity.
>
> - Boriss
I think maybe the amount of thumbnails shown should be capped at the
number of tabs that are able to be shown onscreen or in the window.
That is, have it be based off of the real estate available. The
thumbnails should also be resized based on the number of open tabs
(fewer tabs, larger thumbnails; more tabs, smaller thumbnails),
similar to how the tabs themselves resize as more are added. Since the
order will be based upon the order of last viewed (right?), then this
should be enough to satisfy the user (at least, when there's an
indicator that not all open tabs are shown). There is still always the
option to use the drop-down button to view all of the tabs in the
order they were opened.
anaesthetica
> about Control+Tab, a new feature for Firefox 3.1. I'd like to quickly
> summarize where we are and make this the main thread of discussion so
> we can move forward knowing what's been established and what's still
> on the table.
>
> WHAT LANDED IN THE FIRST VERSION OF CONTROL+TAB
>
> nightlies. It's described in my post here (http://jboriss.wordpress.com/2008/07/16/control-tab-a-new-feature-for...
> ). In this version, pressing Control+Tab would reveal a filmstrip
> view of the users' last three most recently used (MRU) tabs
> (screenshot:http://people.mozilla.com/~jboriss/wiki/tab_preview/controltab.png
> ). Continued presses of tab would scroll the thumbnails back through
> the users' tabs in MRU order with an animation similar to cover flow.
>
> This landed, and people tried it out. A lot of the feedback was
> positive - people generally liked the interface and the ability to
> flip back and forth between tabs. There was agreement that the best
> design would look native to the operating system. The keystroke
> control+tab seemed to be a fairly good quick-key for visual
> navigation, being similar to existing OS preview modes like alt+tab
> (Linux, Windows) and cmd+tab (OSX).
>
> ...BUT THERE WERE CONCERNS WITH CONTROL+TAB
>
> 1. General consensus is that three thumbnail previews isn't enough.
> This design is fine for flipping back and forth between two tabs, but
> it shows too few of a user's overall tabs for practical visual
> ), users will press Control+Tab until they get to what they want;
> their focus is on the item they seek, not its location in MRU order.
> So, without being able to see much of what's coming up, the process of
> tabbing to a particular item takes longer and it's easy to overshoot
> the goal.
>
> So, how many thumbnails should be shown? Our options are to put a cap
> at some number, or display all open tabs. The main benefit to
> limiting the tabs is the optimization of browser performance and
> maintaining a manageable display by not dealing with excess tabs.
> Showing all tabs turns Control+Tab into a bit of a different animal -
> a way to manage and navigate all tabs in a users' browser session. If
> you're searching for that one missing tab, Control+Tab would be a
> place you know you could find it. The main drawback of displaying all
> tabs is that if the user has a ton of tabs open, either they would be
> displayed too small to be useful or a scrolling/panning mechanism
> would have to be implemented.
>
> 2. Should tabs be most-recently-used order, tab-order, or allow the
> ). It also allows for Dao's quick switching: if the tabs are in MRU
> order, a quick Control+Tab and release still flips back to the last
> used tab.
>
> It's true that if the user has too many tabs, either shrinking down
> tabs or giving a scrolling/panning mechanism will be needed. However,
> I believe the gain of having all tabs viewable is well worth future
> mechanisms to keep Control+Tab useful and its performance optimized.
> Also, if we successfully design an intuitive way to view excess tabs,
> its existence in Firefox wouldn't be a drawback.
>
> ). A screenshot of Control+Tab with all tabs is here (http://people.mozilla.com/~jboriss/blog/with_quick_large.png).
>
> So, that's where the debate has gone, and I hope to continue it in
> this thread. Please post your thoughts, and especially if you feel
> the number of thumbnails should be capped. I think the issue's too
> important to move forward without some form of consensus. Control+Tab
> itself will likely go through many interesting iterations in the
> future, possibly with various tab groupings, text search, gestures, or
> ZUIs. However, let's keep the discussion here related to the goals
> of Control+Tab and what can land in 3.1, as the clock does its ticking
> thing and with some regularity.
>
> - Boriss
I'm very excited about the work that you've been doing in opening up
the possibilities for a new tab experience. My feeling, however, is
that the current approaches are mostly incremental, even though a
broader rethinking of tabs is probably in order.
First, tabs as currently implemented, are fundamentally tied to their
spatiality--that is, we continue to think of them in their physical
metaphor: they are accessed and ordered according to their little
piece of screen territory in the tab bar. The tab bar, the width of
the tabs, the tab overflow button--all of these take up screen
territory, and concomitantly run into problems rooted in their
spatiality. For instance, the more tabs you open, the smaller the
tabs get and the less information they display (favicons disappear,
titles disappear). As they get smaller, they're harder to access,
requiring greater precision from the user in clicking on them. As
they get more numerous, it takes more effort to control+tab through
them as well. After a certain point, due to lack of screen space,
they get further hidden in the tab overflow drop-down. All of these
problems are rooted in the need for tabs to maintain the physical
metaphor.
The new approaches you've mocked up are excellent, but remain a
superstructure constructed atop the physical base of the existing tab
metaphor. The superstructure is a gloss rather than a fundamental
change to the tab system. Having the thumbnail of the tab is a big
step forward for Firefox in terms of increasing the amount of
information given, but it's something that other browsers (e.g.
OmniWeb) have already implemented. Similarly, Camino is developing a
Tabsposé, which is basically the "Application View" that you proposed
recently.
OmniWeb: http://www.omnigroup.com/images/applications/omniweb/features/tabs.jpg
Tabsposé: http://www.flickr.com/photos/spaunsglo/987375693/
The commonality here is that these two browsers and the Firefox
mockups remain tied to the physical ordering of the tabs on the tab
bar. The way in which they are ordered is contingent on how the user
has been browsing--the accidents of reading this page or that page
somewhere in the long row of tabs, opening new links into new tabs at
the far right edge, opening a blank tab in order to go somewhere new,
and so on. Ordering them in this contingent manner along an arbitrary
tab bar is profoundly inefficient, and only grows exponentially more
so as the number of tabs increases.
Second, the contingent spatial ordering is less useful than a number
of other possible ordering principles (here I'm extending Jono's
thoughts):
- Temporally (in terms of when they were opened, or in terms of last
focus)
- "Frecency" of visits (either to the unique URL or to the domain)
- Content similarity (group tabs with embedded video, group tabs with
similar text)
- Group tabs by their domain name (all mozilla.org links together,
all cnn.com links together)
- Hierarchically (parent pages grouped with child pages opened from
each parent)
- By keyword (essentially, a "search tabs" feature that would filter
open tabs as the search string got more specific)
Each of these ordering principles has greater intuitive and
navigational value to the end user than the contingent spatial
ordering that currently predominates all browsers (except the most
recent IE8 beta, which colors tabs according to the parent-child
principle).
IE8 beta tabs: http://arstechnica.com/news.ars/post/20080828-ie8-beta-2-shows-microsoft-is-serious-about-playing-catch-up.html
The way that 'Spotlight,' 'Exposé,' 'Dashboard,' and 'Spaces'
dramatically changed the Mac OS X user experience with finding and
organizing their files and open windows should point us in a certain
direction: away from spatially fixed metaphors and toward more
flexible forms of organization. I think it would be a high bar, but a
worthy goal, to design a Control+tab interface as if the tab bar
itself were going to be completely removed from the Firefox UI.
Making switching tabs as quick and discoverable as possible in the
absence of a tab bar will open up new possibilities and new ways of
thinking about tabs once they're no longer tied to a physical
location.
Third, a few minor notes: the number of thumbnails to show in a tab
switcher like Atul's proposal can be increased indefinitely if a UI
similar to Apple's 'Cover Flow' is utilized.
Atul's tabs: http://www.toolness.com/wp/?p=127
Your Application view will run into the same problems as the physical
tab bar: the more tabs that are open, the more the thumbnails will
have to shrink or the more that will have to be hidden. Either way,
the contingent organization combined with static spatiality will
result in more information being hidden from the user arbitrarily.
The only difference between the proposed Control+tab Application View
and the existing tab bar is the popup thumbnails.
Rethinking the organizing principle behind tabs (and giving the user
some control over how they organize their tabs) will allow the user
faster access to the information they desire.
My apologies if this took your thread too far off topic, but I think
it's important to design for the future. Like Napoleon warned, 'there
is nothing more permanent than a temporary solution.' Whatever tab
improvement ends up in Firefox 3.1, let's make sure that it's future
compatible with a more fundamental rethink of tabs, and doesn't create
a path dependency in user behavior that would foreclose any of these
options.
Best regards,
Tom
Peter Lairo
perhaps comment on) the new tab switching. Unfortunately, I am only
seeing the old tab switching behavior (it just switches the tab).
Is there a setting in about:config that I need to make (or accidentally
made and forgot) to see the new tab switching?
Thanks!
(1) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3pre)
Gecko/2008082806 GranParadiso/3.0.3pre
PS. ...
Boriss said on 28.8.2008 9:26:
> On 7.17.08, part of...
Many of us are not in your locale and might misunderstand which date you
mean (yes, this example can be correctly interpreted). Request you use a
date format that is not ambiguous. I suggest using the ISO 8601 date format:
yyyy-mm-dd
Peter Lairo
The browser you can trust: www.GetFirefox.com
Reclaim Your Inbox: www.GetThunderbird.com
Dangers of Islam (NEW): http://www.jihadwatch.org/islam101/
Israel - Myths & Facts: http://www.JewishVirtualLibrary.org/
Church of the Flying Spaghetti Monster: http://www.venganza.org/
Jesper Kristensen
> I'm using the nightly builds of Firefox(1) and would like to test (and
> perhaps comment on) the new tab switching. Unfortunately, I am only
> seeing the old tab switching behavior (it just switches the tab).
>
> Is there a setting in about:config that I need to make (or accidentally
> made and forgot) to see the new tab switching?
>
> Thanks!
>
> (1) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3pre)
> Gecko/2008082806 GranParadiso/3.0.3pre
You need the Firefox 3.1 nightlies instead of the Firefox 3.0 nightlies:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Peter Lairo
That worked. Thanks!
I wonder how I managed to get on the 3.0 branch. I've been using trunk
builds since 1998. :-[
PS. I find the current trunk tab switching highly disorienting. I
suspect that's already the consensus, so I'll refrain from elaborating.
PPS. Now to get the add-on "Sage Too" feed reader working again...
(can't live without it!)
-=Ben=-
css to customize the color of your Ctrl+Tab background!
How cool!
Boriss wrote:
> There's been a great deal of discussion in blogs, bugs, and threads
> about Control+Tab, a new feature for Firefox 3.1. I'd like to quickly
> summarize where we are and make this the main thread of discussion so
> we can move forward knowing what's been established and what's still
> on the table.
>
>
>
> WHAT LANDED IN THE FIRST VERSION OF CONTROL+TAB
>
> On 7.17.08, part of D�o Gottwald's ctrl+tab add-on (
> http://en.design-noir.de/mozilla/ctrl-tab/ ) landed in the Firefox
> nightlies. It's described in my post here (
> http://jboriss.wordpress.com/2008/07/16/control-tab-a-new-feature-for-firefox/
> ). In this version, pressing Control+Tab would reveal a filmstrip
> view of the users' last three most recently used (MRU) tabs
> (screenshot: http://people.mozilla.com/~jboriss/wiki/tab_preview/controltab.png
> ). Continued presses of tab would scroll the thumbnails back through
> the users' tabs in MRU order with an animation similar to cover flow.
>
> This landed, and people tried it out. A lot of the feedback was
> positive - people generally liked the interface and the ability to
> flip back and forth between tabs. There was agreement that the best
> design would look native to the operating system. The keystroke
> control+tab seemed to be a fairly good quick-key for visual
> navigation, being similar to existing OS preview modes like altitab
> http://jonoscript.wordpress.com/2008/08/21/more-questions-and-no-answers-aboutitabs/
> ). It also allows for Dao's quick switching: if the tabs are in MRU
> order, a quick Control+Tab and release still flips back to the last
> used tab.
>
> It's true that if the user has too many tabs, either shrinking down
> tabs or giving a scrolling/panning mechanism will be needed. However,
> I believe the gain of having all tabs viewable is well worth future
> mechanisms to keep Control+Tab useful and its performance optimized.
> Also, if we successfully design an intuitive way to view excess tabs,
> its existence in Firefox wouldn't be a drawback.
>
> More detailed reasons for showing all tabs are here (
> http://jboriss.wordpress.com/2008/08/20/tabs-wantito-be-seen/ ) and
Clint Talbert
> ...BUT THERE WERE CONCERNS WITH CONTROL+TAB
>
> 1. General consensus is that three thumbnail previews isn't enough.
> This design is fine for flipping back and forth between two tabs, but
> it shows too few of a user's overall tabs for practical visual
> navigation. As Atul notes in this post ( http://www.toolness.com/wp/?p=127
> ), users will press Control+Tab until they get to what they want;
> their focus is on the item they seek, not its location in MRU order.
> So, without being able to see much of what's coming up, the process of
> tabbing to a particular item takes longer and it's easy to overshoot
> the goal.
>
> So, how many thumbnails should be shown? Our options are to put a cap
> at some number, or display all open tabs. The main benefit to
> limiting the tabs is the optimization of browser performance and
> maintaining a manageable display by not dealing with excess tabs.
> Showing all tabs turns Control+Tab into a bit of a different animal -
> a way to manage and navigate all tabs in a users' browser session. If
> you're searching for that one missing tab, Control+Tab would be a
> place you know you could find it. The main drawback of displaying all
> tabs is that if the user has a ton of tabs open, either they would be
> displayed too small to be useful or a scrolling/panning mechanism
> would have to be implemented.
>
I think that a method to display all tabs is a worthy goal, however
there should still be a way to switch between several "recent" tabs very
quickly. I think that having CTRL+Tab be the one mechanism to do both
these things might be a bit much. Make some method the "quick switch"
method, and some other method be the "show me all of them so I can find
that *&^%$ document I opened the other day". Those are my two primary
use cases for the tab bar :-)
> 2. Should tabs be most-recently-used order, tab-order, or allow the
> user to choose? This has been discussed in this bug (
> https://bugzilla.mozilla.org/show_bug.cgi?id=445499 ), but once more
> than three thumbnail previews are shown this could be much less of an
> issue.
I still think this is a huge critical issue, at least for my work. When
I am working doing anything on the web these days my work flow is always
like this:
1. Open 1 tab to do either read or edit a document (perhaps an email, a
wiki page, a bug etc)
2. Open new tabs to either browse to links embedded in that original
document, or to look up information to be included in that original
document.
3. Switch back to the original document to either continue editing or
reading.
For that, I depend on fast tab switching and have been wanting a small
list of tabs available in MRU order since Firefox 1.0.
However, I agree with the criticisms that MRU order is only effective as
long as you can remember what that MRU order actually is. My current
upper bound is around 5. After that, it makes sense to switch to a "tab
order" or an "all tabs" type of search.
>
> 3. What information should be shown and what features should be
> available in Control+Tab preview mode? There's general consensus that
> showing a thumbnail preview and the title of a tab is useful, but what
> about being able to close tabs? Showing favicons? Favorited or
> tagged items?
>
I don't think that tagged items are that important, because if I put
them in bookmarks and/or tagged them, then I'd just open another tab and
look them up in the awesome bar. But, that's just me.
I like the thumbnail previews. How are we going to measure the
performance impact of drawing those? I'm not saying we should measure
before we implement it, I just want us to have an idea of *how* we'll
measure that, because I think it will be an important factor.
I think the favicon might even be a quicker method for people to quickly
find the tab they are looking for. But I imagine that will only be
useful to the degree that people visit the same sites and are familiar
with those favicons. (For instance, I could quickly determine which of
my tabs are not bugzilla bugs by a quick glance over the favicons).
As far as close goes, that would be really cool too, I think, in an
"all-tabs" preview mode. Because as some guest we had here once
famously said, "There's no negative impact for opening another tab", I
tend to open new tabs for things even when I perhaps already have it
open. At some point when going through the open tabs, I will find
duplicates and close them. For that process, an all-tabs view with
close buttons would be killer. But the "finding duplicates" is a pretty
specific use case to me, I imagine, unless other people often find
themselves creating to-do lists out of their open tabs in the browser
like I do. :-)
Thanks for the work you're doing on this. I look forward to the next
design.
Loving the MRU switch right now,
Clint
Gordon Hemsley
> Boriss wrote:
> > ...BUT THERE WERE CONCERNS WITH CONTROL+TAB
>
> > 1. General consensus is that three thumbnail previews isn't enough.
> > This design is fine for flipping back and forth between two tabs, but
> > it shows too few of a user's overall tabs for practical visual
> > ), users will press Control+Tab until they get to what they want;
> > their focus is on the item they seek, not its location in MRU order.
> > So, without being able to see much of what's coming up, the process of
> > tabbing to a particular item takes longer and it's easy to overshoot
> > the goal.
>
> > So, how many thumbnails should be shown? Our options are to put a cap
> > at some number, or display all open tabs. The main benefit to
> > limiting the tabs is the optimization of browser performance and
> > maintaining a manageable display by not dealing with excess tabs.
> > Showing all tabs turns Control+Tab into a bit of a different animal -
> > a way to manage and navigate all tabs in a users' browser session. If
> > you're searching for that one missing tab, Control+Tab would be a
> > place you know you could find it. The main drawback of displaying all
> > tabs is that if the user has a ton of tabs open, either they would be
> > displayed too small to be useful or a scrolling/panning mechanism
> > would have to be implemented.
>
> I think that a method to display all tabs is a worthy goal, however
> there should still be a way to switch between several "recent" tabs very
> quickly. I think that having CTRL+Tab be the one mechanism to do both
> these things might be a bit much. Make some method the "quick switch"
> method, and some other method be the "show me all of them so I can find
> that *&^%$ document I opened the other day". Those are my two primary
> use cases for the tab bar :-)
I think many of us (myself included) have forgotten the comment that
seemed merely a footnote in the post introducing Control-Tab (http://
jboriss.wordpress.com/2008/07/16/control-tab-a-new-feature-for-
firefox/):
> What’s going to change?
>
> Pressing Control-Tab will no longer open the next tab (Control-PageDown still will).
In Firefox 3.0, the keyboard shortcuts Ctrl+Tab and Ctrl+PageDown (and
Ctrl+Shift+Tab and Ctrl+PageUp) do the same thing: go to the next (or
previous) tab on the tab bar. In Firefox 3.1, only the Ctrl+(Shift
+)Tab functionality has changed. Ctrl+PageDown/Up still navigate the
tabs in a linear fashion.
At least, that is my understanding—I haven't actually tried Firefox
3.1 yet.
Boriss
Gordon - An interesting idea and one we've talked about - I suppose to
cap we'd chose what the minimum size a thumbnail is useful at and fill
a grid with these. The thumbnails will be resized in any
implementation that showed enough tabs for it to be useful. And yes,
I think at this point we're leaning towards having the tabs in most-
recently-used order.
Anesthetic - You're right that these are all incremental steps and not
complete tab rethinks in the right direction. And yes, the linear
position of tabs is at the moment still an arbitrary arrangement in
many ways. And, in the future, grouping by subject or search or task
is probably in the cards. I'm sure you saw in the latest version of
Interet Explorer, borders of tabs are colored according to the tab
they were linked from. However, let's hold this discussion off for
awhile in favor of discussing Control+Tab.
Your mention of ways to move tabs within a window is interesting.
Obviously there is a fourth option I did not mention in my post. The
first is that we can cap the number of tabs, the second is that we can
show them all, the third is that we can show some but allow scrolling/
panning, and the fourth includes other ways that the user might
navigate a partial selection of tabs to see other tabs. Coverflow is
one possibility, but I would argue that it does not show enough of
your tabs to be really useful in navigation. AT&T's Polo tried this,
and I'd argue with mixed success. What if instead the frame of Control
+Tab could be grabbed and moved around the surface of tabs, much like
a Google maps window?
Peter - Please feel free to elaborate once you've played with Control
+Tab and have a feel for it. :)
Ben - I would argue that it's fairly important to keep the background
consistent with the operating system it runs on. So the screenshots
I've posted would be how it looks in OSX, and in Vista it would have
that silly faded glass, etc. Perhaps in the future customization will
exist, but looking native I think it an important first step.
Clint - Can you elaborate on why having one mechanism for both would
be too much? If the mechanism meets both needs well, then I'd say
it's a good design solution if it can do both. Is it your opinion
that seeing the extra tabs when you want a MRU tab would be
distracting?
I agree with your point of MRU only being useful for a small number of
items. In fact, Microsoft found this out and documented it. That's
why the first seven items in Vista fast-switching are in MRU order and
the rest are not. Past seven items, the benefit of MRU is fairly
negligible. However, you could argue that even tabs you looked at 20
minutes ago are more relevant than tabs you looked at 40 minutes ago
and may justify a place nearer to the front. This would be another
good one to eventually submit to user testing.
We'll definitely judge the performance issue before implementing a lot
of thumbnails. I think this is why Dao's original extension only had
three thumbnails - optimized performance.
I agree that favicons are useful - especially when thumbnails are
shrunken down or not visually distinctive. Of course this is still a
problem if many are small and not distinctive from the same site, but
favicons are a quick visual cue. They're also useful for training the
mind to look for a certain icon, even when the content we go to every
day changes. For example, I don't need to rely on my short-term
memory to tell me what the BBC article looks like. I can draw on my
long-term memory and think of the BBC's logo, which is in their
favicon.
The find duplicates idea, while maybe not implemented in the first
version, is a good one and one we've thought about. Madhava's idea
was to show an indication in the awesomebar if you have something
already opened in a tab. If we went ahead with this, I'd push to
integrate it into Control+Tab and possibly other places in Firefox
also.
Thomas Stache
> We'll definitely judge the performance issue before implementing a lot
> of thumbnails. I think this is why Dao's original extension only had
> three thumbnails - optimized performance.
One thing that irks me about the Ctrl-Tab/All-Tabs performance is that the
previews for the panel are not readily available, but must be drawn either in
the background (degrades overall browser performance, as it needs to update
during navigation and scrolling), or on-demand (as now).
I think there is a reason why live previews on Vista and Linux were only
introduced when compositors like DWM and Compiz became available. Maybe
Ctrl-Tab with previews is better delayed until Gecko's compositor becomes
available.
That being said the discussion about the interaction design should of course
continue now ;-)
Thomas
Clint Talbert
> On Aug 29, 11:48 pm, Gordon Hemsley <gphems...@gmail.com> wrote:
>> On Aug 29, 1:03 pm, Clint Talbert <ctalb...@mozilla.com> wrote:
> Clint - Can you elaborate on why having one mechanism for both would
> be too much? If the mechanism meets both needs well, then I'd say
> it's a good design solution if it can do both. Is it your opinion
> that seeing the extra tabs when you want a MRU tab would be
> distracting?
>
actually be looking at the previews, since you already know what the
"next" tab is going to be. So I don't anticipate that anything you show
is going to be distracting because I don't think it will be seen.
If you can come up with a good solution that can do both, then I'd be
all for it. When I wrote my post, I couldn't (and still can't) think of
any way to do that without being confusing to the end user. Users
typically think that one keystroke == one function (because that's what
they've known if they grew up in old windows land).
For example, when I first got a mac, it took me a long time to discover
that in Finder click + hold (rename) was different than click (select)
because those seemed like the same action to me.
But like I said, if you folks can come up with a single solution that
does it all well, I'll be very happy.
Clint
Boriss
Clint -
I'm not sure we're talking about the same thing, since you mentioned
"tabs from the other day" in your first post. What I'm describing is
a way to see all open tabs, and at least the first few would be in MRU
order. So if you want to flip back to the tab you were just on, it's
still a quick Control+Tab to jump there. If you want the one you were
looking at two tabs ago, then it's third in the MRU list. So the idea
is that if you want a recent tab, you focus on the first few tabs in
the grid. If you want one further back, you scan the window of
thumbnails to find it. It seems like a way to solve both to me, but
if you disagree I'd love to hear your reason.
- Boriss
Clint Talbert
> Clint -
>
> I'm not sure we're talking about the same thing, since you mentioned
> "tabs from the other day" in your first post. What I'm describing is
> a way to see all open tabs, and at least the first few would be in MRU
> order. So if you want to flip back to the tab you were just on, it's
> still a quick Control+Tab to jump there. If you want the one you were
> looking at two tabs ago, then it's third in the MRU list. So the idea
> is that if you want a recent tab, you focus on the first few tabs in
> the grid. If you want one further back, you scan the window of
> thumbnails to find it. It seems like a way to solve both to me, but
> if you disagree I'd love to hear your reason.
good way to solve both usecases. I'd have to play with it to be sure,
but this sounds pretty promising.
Clint