diff --git a/source/components/combobox.rst b/source/components/combobox.rst index 806a647..b57aff7 100644 --- a/source/components/combobox.rst +++ b/source/components/combobox.rst @@ -1,73 +1,73 @@ Combo box ========= Purpose ------- A *combo box* is a combination of a drop-down list and an edit control, thus allowing users to enter a value that isn't in the list. It behaves like a drop-down list and allows the user to choose from a list of existing items but adds the option to type a value directly into the control. Newly typed items are usually added to the list and can be selected next time. Combo boxes are typically applied to provide auto-complete or auto-type functionality in a convenient way to the user. The list provides auto-complete feature for the whole string, independently of the "editable" property. Given the items of "bike", "boat", and "car": - If one types "b", the list selects "bike". - If one (rapidly) types "bo", it selects "boat". - If one types "c", it selects "car". The input field of the combo box ("editable" is true) marks the completed part of the item as selected, making it easy to change the completion. Guidelines ---------- Is this the right control ~~~~~~~~~~~~~~~~~~~~~~~~~ - Use a combo box for single selection of one out of many items of lists that can be extended by the user. Prefer a simple :doc:`drop-down list ` in case of read-only interaction. -- Consider to replace the combo box by a :doc:`list view ` with a connected :doc:`edit control `. +- Consider to replace the combo box by a :doc:`list view ` with a connected :doc:`edit control `. Behavior ~~~~~~~~ - Show a maximum of eight items at once. - When possible apply changes immediately but do not initiate an action (like print, send, delete) when the user selects an item from the list. - Do not add controls to the drop-down (e.g. check boxes for each item). - Place options that represent general options (e.g. all, none) at the beginning of the list. - Sort list items in a logical order. Make sure sorting fits translation. - Make sure the items are easily accessible via keyboard by moving distinctive letters to the beginning of each option. For example, in a list of countries on continents, write "Germany (Europe)" instead of "Europe/Germany". - Do not have blank list items; use meta-options, e.g. (None) instead Appearance ~~~~~~~~~~ - Combo boxes are distinguished visually from drop-down lists (normally by the raised or lowered bevel). Do not override the common processing, e.g. by using a combo box and making it read only in order to simulate a simple drop-down list. - If activating a choice affects the appearance or the enabled state of other controls, place them next to the combo box. - If certain controls in a configuration dialog are only relevant if a certain item is selected (i.e. they are dependent controls), disable them instead of hiding. - Label the combo box with a descriptive caption to the left (cf. :doc:`alignment `). - Create a buddy relation so access keys are assigned. - End each label with a colon. - Use :doc:`sentence style capitalization ` for items. diff --git a/source/components/contextdrawer.rst b/source/components/contextdrawer.rst index 7ee07b2..52a1ff1 100644 --- a/source/components/contextdrawer.rst +++ b/source/components/contextdrawer.rst @@ -1,46 +1,46 @@ Context drawer ============== .. figure:: /img/Context_drawer.jpg :scale: 50 % :alt: Examples of a context drawer Examples of a context drawer Purpose ------- The Context Drawer is used to access controls that depend on the current context. This can be, for example, controls that affect a selected element in a list or that navigate through an opened document. Is this the right control? -------------------------- Use a Context Drawer if your application has any functions which are only relevant in specific contexts, and which are not central enough to the application's main purpose to put them in the main user interface or in a toolbar. For actions which are always available, use the :doc:`Global Drawer `. Guidelines ---------- - The Context Drawer is opened by swiping in from the left or right edge of the screen (depending on a system-wide setting) and closed by swiping in the other direction or tapping outside of it. - At the top of the drawer, state which object the controls affect (e.g. "Selected email") - By default, the Context Drawer simply contains a vertical list of action buttons which affect the currently selected/opened element - Center the list vertically instead of top-aligning, to allow an easier reach with the thumb - If needed, other controls related to the current context can be put in the Context Drawer - Try to keep the content of the context drawer in one page. If there two distinct "modes" of contextual actions (for example navigating through a PDF either by table of contents or - thumbnails), consider using two :doc:`Tabs ` to separate them, but + thumbnails), consider using two :doc:`Tabs ` to separate them, but never use more than two tabs. diff --git a/source/components/dialog.rst b/source/components/dialog.rst index d6d4465..19e0594 100644 --- a/source/components/dialog.rst +++ b/source/components/dialog.rst @@ -1,79 +1,79 @@ Dialog ====== Purpose ------- A *dialog* is a secondary window that allows users to perform a command, asks users a question, or provides users with information or progress feedback. Dialogs can be modal and require users to complete and close before continuing with the owner window, or modeless, i.e. users can switch between dialogs and parent window. Guidelines ---------- Is this the right control? ~~~~~~~~~~~~~~~~~~~~~~~~~~ - Use a dialog to structure the work flow. For instance, the functions Open, Save, Advanced Search need user input or confirmation. In particular, dialogs are expected by users for configuration. - Do not use dialogs if the flow must not get interrupted. In this case prefer inline controls. - Consider to use alternative ways for communication with users like - :doc:`tooltip ` or :doc:`message panel `. + :doc:`tooltip ` or a :doc:`inline message `. - Always use standard dialogs, if available. Behavior ~~~~~~~~ - Do not apply dialog boxes that require the use of a scroll bar. - Do not include a menu bar or status bar in dialogs. - Do not display more than one owned choice dialog at a time from an owner choice dialog. - Always keep dialogs on top of their parent. - Set input focus on confirmation button by default. But set focus on disruptive button (Cancel, Don't apply or the like) if the dialog comprises of critical confirmation. - Avoid to nest dialogs, especially in case of modal dialogs. - Avoid dialogs that contain only one or two options. If possible, use direct selection or inline-editing instead. - Do not use dialogs to display non-critical messages which do not require any further user interaction (typically dialogs with a single "OK" or "Close" button). Consider to use :doc:`tooltip ` or a - :doc:`message panel `. + :doc:`inline message `. - Use modal dialogs only if allowing interaction with other parts of the application while the window is opened could cause data loss or some other serious problem. - Provide a clear way of leaving the modal dialog, such as a Cancel button. - When the dialog is used to inform about an unexpected condition that needs interaction, follow the guidelines for :doc:`message dialogs `. Appearance ~~~~~~~~~~ - Use tabbed dialogs when you have a limited number of tabs (max. 6). If you cannot see all the tabs without scrolling or splitting them into multiple rows, you are probably using too many and should use a paged dialog instead. - Always use paged dialogs for configuration dialogs - assuming that there is more than one section of options to be configured. For other dialogs, use paged dialogs if there are too many tabs to put them into a tabbed dialog. - Dialogs should not be bigger than two thirds of the screen size and should always be resizable. Take care about high resolution displays (i.e. QXGA and more). - Save and restore user adjustments of dialog size. - Make sure there is at least one third white space, do not overload the panel. - Consider the common reading direction from left to right and top to bottom. - Dialogs are grouped in meaningful sections, for instance by :doc:`group boxes `. The actions are grouped along their context of use, not along technical relations. - Provide a title to each section. - Follow the guidelines for :doc:`alignment `. diff --git a/source/components/dropdown.rst b/source/components/dropdown.rst index fec33e7..817fad7 100644 --- a/source/components/dropdown.rst +++ b/source/components/dropdown.rst @@ -1,80 +1,80 @@ Drop-down ========= Purpose ------- A *drop-down list* is a GUI control which allows the user to choose one value from a list. When a drop-down list is inactive, it displays a single value. When activated, it displays (drops down) a list of values, from which the user may select one. When the user selects a new value, the control reverts to its inactive state, displaying the selected value. A drop-down list works similar to a list box but hides the complete list until the user initiate the drop down. The disadvantage of drop-down lists compared to related controls like radio buttons or lists is that the options are not visible without further interaction. The list provides auto-complete feature for the whole string, independently of the "editable" property. Given the items of "bike", "boat", and "car": - If one types "b", the list selects "bike". - If one (rapidly) types "bo", it selects "boat". - If one types "c", it selects "car". One can repeatedly type a letter to cycle through items of the (read-only) drop-down list starting with this letter. Guidelines ---------- Is this the right control ~~~~~~~~~~~~~~~~~~~~~~~~~ - Use a drop-down list for single selection of one out of many items. If users should be able to add items use a :doc:`combo box `. - For only a few options, consider to use a set of :doc:`radio buttons `. - For a single selection out of a large number of items (n>20), use a - :doc:`list view `. + :doc:`list view `. - Prefer controls that show the options without further user interaction, except for the following cases: - the list of options may change over time, - the contents are obvious from the label and the one selected item, for example *Month* and *January* - the control is part of a related sequence of controls. For example, to set a reminder to ring 5 hours or minutes before or after an event. Behavior ~~~~~~~~ - Show a maximum of eight items at once (maxVisibleItems=8). - When possible apply changes immediately but do not initiate an action (like print, send, delete) when the user selects an item from a drop-down list. - Do not add controls to the drop-down (e.g. check boxes for each item). - Place options that represent general options (e.g. all, none) at the beginning of the list. - Sort list items in a logical order. Make sure sorting fits translation. - Make sure the items are easily accessible via keyboard by moving distinctive letters to the beginning of each option. For example, in a list of countries on continents, write "Germany (Europe)" instead of "Europe/Germany". - Do not have blank list items; use meta-options, e.g. (None) instead Appearance ~~~~~~~~~~ - If activating a choice affects the appearance or the enabled state of other controls, place them next to the drop down. - If certain controls in a configuration dialog are only relevant if a certain item is selected (i.e. they are dependent controls), disable them instead of hiding. - Label the drop down with a descriptive caption to the left (cf. - :doc:`alignment )`. + :doc:`alignment `). - Create a buddy relation so access keys are assigned. - End each label with a colon. - Use :doc:`sentence style capitalization ` for items. diff --git a/source/components/globaldrawer.rst b/source/components/globaldrawer.rst index 5cc21c0..3e4aede 100644 --- a/source/components/globaldrawer.rst +++ b/source/components/globaldrawer.rst @@ -1,52 +1,52 @@ Global drawer ============= .. figure:: /img/Menu_Drawer.png :alt: Examples of different global drawers Examples of different global drawers Purpose ------- The Global Drawer is a standard element in KDE mobile applications. It contains an application's main menu, and any functions which are not part of the application's main usecases but are not specific to the current context either. Is this the right control? -------------------------- Use a Global Drawer whenever your application has any functions which are not central enough to the application's main purpose to put them in the main user interface, and which are not dependent on the current context. For context-specific actions (e.g. those affecting a selected item), use the :doc:`Context Drawer ` Guidelines ---------- The Global Drawer is opened by swiping in from the left or right edge of the screen (depending on a system-wide setting) and closed by swiping in the other direction or tapping outside of it. A Global Drawer may contain the following controls: -- :doc:`Tabs ` +- :doc:`Tabs ` - A main menu - :doc:`Push Buttons ` to execute non-contextual actions - :doc:`Checkboxes ` or :doc:`Radio Buttons ` to change settings which are commonly changed The main menu - Must not have more than three levels - Should if possible not contain more elements than fit on the screen -- Should contain an entry :doc:`Settings ` in the last position if the +- Should contain an entry :doc:`Settings ` in the last position if the application has settings which are not commonly changed - Selecting an entry in the menu either executes an action or goes down one level, replacing the menu with the items in the selected submenu - In lower menu levels, below the entries there is a button to go up one level. Do not use the Menu Drawer for navigation purposes. diff --git a/source/components/menubar.rst b/source/components/menubar.rst index 0c7c56c..0c477a7 100644 --- a/source/components/menubar.rst +++ b/source/components/menubar.rst @@ -1,71 +1,71 @@ Menu bar ======== Purpose ------- A *menu bar* appears at the top of the main window of applications with -a :doc:`very complex command structure `. It provides access to all commands +a :doc:`very complex command structure `. It provides access to all commands and most of the settings available in an application. It contains of a list of functions or options (respectively menu items), submenus or cascading menus that is a secondary menu displayed on demand from within a menu, and separators to organize the content for easy recognition. Users refer frequently to the menu bar, especially when they are seeking a function for which they know of no other interface. Ensuring that menus are well organized, are worded clearly, and behave correctly is crucial to the user’s ability to explore and access the functionality of the application. Examples -------- Guidelines ---------- Is this the right control ~~~~~~~~~~~~~~~~~~~~~~~~~ - Provide a menu bar in the main window of applications with a - :doc:`very complex command structure ` + :doc:`very complex command structure ` - Do not display a menu bar in secondary or internal windows. Behavior ~~~~~~~~ - Do not have more than nine menu categories within a menu bar. Too many categories are overwhelming and make the menu bar difficult to use. - Do not put more than 12 items within a single level of a menu. Add separators between logical groups within a menu. Organize the menu items into groups of seven or fewer strongly related items. - Use these standard menu categories if they apply to your application: File, Edit, View, Insert, Format, Tools, Settings, Window, Help. - If an application does not have options under one of the standard menu items, do not include it in the menu. At the minimum, all windows should have a File (or File equivalent, such as in the case if Konqueror and Amarok) and Help menu. - Do not hide the menu bar by default. If configurable, users should easily be able to make the menu bar viewable again. - Do not change labels of menu item dynamically. Appearance ~~~~~~~~~~ - Choose single word names for menu categories. Using multiple words makes the separation between categories confusing. - Disable menu items that don't apply to the current context, instead of removing them. - Assign :doc:`shortcut keys ` to the most frequently used menu items (Ctrl+). For well-known shortcut keys, use standard assignments. Use function keys for commands that have a small-scale effect (F2 = Rename) and ctrl key for large-scale effect (Ctrl+S = Save). - Indicate a function that needs additional information (including a confirmation) by adding an ellipsis at the end of the label (e.g. Save as…). - Provide menu item icons for the most commonly used menu items. - Turning on an item in the menu should always enable the option. Negative options create a double negative which can be confusing. For example, use 'Show hidden files' instead of 'Hide hidden files'. - Do not use compound words (e.g. ToolOptions), and hyphens (e.g. Tool-Options) in label names; they make words harder to read and recognize. diff --git a/source/components/swipelistitem.rst b/source/components/swipelistitem.rst index f7c0ea9..ce81687 100644 --- a/source/components/swipelistitem.rst +++ b/source/components/swipelistitem.rst @@ -1,56 +1,56 @@ Swipe list item =============== When to use ----------- -This uses an :doc:`on-demand pattern ` as +This uses an :doc:`on-demand pattern ` as alternative to always visible controls in lists. If the user often performs tasks on single items of a list, add a handle on the side the list item (next to the context drawer's edge, defined by a system-wide configuration) which. Example ------- .. image:: /img/Slide_to_reveal.jpg :alt: Slide to reveal actions :scale: 30 % How to use ---------- -- See :doc:`on-demand pattern ` for +- See :doc:`on-demand pattern ` for general recomendations. - |desktopicon| If only one action is available, most the time it's better to not use the on-demand pattern, but show the action right away. Behavior --------- The item slides only as far as needed, so the user has a visual hint which item is swiped. |desktopicon| Desktop ~~~~~~~~~~~~~~~~~~~~~ .. image:: /img/desktop-listview.png :alt: Hover to reveal :scale: 80 % On-demand controls are shown when hovering over the item with the cursor. A handle is shown to support devices with touch screens. Swiping the handle right to left reveals the actions. As soon as the user taps anywhere else or the pointer is not any longer hovering the item, the handle is slid back. |mobileicon| Mobile ~~~~~~~~~~~~~~~~~~~ .. image:: /img/mobile-listview.png :alt: Hover to reveal :scale: 80 % On-demand controls are revealed by sliding a handle from right to left to reveal them. As soon as the user taps anywhere else, the handle is slid back. diff --git a/source/components/tab.rst b/source/components/tab.rst index 80adbba..859d6e8 100644 --- a/source/components/tab.rst +++ b/source/components/tab.rst @@ -1,137 +1,137 @@ Tabs ==== Purpose ------- 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 a view of exclusive options. .. image:: /img/Tabs-HIG.png :alt: Tabs-HIG.png Tabs have several advantages. Users 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 use. Having tabs beyond the screen size may lead to visual clutter. General 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 global application controls. - for sequential steps, like wizards. Guidelines for desktop user interfaces -------------------------------------- Behavior ~~~~~~~~ - Do not abuse other controls to simulate tab behavior. - Use horizontal tabs with 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 :doc:`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 tab rows. It leads to disorientation. - Do not disable a tab when it doesn't apply to the current context; disable the controls on the page. - Make content from one page independent and differentiated from another through the use of tabs. - 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 ~~~~~~~~~~ - Make last used tab persistent. Otherwise, select the first page by default. - Do not assign effects to changing tabs; tabs must be accessible in any order. - Only use text in horizontal tabs and not icons. - Provide a label with an access key for each tab. Use nouns with :doc:`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. Use a compelling, easy to understand label. Phrases not sentences. -- Do not use :doc:`abbreviations ` +- Do not use :doc:`abbreviations ` (acronyms such as HTML are allowed). - Do not use triangular shape of tabs. Guidelines for phone user interfaces ------------------------------------ .. image:: /img/Tabs_in_drawer.png :alt: Tabs in global drawer Behavior ~~~~~~~~ - Do not abuse other controls to simulate tab behavior. - Do not nest tabs. - When the tabs are used to group controls, put them at the top of the screen. Do not use more than three tabs. - Do not disable a tab when it doesn't apply to the current context; disable the controls on the page. - Keep interdependent elements in the same tab. - When using tabs to open multiple documents (e.g. websites) in the same instance of an application, show them as a list at the top of the :doc:`global drawer ` - Offer the user the option to choose between "Use tabs" and "Use separate windows", the default of which is specified by the gobal setting, if it is set, otherwise the default is new windows unless users are used to tabs from existing apps of the same type (e.g. for web browsers) - Swiping on a tab away from the screen edge that the menu drawer is attached to (e.g. to the right if the drawer is on the left side) closes the tab Appearance ~~~~~~~~~~ - Use short labels for tabs that group controls - Use descriptive names for tabs, e.g. page titles for browser tabs - Put a control to open a new tab below the list of tabs diff --git a/source/components/tableview.rst b/source/components/tableview.rst index d599c34..b027166 100644 --- a/source/components/tableview.rst +++ b/source/components/tableview.rst @@ -1,65 +1,65 @@ Table view ========== Purpose ------- A *table* (also known as *grid* or spreadsheet) is a graphical control to present data in an ordered arrangement of rows and columns. The intersection of a row and a column is a cell. The elements of a table may be grouped, segmented, or arranged in many different ways, and even nested recursively. It provides a familiar way to convey information that might otherwise not be obvious or readily understood. Tables provide inline editing with the advance of a concise layout since no additional control is needed for input. The approach is usually less error-prone because a list with direct input has no dependency to other controls (in contrast to the combination of a list with an edit which needs to be enabled or disabled appropriate to the list entry the user clicks). The drawback is reduced discoverability for lists with restricted editing function, at least when only a few cells can be changed. User does not know which cell is editable and which is not. Example ------- Guidelines ---------- Is this the right control ~~~~~~~~~~~~~~~~~~~~~~~~~ - Use a table to arrange data in two dimensions. - Use a table for a concise layout with inline editing feature. - Do not use a table for read only purpose. In this case use a simple - :doc:`list view ` or a :doc:`tree view ` with multiple columns. + :doc:`list view ` or a :doc:`tree view ` with multiple columns. Behavior ~~~~~~~~ - Switch from viewing mode to edit mode after single click on the editable cell. - Change appearance of cells when switching from viewing to editing. Editable cells have a lowered bevel; they look like they can be filled. - Mark currently changed cells with a red corner. - Define keyboard navigation within the table since the control receives focus as a whole. By pressing arrow-down key the next row is focused; respectively arrow-up for previous row. The arrow-left or arrow-right key navigates to adjacent columns if available. Do not change tab key navigation to allow users to switch to other controls. - Use the appropriate control for constrained input. Show the control’s UI (e.g. arrow for :doc:`drop-down list `) not until the cell is in edit mode. - Distinguish editable cells from those that are read-only. - Allow tables to be extended by users in both directions. - Provide copy/paste feature for single as well as multiple selected cells, if appropriate. Appearance ~~~~~~~~~~ - Avoid horizontal scrollbars. Size the table to a reasonable width. - Use fixed column header. - Label the table with a descriptive caption to the top left (cf. :doc:`/layout/alignment`). - Create a buddy relation so access keys are assigned. diff --git a/source/components/toolbar.rst b/source/components/toolbar.rst index 6f6e4dc..4fedf88 100644 --- a/source/components/toolbar.rst +++ b/source/components/toolbar.rst @@ -1,57 +1,57 @@ Tool bar ======== Purpose ------- A *tool bar* is a graphical presentation of commands optimized for fast access. Typically, a toolbar contains buttons that correspond to items in an application's menu, providing direct access to application's most frequently used functions. A good menu bar is a comprehensive catalog of all the available top-level commands, whereas a good tool bar gives quick, convenient access to frequently used commands. Guidelines ---------- Is this the right control ~~~~~~~~~~~~~~~~~~~~~~~~~ - For standard applications, apply a tool bar by default. - Provide a tool bar in addition to the menu bar, but do not replace the menu bar. Behavior ~~~~~~~~ - A tool bar should contain only a few, frequently used operations. If the number of operations is above 5 they have to be grouped with separators. Not more than 3 of those sections should be implemented. - Do not abuse the tool bar to expose application's features. Only the most frequently functions should be add to the tool bar. - Execute operations immediately; do not require additional input from user. -- Do not use :doc:`menu buttons