1. Tabbed Interface Design Specification
This document is still in draft form. Suggestions and comments are welcome.
1.1. Background
GNOME has a single desktop-wide tab interface widget, called GtkNoteBook. In addition, each GNOME application is responsible for integrating tabs (including things such as defining keyboard shortcuts, menu items, and context menus which relate to tabs). A number of GNOME applications utilise tabs in their interfaces: Epiphany, Gedit, Nautilus, Empathy, and GNOME Terminal. Tabs are also used in many preferences dialogues.
Unfortunately, there are a number of significant problems with GtkNoteBook, which are detailed below. There are also inconsistencies in the way that different GNOME applications integrate tabs. Currently, there are no guidelines on the usage of tabs in the GNOME's Human Interface Guidelines (known as the HIG; see GNOME bug 72101). This design specification is part of an attempt to overcome these problems by producing a new design for GtkNoteBook and a set of guidelines detailing how GNOME applications should integrate tabbed interfaces.
More information about existing discussions on this issue can be found here.
1.2. Basic design requirements
Designs for tabs in GNOME should:
- Provide consistency (or have intelligable consistencies) in tab implementations across the range of different applications found on the GNOME desktop.
- Accomodate a range of use cases. The design must work effectively with a range of numbers of open tabs - it must scale.
- Be accompanied by a set of guidelines for application developers as to when and how to integrate tabs into their applications.
- Fit with existing GNOME interface patterns, as set out in the HIG and as witnessed in current and future versions of GNOME.
1.3. Detailed design requirements
Designs should fulfil the following detailed design requirements.
1.3.1. Handling of high numbers of open tabs
Current tab implementations in GNOME perform badly when a high number of tabs are open. Any redesign of tabs should address this issue. In particular:
- Information about the number of open tabs should be available to the user at all times.
- Visual feedback should be provided when new tabs are opened (see GNOME bugs 300537, 330676, and 167693; also see section on tab states below).
- It should be easy and obvious to navigate, apprehend, and organise/reorder tabs, even when a high number are open.
- If utilising scroll buttons (as is the case in current tab implementations), those scroll buttons should be large and should highlight on mouseover (GNOME bug 326953).
1.3.2. Tab states
- Tabs should provide visual feedback of changes in their state (they should indicate ongoing processes, if they contain unsaved documents, if they require the attention of the user, etc).
- This feedback should be consistent with other similar parts of the desktop, particularly the task bar (or equivalent).
1.4. Notes on current GNOME tab implementations
Discussions of current tab implementations in GNOME have produced a number of conclusions that designers should be aware of. Highlights are provided below. Greater detail of these discussions can be found here.
1.4.1. Intrusiveness
- Currently, the trend in GNOME applications is to hide the tab bar from users until more than one tab is open.
1.4.2. Tab appearance
- Tabs should be easy targets to hit with a pointing device. ie. The shouldn't be too small. Dynamic widths are to be avoided.
- Previous research has suggested that the appearance of a close button on each tab is a desirable feature. This is currently standard practice in GNOME tab implementation.
1.4.3. Interacting with tabs
- Drag and drop reordering is currently standard practice in GNOME.
- Docking and detaching is one area where there are inconsistencies in current GNOME tab implementations. Is it advantageous to include this functionality? How should it work?
1.4.4. Integration with menu systems
- Should there be a tab menu? Which entries should it have?
- 'File' menu entries should conform to tab mechanics (Open, Close, Quit, etc).