About Face 2'0

1
About Face 2.0
Section Three Interaction Details Part VI
Controls and Their Behaviors

• Chapter 25 Window Behaviors
• Chapter 26 Using Controls
• Chapter 27 Menus The Pedagogic Vector
• Chapter 28 Using Menus
• Chapter 29 Using Toolbars and ToolTips
• Chapter 30 Using Dialogs
• Chapter 31 Dialog Etiquette
• Chapter 32 Creating Better Controls

Next
Then
And
2
Dialogs

• Dialog boxes are superimposed over the main
  window of the parent program
• Dialogs engage the user in a conversation
• Offering information
• Requesting input
• When the user has finished viewing or changing
  the information presented, he has the option of
  accepting or rejecting his changes
• The dialog then disappears and returns the user
  to the main program

3
Dialogs Break Flow

• Dialog boxes support the main program
• They are NOT the main interaction, they support
  it
• They break the flow in the main interaction
• They make the user react to the program instead
  of driving it
• They take control away from the user
• Put primary interactions on the primary window
• But, dialog boxes are appropriate for many
  interactions
• Secondary, brief interactions
• Dialogs break flow

AXIOM
AXIOM
4
Dialog Boxes are Often Appropriate

• Use dialog boxes for
• Functions or features out of the mainstream of
  interaction confusing, dangerous, or rarely used
• For example, things that make immediate, gross
  changes to the screen imagedislocating actions
• Presenting infrequently used functions and
  settings
• Providing a richer context than a toolbar for
  presenting options and explanations
• Concentrating information related to a single
  subject
• Encapsulate and separate it from other functions
• Note that menu items often lead to a dialog
• Dialog boxes serve frequent user AND learner
• Compact, powerful, speedy, smooth
• AND clear and self-explanatory

5
Dialogs Support the Structure Principle

• Note how the dialog box is a way to enforce the
  structure principle (put related things together
  and separate unrelated things)
• Related keep on primary window
• Unrelated moving to a dialog logically separates
  from main flow and logically groups the elements
  of the dialog

6
Dialog Box Basics

• Most dialogs have buttons, comboboxes, and other
  controls
• Selection and layout driven by the needs of the
  interaction
• All dialog boxes have an owner
• The application that created it or the system
• Obscures the application window, but other
  windows can obscure the dialog, too
• Must have at least one terminating command
• General OK, CANCEL, and window close butcon
• Even when the application will automatically
  close the dialog (e.g., a status), should offer a
  user terminating command, too
• Optional title/caption bar
• Optional window sizing and positioning mechanisms
  (frame)

7
Modal Dialog Boxes

• Once the modal dialog comes up, the owning
  program cannot proceed until the dialog box is
  closed
• Stop what you are doing and deal with me now.
  When you are done, you can return to what you
  were doing.
• So, what the user was doing had better require
  the dialog to proceed
• The idiom may be abused, but its meaning is clear
• The user can interact with other programs, but
  not the owning program
• Never create a system modal dialog box
• They stop all applications
• Function-oriented dialog boxes deal with the
  entire program or the entire active document
• Process- or property-oriented dialog boxes
  operate on the current selection

DESIGN TIP
8
Modeless Dialog Boxes

• Once the modeless dialog comes up, the owning
  program continues without interruption
• Modal dialogs are easy to understand do me now!
• The scope and operation of modeless dialogs is
  often unclear
• When modeless dialogs operate on a selection, the
  user can change the selection while the modeless
  dialog is still visible
• Select something then change it, select something
  else then change it,
• Example MS Words Find and Replace dialog
• Drag objects between the dialog and the
  application window
• Tool or object palettes in drawing programs, for
  example
• Modeless dialogs must be conservative in using
  screen real estate

9
Modeless Dialog Issues

• Modeless dialogs are visually very close to
  modeless, but they are functionally very
  different ? confusion
• User assumes a dialog is modal
• Modal dialogs can be created reflecting a
  specific selection in the main application
• Modeless dialogs must change on the fly to
  reflect different selections
• Are the range of changes consistent for the range
  of selections?
• Should options gray out, disappear, freeze, etc.?

10
Modeless Dialog IssuesEvolutionary Solution

• Visually differentiate modeless dialogs from
  modal dialogs
• Distinctive background or border hue or pattern,
  distinctive butcons, distinctive shape,
  distinctive caption bar, colored stripe across
  corner, etc.
• Give modeless dialog boxes consistent terminating
  commands
• A CLOSE button in the same location on all
  modeless dialogs
• Consider using the Close box on the title bar
• OK and CANCEL have confusing meaning on modeless
  dialogs
• But it is even more confusing to try to change
  the captions
• Never dynamically change the labels of
  terminating buttons
• Consider replacing CANCEL with UNDO
• If activating a function closes the dialog, use a
  modal dialog, instead

DESIGN TIP
DESIGN TIP
DESIGN TIP
11
Modeless Dialog IssuesRevolutionary Solution

• Use floating toolbars as the visual mechanism for
  modeless dialogs
• Can dock to the side so they do not cover the
  content underneath
• Gray out butcons for options not available for
  the current selection
• Things that behave differently should look
  different
• Floating toolbar looks and behaves differently
  than modal dialog box

12
A Floating Toolbar (and Modeless Dialog?)
Note how the dialog control values reflect the
selected text
13
Is This a Well-designed Modeless Dialog?
It is big, it obscures the text it is to search,
its button labels are unclear, Make this part
of the main window surface!
14
Goal-Directed Dialog Boxes

• Four varieties of dialog box
• Property dialog box
• Function dialog box
• Process dialog box
• Bulletin dialog box

15
Property Dialog Boxes

• Present the user with the settings or
  characteristics of a selected object
• Enable the user to change those characteristics
• Can be modal or modeless

Why not use the font to show the font name in
both places?
16
Function Dialog Boxes

• Control a single function like printing,
  inserting or spell checking
• Usually invoked from the menu
• Usually modal
• Allow configuring the launched actions behavior
• For example, which pages to print, number of
  copies to print, printer options, etc.
• OK button finishes configuring and launches action

• Do not rename OK to the action name
• Keep consistently-named terminating button
  captions
• Instead, use dialog title or add text hint
• Note also the drop-down on the button

17
Process Dialog Boxes

• Always issued unilaterally by the program
• Indicate to the user that the program is busy
  with some internal function
• That the program has become stupid
• Often reflect hardware limitations
• Slow access to peripherals and networks
• Long computations
• Example File copy or Download status
• The program must inform the user when they are
  about to become unresponsive
• Animated wait cursor hinting is not sufficient in
  multi-tasking systems
• Put a progress bar in the applications main
  window (instead of a process dialog box)

DESIGN TIP
18
Process Dialog Boxes

• Four tasks of a process dialog box
• Make clear to the user that a time-consuming
  process is happening
• The existence of the process dialog box does this
• Make clear to the user that things are still
  operating normally
• Animation, such as flying paper in copy operation
  or a turning crank in a compute operation
• Make clear to the user how much more time the
  process will take
• Progress meter (relative to time, not task size)
• Provide a way for the user to cancel the
  operation
• Make clear whether cancel will undo the whole
  operation, or preserve whatever change has
  already occurred
• If the latter, also provide an undo
• Instead, provide two buttons CANCEL and STOP

19
Bulletin Dialog Boxes

• Always issued unilaterally by
• the program
• They serve the program
• Do they also serve the user?
• Or do they anger the user or make them feel
  stupid?
• Example error or confirmation message box
• Caption name of issuing program
• Brief text capturing the message
• If an error, a graphic icon indicating the type
  or severity of the error
• OK or Help button
• Never use transitory dialogs as
• error messages or confirmations

DESIGN TIP
20
About Face 2.0
Section Three Interaction Details Part VI
Controls and Their Behaviors

• Chapter 25 Window Behaviors
• Chapter 26 Using Controls
• Chapter 27 Menus The Pedagogic Vector
• Chapter 28 Using Menus
• Chapter 29 Using Toolbars and ToolTips
• Chapter 30 Using Dialogs
• Chapter 31 Dialog Etiquette
• Chapter 32 Creating Better Controls

Next
21
Basic Etiquette

• Property and function dialog boxes come at a user
  request
• It is appropriate that they be large,
  front-and-center
• Bulletin and process dialog boxes come at system
  request
• They should be compact and not obstruct the main
  view
• Better yet, avoid them altogether
• Strategies for removing bulletin dialog boxes are
  in Chapters 33 (Eliminating Errors) and 34
  (Notifying and Confirming)
• Put progress information in the main window

22
Title Bar

• All dialog boxes should have title bars
• Dialog boxes should be movable
• The title bar enables this
• Title bar name
• Use verbs in function dialog title bars
• For function on selection, use verb-object, where
  the object is the selected item
• Format Font for This is selected text
• Use object names in property dialog title bars
• Properties for ltselected itemgt

DESIGN TIP
DESIGN TIP
DESIGN TIP
23
Transient Posture

• Dialog boxes should look and behave like
  transient programs
• Bold, visual idioms, bright colors, large buttons
• AND dialog boxes must not waste screen real
  estate from the underlying sovereign application
• So, Dialog boxes should be as small as possible,
  but no smaller
• Slightly larger controls, and no wasted space

DESIGN TIP
24
Reduce Excise

• Dialog box should remember where it was last
  placed (geographic placement) and return there
• Dialog box should remember their last state and
  restore those
• Selected tabs, property settings, input field
  values, etc.
• Make sure the dialog is, indeed, needed
• Dont ask me if I want to save after I just saved
• Dont post bulletins that a function completed
  normally
• Dont offer me options when I always make the
  same choices

25
Terminating Commands on Modal Dialogs

• Offer OK and CANCEL buttons on all modal dialog
  boxes
• OK accept changes, then close and go away
• CANCEL reject changes, then close and go away
• Bulletin dialogs reporting errors only need OK
• Process dialogs only need CANCEL
• Never use terminating words in dialogs
• For example, Cancel Reservation? is confusing
  does the CANCEL button cancel the cancellation?
• Use Remove the Reservation?

DESIGN TIP
DESIGN TIP
26
Terminating Commands on Modal Dialogs

• Make the OK and CANCEL buttons be immediately
  identifiable
• Geographically and visually separate from other
  buttons
• Do not line them up with other buttons
• Always in the same place
• OK always in lower right and CANCEL immediately
  to its left
• Dont put close boxes on modal dialogs
• Does close mean OK or CANCEL?
• A HELP button is not a terminating command
• Can be put with terminals
• Better to be placed on the title bar

DESIGN TIP
27
Keyboard Shortcuts

• Provide keyboard shortcuts to bring up often-used
  dialogs
• Find CtrlF and F2
• Replace CtrlR and F3
• Also provide shortcuts or mnemonics for
  often-used settings in a dialog

28
Tabbed Dialogs

• Dialog is organized into overlapping panes, each
  with an identifying tab
• By convention, tabs are across the top (more
  usable that way)
• Pressing a tab brings that pane to the
  foreground, hiding the others
• Allows monocline grouping (most users dont
  understand hierarchies)
• The contents of the panes must logically belong
  together
• Since all panes are the same size, some will have
  wasted space
• Terminating the pane or the whole dialog?

Put terminating buttons on the untabbed area of a
tabbed dialog
DESIGN TIP
29
Stacked Tabs

• Stacked tabs tabs in more than one row
• The selected tab must be on top, so when
  selecting a back tab, it must be moved to the
  front
• Thus re-organizing the layout of tabs
• ? confusion
• Moving the whole row helps, but is it enough?
• Consider grouping the tabs into separate dialogs,
  instead
• All idioms have practical limits
• Stacked tabs, too many radio buttons, etc.
• Dont stack tabs

AXIOM
DESIGN TIP
30
Expanding Dialogs

• Expanding dialogs unfold to expose more
  controls
• Avoids exposing the beginner to too much
  complexity
• Insults the beginner and hides their discovery of
  the programs features
• Hassles the experts if they have to repeatedly
  open up the details

31
Expanding Dialogs

• Find and Replace dialog in MS Word
• Remembers the state it was last in and reopens in
  that state
• So the expert is not hassled with having to
  continuously open from the default beginner mode

32
Cascading Dialogs

• Button on one dialog brings up another dialog
• Hierarchy
• What is the scope of the terminating commands?

Would an additional tab be better?
33
Dynamic Dialogs

• Dynamic dialogs change and adapt their suite of
  controls based on user input
• Example a database access programs sequence of
  selections
• Select server ? list of databases on the server
• Select a database ? list of tables in the
  database
• Select a table ? add user/login controls to the
  dialog
• Example customize toolbars
• Different user selections in the left pane change
  the commands in the right pane

34
About Face 2.0
Section Three Interaction Details Part VI
Controls and Their Behaviors

• Chapter 25 Window Behaviors
• Chapter 26 Using Controls
• Chapter 27 Menus The Pedagogic Vector
• Chapter 28 Using Menus
• Chapter 29 Using Toolbars and ToolTips
• Chapter 30 Using Dialogs
• Chapter 31 Dialog Etiquette
• Chapter 32 Creating Better Controls

Next
35
Creating Better Controls

• Controls pack lots of complex user interaction
  behavior into a ready-to-use package
• Use them because they work, not because they are
  easy
• If they dont solve the problem, find/create a
  better answer
• Opportunities for rich direct manipulation,
  drag-and-drop behaviors, validated input, etc.
• Show dont tell use pictures, not words
• Huge list of ActiveX controls, Java Beans, etc.,
  are available
• Some of those in my default VisualBasic
  installation

• Document readers (Acrobat, HTML, RTF,
  multi-media, etc.)
• Browser
• Database query, forms, etc.
• Structure browsers
• Image browse/view

• Calendar
• Chart
• Speech
• Mail services
• Network access
• Complete applications as OLE objects

36
Better ControlsExamples from Cooper and Reimann

• Direct manipulation removes the need for bounded
  entry controls
• Dragging an objects shadow
• Draggable grid intervals
• Extraction controls that are smart about the
  format and semantics of text edit fields
• Extract form fields from free text entry (mailing
  address, proper name, email address, phone
  number, etc.)
• Visual controls
• Layers palette in Adobe Photoshop (see Figure
  32-2, p. 430)
• Controls on next slide
• Need to integrate the controls into the main
  window, rather than as separate dialogs
• Need toolkits to ease this programming task

37
Visual Controls
In Windows 95, you could click on the map and the
time zone would highlight and scroll to the
center. This no longer has a clickable map! Why?