Menus, Forms, and Dialog Boxes
(Based on Shneiderman Chapter 7)
[ lecture notes | CSC 397 | Pete Sanderson | Computer Science | SMSU ]
Table of Contents
Overview
The World of Menus
Organize for Task Support
Menu Layout
Menu fast select and response time
Form Fillin
Dialog Boxes
Resources
Chapter 7 of Designing the User Interface Third Edition, by Ben Shneiderman.
Human-Computer Interaction 2nd edition, by Dix, Finlay, Abowd, Beale, Prentice Hall Europe, 1998.
Overview.
Menus and forms considered "attractive alternatives" to DM. Why?
- low mental load (recognition, not recall)
- attractive to novice or intermittent users
Their use does not guarantee appealing and easy to use UI!
Shneiderman definitions:
- Menu: any selection from list. Quite a broad definition.
- Form fillin : collection of data entry fields (paper form as metaphor)
- Dialog box : device to organize menus and forms
Return to the Top
The World of Menus
How many kinds can you name, based on Shneiderman definition?
(pulldown, popup, check box, command buttons, radio buttons, www links, toolbar, palette, . . .).
A tour through MacWrite and Word 97 revealed a large number of techniques.
Return to the Top
Organize for Task Support
M,F,and DB should be designed and organized to support user tasks.
Some menu organizations include:
1. single menu: two or more items simultaneously available.
- There are semantic variations (e.g. single vs multiple item selection, state vs. command).
- There are many different styles (buttons, radio buttons, icons, numbered list, scrolling list, toolbars, palettes, embedded links in web page)
2. linear sequences and multiple menus: guided sequence of choices (such as Wizard)
- Guides user through complex decision making by presenting one decision at a time.
- Possible alternative to dialog box.
3. tree-structured menus: requires classification into mutually-exclusive categories
- such classification may not be feasible (do not use in that case)
- uses abstraction to handle large numbers of choices
- selection speed depends on:
- logical organization (grouping, breadth vs depth)
- terminology (get from task domain),
- user knowing what name to look for
- Breadth (number of items per list) is preferred to depth (number of levels) -- tradeoff. Many empirical studies confirm this.
- Each layer of depth increases chances for disorientation and error (offset with menu map)
- In designing groupings, follow these guidelines:
- create groups of logically related items
- make sure groups cover all possibilities (leave no gaps)
- make sure items do not overlap
- use domain terminology
- each item has distinctly different label
4. acyclic and cyclic menu networks:
- use if appropriate,
- beware that disorientation occurs more easily than with tree.
- Provide orienting information (distance from main, position in network).
Return to the Top
Menu Layout
Menu Item Sequence:
- Some possibilities include:
- chronological ordering
- numeric ordering (ascending or descending)
- alphabetical order
- usage frequency order (most frequent first)
- importance order (most important first)
- subgroups of functionally related items (separate by space/line)
- One cannot categorically say that one of these is better than another. Depends on what items represent, user familiarity with items and task
- All studies show that dynamically adaptive ordering is no good -- surprises the user.
- If ordering by frequency, let user determine when to update order!
Menu Item Names:
- terminology should be familiar to expected user audience
- terminology should be consistent across items
- names and phrases should be clearly distinct from each other
- if phrase, place keyword first (leftmost)
- item phrases should be concise
Other layout guidelines:
- Menu titles should be left- or center-justified
- Menu tems should be left-justified
- Consistency, consistency, consistency!!
Return to the Top
Menu Fast Select and Response time
Fast select through:
- Shortcut keystrokes and key combinations
- Bookmarks
- Macro facility to record menu selection paths (hierarchical)
Response time is how long for system to respond to menu selection.
Can affect menu organization :
- longer response time should lead to fewer levels of menus
This had all but disappeared as an issue until the Web!
Return to the Top
Form Fillin
- For entering several items or groups of related items concurrently.
- Existed long before bitmapped displays and DM.
- Attractive due to metaphor: paper form.
Here are some Shneiderman guidelines for designing such a form.
- Give form a meaningful title
- Group related fields
- Separate groups with space.
- Uniformly distribute and align fields/groups on form.
- Match screen form layout to paper form (if data entry from paper)
- Use concise instructions in command form ("Type the address.").
- When instructing user to type normal characters, use "type".
- When instructing user to type control keys, use "press".
- Use the word "enter" only to refer to Enter key.
- Use familiar and consistent terminology for field labels.
- Allow easy movement between fields (tab, arrows)
- Prevent input errors (through e.g. list selection)
- Allow easy error correction
- Use concise error messages in familiar terms
- Show error messages only after erroneous field value complete.
- When cursor is on field, provide explanation in standard place.
- Use coded fields as appropriate
(e.g. for ss#, supply dashes and skip forward automatically)
- Mark optional fields and place them at end if appropriate
- Explicit completion signal (e.g. Submit or OK button)
There are many more guidelines, concerning use of graphics, color, multiscreen, etc., which are not addressed here.
Return to the Top
Dialog Boxes
What is the difference between a form and a dialog box? According to Dix, et al :
- forms used primarily for data entry
- dialog boxes primarily for system messages and subdialogs.
Direct quote from Dix et al: "Dialog boxes are information windows used by the system to bring the user's attention to some important information, possibly an error or a warning used to prevent a possible error. Alternatively, dialog boxes are used to invoke a subdialog between user and system for a very specific task that will normally be embedded within some larger task."
Dialog boxes range from very simple (click OK in response to message), to quite complex (e.g. Word 97 Font specification, or Open dialog).
Shneiderman relates dialog boxes to menus and forms:
"Dialog box design combines menu-selection and form-fillin issues with additional concerns about consistency across hundreds of dialog boxes and relationship with other items on the screen."
Some guidelines for designing menus also apply to dialog boxes.
Most guidelines for designing form fillin also apply to dialog boxes.
Dialog boxes pop up in front of other UI info, so:
- Box should appear close to relevant information without obscuring it.
- Box should be moveable
- Box should be as small as possible without being cramped.
- Box should be clearly distinguishable from background
- Box should not be too visually annoying or disruptive
- Use standard buttons (OK, Cancel, etc) to lessen mental burden.
Return to the Top
[
lecture notes | CSC 397 | Pete Sanderson | Computer Science | SMSU ]
Last reviewed: 2 November 1998
Peter Sanderson ( pete@csc.smsu.edu )