How to Find Problems

With the basics out of the way, I'll now list a number of issues related to dialog boxes to help you avoid most dialog box problems.

General Appearance

  • Check the dialog box sizes When displayed in VGA mode (640 × 480), a dialog box should be no larger than 640 × 460 (saving 20 pixels for the taskbar) so that it can be displayed in all video modes.
  • Check the arrangement and flow In Western cultures, people read from left to right and from top to bottom, so make sure that the more important information is on top and to the left. The upper left corner receives the most attention.
  • Check the alignment In general, left alignment should be used to make user interface elements easier to scan. Decimal alignment or right alignment should be used for numeric text. Avoid center alignment and right alignment for nonnumeric text. Everything doesn't have to be centered or made symmetrical. Prefer having white space on the right side and bottom instead.
  • Check the grouping Related user interface elements should be grouped to show relationships. Related information should be displayed together and controls should be placed near the objects acted upon. White space, group boxes, lines and labels, or other separators should be used to group related user interface elements.
  • Dialog boxes used as secondary windows should not have title bar icons, menu bars, toolbars, and status bars Secondary windows must not appear on the taskbar, since clicking on a primary window taskbar button also activates any secondary windows. Secondary windows should not have the complexity to warrant a menu bar, toolbar, or status bar. Title bar icons are used as a visual distinction between primary windows and secondary windows. Also, the default Windows icon (the flying window icon) should never be used as a window icon.
  • Check the title text Ellipses should not be used in dialog box title text. For example, a dialog box that is displayed as the result of choosing the Print Options… command should have the title Print Options. An exception is to indicate that a command is in progress, such as with "Connecting To The Internet…" The title of a Properties property sheet should include the word Properties.

General Usability

  • Check the defaults Are there appropriate default values for the fields in the dialog box? Having default values makes the dialog box easier to use and makes it less likely that the user will make mistakes. The default value that is most likely to be right should be used based on how the setting is actually used. Often the best default is the last setting that the user input. A dialog box with many empty controls is tedious to use.
  • Make sure modal dialog boxes are really modal Make sure that all modal dialog boxes that have parent windows supply the correct parent window handle instead of a NULL handle. (Note that the correct parent handle is automatically supplied when using MFC.) If the parent window handle isn't supplied, the parent window is still active, so the dialog box really isn't modal.
  • Check the default button Is the default command button selected correctly? The default button should not be one that initiates an irreversible or destructive action, unless the user has another way to correct mistakes.
  • Check the input focus Make sure that the initial input focus is on the control that is most likely to be used first.
  • Check the Help Review the online Help for helpfulness. Does the Help explain the dialog box? Does it answer any questions you have? Is there a Help button? Do the F1 and Shift+F1 keys work?

Navigation

  • Check the keyboard navigation Test the dialog box using the keyboard alone. Is it easy to use? Does the Tab key move among the controls in a sensible and orderly manner? Is the tab stop attribute assigned to all controls that should have it? Is the tab stop attribute not assigned to controls that shouldn't have it? Do the arrow keys move among controls in a sensible order? Do the arrow keys get stuck on a control or leak out of a group?
  • Check using the mouse Test the dialog box using the mouse alone. Is it easy to use? If the dialog box has edit boxes, could they be replaced with other controls that don't require typing, such as spin boxes, combo boxes, lists, and radio buttons?
  • Check the access keys Try accessing all controls with access keys. Does each control that could possibly be accessed with an access key have one assigned? Are the access keys unique? Are access keys assigned that don't do anything? Is the tab order correct so that each static text label access key activates its associated control? If possible, avoid assigning an access key to a lowercase g, j, p, q, or y, or to a character immediately preceding or following one of these characters. The underline doesn't look right against the character's descender.

Main Command Buttons

  • Check the command button separation Are the main command buttons separated from the main body of a dialog box? Main command buttons are command buttons such as OK, Cancel, Close, Help, Stop, Hide, and other related buttons. This separation makes the main command buttons easier to find and identify.
  • Check the dialog box orientation In Western cultures, people read from left to right and from top to bottom, so main command buttons are easier to find if they are on the bottom or right. The dialog box orientation chosen should make the aspect ratio of the dialog box more similar to the aspect ratio of the screen, which is typically 3 units high to 4 units wide. This makes the dialog box appearance more comfortable and easier to position on the screen. Position the command buttons on the bottom if they have different sizes.
  • Check the command button alignment Are the main command buttons placed on the bottom right-aligned? Right-aligned main command buttons follow the left-to-right flow. You might want to make an exception by centering the main command button when there is only one.
  • For modal dialog boxes, check the OK and Cancel buttons For modal dialog boxes, are OK and Cancel buttons provided? To use a dialog box, the user needs to be able to easily identify how to move forward (with the OK button) and backward (with the Cancel button). The OK button can be replaced with a more specific command, but never replace Cancel in a modal dialog box, except with Stop to indicate that the effect of an operation in progress cannot be cancelled.
  • For modeless dialog boxes, check the Close button For modeless dialog boxes or dialog boxes used as primary windows, is a Close button provided but not OK and Cancel buttons? Using OK and Cancel for a modeless dialog box or primary window makes the dialog box appear to be a modal dialog box. Furthermore, OK and Cancel are not meaningful when used in a modeless context. Use Close instead to eliminate any confusion.
  • Check the button order Is the OK button first, Cancel second, and Help last? OK or its equivalent should always be the first main command button. Cancel should be to the right of or below OK. The OK and Cancel buttons should be placed next to each other. The Help button should be the last button. If there is no OK button, the Cancel button should be just before the Help button. This makes the main command buttons easier to find and identify.
  • Make sure the OK and Cancel buttons are labeled correctly The OK button should be labeled OK, not Ok or OK. The Cancel button should be labeled Cancel, not Cancel or CANCEL.
  • Make sure the Cancel button really cancels The program state should be exactly the same as it was before a modal dialog box was displayed. If not, the Cancel button should be replaced with a Stop button. Make sure that the Cancel button in the body of a modal dialog box has the same effect as the Close button on its title bar. Property sheets are an exception, since the Cancel button doesn't cancel or undo changes that have already been applied.

Controls

  • Check the control sizes Are the controls consistently sized, especially the command buttons? Command buttons with text labels should have a minimum width of 50 dialog units (1095 twips in Microsoft Visual Basic) and a standard height of 14 dialog units (375 twips in Visual Basic). The static text control sizes should be large enough so that they can display their text in all video modes.
  • Make sure invalid controls are disabled Make sure controls that don't apply in the current program state are disabled.
  • Check for unnecessary scroll bars Will scroll bars be eliminated from list boxes, edit boxes, or combo boxes if you make the control slightly larger? If so, making the control larger will make it easier to use.
  • Always give combo boxes, list boxes, list views, tree views, edit boxes, and sliders labels Labels are necessary to identify what the control is for.
  • Check for bold text Bold text should be used sparingly. Bold text was used in Windows 3.1 dialog boxes to draw disabled text on old video hardware (that is, dithered gray). Since modern video hardware can draw gray text without dithering, Windows now uses normal text in dialog boxes for a much cleaner look. Bold text should be used only for emphasis. Most dialog boxes should not use any bold text.
  • Check that edit box widths suggest the size of the expected input The width of an edit box should be a visual clue of the expected input. For example, if the user is entering an address, a State field that is about two characters wide clearly suggests entering a two-character state abbreviation. If the expected input has no particular size, a width that is consistent with other edit boxes or controls should be used.
  • Check the static text labels for colons Colons should be used to clearly indicate that the static text is a control label. Labels used to give supplemental information about a control should not have a colon, such as labels used to interpret a slider control. Colons are also used as a clue by screen readers.
  • Check the justification of static text labels Left justification gives the labels an organized look and makes them easy to scan.
  • Check the use of ellipses An ellipsis in a command indicates that more information other than a simple confirmation is required to carry out the command. An ellipsis does not mean that a dialog box follows.

Details

  • Check the error handling Enter invalid input when possible. Is there feedback? If there is an error message, does it make sense? Is it necessary? Could the interface prevent the error from happening? Could different control types be used to prevent invalid input?
  • Review the dialog box templates Are the window styles, such as WS_POPUP, WS_CAPTION, and WS_SYSMENU, applied consistently? Is the same font used consistently?

I admit that there's a lot to check in this list. However, once you master this list you can make sure your dialog boxes are correct while you create them, enabling you to review them rather quickly during the QA process.



Developing User Interfaces for Microsoft Windows
Developing User Interfaces for Microsoft Windows
ISBN: 0735605866
EAN: 2147483647
Year: 2005
Pages: 334

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net