diff --git a/source/components/contextmenu.rst b/source/components/contextmenu.rst new file mode 100644 --- /dev/null +++ b/source/components/contextmenu.rst @@ -0,0 +1,75 @@ +Context menu +============ + +Purpose +------- + +A *context menu* is a list of functions or options (respectively menu +items) available to users in the current context. A submenu or cascading +menu is a secondary menu displayed on demand from within a menu. + +Menus are normally hidden from view (except :doc:`menu bars `) and drop down +when users right-click an object or window region that supports a +context menu. They are an efficient means of conserving screen space, +therefore. + +Examples +-------- + +Guidelines +---------- + +Is this the right control +~~~~~~~~~~~~~~~~~~~~~~~~~ + +- Provide a context menu for inherent functions. For instance, + functions that have only keyboard access like 'Copy' and 'Paste' for + textual controls, or standard functions like 'Forward' and 'Backward + in case of navigation. +- Use context menus for well known functions only. +- Do not use context menus as the only way to start a function. Always + have a redundant access. + +Behavior +~~~~~~~~ + +- Do not put more than 10 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. +- If appropriate, use an access button to make contextual menu + functionality easier to access. +- Place the most frequently used items at the top of the menu. +- Avoid combining actions and attributes in the same group. +- Use submenus cautiously. Submenus add complexity to the interface and + are physically more difficult to use, so you should take care not to + overuse them. +- 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. +- Hide menu items completely if they are permanently unavailable on the + user's system (e.g. due to missing hardware capabilities or missing + optional dependencies). +- 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. +- Prefer verb-based menu names; Avoid generic, unhelpful verbs, such as + 'Change' and 'Manage'. +- Use singular nouns for commands that apply to a single object, + otherwise use plural no diff --git a/source/components/dropdown.rst b/source/components/dropdown.rst new file mode 100644 --- /dev/null +++ b/source/components/dropdown.rst @@ -0,0 +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 `. +- 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 )`. +- 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/index.rst b/source/components/index.rst --- a/source/components/index.rst +++ b/source/components/index.rst @@ -7,15 +7,23 @@ :hidden: combobox + contextmenu + dropdown groupbox lineedit + menubar slider spinbox + splitter tableview * :doc:`combobox` +* :doc:`contextmenu` +* :doc:`dropdown` * :doc:`groupbox` * :doc:`lineedit` +* :doc:`menubar` * :doc:`slider` * :doc:`spinbox` +* :doc:`splitter` * :doc:`tableview` diff --git a/source/components/menubar.rst b/source/components/menubar.rst new file mode 100644 --- /dev/null +++ b/source/components/menubar.rst @@ -0,0 +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 +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 ` +- 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/slider.rst b/source/components/slider.rst --- a/source/components/slider.rst +++ b/source/components/slider.rst @@ -28,7 +28,7 @@ - Use a slider when it is useful for the user to control the rate of change of the value in real time. - If the value is open-ended on one or both ends, consider using a - `Spin Box`_ instead. + :doc:`Spin Box ` instead. Behavior ~~~~~~~~ @@ -46,7 +46,7 @@ - Align the label horizontally in line with the slider. - You can show the current value on the right of the slider or if space is very dense show it only as a tooltip when the slider is moved - + .. figure:: /img/Slider.value.qml.png :alt: Show value always or as tooltip @@ -60,7 +60,7 @@ .. figure:: /img/Slider.qml.png :alt: Spacing - + Spacing of slider components - Mark significant values along the length of the slider with text or @@ -78,7 +78,7 @@ .. figure:: /img/Slider.Volume.qml.png :alt: Exact value is not important - + Exact value is not important - Don't show checkmarks if the exact value is not important @@ -89,5 +89,5 @@ .. figure:: /img/Slider.Speed.qml.png :alt: Offer text input for exact value - + Offer text input for exact value diff --git a/source/components/splitter.rst b/source/components/splitter.rst new file mode 100644 --- /dev/null +++ b/source/components/splitter.rst @@ -0,0 +1,32 @@ +Splitter +======== + +Purpose +------- + +A *splitter* is a visual separator between two element groups. It allows +the user to resize the adjacent groups. + +Example +------- + +Guidelines +---------- + +Is this the right control +~~~~~~~~~~~~~~~~~~~~~~~~~ + +- Always put a splitter between aligned, resizable grouping controls to + allow individualization for users. + +Behavior +~~~~~~~~ + +- Remember position and adjust control size accordingly on next login. + +Appearance +~~~~~~~~~~ + +- Define a minimum size for areas that cannot be undercut by users. +- Make splitters at least 5 pixels wide so that they can be easily + clicked by any input device.