Dialog Design - Representation at the Interface

1Gabriel Spitz

Dialog Design -Representation at the Interface

Lecture #13

Gabriel Spitz 2

Activity Flow or Interaction

DesignDialog Design Visual DesignConceptual

Design

User Interface Design Process

Gabriel Spitz 3

Dialog Design• A Dialog is the means by which the UI enables a

user to specify how a given task should be performed

• During Dialog Design we translate the task flow into a dialog flowo A set of one or more windows required to perform the

task• Thus Dialog Design focuses on implementing

each UI task identified in the Activity Flow

Gabriel Spitz 4

Dialog Design Objective

• The objective of Dialog Design are:o To guide and manage the task flowo To adapt the task flow to the realities of the interface

• E.g., Activity Flow for a Security Clearance application might ask the user to specify all the places a person ever worked at. This can be along list

------------------------------------------------------------------------------------

Work History

Work History 2-22

Work History 23-45

Work History 45-60

------------------------

------------------------

------------------------

OK OK OK OK

A BVS.

Gabriel Spitz 5

Representation

• Representation is an important element of Dialog Design

• It is concerned with the content of the dialog• If we imagine a dialog to be a sentence, than

Representation are the individual words making up the sentence

Gabriel Spitz 6

Behavior to Represent

CommandsVS.Options

Gabriel Spitz 7

What is Representation (1)

• Representation is the choices that a designer make in:o selecting control typeso conceptualizing iconso specifying labelso composing instructions to support a function or an object at the interface

Gabriel Spitz 8

Representation - Example

Gabriel Spitz 9

What is Representation (2)

• Representation is concerned primarily with the nature of the choice rather then its implementationo For example should a command to get out from a

process be labeled ; Exit, Close, Finish, OK, OR MAYBE kill

• Implementation of the selected choice will be discussed later when we talk about Presentation

Gabriel Spitz 10


Gabriel Spitz 11


Gabriel Spitz 12

Representation - Examples

• The controls in the previous examples were all:o Supporting a single task/function – date pickingo They differed in terms of how the user had to specify a

date o They also differed in terms of

• The type and intensity of (cognitive) demands placed on the users

• Speed of task performance • The likelihood of making an error

Gabriel Spitz 13


What are the cognitive demands associated with each control?

Gabriel Spitz 14

Impact of Representation

• The choices a designer makes in selecting a control, specifying a label, or instruction at the interface can:o Impact task performance – e.g., speed, errorso Users’ workload – e.g. memory, calculationo Users’ satisfaction

Gabriel Spitz 15

Effective Representation

• A representation of an item that is:o Compatible with users characteristics

o Suitable for a specific task and usability goals within a given context and culture

o Compliant with published standards and guidelines

• There is significant overlap among the above elements

Gabriel Spitz 16

Effective Representations

• Effective representations from a user perspectives are those that are:o Easy to remembero Easy to interpreto Easy to use

Gabriel Spitz 17

Effective Commands

• Easy to interpretFor Example:

VS.

• For Slideshow in Power Point for the Mac

Gabriel Spitz 18

Examples of Poor Representation Decisions

Gabriel Spitz 19

Dynamic Menus

• Objective is to reduce menu size and complexity• Often confuses users because menu items appear

at different locations• OK in some circumstances, e.g.

o lists, e.g., recently opened fileso Adding menus when users move from one context to

another

Gabriel Spitz 20

Dynamic Menus

Gabriel Spitz 21

Commands are only on Toolbar

• Menu bars o Are organized hierarchically o Teach/communicate structure of application

• Toolbarso Are for most common actionso Are not used by some userso Should be optional

Gabriel Spitz 22

Duplicated Menu Items

• Commands that are functionally the same and appear in more than one menu can impact usability

• Even more problematic is when the same command has different names o E.G., Exit and Close

• Such duplication can hinder performance and slow learning down

• But OK while developing prototypes, to see where a command would best fit

Gabriel Spitz 23

Confusing Primary and Secondary windows

• Primary window: likely to remain open long time; never modalo Main application window must be a primary window.

• Secondary window: usually temporary & often modal (blocking input to other windows)o Dialog boxes must not be minimizable nor have a menu

bar.

Gabriel Spitz 24

Primary/Secondary Window

Same functionality using different types of window

Gabriel Spitz 25

Confusing Checkboxes and Radio buttons

• Radio buttonso 1 choice from N,

• where N > 1 • usually, N 8; e.g., COM1, COM2,

o Binary• {yes, no}, {true, false}, or {on, off}

o Independent choices• e.g., (for text)Underline, Shadow, Emboss, etc.,

Gabriel Spitz 26

Checkboxes and Radio buttons (2)

Some checkboxes should be radio buttons- e.g., Strikethrough & Double strikethrough

Gabriel Spitz 27

Confusing Checkboxes and Radio buttons (3)

Problem: sometimes independent choices aren’t quite independent

Gabriel Spitz 28

Using a Checkbox for a Non-ON/OFF Setting

• Sometimes we use a single checkbox when there are only two choices, e.g., red vs. green, ascending vs. descending

• Problem is that user has to infer the meaning of not checking the box

• Contextual: what’s the difference between o yes/no o ascending/descending

Don’t ask me againFor example:

Gabriel Spitz 29

Using Command Buttons as Toggles

• “command button” = “pushbutton” and should invoke some actiono If label doesn’t change, then user confused as to what

action to expecto However, if label does change, then does it describe

• current state or• what will happen if pressed• e.g., does “Stop” describe current situation or what

will happen if button pressed?

Gabriel Spitz 30

Using Command Buttons as Toggles

Gabriel Spitz 31

Abuse of Text Fields

• Do not use text fields for read-only datao Confuses user

• is it text to be altered? • temporarily grayed out? • or always read-only?

o Use a label field instead• Using plain text field for formatted input

Gabriel Spitz 32


We suggest no specific format, but expect one

Gabriel Spitz 33


• Use multiple fieldso Instead of (415) 555-1221 as one field, enter it as three.o For time, use hours, minutes, seconds, and AM/PM if 12-

hour format (but only as many as appropriate).• Better:

o Free-format fields o Intelligent programming to figure out the data, no

matter how it was entered.o E.g., Microsoft Outlook’s handling of phone fields.

Gabriel Spitz 34

Abuse of Dropped Down List Boxes

Over compensation that borders on user abuse

Gabriel Spitz 35

Mixing Control and Content Buttons

• Dialog box control buttons are, e.g., OK, Apply, Close, Cancel, HelpRelate to the activity associated with the dialog box

• Content control buttons are, e.g.,Add, Delete, Set, …Relate to the content of the dialog box

Gabriel Spitz 36


Gabriel Spitz 37


• Clear mapping of buttons’ effects• Separate area for window control buttons

Gabriel Spitz 38

Misusing Group Boxes

• Variationso Group box around one settingo Group box within group boxo Only one group box within window

Gabriel Spitz 39

Misusing Group Boxes

Documents

Dialog Design - Representation at the Interface