TabConsistency

Revision 8 as of 2006-06-21 10:55:46

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 mucle 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. 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. 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