Guidelines for Dialog Boxes Development
Dialog boxes are designed for data input/output to/from user in comfortable, secure and readable manner. They could be displayed in modal or modeless mode. Modeless mode allows a user to switch between other windows and dialog boxes. Modal mode blocks any user input to parent window as well as sibling dialog boxes, for instance it keeps from main menu item selection. In case application actively utilizes both modal and modeless dialog boxes, it is important to give attention to their collaboration and dealing with other applications' objects. Modal dialog box is considered that it is designed well if its contents are expected and natural, and meet the requirement of ergonomics.
There are a list of guidelines, intelligent adherence to it allows to arrange usable dialog boxes.
Guideline 27. I guess this guideline is the most important. Keep user interface as simple as possible. Accompany each dialog box by help system. This is adding of 'Help' menu item to dialog system menu (Alt+Space) that opens help file for application at respective page with article about current dialog box (figure, description, usage, tricks, etc.). This is question-mark-button in minimize-maximize/restore-close buttons group. When user clicks it, a question-mark appears near the cursor and window with respective description that shows when user has clicked on any dialog box control/element. User has the right to know why one or another control is disabled. In that case, you should provide information in status line or pop-up tool tip. If any input to control is not allowed, inform user about this and offer variants how to handle this problem or explain why it would be better to forbear from changing this value. Provide so much in-place information or valuable references as possible. There are a lot of software products in the market. Customer makes decision to use product or not over a period of an hour, maximum, it is one day. Supposition that users will read a lot of manuals and help-files is strategically wrong, they won't. User starts to work with the thought that he already mastered the application. If he does not understand something, he wants to get quick short-spoken answers. If the software does not respond to his questions, it goes to Recycle Bin. Dialog box (and Application in general) must be robust and easy-to-operate, and easy-to-master.
Guideline 01. You have to consider the user as the stupidest and laziest human that even could be. It is a strategical mistake to believe that something "is obvious", "everybody knows that", "even kids can understand this", - they won't! Keep level of your product audience as low as possible.
Guideline 02. If you intend to use dialog box for just informational purposes or to obtain short 'yes-no-answers' quickly, it would be to use standard MessageBox. User knows how to deal with it, therefore choice will be made quickly and without any difficulties. Advise is to determine icon relatively to message content in every message box. Use this type of dialog box in single occurrence (I mean avoid queues).
Guideline 03. You don't have to consider that your application is the only application which the user is dealing with. Therefore, embed standard elements to graphical user interface frequently instead of different delicacies. Exception to the rule is interface of game or some multimedia product. It is good practice to keep in mind that other programs utilize dialog boxes actively as well. And user is familiar with controls of those boxes and as appears she has some expectations about their functionality. And she has some opinion about usability of graphical user interface.
Guideline 04. This guideline is sequent of the previous one. It is wasting time and money to create refined graphics for business-user. Also, please, avoid ingenious labels for buttons like a 'U r right', 'w8t', 'You r the BOSS!!!', and other non standard utterance and especially slang.
Guideline 05. Do not consider user screen resolution and color quality. Dialog boxes must have size lower or equal to 800x600 (640x480, or even smaller if there are too old PCs or end device has a small screen). Exceptions to the rule are games, of course, and custom applications for special enterprise where information about minimum screen resolution is available. It would be 1024x768, for instance. Controls with painting elements (like charts) must be tested with different color qualities.
Guideline 06. It is good to use modal mode for dialog box, with title that could be used to move window at new location. Possibility to change size is good if it increases handy of dialog box, if it's all the same then it would be better to make fixed window size, or at least to set its maximum size. And in all cases when sizing window is applied, it is good practice to set minimum size that allows to save dialog box usability. If you chose modeless dialog box nevertheless, it is good to make it as singleton.
Guideline 07. This guideline is sequent of the previous one. In case you granted user possibility to change window size and window position, she will do that how it comes into her head. And result size and position will consider it handy. So it would be a good idea to restore size and position that the user has chosen. Else user loses her temper each time she resizes and moves dialog box, or she will refuse this possibility. In any case, saving and restoring of user preferences will increase end user satisfaction.
Guideline 08. It is a rule to have two menu items 'Move' and 'Close' in system menu. In case window is resizable, the third menu item 'Size' is added. You can ensure quickly that your application supports this feature by clicking Alt+Space. Other items are optional. All menu items must perform any action in response to click at it. In case action failed, it is good practice to inform about this via message or status line. Else silence will confuse user and this will incline user to think that application is not working.
Guideline 09. There are two types of controls at dialog box area: input-output controls and user conformation controls (like 'Ok' and 'Cancel' buttons). It is preferable to make the same size and appearance for controls of second type, and to arrange them together. By the way, it is good practice to follow after only style for look and feel of all application UI elements. There are two main approaches to arrange controls at form. First is when editors occupy top and center parts of form while conformation controls are arranged in one row at the bottom, and the second is when all input-output controls are located at left-center part of form while buttons are lined up in one column. Keep empty remainder of space near conformation controls.
Guideline 10. Arrangement of conformation controls in column at right side of form is more commonly used. It is so because you may put buttons in column more than you may put them to row (with the same size). In any case, you chose it is good practice to follow this choice further in all applications. It makes application GUI more friendly and allows end user to spend a bit of time for searching of proper control at dialog box.
Guideline 11. Arrange controls in order in accordance with importance of edited information. Most significant controls must go first, less valuable controls (especially dependent ones) go after them in descending order of information they represent.
Guideline 12. Effect of Guideline #11. When all controls are at form and dialog box design is completed, it is time to set (or revise) tab order. Tab number is assigned accordingly to adding of control at form. This order is not coincided with natural order in general. Tab order must be arranged to increase dialog box usability. Arrange tab order in accordance to which user deals with form. There is a main principle below. Input fields must be first in queue, then confirmation button (OK), then cancel button, then others.
Guideline 13. Only visible for user control may get a tab focus. Focused control must be always in visible zone. If focus goes out of form, it will confuse the user. So if tabbed control is out of visible zone, scroll form to make it visible.
Guideline 14. If number of controls is too high, do not pile them up - make use of pages of tab control. Group controls in smaller groups and put them in a separate page. Sort confirmation buttons as well. Buttons that are related to controls of group only must be put the respective tab. Controls that manage whole dialog box behavior must be accessible under any tab chosen.
Guideline 15. Keep in mind that user can choose tabs in any order. Consider tabs just as form extension, therefore controls could be chosen in any moment of time and in any sequence.
Guideline 16. If order of controls traversing is important and its collection depends on options user chose, you should arrange dialog in form of a Wizard. It allows to divide task at parts and to guide user while collecting information.
Guideline 17. If application starts any actions with irreversible results (like one-way data transformation) after user has pushed the button, that button must have a meaningful label - verb represented action. For instance, if disk burning starts (if user cancels this action, disk could be lost) after user pushed the button, that button must be labeled as 'Burn' to call user's attention to the following application actions.
Guideline 18. Location of dialog box must be natural or traditional. New tool box must appear in the top part of application screen where other tool boxes are located (or where tools panel is located, I mean place any other than from top. Left part, for instance), status line must appear at the bottom. Other dialog boxes must be centralized accordingly to application screen, more critical ones must be centralized accordingly to desktop. It helps to find them quickly. If this is modeless (or dockable) dialog box, it must be arranged near object it related, but do not overlap important information. Great example is 'Find' dialog. It moves over a screen to make visible searching text. This is a sign of respect for user's data and user's time.
Guideline 19. Dialog box should have a default button. It is a synonym for 'Enter'-key pressed. It makes possible close dialog box with confirmation quickly without use of mouse. At the same time, dialog box should have a button that cancels input. And that one must be associated with 'Esc'-key pressed. It makes it possible to close dialog box without use of mouse as well but with telling user has cancelled input. In general, confirmation button is 'Ok', cancelling one is 'Cancel'.
Guideline 20. Application must handle any of the following events correctly: user clicks 'Cancel'-button, user presses 'Esc'-key, and user clicks 'criss-cross' at top right corner of form. It is especially important in case cancelling requires performance of some additional actions. Good practice is handling of cancelling in form closing event handler if proper actions are in running state. You may act so because closing of form is losing control under process, thus it would be better to terminate (cancel) it. Otherwise, if process must still run, provide additional button like 'Perform in Background'.
Guideline 21. If control does not have any label, accompany it by label control and put control destination text into its label-buddy. This label must be implemented to switch focus at its buddy as soon as it takes a focus. In most of IDE, it is enough just to set to label tab order previous to control tab order.
Guideline 22. It is handy when it is possible to switch input focus in arbitrary order. This performs with aid of accelerators. Underlined letter in button label indicates possibility to set focus at this button using that key (in general this is combination of 'Alt+key'). In case control has not got a label, like a text edit, accompanied label consists of an underlined letter that is accelerator for such control. Developer assigns accelerator inside of control label using & sign, '&OK', for example. As an alternative to underlining, you may put accelerator letter into round brackets at tail of description.
Guideline 23. There are standard controls for editing of most data types. Thus create custom controls in special cases only. Microsoft products (or any software leader in OS for which you implement solution) are great sources for ideas. It is a drop-down with tree control instead of list, for instance. There is a big temptation to implement it like classic drop-down-list control, but this is too complex and could add bugs to your program, implement drop-down window just as modal dialog box with tree control, 'Ok' and 'Cancel' buttons at it like Microsoft did that. In case you added some non standard behavior for control (like drag-and-drop feature), take care to keep user informed about it (put the note below such control).
Guideline 26. If dialog box serves for editing some entity, its controls (entity attributes) must be initialized by respective data after loading. In case this entity is new, the general recommendation is to initialize fields by default values where it is possible. These default values can depend on current context. The best practice is to delegate this default initialization to default entity constructor (or one with any set of parameters) and then to take data from created object. Such practice reduces code duplication and indicates robust development.
All these guidelines do not pretend to be some standard or rules. But your dialog boxes will be more user friendly if you stress them by provided guidelines. And your application will have more satisfied users.
History
- 20th February, 2010: Initial post
