TabConsistency

Revision 39 as of 2007-08-29 19:48:48

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.

Current Behaviours

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.

Pidgin

Tabs are enabled by default. When enabled, windows with a single tab render the tab. By 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 are enabled by default, but do not show for single document windows. 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.

GnuCash

Tabs shown per default. Tabs att top, close button on toolbar next to save button. Tabs sized to fit its label, and icon if it has one. Some tabs have icons. Tabs not draggable.

Desired Behaviour

The desired behaviour is that of Firefox 1.5:

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

Implementation

Firefox 2.0 can be configured to behave as Firefox 1.5 through the use of configuration keys, the defaults will be changed in the package so that new installations behave correctly.

The other applications listed above are all GTK+ applications which use the GtkNotebook API to draw and manage the individual MDI pages. However this API is also shared with those applications that use tabs for worksheets or pages of property dialogs, so it's important that only MDI applications are changed.

Previously this API did not support re-arranging of pages, GTK+ 2.10 added the following new functions to permit detaching and reordering of tabs:

  • gtk_notebook_set_tab_detachable
    gtk_notebook_set_tab_reorderable

The latter can be used to support reorderable tabs. Each application would be altered to call the same sequence of gtk_notebook_* functions so that they behaved the same:

  • gtk_notebook_set_scrollable (GTK_NOTEBOOK (notebook), TRUE);
    gtk_notebook_set_tab_reorderable (GTK_NOTEBOOK (notebook), child, TRUE);

Calls to other behaviour changing functions (e.g. gtk_notebook_set_homogeneous_tabs would be removed).

This would be a divergence on each of these packages, the patches may or may not be accepted upstream; if it would, it's recommended to make it a GNOME Goal project so that the same happens to other packages as and when other people use them.

After this work, GTK+ applications would behave in somewhat the same way (see Problems below); however this behaviour would still not be the same as that desired by this specification.

In order to change the keybindings and mouse actions for the tabs, as well as the fashion in which windows are re-ordered, GtkNotebook itself (in the GTK+ library) would need to be modified. This would be a large divergence from upstream that would never be resolved.

In particular this work would require to modify the new reordering code to draw arrows instead of performing "live rearranging". It would also need to modify the code that focuses tabs when others are removed, in order that the new tab was consistent with this specification.

Problems

Unfortunately this is not sufficient to implement the required consistency. Each GTK+ application implements its own close button behaviour; most pack a button with a stock icon into the tab container (thus appearing inside the tab) and then handle this in their own way.

Unfortunately this close handling is also different, while some simply call gtk_notebook_remove_page and handle the necessary clean-up as a result of the GtkNotebook::page-removed signal; most do not and instead implement custom close behaviour that cleans up and removes the page as a side-effect of the clean-up.

This would need to be made consistent with each application, often performing major rework to clean up a document on a page being removed instead of in their custom close handler.

That's still not enough, we would need to add a "close button" API to GtkNotebook. This is a dangerous step, and should be discussed and designed with upstream to avoid Ubuntu implementing an API that conflicts with a later upstream API (which would cause major problems for vendors such as VMware who use GTK+).

This API would need to have the possibility of adding close buttons to tabs, functions may look like:

  • gtk_notebook_set_show_close_button (GTK_NOTEBOOK (notebook), TRUE);
    gtk_notebook_set_tab_closeable (GTK_NOTEBOOK (notebook), child, TRUE);

When the close button is clicked, a signal would need to be emitted to decide whether or not the current page CAN be closed (e.g. to prompt for saving). And then the application could handle this signal, and remove the page.

The implementation of this behaviour in GtkNotebook could then be arranged so that for upstream, the close button is drawn into each tab, and for Ubuntu a single button is drawn to the right of all tabs (in the GtkNotebook area).

Other considerations

  • Commentary is needed from the accessibility community.
  • Google and Nasa performed [http://people.mozilla.com/~faaborg/files/20070509-CHI2007/p1783.pdf both user testing and cognitive modelling] (PDF) in deciding to switch to the "close button on each tab" design. We should probably examine that and perform our own study before changing it.

  • This absolutely must be configured via gconf, at least for the GNOME apps. We are going to *seriously* piss of upstream with this. Also dragging to produce an arrow versus the tab just moving violates the principle of directly interacting with the object. A single close button also violates several usability guidelines, as you expect to be able directly interact with the object, no have to go somewhere else. CoreyBurger

  • First of all I agree: Tab handling must be unified. But I definitly would be pissed by "single close button", as I've accidently closed far too much tabs in apps using the "single close" approach (namely Firefox 1.5 and Visual Studio 2003). As already mentioned a single close button detaches the action from it object: Why should I click an object in sitting outside of the tabs, if I want to interact with some specific tab. You also should consider, that /at least for me/, the single tab approach leads to (the impression?) to move the mouse much more than neccessary. On the other hand, I agree, that the "close button on each tab" has the problem of wandering close buttons, when closing zillions of tabs, alltough I have to admit, that I know just a single person having problems with that issue - and this person is not me. It should be considered, that the optimal position of the close button could depend on the user's capabilities to organize/abstract/whatever-dunno. So I strongly suggest, if you definitly want/need single-close-button everywhere, than make it configurable. Well, and before making a decision about the default setting, consult exisiting usability studies, or start a new one, if none of the exisiting studies is adiquate. Usability is far to sensitive to base decisions made here on oppinions instead on facts. Greetings, MathiasHasselmann

  • Using a common keyboard combination is a good idea, but the suggestion to go with pgup/pgdown feels wrong to me. First of all, KDE has already used the less than (<), greather than (>) keys as default for several releases, which is to be taken into account. Next is that the ctrl-pgup can not be used in xterm-like applications as this key is commonly used to scroll in the buffer. Irssi is one app that catches that key. (Thomas Zander)

  • Tab position is not as simple as 'always on top'/'always below'. The type of application makes a difference here. Almost all GUI applications have a workflow that is top-to-bottom. With blank space at the bottom when there are no more widgets. For all these apps having the tabs at the top is a good idea as your focus will be at the top anyway. There is a small set of applications where this is not the case. Where your focus is mostly at the bottom of your window. For such applications its usefull to have the tabs at the bottom of the window as thats where your focus is. Makes it consistent. Examples of apps that have focus at bottom of the window are xterm like apps, as well as IRC and maybe even instant-messaging applications. (Thomas Zander)
  • Keyboard behavior should also be consistent. Control + Page Up/Down to select tabs in most applications. Some applications support keyboard dragging - Control + Page Up/Down + Shift to drag / move tabs (Gnome Terminal), some do not support this (Pidgin, Firefox). Inconsistent behavior when selecting tabs past end, some applications loop back around (Firefox, Pidgin), others don't (Gnome Terminal). (Aaron Mitti)
  • I'm not sure why the arrow-dragging was chosen instead of the live-tab-moving that's the new standard in GNOME. If GNOME is wrong, shouldn't this be argued upstream? --RichardLaager

  • Should a tab bar be shown in single-tab windows? In Pidgin, they do, as you can drag tabs from window to window. Should that behavior be implemented for other applications? --RichardLaager

  • Pidgin allows tabs to be disabled and shown in places other than at the top. Should that customizability be retained, simplified, or removed entirely? What about other applications? --RichardLaager

  • There should be a central way to configure "Tabs at bottom" or "Tabs on top" and "close button on tab"(or not) --Allo
  • There needs to be a way to config keyboard shortcuts for tab switching. Personally, I find ctrl+tab to be the most logical switcher but I know many people would be miffed if terminal didn't recognize ctrl+pgup. Pidgin supports switching with ctrl+pgup, ctrl+square bracket (]) and ctrl+tab. --IanMiller

  • I don't think the "switching between tabs" desired behavior description is very clear. I can't tell if it is for or against the ctrl+tab history switching (like alt+tab). Rather than simply cycling through tabs, it has a notion of recentness. There's a plugin for Firefox called LastTab which emulates this behavior (and even includes a tab preview much like alt+tab does).

-- CategorySpec