TabConsistency

Revision 32 as of 2006-11-12 19:16:17

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.

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.

GnuCash

Tabs shown per default. Tabas 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 performed a large usability study to produce 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

-- CategorySpec