Projects/Usability/HIG/TabControl: Difference between revisions

From KDE TechBase
< Projects‎ | Usability‎ | HIG
m (Linked list view to corresponding HIG)
Line 10: Line 10:
== Guidelines ==
== Guidelines ==
=== Is this the right control ===
=== Is this the right control ===
<div id="Tabs1"></div>
* Use tabs
* Use tabs
** for many controls that can be organized within a few categories, like extended configuration settings
** {{HIG|TABS-1}} for many controls that can be organized within a few categories, like extended configuration settings
** for a variable number of sections, like browser pages
** {{HIG|TABS-2}} for a variable number of sections, like browser pages
** to manage multiple documents
** {{HIG|TABS-3}} to manage multiple documents
<div id="Tabs2"></div>
 
* Do not use tabs  
* Do not use tabs  
** for only one page (but do not hide the tab when more pages are expected, for example in web browser)
** for only one page (but do not hide the tab when more pages are expected, for example in web browser)
** for controls that apply to the entire application
** for controls that apply to the entire application
** for sequential steps, like wizards.
** for sequential steps, like wizards.
=== Behavior ===
=== Behavior ===
<div id="Tabs3"></div>
<div id="Tabs3"></div>

Revision as of 16:54, 23 October 2014


Tabs

A tab control is a way to present related information on separate pages. Tabs are used for dynamic window surface to increase the surface, to manage multiple documents within a single window, or as view of exclusive options.

Tabs have several advantages: The user can easily access available options or see which forms have been opened. Because foreground tabs are visually differentiated from background tabs the user knows what item is currently in progress. The disadvantage is when dealing with many tabs at once. When a window is tabbed to a certain number that exceeds the available area of the monitor, the tabs clutter up.

Guidelines

Is this the right control

  • Use tabs
    • for many controls that can be organized within a few categories, like extended configuration settings
    • for a variable number of sections, like browser pages
    • to manage multiple documents
  • Do not use tabs
    • for only one page (but do not hide the tab when more pages are expected, for example in web browser)
    • for controls that apply to the entire application
    • for sequential steps, like wizards.

Behavior

  • Do not abuse other controls to simulate tab behavior.
  • Use horizontal tabs if the window has seven or fewer tabs and all the tabs fit on one row.
  • Do not use vertically stacked tabs. Tabs are drawn above the pages only (QTabWidget::TabPosition = North).

  • Do not use too many tabs. Use a list view with icons and associated pages if there are many pages or if you want to group static pages, e.g. in case of configuration content. This also gives ability to present hierarchy of pages as a tree.

  • Do not use multiple rows of tabs because it leads to jumping UI elements, which destroys spatial memory.
  • Do not disable a tab when it doesn't apply to the current context; disable the controls on the page.
  • Do not make the settings on a page dependent on settings on other pages.
  • Do not nest tabs.

  • Make tabs movable (possible to reorder) if their pages contain documents, but not if their pages contain static application's user interface.
  • Make tabs closable if their pages contain documents, but not if their pages contain application's user interface.
  • Make the tabs use scroll buttons to scroll tabs when there are too many tabs.
  • Provide a context menu on each tab if their pages contain documents. This menu should only include actions for manipulating the tab itself, such as Move Left, Move Right, Move to New Window, Close, Close All, Reload.

  • Consider to provide 'add new tab' function if their pages contain documents, not for static content. In this case the 'Add Tab' button should be used as a corner widget placed on the right hand of the tab bar. Have keyboard shortcuts or menu items for easy access, but do not displayed the 'add tab' function in the application toolbar.

Appearance

  • If users are likely to start with the last tab displayed, make the tab persist and select it by default. Otherwise, select the first page by default.
  • Do not assign effects to changing tabs; tabs must be accessible in any order.
  • Do not place icons on horizontal tabs since they usually add unnecessary visual clutter and consume screen space.
  • Provide a label with an access key for each tab. Use nouns with title capitalization to describe the content.

  • Do not expand tabs to use empty space of the widget (see expanding property of the Qt tab bar, unfortunately true by default).
  • Avoid long tab names.
  • Do not use abbreviations (acronyms such as HTML are allowed).
  • Do not use triangular shape of tabs.

Implementation