TabConsistency

Revision 26 as of 2006-11-07 00:53:49

Clear message

Summary

This spec documents the plan to create consistency of the user interface and keystrokes associated with multi-document tabbed interfaces, starting in the Edgy release cycle.

Rationale

Multi-document tabbed interfaces are becoming extremely popular in desktop applications, driven by killer apps like Firefox which have gained rapid traction in both free software and proprietary environments. However, there is a great variety in the interfaces offered by the different applications. This makes it difficult for users to develop consistent patterns of usage and muscle memory.

Scope

This specification covers:

  1. Multi-document interfaces. Specifically, apps where each tab represents a separate document or conversation. This does not apply to apps like spreadsheets where tabs are like an extra dimension on the current "workbook".
  2. The presentation of the user interface and keystrokes for creating a new tab, closing a tab, switching between tabs, and shifting tabs to change their order.

User Interface and Keystrokes

  • Tab positioning. tabs should appear at the top of the application window, below the toolbars and menus but above the documents themselves. In the case of "internal document tabs" such as spreadsheets which have multiple tabs in a single document, those tabs should appear at the bottom of the content page, as they currently do in OpenOffice and Excel. Tabs shall display the content title and direct access hotkey ([Alt-3]) as a tooltip on mouseover.

  • Opening a new tab. Opening a new tab results in a "new document" or "blank page", in a new tab. It should be possible to open a new tab either through the user interface (clicking on a "new tab" icon) or through the menu (File->New) or using a keystroke. The "new tab" icon should itself be on a tab (which can be tiny - just containing the "new tab" icon) which is on the left of all the tabs. The "new tab" icon should use the same symbology between desktop platforms. Clicking several times in succession on this "new tab" tab would create the corresponding number of new, empty tabs. The rationale for having the "new tab" tab on the LEFT is that it keeps it far away from the "close tab" icon (which will be on the RIGHT of all the tabs), and keeps it in a consistent place. The other option was to have the "new tab" tab on the RIGHT of the current set of tabs, but this means it will constantly move around, meaning there is no opportunity to build up muscle memory for the "new tab" click. The suggested keystroke to open a tab is always Ctrl-T, or Ctrl-Shift-T if the application currently uses Ctrl-T. In some cases, such as instant messengers, it does not make sense to open a "blank" tab because every tab should be a real conversation. In these cases the "new tab" tab can of course be omitted.

  • Closing a tab. There should be a "close tab" icon on the far RIGHT side of the tab bar (the bar on which the tabs appear). This should be similar to but not exactly the same as the close-window button on the window manager. The "close tab" icon should be a distinct general theme element and changing it in the theme should change it in all tabbed applications. The "close tab" icon should also use the same symbology between desktop platforms. We decided to reject the idea of putting a close button on every single tab, because there are too many reports of accidental closures with that model, and because there is no opportunity to build up muscle memory. The keystroke to close a tab should always be Ctrl-W, or Ctrl-Shift-W if the app already uses Ctrl-W.

  • Switching between tabs. Clicking on a tab should switch to that tab. We propose to standardise on Ctrl-TAB and Ctrl-Shift-TAB for switching between tabs. This is a keystroke combination that is not commonly used already, and resonates with the use of Alt-TAB and Alt-Shift-TAB to switch between applications in the current workspace. Tab switching should wrap. So, for example, if you are on the RIGHT-most tab and press Ctrl-TAB you should jump to the LEFT-most tab. And If you are on the LEFT-most tab and press Ctrl-Shift-TAB you should jump to the RIGHT-most tab. Using the menu, it should be possible to see a list of open documents in tabs, and switch directly to one by choosing its menu item. Switching between tabs using Alt-Num keys (ie: Alt-1, Alt-2, etc...) will switch between tabs in visual order. Alt-1 shall always display the leftmost tab currently visible and Alt-0 shall always display the rightmost tab currently visibile.

  • Changing the order of tabs. It should be possible to move a tab around in the sequence of tabs, by dragging it with the mouse. A small arrow should show the space between two tabs into which the current dragged tab would be placed. The arrow should be themable and consistent across all tabbed applications. The keystrokes Ctrl-Shift-PgUp and Ctrl-Shift-PgDn should move the current tab to the left or to the right, respectively. Tab movement should NOT wrap, so once a tab has been moved to the far left pressing Ctrl-Shift-PgUp would not move the tab.

  • Closing a window with tabs open. When you want to close a window with tabs open, the application may take one of three approaches. If there is no unique data in the tabs (for example, you are closing a text editor with 4 documents in tabs, but all the documents have been saved recently) then the app should simply close the tabs. If there is some unique state but not unique data (for example, you have a browser with 10 pages open, where all the pages can be reached again but the *state* of the "set of open pages and how you got there" is not saved anywhere) then the application can either warn the user ("you have n tabs open, would you like to save the state?") offering the ability to save the state and reuse it when the app is launched again, which the user might decline, or the app could simply save the state and restore it on launch again (along with any new state, such as a new page that the app was started to view).

Other considerations

  • We did consider the idea of switching the "new tab" (far LEFT) and "close tab" (far RIGHT) positions for RTL (Right-To-Left languages like Arabic, but decided that these were better kept in a single position so that documentation etc would not be inaccurate simply because of a change in locale.
  • It is proposed that all directions under "Opening a new tab" should be reversed, to cater for RTL language usability. Good example to derive upon are Gedit and Nautilus properties window.

Applications on the Ubuntu Desktop using tabs and their default tab behaviour

GNOME terminal

Tabs not shown per default. Tabs at top, close button on each tab. Tabs extend to fill whole bar. Tabs do not have icons. No display arrows when you drag the tabs around.

Text editor

Tabs shown per default. Tabs at top, close button on each tab. Tabs have fixed size. Tabs have icons. No display arrows when you drag the tabs around.

Firefox 2

Tabs at top, close button on each tab. Tabs have fixed size. Tabs have icons. Tabs are highlighted on Mouseover. It does display arrows on tab drag. Has a dropdown tab selector on the right.

GAIM

Tabs not shown per default. Tabs at top, close button on each tab. Tabs extend to fill whole bar. Tabs have icons. It does display arrows on tab drag. You can drag tabs outside of the window to create a new window.

Gobby

Tabs shown per default. Tabs at top, close button on each tab. Tabs are all the width of the widest tab.

Epiphany (new GNOME standard)

Tabs not shown per default. Tabs at top, close button on each tab. Tabs have fixed size. Tabs have icons. Tabs move out of the way when dragged.

Gossip

Tabs not shown per default. Tabs at top, close button on each tab. Tabs extend to fill whole bar. Tabs do not have icons.

Comments

  • We need some commentary on this spec from the accessibility community.
  • The problem with having only one close button for all tabs is that when the user wants to close a tab that's not focused he has to make 2 (one to focus the to close tab + one for pressing the close button) clicks and has to move the mouse nearly across the whole screen. The middle click should be the common shortcut for closing tabs, since several applications are already using it and the user only has to focus the tab he currently wants to close. --AndreRuediger

  • The tabbed interface behaviour is going to change for Firefox 2.0. Firefox 2.0 will have close-buttons on each tab, sililar to the way gnome-console, Epiphany and gEdit implement them.

wolki: Some quick comments:

  • Ctrl-Tab is already used in GNOME as an universal get-the-focus-out-of-here button. Usually, to switch focus between elements of a window, Tab is used directly; some widgets need to accept tabs however (like multiline text entries). Being able to do this quite important for keynav; Ctrl-Tab is what the HIG specifies for this. (see HIG 10.2.4.2, see also http://mail.gnome.org/archives/usability/2006-February/msg00189.html ) If crtl-Tab is to be used for switching tabs, a reasonably discoverable alternate shortcut should be used.

  • According to Calum Benson, tab wrap-around could be problematic for blind users. (same link: http://mail.gnome.org/archives/usability/2006-February/msg00190.html ). It also makes it hard to reach the first/last tab by just holding the shortcut key or scrolling with the mouse wheel (both of which may well be idiosyncratic behaviors of mine Smile :) ).

  • There are apparently considerations to make ctrl-pageup/down the more universal tab change shortcut in GNOME: http://mail.gnome.org/archives/usability/2006-June/000000.html

  • Tabs in gEdit/Ephy and other GNOME applications will only shrink to a certain degree, then add switching buttons. It is very debatable whether this is good behavior; while it moves tabs out of the one-click access area and makes it impossible to see whether a new tab has been opened, it will give you longer tab titles in the tab bar, thus making them easier to handle. If this is not changed, how would these tab switch buttons interact with the new/close buttons?

JonathonConte:

  • Altering tab behavior of all applications to look like Firefox will put GNOME and Ubuntu developers at odds with each other. Is Ubuntu going to attempt to convince GNOME to change its HIG? If not, is keeping Firefox's interface the same as it is on Windows really worth the extra effort that it will take to undo the work of upstream developers of all of the applications that adhere to the HIG? If consistency is really the goal, perhaps we should re-consider the replacement of Firefox with Epiphany rather than continue to struggle to make Firefox seem less out-of-place in GNOME.

JamesLivingston:

  • Firefox 2 is changing to "close-tab button per tab" too, so having a single close-tab button will be inconsistant with that too.
  • The tab shrink versus scroll issue is fairly user-visible, and has a fair number of proponents on both sides. Having it be different in different applications isn't good, but changing either way will probably annoy a lot of people. On one hand shrinking tabs stops them going "missing" (until you get a really large number of tabs anyway), but after you have a certain number of tabs there isn't enough of the label left to be useful (which is very annoying).

Chris34:

  • I've read that the plan for Firefox 2.0 to deal with the shrinking tabs not having a title is to expand the tab temporarily on mouseover.

AnarchoAl:

  • I find the GEdit behaviour when moving tabs far easier than Firefox's. The whole tab just moves, like an icon or window does. This is good because it maintains the metaphor that you're "picking up" a real object and moving it. Firefox's little arrow is also difficult to see due to its size.

AaronMitti:

  • Another thing that should be examined is the maximum width of tabs. In the message window of Gaim 2.0 a single conversation (one tab) has a width that extends the full size of the window. This is inconsistent with other tabbed applications which typically have a maximum width of about 150 - 200 pixels. I also think it would make it hard for new users to recognize that it is a tabbed application.

Petr Tomeš

  • Put close buttons on the tabs
    • "Here at Google, we did some usability studies on the tabbed browsing feature. Our usability analyst designed a study to see how well people responded to tabs and how easily they were able to switch between them and close them. ... What we also found is that the users we sampled were by and large using the context menu to close tabs. Some tried to close the entire browser window first, and most paused before trying the context menu. ... So here are a couple of things we have been experimenting with. 1. Put close buttons on the tabs. This makes it a lot easier to close tabs with the mouse. People weren't seeing the close box in the usability test. It's also out of the way and not connected with what's actually being closed. Mindful of stealing space from the tab strip when there are many tabs, the close boxes on inactive tabs are hidden when the tab width falls below a certain minimum value." (http://weblogs.mozillazine.org/ben/archives/009210.html)

    • Internet Explorer 7, Opera, Safari, GNOME applications and other relevant/important applications uses close buttons on the tabs. Why should Ubuntu bring that consistency of the standard, expectable behaviour???
    • "We decided to reject the idea of putting a close button on every single tab, because there are too many reports of accidental closures with that model..." Firefox solves this issue by sufficient width of a few tabs and putting close button only on a active tab of more than 7 tabs respectively.