TabConsistency

Revision 18 as of 2006-06-24 19:41:52

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.

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-evaluate 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).