Commit 43f16e24 authored by Carson Black's avatar Carson Black

Do not -> Don't in all writing

parent d127200d
......@@ -33,7 +33,7 @@ Keyboard Navigation
Testing
^^^^^^^
The following keyboard operations should be tested. Do not use the mouse in any
The following keyboard operations should be tested. Don't use the mouse in any
part of this test.
- Using only keyboard commands, move the focus through all menu bars in the
......@@ -201,7 +201,7 @@ Keyboard Focus
presses an inappropriate key.
- There is sufficient audio information for the visual focus that the user
can figure out what to do next.
- Set the focus to the actual control, do not just highlight an area.
- Set the focus to the actual control, Don't just highlight an area.
- When using assistive technologies, such as a screen reader or braille
device, the current program indicates the position and content of the visual
focus indicator.
......
......@@ -107,7 +107,7 @@ verbose "this button does foo and then bar". Qt will try hard to return
something for the name. In case of a button, usually the text on the button is
returned. But if your button has text that makes only sense when seeing the
arrangement of buttons, or only has an image as label, you need to help the AT
read the button. If you do not, it will only say the type of the widget, "Button"
read the button. If you Don't, it will only say the type of the widget, "Button"
is not very helpful information.
......
......@@ -28,7 +28,7 @@ Guidelines
in a file manager, system tray, task manager, dock, image view, etc. Emblems
should not be applied to textual content.
- Use emblems to display that an icon or image has some unusual status
associated with it, or that there are unread notifications. Do not use
associated with it, or that there are unread notifications. Don't use
emblems to display an element's normal, common, or typical status. For
example, an emblem could indicate that a folder is read-only or is a symlink,
or that a disk is unmounted or encrypted. An emblem should not be used to
......@@ -38,7 +38,7 @@ Guidelines
in a clockwise order.
- Emblems that indicate unread notifications should be located in the
top-right corner.
- Use the minimum number of emblems and do not overwhelm the icon itself.
- Use the minimum number of emblems and Don't overwhelm the icon itself.
Three is usually too many.
Appearance
......
......@@ -49,9 +49,9 @@ Guidelines
"Remember password?"
- Display the information immediately.
- When users dismiss the inline message, do not display any other UI or start
- When users dismiss the inline message, Don't display any other UI or start
any other side effect.
- Do not add controls to the inline message other than action buttons
- Don't add controls to the inline message other than action buttons
for opportunistic interaction.
- Consider to show a :doc:`notification` if information does not concern
the current workflow.
......@@ -83,7 +83,7 @@ the user. An inline message should also not appear as an overlay to prevent
blocking access to elements the user needs to interact with to fix the
failure.
When used for negative feedback, do not offer a close button. The
When used for negative feedback, Don't offer a close button. The
message panel only closes when the problem it informs about (e.g. the
error) is fixed.
......
......@@ -29,7 +29,7 @@ Is this the right control?
Behavior
~~~~~~~~
- Dialogs should be modal, and block user interaction with the rest of the
application until a choice has been made. Do not block the entire user
application until a choice has been made. Don't block the entire user
interface for the whole system, though.
- Create specific, actionable, user-centered error messages. Users should
either perform an action or change their behavior as a result.
......
......@@ -37,14 +37,14 @@ Behavior
- Clearly indicate real progress – and lack of progress. The progress
bar must advance if progress is being made and not advance if no
progress is being made.
- Show progress by steps in respect to context. For instance, do not
- Show progress by steps in respect to context. For instance, Don't
inform about the number of files that have been downloaded but rather
the total size in bytes.
- Provide additional progress information, but only if users can do
something with it, e.g. cancel the processing, relate an error to a
particular processing step, etc. Do not provide unnecessary details.
- Do not use progress bars if the time needed to complete the task
particular processing step, etc. Don't provide unnecessary details.
- Don't use progress bars if the time needed to complete the task
cannot be estimated, as well not per waiting bar (aka marquee style).
In that case, if the task will likely take only a few seconds, use a
spinner. If it takes longer, move the task to the background.
- Do not combine a progress bar with a busy pointer.
- Don't combine a progress bar with a busy pointer.
......@@ -20,25 +20,25 @@ Is this the right control?
- Omit the status bar in the main window to maximize vertical space for
content.
- Do not show meaningless information like 'Ready'.
- Don't show meaningless information like 'Ready'.
- Use a floating panel or :doc:`tooltips <tooltip>` for short-term status
information like full length text of links.
- Move controls to the toolbar.
- If you cannot find good replacements for status bar functions,
please ask the usability team for support.
- Do not display a status bar in secondary or internal windows.
- Don't display a status bar in secondary or internal windows.
- If a status bar is really necessary in your application consider to
use a :doc:`toolbar <../navigation/toolbar>` with all customization features.
Behavior
~~~~~~~~
- Do not use the status bars or any kind of replacement for crucial
- Don't use the status bars or any kind of replacement for crucial
information. Users should never have to know what is in the status
bar.
- Do not use the status bar or any kind of replacement to display
- Don't use the status bar or any kind of replacement to display
advisory messages in place of standard :doc:`tooltips <tooltip>`.
- Keep the status information plain; e.g. do not add icons.
- Keep the status information plain; e.g. Don't add icons.
.. for more info see http://user-prompt.com/what-is-a-status-bar-good-for/
......@@ -49,7 +49,7 @@ Appearance
self-explanatory control labels or in-place supplemental text
- static: tips should not change from one instance to the next
- Do not use icons and formattings for tips of unlabeled controls.
- Don't use icons and formattings for tips of unlabeled controls.
- Use tool-tips with icons and formatting
- if tips describe comprehensive functions,
......
......@@ -13,14 +13,14 @@ Guidelines
Is this the right control?
~~~~~~~~~~~~~~~~~~~~~~~~~~
- Do not use a card to display long texts.
- Don't use a card to display long texts.
- Cards can be used to display items with different content types, e.g. images
text, videos.
- Do not use cards for content that should be directly comparable, use a
- Don't use cards for content that should be directly comparable, use a
table view or a grid view for that.
- If you would show more than 20 cards at a time, or if the user would have to scroll
for more than three screen heights to see all of them, consider using a list instead.
- Do not use cards with text input elements.
- Don't use cards with text input elements.
- If your cards consist of just one image a grid with overlay actions
might be more suitable.
......
......@@ -8,7 +8,7 @@ A checkbox is a control that permits the user to make multiple
selections from a number of options. Checkboxes are used to toggle an
option on or off, or to select or deselect an item. Users make a
decision between two clearly opposite choices, e.g. 'on vs. off', 'apply
vs. do not apply', 'show vs. hide'.
vs. Don't apply', 'show vs. hide'.
Guidelines
----------
......@@ -28,7 +28,7 @@ Is this the right control?
:figclass: border
:iconred:`Don't.` |br|
Do not use a checkbox if the opposite is ambiguous.
Don't use a checkbox if the opposite is ambiguous.
.. container::
......@@ -42,7 +42,7 @@ Is this the right control?
- For more than five options, use either a :doc:`list view <list>` or
the :doc:`dual-list pattern </patterns/content/duallist>` in case of
multiple selections.
- Do not use the selection to perform commands.
- Don't use the selection to perform commands.
.. container:: flex
......@@ -52,7 +52,7 @@ Is this the right control?
:figclass: border
:iconred:`Don't.` |br|
Do not use the selection to perform commands.
Don't use the selection to perform commands.
.. container::
......@@ -77,7 +77,7 @@ Behavior
:figclass: border
:iconred:`Don't.` |br|
Do not use checkboxes for negatives.
Don't use checkboxes for negatives.
.. container::
......@@ -97,7 +97,7 @@ Behavior
- Users must not be able to set a mixed state directly.
- Clicking a mixed state checkbox enables all child objects.
- Do not use sliding switches in Desktop applications. They only offer
- Don't use sliding switches in Desktop applications. They only offer
good user interaction on touch screens, so they should only be used
in applications for mobile devices.
......@@ -108,7 +108,7 @@ Behavior
.. figure:: /img/Checkbox_Switch_Desktop.qml.png
:iconred:`Don't.` |br|
Do not use sliding switches on desktop.
Don't use sliding switches on desktop.
.. container::
......@@ -167,9 +167,9 @@ which will take care of the layout and spacing of your controls.
- If certain controls in a configuration dialog are only relevant if a
certain checkbox is checked (i.e. they are dependent controls),
disable them instead of hiding them if that checkbox is unchecked.
- Do not separate checkbox and label. Clicking on both the box and the
- Don't separate checkbox and label. Clicking on both the box and the
label should toggle the option.
- Do not add line breaks. If necessary place an additional label below
- Don't add line breaks. If necessary place an additional label below
the checkbox.
.. container:: flex
......@@ -180,7 +180,7 @@ which will take care of the layout and spacing of your controls.
:figclass: border
:iconred:`Don't.` |br|
Do not use linebreaks in a checkbox's label.
Don't use linebreaks in a checkbox's label.
.. container::
......@@ -195,7 +195,7 @@ which will take care of the layout and spacing of your controls.
- Create a buddy relation so access keys are assigned.
- Use :doc:`sentence style capitalization </style/writing/capitalization>`
for checkbox items.
- Do not use ending punctuation (neither dot nor colon) for group
- Don't use ending punctuation (neither dot nor colon) for group
label.
Code
......
......@@ -46,10 +46,10 @@ Behavior
~~~~~~~~
- Show a maximum of eight items at once.
- When possible apply changes immediately but do not initiate an action
- When possible apply changes immediately but Don't 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. checkboxes for each
- Don't add controls to the drop-down (e.g. checkboxes for each
item).
- Place options that represent general options (e.g. all, none) at the
beginning of the list.
......@@ -59,13 +59,13 @@ Behavior
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.
- Don't 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
by the raised or lowered bevel). Don't 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
......
......@@ -38,7 +38,7 @@ Guidelines
start date, switch the end date at least to the same date.
- Avoid wrong input by restricting the period to a reasonable range
(for instance when a range is being selected).
- Do not modify localization settings (i.e. first day of week, date
- Don't modify localization settings (i.e. first day of week, date
label etc.)
- Use controls consistently; either all date input should be done by
date picker or none.
......
......@@ -57,10 +57,10 @@ Behavior
~~~~~~~~
- Show a maximum of eight items at once (maxVisibleItems=8).
- When possible apply changes immediately but do not initiate an action
- When possible apply changes immediately but Don't 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. checkboxes for each
- Don't add controls to the drop-down (e.g. checkboxes for each
item).
- Place options that represent general options (e.g. all, none) at the
beginning of the list.
......@@ -70,7 +70,7 @@ Behavior
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
- Don't have blank list items; use meta-options, e.g. (None) instead
Appearance
~~~~~~~~~~
......
......@@ -26,7 +26,7 @@ Is this the right control?
- Use edits for input of single lines of unconstrained text.
- In case of multiple lines of text or more than a few words, use a
:doc:`text edit <textedit>`
- Do not use a line edit if only a specific type of data is valid. Use
- Don't use a line edit if only a specific type of data is valid. Use
a control for constrained input.
Behavior
......@@ -50,7 +50,7 @@ Behavior
- If the input data is inconsistent with other controls on the window,
give an error message when the entire input is complete, such as when
users click OK for a modal dialog box.
- Do not clear invalid input data unless users are not able to correct
- Don't clear invalid input data unless users are not able to correct
errors easily. Doing so allows users to correct mistakes without
starting over.
......
......@@ -37,7 +37,7 @@ Is this the right control?
Behavior
~~~~~~~~
- Do not have blank list items; use meta-options, e.g. (None) instead.
- Don't have blank list items; use meta-options, e.g. (None) instead.
- 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
......@@ -104,7 +104,7 @@ state.
Multiple selected items in a picker overlay.
- Do not provide extended multiple selections with Shift+Click or
- Don't provide extended multiple selections with Shift+Click or
Ctrl+Click to select groups of contiguous or non-adjacent values,
respectively. Instead, use the
:doc:`dual-list pattern </patterns/content/duallist>` or the
......
......@@ -29,7 +29,7 @@ Is this the right control?
:figclass: border
:iconred:`Don't.` |br|
Do not use radio buttons for more tham five options.
Don't use radio buttons for more tham five options.
.. container::
......@@ -41,7 +41,7 @@ Is this the right control?
- If there are only two options where one is the negation of the other
(e.g. "apply" vs. "do not apply"), consider replacing the radio
(e.g. "apply" vs. "Don't apply"), consider replacing the radio
buttons by one :doc:`checkbox <checkbox>`.
.. container:: flex
......@@ -52,7 +52,7 @@ Is this the right control?
:figclass: border
:iconred:`Don't.` |br|
Do not use radio buttons for do/do not operations.
Don't use radio buttons for do/Don't operations.
.. container::
......@@ -73,7 +73,7 @@ Is this the right control?
:figclass: border
:iconred:`Don't.` |br|
Do not hide choices that the user should see from the start
Don't hide choices that the user should see from the start
in comboboxes.
.. container::
......@@ -84,7 +84,7 @@ Is this the right control?
:noblefir:`Do.` |br|
Use radio buttons instead.
- Do not use a radio button to initiate an action. Consider using a
- Don't use a radio button to initiate an action. Consider using a
:doc:`push button <../navigation/pushbutton>` instead.
.. container:: flex
......@@ -95,7 +95,7 @@ Is this the right control?
:figclass: border
:iconred:`Don't.` |br|
Do not use the selection to perform commands.
Don't use the selection to perform commands.
.. container::
......@@ -120,7 +120,7 @@ Behavior
:figclass: border
:iconred:`Don't.` |br|
Do not forget a default option.
Don't forget a default option.
.. container::
......@@ -140,7 +140,7 @@ Behavior
:figclass: border
:iconred:`Don't.` |br|
Do not have an option besides the first as the default.
Don't have an option besides the first as the default.
.. container::
......@@ -174,16 +174,16 @@ which will take care of the layout and spacing of your controls.
certain radio button is toggled on (i.e. they are dependent
controls), disable them instead of hiding them if that radio button
is toggled off.
- Do not separate radio button and label. Clicking on both the button
- Don't separate radio button and label. Clicking on both the button
and the label should toggle the option.
- Do not add line breaks. If necessary place an additional label below
- Don't add line breaks. If necessary place an additional label below
the checkbox.
- Label a group of radio buttons with a descriptive caption to the top
left of the group (cf. :doc:`alignment </layout/alignment>`).
- Create a buddy relation so access keys are assigned.
- Use :doc:`sentence style capitalization </style/writing/capitalization>`
for radio buttons.
- Do not use ending punctuation (neither dot nor colon) for group
- Don't use ending punctuation (neither dot nor colon) for group
label.
Code
......
......@@ -35,7 +35,7 @@ Behavior
- Try to give immediate feedback while the user makes a selection.
- Size the control so that a user can easily set the desired value.
- Do not use a non-linear scale, e.g. logarithmic.
- Don't use a non-linear scale, e.g. logarithmic.
Appearance
~~~~~~~~~~
......@@ -68,7 +68,7 @@ eg screen size, symbol-size
emphasize them.
- Min/max labels are optional. Label min/max with real values, eg
'640x480' and '5120×2880' in case of screen resolution.
- Label the range of values; use checkmark and value label; do not label
- Label the range of values; use checkmark and value label; Don't label
every checkmark.
Slider with many steps
......@@ -81,9 +81,9 @@ eg volume control, mouse speed, brightness
Exact value is not important
- Do not show checkmarks if the exact value is not important
- Do not show min/max label if the values donot give the user additional
information, eg. do not label them 0%, 100%
- Don't show checkmarks if the exact value is not important
- Don't show min/max label if the values donot give the user additional
information, eg. Don't label them 0%, 100%
- If the exact value might be important to the user offer an input
field instead of the current value label
......
......@@ -46,7 +46,7 @@ Behavior
- If the input data is inconsistent with other controls on the window,
give an error message when the entire input is complete, such as when
users click OK for a modal dialog box.
- Do not clear invalid input data unless users are not able to correct
- Don't clear invalid input data unless users are not able to correct
errors easily. Doing so allows users to correct mistakes without
starting over.
......
......@@ -28,7 +28,7 @@ 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
- Don't use a table for read only purpose. In this case use a simple
:doc:`list view <list>` or a :doc:`tree view <tree>` with multiple columns.
Behavior
......@@ -43,7 +43,7 @@ Behavior
- 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
arrow-right key navigates to adjacent columns if available. Don't
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 <dropdown>`) not until the cell is in edit
......
......@@ -24,15 +24,15 @@ Is this the right control?
- Use text edits for input of unconstrained text with more than one
line.
- Do not use a text edit for input of a few words. Use a :doc:`line edit <lineedit>`
- Don't use a text edit for input of a few words. Use a :doc:`line edit <lineedit>`
to enter single lines of text.
Behavior
~~~~~~~~
- Do not make users scroll unnecessarily; size text boxes to eliminate
- Don't make users scroll unnecessarily; size text boxes to eliminate
the need for scrolling.
- Do not put horizontal scroll bars on multi-line text boxes.
- Don't put horizontal scroll bars on multi-line text boxes.
Appearance
~~~~~~~~~~
......
......@@ -39,8 +39,8 @@ Behavior
- Group toggle buttons in case of multiple selection.
- Separate toggle buttons from other controls, so they are not mistaken
for push buttons.
- Do not use a toggle button to initiate an action.
- Do not change the label according the button state.
- Don't use a toggle button to initiate an action.
- Don't change the label according the button state.
Appearance
~~~~~~~~~~
......
......@@ -19,16 +19,16 @@ Is this the right control?
- Always use a group box to arrange related controls.
- Use a frame to arrange related controls that cannot be labeled.
- Do not group single controls.
- Don't group single controls.
- Show relationship by layout only.
Behavior
~~~~~~~~
- Do not nest grouping elements; use layout to show relationships
- Don't nest grouping elements; use layout to show relationships
within a group.
- Do not place controls in group box caption.
- Do not disable groups. To indicate that a group of controls does not
- Don't place controls in group box caption.
- Don't disable groups. To indicate that a group of controls does not
currently apply, disable all the controls within the group, but not
the group itself.
- Put a :doc:`splitter` between aligned grouping controls.
......@@ -37,6 +37,6 @@ Appearance
~~~~~~~~~~
- Label the group box with a descriptive caption.
- Do not assign an access key to the group box caption.
- Don't assign an access key to the group box caption.
- Set the group box or frame shadow to 'flat' to provide the consistent
spacing required to convey relationship.
......@@ -21,7 +21,7 @@ Is this the right control
- Use command links for a set of mutually exclusive responses like
navigation from hub to spoke pages.
- Do not present single command links.
- Don't present single command links.
- Consider to use a :doc:`push button <pushbutton>` for single commands
or if the action does not contain navigation.
......@@ -31,7 +31,7 @@ Behavior
- Provide feedback when result is not aware to user or not available
instantaneous. Display a busy pointer or present a progress bar to
users.
- Do not mix command links and command buttons at one place.
- Don't mix command links and command buttons at one place.
Appearance
~~~~~~~~~~
......@@ -42,4 +42,4 @@ Appearance
- Icons should have a size of 48x48 pixels.
- Choose a concise, self-explanatory label that clearly communicates
and differentiates what the command link does.
- Do not use ellipsis.
- Don't use ellipsis.
......@@ -9,7 +9,7 @@ It is normally hidden from view (except :doc:`menu bars <menubar>`) and drops
down when the user right-clicks on something.
Context menus should be considered accelerators for advanced desktop users.
Many mouse users do not think to right-click on things. The right-click gesture
Many mouse users Don't think to right-click on things. The right-click gesture
required to show a context menus can be difficult to perform on many laptops,
and it is flat-out impossible on a touch device.
......@@ -22,7 +22,7 @@ Is this the right control?
- Provide a context menu for any item with actions that can be performed on it.
- Provide a context menu for common actions like 'Copy' and 'Paste' for
textual controls, or navigation actions like 'Forward' and 'Backward.
- Do not use context menus as the only way to access functionality. Every item
- Don't use context menus as the only way to access functionality. Every item
in a context menu must be available via a method that is somehow visible by
default--typically the app's main :doc:`menu bar <menubar>`, but also
via toolbar buttons.
......
......@@ -26,7 +26,7 @@ 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
- Don't 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 <../assistance/tooltip>` or a
......@@ -36,18 +36,18 @@ Is this the right control?
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
- Don't apply dialog boxes that require the use of a scroll bar.
- Don't include a menu bar or status bar in dialogs.
- Don't 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, Do not apply or the like) if the dialog
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
- Don't use dialogs to display non-critical messages which Don't
require any further user interaction (typically dialogs with a single
"OK" or "Close" button). Consider to use
:doc:`tooltip <../assistance/tooltip>` or a
......@@ -76,7 +76,7 @@ Appearance
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
- Make sure there is at least one third white space, Don't overload
the panel.
- Consider the common reading direction from left to right and top to
bottom.
......
......@@ -79,7 +79,7 @@ The main menu
- 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.
Don't use the Menu Drawer for navigation purposes.
|desktopicon| Collapsible
"""""""""""""""""""""""""
......
......@@ -25,22 +25,22 @@ Is this the right control?
- Menu bars are optional for simple apps that are able to expose all
functionality using visible buttons and toolbars. If any functionality is
not visible by default, err on the side of providing a menu bar.
- Do not display a menu bar in secondary or internal windows, like the
- Don't display a menu bar in secondary or internal windows, like the
settings dialog or file dialog. Very small main windows are likewise usually
poor candidates for menu bars.
- Do not include a menu bar in a convergent application's mobile user
- Don't include a menu bar in a convergent application's mobile user
interface.
Behavior
~~~~~~~~
- Do not have more than nine menu categories within a menu bar. Too
- Don't have more than nine menu categories within a menu bar. Too
many categories are overwhelming and makes the menu bar difficult to
use.
- At the minimum, all windows should have File, Edit, Settings, and Help menus.
If they apply, the window can also have View, Insert, Format, Tools and,
Window menus.
- Do not put more than 12 items within a single level of a menu. Add
- Don't 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.
- Assign shortcut keys to the most frequently used menu
......@@ -49,7 +49,7 @@ Behavior
result in menu items automatically receiving consistent names, icons, and
shortcut keys. Any tool or function that is accessible using a keyboard
shortcut must have an item in the menu bar so that users can discover it.
- Do not hide the menu bar by default. If this is configurable, users should
- Don't hide the menu bar by default. If this is configurable, users should
easily be able to make the menu bar viewable again.
- Use submenus cautiously. Submenus add complexity to the interface and
are physically more difficult to use, so you should take care not to
......@@ -58,14 +58,14 @@ Behavior
Appearance
~~~~~~~~~~
- Place the most frequently used items at the top of the menu.
- Provide icons for all menu items. Do not re-use the same icon for multiple
- Provide icons for all menu items. Don't re-use the same icon for multiple
items.
- For your menu items' text, follow the
:doc:`general label guidelines </style/writing/labels>`.
- Do not change menu items' labels dynamically.
- Don't change menu items' labels dynamically.
- Choose single word names for menu categories. Using multiple words
makes the separation between categories confusing.
- Disable menu items that do not apply to the current context instead
- Disable menu items that Don't apply to the current context instead
of removing them from view. **Exception:** It is acceptable to hide menu
items completely if they are permanently unavailable on the user's system
due to missing hardware capabilities.
......@@ -75,7 +75,7 @@ Appearance
Rename) and ctrl key for large-scale effect (Ctrl+S = Save).
- For menu items that toggle some state on or off, always use the positive
form. For example, use the text 'Show hidden files' instead of 'Hide hidden
files', and do not change the text when hidden files are shown.
files', and Don't change the text when hidden files are shown.
Code
----
......
......@@ -24,10 +24,10 @@ Command Button
^^^^^^^^^^^^^^
- Use a command button to initiate an immediate action.
- Do not use a command button for navigation to another page (prefer a
- Don't use a command button for navigation to another page (prefer a
:doc:`link <commandlink>` in this case).
- Do not use a command button embedded in a body of text.
- Do not use command buttons for a group of actions. Consider to use
- Don't use a command button embedded in a body of text.
- Don't use command buttons for a group of actions. Consider to use
radio buttons with one 'Apply' option or a menu button.
Menu Button
......@@ -49,7 +49,7 @@ Menu Button
set of related functions.
- Indicate the menu by a single downward-pointing triangle.
- Clicking the button will drop down the menu only.
- Do not use the delayed menu button pattern.
- Don't use the delayed menu button pattern.
Split Button
^^^^^^^^^^^^
......@@ -75,29 +75,29 @@ Behavior
- Buttons are not dynamic: their icon and label should not change
depending on the context (except special split buttons).
- Do not initiate an action on right-click or double-click.
- Don't initiate an action on right-click or double-click.
- Provide feedback when user is not aware to results or when results
are not available instantaneous. Display a busy pointer or present a
progress bar to users (see :doc:`progress indicator <../assistance/progress>`).
- Denote the relationship between buttons with other controls by
placing them logically together.
- Do not use the delayed (menu) button pattern.
- Don't use the delayed (menu) button pattern.
Appearance
~~~~~~~~~~