To report a found bug,
please, select the text with the bug and click Report a Bug or
CTRL+ENTER.
Help
system 10.4 of 09/07/2024,
©
FORESIGHT
Article number: KB000020
Using control lists is an effective and efficient way of upgrading software quality. Using these lists for an interface does not require expensive procedures like usability testing.
This is an absolute control list, that is, all items do not require subjective answers and evaluations (like "navigation is implemented well"). Thanks to this fact, anyone can check if an interface complies with the controls list. The examiner does not have to be specially trained. On the other hand, an absolute list is certainly incomplete.
You also need to take into account that no control list can ensure that an interface is really good. At best, a list ensures that an interface does not contain any gross errors.
Text of all buttons that initialize operations contains infinitive form of a verb (for example, search), and not the other part of speech, or verb form (for example, finished). You can assign the text OK to a button only if it cannot house a verb.
There should be whitespace between neighbor buttons, clicking which is not handled.
No different buttons' states look the same.
Unavailable commands do not disappear from the screen but become locked.
Frequently used buttons are provided both with a text and an icon, seldom used buttons used have only text.
Modal dialog boxes do not include the Apply buttons.
Text of buttons that require entering additional information should end with ellipsis.
Edit boxes already contain the most probable values (default values).
If a numeric value is entered into an edit box, a tooltip shows the value range.
If a numeric value from a limited range is entered into an edit box, this box has buttons that are used to change the value (the SpinEdit, IntegerEdit, FloatEdit components).
The length of edit boxes is not less (and where possible not more) than the length of the data to be entered.
If a box is used to enter a significant amount of text, the box is to be multiline.
Multiline edit boxes have the maximum possible height, it cannot be increased.
The lists already contain the most probable values (default values).
If a list includes 50 elements or more, a filter or search mode is used.
There are no frequently used short lists (less than 5 elements); these lists are presented as groups of radio buttons or checkboxes.
List width cannot be less than width of its elements.
List elements are sorted: based either on their structure, that is, on general characteristics, or on the frequency of used (the list with less than 7 elements) or in alphabetical order).
If a list includes more than 50 elements sorted in alphabetical order, the first three elements displayed are the most frequently used elements. They also appear in their alphabet positions.
Multiline lists with multiple choice have checkboxes next to each element.
The height of multiline lists is 4 lines or more.
Advanced comboboxes are used instead of single-line boxes if there is enough space (for example, the dialog box for font selection).
If a group contains 10 or more checkboxes, an extra checkbox is added to select or deselect all checkboxes.
At least one radio button within a group is selected by default.
Radio buttons and checkboxes within a group are positioned one under another.
When a dialog box contains only a set of radio buttons and buttons closing the box, double-clicking a radio button selects it and closes the dialog box.
Drag&Drop mechanism should be implemented for the list that allow for moving elements.
Basic operations: Add (INSERT), Delete (DELETE), Edit (ENTER, double-click).
Deleting groups of elements should be implemented if possible.
Label size should be enough to display required text.
A sufficient size of a text label should be increased by 3 DLU to house the whole text when using large font sizes because rounding errors are possible.
The NoWrap property should be set to TRUE for single-line labels.
When the system finishes a long operation (that takes more than one minute), it makes a beep noise using PC speaker.
If direct manipulation is not used in the interface, the system does not have its own cursors. If the direct manipulation is used, own cursors are used only when there are no appropriate analogs in the operating system.
In data-entry forms values are checked for validity during the input; if incorrect data is being entered, the system immediately informs the user without waiting for finishing the data entry.
The messages indicating that the entered data is incorrect are displayed next to the control containing invalid data.
Text of messages on data ill-posedness do not say that a mistake has been made. On the contrary, it only informs the user on acceptable data types and formats.
Text of an error message includes the following three parts: the first part briefly outlines the problem, the second one offers the solution and the third part says how to avoid this problem in the future.
Status messages (Synchronization completed successfully) are displayed only in the status bar.
Pressing the TAB key in input forms allows for moving around the form, while pressing CTRL+TAB allows for switching between the tabs if there are any.
Form processing is started either by clicking the finishing button or by pressing the ENTER key.
Hotkeys are assigned to most frequently used controls (including menu items).
An ALT combination (underlined) is assigned to each menu item.
ALT combination and hotkeys are standard.
If there are more than 40 hotkeys, you can use interface to change them.
Press the TAB key to go from one element to another within a form from top to bottom and from left to right.
Shadow direction should be the same for all controls: at the bottom right.
Color indication is not the only method. If this kind of indication is used, the system is provided with another type of indication.
For long-term operations (more than one second) a progress bar should be displayed with a text that describes the purpose of the operation. If possible, progress bar is to be displayed. The text should not contain words like "Running" or "Executed" but only description of the purpose of an operation (for example, "Opening object" or "Saving", and so on).
Icon groups should not contain icons similar in color and shape.
The system does not have icons with standard values but non-standard scenes.
Icons do not contain any text.
Icon sets contain icons with the same purpose but of various sizes. The icons have the same features and/or scenario.
Resizable windows have size indicators.
Window titles correspond with the names of controls using which the windows are opened. If a window is called by a control with no explicit name, the window title displays the name of the data entry form.
Window type (modal, non-modal, with or without minimizing and maximizing) was chosen deliberately, in accordance with users' tasks.
Dialog boxes do not have menus or toolbars.
Apply buttons are used only in palette windows (instead of OK buttons).
Controls should be correctly aligned relative to each other.
A dialog box should support scaling if there are no valid reasons for the opposite. Controls in resizable dialog boxes should be correctly scaled. Modified window sizes should be saved in the registry.
When a dialog box opens, the main control is to be focused. If it is impossible to define the main control, the one at the upper left corner should be focused.
The system should support closing a window on pressing the ESC (operation is canceled) and ENTER (operation is executed) keys provided that a focused control does not handle these keys.
Pressing the F1 key should open help for an active window.
All windows and dialog boxes in the system as well as all tabs if there are any should have a unique class identifier used for calling context help.
Have an icon that differs from other icons of top-level windows.
A toolbar has a name that describes its functions.
All buttons are provided with an icon and a tooltip.
Text of menu commands that require entering additional data to complete operation should end with an ellipsis. Use the ALT+0133 code to enter the "…" character.
The View menu window should include the Toolbars submenu, which displays the list of main window toolbars. The toolbars may be displayed and hidden. This submenu should also include the Settings item (at the bottom of the menu) that opens a standard toolbar setup dialog box.
Clicking the right mouse button over toolbars area of a window should display a pop-up menu with the same options as the View > Toolbars menu.
All toolbar buttons should have corresponding functions in the menu.
Location of panels when a window is opened for the first time should be convenient, intuitive and compact.
Docking a panel in an appropriate area of a window should be prohibited.
The View menu for each side panel should contain a command with the name of the side panel that allows displaying and hiding this panel. Commands for various panels of a window should be combined into a group.
Panel layout should be correctly maintained between user sessions.
A title should include names of an object and a system block.
When closing a window the system should display a dialog box to confirm saving changed data: Yes/No/Cancel.
The status bar displays information on the current status of the system and buttons (that do not look like buttons) of functions meant for advanced users only.
Progress bars are displayed in the status bar. Exception: in master windows progress bars can be displayed within windows.
Menu items should start with an uppercase letter.
All items of the top level menu have drop-down lists.
No more than two submenu levels should be used.
Menu icons are used only for most frequently used elements.
Elements opening submenus look different than terminal elements.
Menu items for the operations unavailable at the moment should be disabled. Items of the top level menu cannot be disabled.
If possible, all objects displayed in an interface have specific popup menus.
Context menus include maximum ten items.
Context menu items are sorted in decreasing order of frequency of their usage.
All items of context menus are included in other areas of the interface, there are no commands that can be executed only using a context menu.
Groups of interactive elements (form fields, radio buttons, and so on) have maximum seven elements.
The Cancel button is always the rightmost.
Multi-page forms are indicated as such. The user can always see how many pages are left. For example, "Screen x of y".
If a form contains several buttons, one of the buttons is used as a default one. Hazardous buttons are not selected as default buttons.
Operations resulting in possible data loss must be executed only after they are confirmed by the user. Format of a message to confirm operation with a single object: "Are you sure you want to <operation> <object>?" "Yes/No". Format of a message to execute operation with multiple objects: "Are you sure you want to <operation> objects (<number of objects> )?" "Yes/No".
If there is free space in the window, termination button looks larger than other buttons.
Buttons are positioned in the area which they directly influence.
Termination buttons (buttons controlling the window) are positioned either at the bottom in a row or at the right in a column.
Buttons affecting a whole tabs block are positioned outside the block.
If the contents of a window or a tab is automatically augmented, for example, this is a list of incoming messages, the name of the interface element that opens this window or tab displays the number of objects in this window and the number of new objects. For example: Documents (8/3)".
Menu items and buttons that require additional actions of the user have an ellipsis (...) at the end. Examples: the Save As option requires an ellipsis because the user should select file name, while the About element does not require an ellipsis because the window to be opened does not have independent interface elements.
Captions of interface elements are placed uniformly.
Unavailable interface elements are disabled and not hidden.
Interface cannot include controls without any functions.
All forms used to collect information should contain the following options: Other and Not Applicable or similar.
All required fields are marked and contain appropriate comment.
All forms for collecting data have description of data collection purpose, an explanation how the data should be processed.
All main interface elements have tooltips, which text describes the result of using these elements.
Slang expressions are not used in interfaces.
Negative wording is not used for interfaces. For example, you cannot use the Do Not Display Comments checkbox. Use the Display Comments checkbox instead.
No element can have different names in different parts of an interface (interface glossary is created in explicit form and verified).
Text of all confirmation messages contains the name of the object, with which the operation is executed.
To improve the readability, long numbers are separated with system thousands separator. For example: 1 234 567.
Each element of a list ends with a point or starts with an uppercase letter according to the rule: Text of all elements starts with an uppercase letter. All elements end with the last letter of a word without any punctuation marks, except for the last element which ends with a point. Exception: if at least one list element contains more than one sentence, all elements start with an uppercase letter and end with a point.
Each list is preceded by at least one text paragraph.
In tables all columns containing numeric data are right-aligned.
A point at the end of a phrase is not used in titles (if they are separated from the text), at the end of a label under an image and in tables.
Text labels for interface elements start with an uppercase letter and end with a colon.
Size of controls and their layout should allow for translating interface to other languages (primarily, English).
When text labels are aligned to the right edge, the text of these labels is also aligned right.
Interface control list / Usethics [In the Internet] // usethics.usability testing and interface designing. - Usethics, 11/28/2005 - http://www.usethics.ru/lib/software_checklist.html.
See also: