CSE 8316 User Interface Design Rob Oshana Southern Methodist University.

CSE 8316User

InterfaceDesign

Rob OshanaSouthernMethodistUniversity

Interaction Styles

Agenda• Windows

• Files

• Storage and Retrieval Systems

• Menus

• Forms

• Dialog boxes

• Typed command languages

Introduction

• Interaction Style: A collection of interface objects and associated techniques from which the designer chooses

• Provide behavioral view for user communication

• These objects are implemented with widgets/toolkits

• This implementation falls in the constructional domain

Steps to good GUI design

1. Know your client

2. Understand the business function

3. Understand the principles of good screen design

4. Develop system menus and navigation schemes

5. Select the proper kinds of windows

Steps to good GUI design

• 6. Select the proper device based controls

• 7. Choose the proper screen based controls

• 8. Write clear text and messages

• 9. Provide effective feedback and guidance and assistance

Steps to good GUI design

• 10. Provide effective internationalization and accessibility

• 11. Create meaningful graphics, icons, and images

• 12. Choose proper colors• 13. Organize and layout windows and

pages• 14. Test, test, and retest

Windows

History

• Xerox PARC - Apple Mac

• Contributed many things–mouse– rectangular window– scrollbar– push button– desktop metaphor– pull down menus

PARCs Principles

• Modes– confusing and frustrating

• Overlapping Windows–metaphor of overlapping sheets on desk

• Tiling–more than one application on the screen

Description

• Window: Screen object that provides basis for other interaction objects

• All interaction occurs through the window

• Two types:– Primary: The first window for an application,

acts as ``parent'' for other windows – Secondary: Created from primary. Include

such objects as dialogue boxes

Window Name

Control menubutton

Window borderTitle bar

Client area

Maximize buttonMinimize button

Window Name

Title bar

Client Area

Sizing grip

Close buttonWindow border Minimize buttonMaximize button

Standard window decorations

Key:P = Primary windowD = Dialog windowM = Message window

= Interaction not allowed

= Interaction allowed

Modeless

P

D D

M

App A App B

P

D D

M

ApplicationModal P

D D

D D

M

App A App B

P

D D

D D

M

SystemModal

P

D D

D D

App A App B

P

D D

D D

M

D DD D

M

Interaction restrictions in modeless and modal windows

Interaction restrictions in modeless and modal windows

Unnecessary Rooms

• Should not add windows to our program unless they have a special purpose that can’t or shouldn’t be served by existing windows

• A dialog box is another room. Have a reason to go there

• Build function controls into the window where they are used

Necessary Rooms

• When providing a function out of the normal sequence of events, provide a special place to perform it

• Examine the users goals

• Don’t put every function in a dialog box

Windows Pollution

• A gallon of oil won’t make a bicycle pedal itself

• No way to show the connections between lots of windows–modal dialogs don’t count; they always get

you back immediately to the point of departure

• Tools make it easy to make lots of windows and boxes

Guidelines

• Don't overuse windows–Minimize window manipulation needed – Give user flexibility to move and resize – Tiled windows give better user

performance, but require more area

• Appearance and behavior of primary window should be consistent– Primary is user's home base

• Use different windows for different independent tasks – Allows one-to-one mapping to be set up

in mental model – Completion of task equates to

completing window

Guidelines

• Use different windows for different coordinated views of the same task – Permits examination from different

perspective or detail – All views should be updated uniformly

to prevent inconsistency between windows

Guidelines

Files

Tragedy of the file system

• Most difficult to understand

• Main memory and disk storage confusing

• Programs stored in two places at once

• Putting might on will; user might say no but will probably say yes

Problems caused by disks

• Disks and files make users crazy

• Influence of the file system on the user interface is deep

• We still render the implementation model to the user

Problems caused by disks

• Behavior characteristics applied based on real world metaphor– only one document– it belongs to the user

• Implementation model violates most of these

• Disk drive is the book shelf• Main memory represents the hands doing

the editing (copy is made!)

Dispensing with the disk model

• “Put the book back on the shelf” instead of “Save changes”

• Structure commands according to the goals of the user instead of according to the needs of the operating system

• Change “file” to “document”

Designing software with the proper model

• Treat documents as single instances instead of copies - unified file model

• Save automatically at intervals– countdown clock– noticeable delay– wait til the user stops typing to save

Designing software with the proper model

• Closing

• Does not map well to unified model

• Required knowledge of file system

Designing software with the proper model

• Rude error message for something that a user should be able to do

Archiving

• No explicit function for making a copy of or archiving a file

• Must use the “save as” function

• Not very clear

• “Save as” dialog is the wrong tool for making and managing copies

Unify the file model

• If the file system is going to show the user a file that cannot be changes because it is already in use, this should be indicated to the user– special color or icon

• Pull a hammer out of the toolbox only to look inside and find another hammer!!

Document Management

• Goal directed functions– creating a copy of the document– creating a milestone copy of the document– naming and renaming the document– placing and repositioning the document– specifying a stored format for the document– reversing some changes– abandoning all changes

How did we get here?

• From a user’s point of view, there is no reason for a disk to exist

• Advantages for the engineer;– disks are cheaper than solid state memory– once written to, disks don’t forget when

the power is off– disks provide a physical means of moving

information from one computer to another

How did we get here?

• Drawbacks– slower than solid state memory– less reliable with many moving parts–more space and power– CPU needs help to access– processing more complex

• Mainly a cost issue

Storage and Retrieval Systems

Storage vs. Finding

• In the real world, storing and retrieving are linked

• Not so in the digital world

• Storage system; a tool for placing goods into a repository for safekeeping

– physical container– tools necessary to put objects in and take

them back out again

Storage vs. Finding

• Retrieval system; method for finding goods in a repository– logical system that allows the goods to

be located according to some abstract value• name• position• aspect of contents

Storage vs. Finding

• Real world retrieval indices– author– subject– title

• We ignore these in the computer world– where we put them– what we named them

Storage vs. Finding

• Books can also be identified by– color– shape

• Location may change– bookshelf– coffee table– night stand

• We don’t find a book by referring to its contents!!

Retrieval Methods

• Positional retrieval; remembering where you left it

• Identity retrieval; remembering its identifying name

• Associative retrieval; remembering some inherent quality of the document

Indexing

• Libraries used Dewey Decimal system because names can be too disparate or insufficiently unique– good approach to storage

• Card catalog helps in retrieval

• Libraries provide three indices– author

– subject

– title

Indexing

• Each index is associative– allows the user to find the book

according to an inherent property of the book other than its identifying number or its location on the shelf

• Retrieval is done by looking up one of the indices, find its number, find the row of books, examine signs

Retrieval Systems in Computer

Retrieval Systems in Computer

An associative retrieval system

• Enables us to find documents by their contents

• Should know where documents can be found

• Create temporary or permanent groups of files

• Browse by synonym or related topic

• Assign attributes to files

Things to remember

• The program that created the file

• The type of document

• The program that last opened the document

• If the document is very large or small

• If the document has been untouched for a long time

• The length of time the document was last open

Getting Better

• SGML and XML

• OLE

• Unix standard file formats

Menus

Brief History

• Typing commands into a standard keyboard was once considered revolutionary

• Command line interface• Hard to know what to type• Still preferred today in some spaces• Modern complexity makes it hard to

use

Brief History

• Hierarchical menu in the late 70’s• User could forget many of the

commands and option details• Read information of the screen

instead of keeping it in your head• Very sequential in nature due to

batch nature of computers at the time

Example

• Enter transactions

• Close books for month

• Print income statement

• Print balance sheet

• Exit

1. Enter Transactions

• Enter Invoices

• Enter payments

• Enter invoice corrections

• Enter payment corrections

• Exit

Lotus 1-2-3• Revolutionary• Visible hierarchical menu• Took advantage of 1979 computer screens– 2000 characters/screen– 25 horizontal rows– 80 characters each

• Powerful because it enabled users to move in an ad hoc, piecemeal fashion, from beginner to expert

Monocline grouping

• Method of organizing things into a single layer of groups– simple and powerful (users mental model)– the method we use at home/office– never exceeds a single level of nesting

• Most users don’t like hierarchies– in a file cabinet you don’t see folders within

folders

Command types

• Command vector; each distinct technique for issuing instructions to a program

• Multiple command vectors - each function has– menu commands– toolbar commands– keyboard commands– direct manipulation commands

Migrating commands

• Immediate vectors– direct manipulation; immediate affect on

the information without intermediary • menus and dialog boxes don’t have this

– toolbar-button command vectors– no delay between pressing a button and

seeing the results of the function

• Most frequently used commands migrate to buttons on the toolbar

Menu commands

• Menu commands that have the advantage of natural language descriptions of the functions, and the detailed controls and data that appear on corresponding dialog boxes

• Menus and dialog boxes are the pedagogic vector

Menus

• Hard to first understand what a complex application can do

• We look at the menu

• Similar to a restaurant menu that we view at the entrance to get a feel for type, price, setting, etc

Menus must be complete

• Full selection of actions and facilities available in the program

• Hints that describe keyboard equivalents

Example

Description

• Menu: Object that provides a list of items from which one or more of the items are selected.

• One of the most popular, easiest to use interaction objects

• Promotes recognition over recall • Reduces typing errors • Wide assortment of styles

Structures of menus

• Single menus

• Sequential menus

• Simultaneous menus

• Hierarchical menus

• Connected menus

Single menus

• Single screen to seek input or request action to be performed

• Conceptually require choices from one menu only and no others will follow

• User only considers immediate consequences

• May be iterative – data entry

Single menus

Galitz, Essential Guide to User Interface Design

Sequential linear menus

• Presented in a series of screens possessing only one path

• Presented in preset order (may be problem if user wants a different order)

• Objective to specify parameters or for entering data

• Path may be short or long (long may become tedious)

• All important and require user action

Sequential linear menu

Galitz, Essential Guide to User Interface Design

Sequential linear menu

Simultaneous menus

• Instead of being presented on separate screens, all menu options are available simultaneously

• Menu may be completed in order desired by user• Choices can be skipped and returned to later• Tedium associated with long series of sequential

menus greatly reduced• Large collections of alternatives can clutter

screen – paging or scrolling may be necessary• Important to clearly indicate menu choice

relationships and dependencies (this can be confusing if not done right)

Simultaneous menus

Galitz, Essential Guide to User Interface Design

Hierarchical Menus

• When many relationships exist between menu alternatives, and some menu options are only appropriate depending on a previous selection, a hierarchical structure is the best solution

• This approach provides an increasing refinement of choice as menus are stepped through– Options to suboptions– Categories to subcategories– Pages to sections to subsections

• Represent with an inverse tree

Hierarchical Menu

Galitz, Essential Guide to User Interface Design

Hierarchical Menus

• Examples are menu bars with pull-downs• Web sites with navigation links• Order and structure of branching in a

hierarchy is preset• Normal order of flow is one way top down• Branching order may not fit user

conception of the task flow• May go down wrong paths

Connected menus

• Networks of menus interconnected in some manner

• Movement not restricted to a hierarchical tree – permitted between most or all menus in the network

• My be cyclical or acyclical (movement in only one direction)

• Gives user full control over navigation flow• For novice, complexity and navigation may

be daunting

Connected menu

Galitz, Essential Guide to User Interface Design

Event trapping menus

• Provide ever-present background of control over the system’s state and parameters while the user is working on a foreground task

• Serve three functions– Immediately change some parameter in the

current environment (bold text)– Take user out of current environment to

perform function (spell check)– Exit and allow user to go to new environment

(exit)

Event trapping menus

Paste option will only function if there issomething in a clipboard to paste

Suggested Menu Structure

Program Document Pieces Help

PropertiesViewsFunctionsAccess

PropertiesViewsFunctionsAccess

PropertiesViewsFunctionsAccess

Suggested Menu Structure

• Far left is the topic of broadest scope (program)

• Move to the right with diminishing scope• Submenus in descending order of

importance– properties– views of them– functions that operate on them– access to the “outside world”

Program Menus

• Default settings

• What templates are available

• What mode it is in

• Configuration of standard interface idioms like toolbars

• Personalization items like color and graphics

Document menus

• Covers document under construction• Prime menu items cover properties of the

currently active document• Views (draft vs presentation)• Functions that operate on the entire

document at once– calculating spreadsheets– formatting text

• Most recently used information

Pieces of the document

• Covers objects embedded in the document (tables or images)

• Only active when the particular object is selected

• Handles transformations like rotation, formatting

• Ability to load and save objects to/from other documents/disk

File Menu

mnemonics

accelerators

separator

MRU list

Pop up menu

• Used to present alternatives or choices within the context of the task

• Choices are context sensitive depending on where the pointer is positioned and when the request is made

Pop up menu

• Advantages • Appear in working

area• Do not use window

space when not displayed

• No pointer movement needed if selected by button

• Vertical orientation efficient for scanning and grouping

• Disadvantages• Existence must be

learned and remembered

• Require a special action to see the menu

• Items are smaller than full size buttons which slows selection time

• Display locations may not be consistent

Pop up menu guidelines

• Provide a pop-up menu for common, frequent, contextual tasks

• Items that cannot be chosen due to the current state of an application should not be displayed

• Continue to display pop-up until– Choice is selected– An action outside the pop-up is initiated– The user removes the pop-up

Iconic menu

Iconic menu

• Use to remind users of the functions, commands, attributes, or application choices available

• Create icons that– Help enhance recognition and hasten

option selection– Are concrete and meaningful– Clearly represent choices

Iconic menu advantages/disadvantages

• Pictures help facilitate memory of applications

• Large size increases speed of selection• Pictures consume more screen space and

difficult to organize for scanning efficiently

• Creating meaningful icons requires special skills and extended time

Menu System

• Standard menus– File menu– Edit menu– Windows menu– Help menu

• Optional menus– View menu– Insert menu– Setting menu– Format menu– Tools menu

Types

• Push-Button Menus – Choices are in terms of push-buttons,

sometimes called a button bank – Typically one of the selections is the default

and is highlighted in some way – Selection may be based on pointer object or

keyboard accelerators – Articulatory feedback is given – Need to label carefully and clearly -- shortness

of label versus clarity of meaning

Increase Scale Range Circle Range Radius

Push Buttons with Graphic and Text Labels

2X

Save Delete

Push Buttons with Text Labels

Options... Help

APush Buttons with Graphic Labels

Example push buttons with text labels, graphic labels,

or both

Types• Radio-Button Menus – Choices are exhaustive and mutually

exclusive, selecting one deselects another – Selection indicated by highlighted box – Typical for dialogue or property boxes

• Check-Button Menus – Like a radio-button menu, but more than one

item may be selected – Selections indicated by highlighted box, check

mark, etc

Menu Title_

Command

Dialog Window . . .

Submenu

Check Button 1

Check Button 2

Radio Button A

Radio Button B

Toggle On

Action

Routings

Settings(state toggles)

Settings(actiontoggle)

_

_

_

_

_

_

_

_

Examples of menu options in Motif

Name

SIF/DI

Short Name

FOTC TN

Call Sign

_

_

_

_

_

Indicator Label

Example radio button in MS Windows

Plain Text

Bold

Italic

Outline

Indicator Label

Example check box group in Motif

TDAs_

Route . . .

Intercept . . .

CPA . . .

DR . . .

Sailplan On

Unavailable

option

_

_

__

_

Example of unavailable menu option in Motif

Types

• Pull-Down Menu –Menu title is shown. When selected,

entire menu appears, selection is made and menu is hidden

– Since only title is permanent, provides compromise between pop-up and continuously displayed menus

– Selection may be done with one or more user actions

Edit_

Clear

Undo_

Cut_

Copy_

Delete__

Paste_

Ctrl+Z

Ctrl+X

Ctrl+C

Ctrl+V

Menuoptions

Menutitle

Example pull-down menu in MS Windows

Types

• Pop-Up Menus –Menu appears at location where mouse

is pressed – Unlike pull-down, there is no evidence

the menu exists – Contents may change depending on

location of cursor –Minimizes mouse movement and screen

real-estate

xterm Workspace Object

Remove from Workspace

Open Parent Folder

Rename

_

_

_

xx Pop-up menu

Example pop-up menu in Motif

Types• Option Menu – Appears much like a field in a form, but when

selected a menu appears – Distinct from pop-up since visual cue of

existence

• Toggle Menu – One choice is shown. – Clicking on item will sequence through all

possible choices – User is not presented with all choices at once

Font: Helvetica Font:

Chicago

Courier

Geneva

Helvetica

Palatino

Times

Optionbutton Option

menu

Bargraphic

Label

Example option menu in Motif

Edit

UndoCutCopyPasteClearDelete

Edit

Example menu button in Motif

Types

• Cascading Menus – Like a pull-down, however selecting one

choice brings up another menu – Helps group into hierarchical fashion – Visual clue to existence should be

provided – Requires more coordination than other

styles

Do this: Not this:

Organization of options in submenus

Types

• Pie Menus – Choices arranged as wedges in circle –Minimizes mouse movement over linear

list – Other aspects (such as radius or wedge

size) can be used

Types

• Palette/Iconic Menus –Menu consists of an array of icon push-

buttons. – Used for frequently chosen features or

in graphically oriented applications – Choice is indicated by highlighting icon

Types

• Embedded Menus – Menu items are highlighted/underlined text – Selecting text performs action – Also called hypertext

• Dynamic Menus – Menu contents change over time – Sometimes done by graying out selection

items

Map Options__

Predefined Maps . . .

World View

Recenter

Map Source

Map Intensity. . .

Map Manager . . .

Digital

WDBII

DTED

_

__

_

_

_

_

_

_

_

Submenu

Example submenu in Motif

Help

Window Name

_File Edit View__ __ _ _ _ _ _ _ _ _ _ _ _ _ _

Clear

Undo_

Cut_Copy_

Delete__

Paste_

Ctrl+Z

Ctrl+X

Ctrl+C

Ctrl+V

Tear-off button

Example tear-off menu in Motif

Help

Window Name

_File Edit View__ _

Undo

Cut

Copy

Paste

Clear

Delete

Ctrl+Z

Ctrl+X

Ctrl+C

Ctrl+V

Edit: Tear-off

_

_

_

_

_

_

Tear-offwindow

Example menu window in Motif

Guidelines

• Use the user tasks and system functions to organize hierarchical menus – Goal is three to four levels with four to

eight items per level – Can place tasks on paper and organize

into hierarchy to aid design

• Use meaningful groupings of menu choices

Guidelines

• Use meaningful ordering of menu choices – Orderings include alphabetical,

numerical or temporal, frequency – Not good to dynamically change

ordering

Guidelines• Use brief descriptions for menu choices – Single word is best – Otherwise begin each choice with same type of

word (noun, verb, etc)

• Use a consistent layout across all menus and keep the screen uncluttered – Should be covered in customized style guide

Guidelines

– Separate with white space, use consistent help messages

• Allow Shortcuts – Provide accelerator keys and macros

Other Design Tips

• Disable menu items when they are moot

• Parallel visual symbols on parallel command vectors

• Don’t use bang menu items

Parallel visual symbols

Tips for Creating Good Accelerators

• Follow standards

• Provide for their daily use

• Show how to access them

Forms

Description

• A series of labeled fields that are to be filled in by the user

• Intuitive interface, however free form typing is more prone to errors

• Various types of fields for forms

Field Types

• User-Typed Strings – Can have validated and invalidated – Validated fields should have some visual cue

• User Choices from a List – Toggle and option menus are good for this

situation

• Default Values for Fields – All fields for which values can be predefined

should have them

Types of Fields

• Required vs. Optional Values – Should have visual cue as to which is

optional and which required

• Dependent Fields – These are fields that are required if a

particular value is entered in another field.

Guidelines

• Use a consistent, visually appealing layout and content – Group fields and separate with white

space – Provide titles and concise instructions – Be consistent across different forms

Guidelines

• Do not assume that existing paper forms convert directly to screen designs and a good user interface – Paper forms frequently are not optimal – Good opportunity to evaluate purpose of

forms, involving users – Screen size versus paper is different. – Attempting to copy the form directly, but

changing some aspects can be confusing

Guidelines

• Use appropriate visual cues for fields on forms – Indicate maximum length, types of input

allowed, etc.

• Use familiar and consistent field labels and abbreviations – Field labels should be concise, using standard

terms – Labels should be located to the left of the field

with a simple delimiter

Guidelines

• Use logical navigation among fields – Arrow keys, return key, tab – Permit wraparound or direct access using

mouse

• Use logical navigation within fields • Support editing and error correction of

fields – Do no require entire field be replaced, but

rather permit changing of single characters

Guidelines

• Use consistent, informative error messages for unacceptable characters and values

• Provide explanatory messages for expected field inputs – Can be made available on user demand

or automatically provided. – If automatic, should be concise

Guidelines

• Provide default values in fields whenever possible – Fill in obvious fields, allow user to change – Can help describe format for input

• Provide a completion indicator for each form-filling screen – Give user control over when finished – Permit cancellation and ability to return to

partially completed form

Dialog Boxes

Description

• A rectangular, delineated screen area that is used for messages, text entry, commands, selection and user control

• May be initiated by user or system

• Temporary object that obscures part of screen

Suspension of Normal Interaction

• Dialog boxes are superimposed over the main window of the owning program

• Engages user by offering information and requesting some input

• After editing user has option of accepting or rejecting changes

• Dialog box then disappears

Suspension of Normal Interaction

• When the application presents a dialog box, it is temporarily moving the action out of the mainstream

• Taking the focus off the dinner party and into the kitchen for preparation of the food

• May be crucial but not the main point• Should be use for secondary interaction

Put primary action on the primary window

Dialogs break flow

Dialogs break flow

• Appropriate for functions or actions out of the mainstream interaction

• Good for presenting infrequently used functions and settings

• Well suited for concentrating information related to a single subject

• Serve two masters; frequent users and infrequent user

Dialog box basics

• All dialog boxes have an owner

• Always placed visually on top of the owning program

• Every dialog box has at least one terminating command– OK– Cancel

Modal Dialog boxes

• Most common• Once the box comes up, the owning

program cannot continue until the dialog box is closed

• It stops the proceedings• User can activate other programs

while the modal dialog box is up– dialog box remains indefinately

Modal Dialog boxes

• Easiest for users and designers to understand

• “Stop what you are doing and deal with me now! When you are done you can return to what you were doing”

• Like a subroutine call• Rigidly defined behavior

Modal Dialog boxes

• Function-oriented; operates on the entire program or document

• Process- or property- oriented; operates on the current selection

• Application modal; can only stop their owning application

• System modal; brings every program in the system to a halt (catastrophic conditions only!)

Modeless Dialog boxes

• Less common and more misunderstood

• Owning program continues to run without interruption

• Does not stop the proceedings

• Have terminating commands

• Scope of operation is often unclear

Modal Dialog box design tips

• Visually differentiate modeless dialogs from modal dialogs

• Give modeless dialog boxes consistent terminating commands

• Never change the terminating button captions

• Things that behave differently should look different!

Making modeless dialog boxes into toolbars

Typical state-of-the-art modeless dialog box

Property Dialog Box• Usually modal, but not uncommon to

find these modeless

Function Dialog Box

• Usually summoned from the menu

• Most frequently modal dialog boxes

• Control a single function– printing– inserting– spell check

Bulletin Dialog Box

• Most abused part of the interface• Error message box• Property and function dialog boxes are

intentionally requested by the user– they serve the user

• Bulletins are issued unilaterally by the program– they serve the program

Bulletin Dialog Box

Process Dialog Box

• Like bulletin in the sense that they are erected at the program’s discretion rather than users request

• Indicate that the program is busy with some internal function

• Alerts the user to the program’s inability to respond normally

• Warns the user not to be overcome with impatience

Process Dialog Box

• Single CPU systems require this to some extent– good at time sharing between software

tasks– once the hardware becomes involved

problems arise• accessing the disk• dialing up a modem

Process Dialog Box

Process Dialog Boxes• The program must inform the user when it

gets stupid• Four basic tasks– make clear to the user that a time-consuming

process is happening– make clear to the user that things are

completely normal– make clear to the user how much more time

the process will take– provide a way for the user to cancel the

operation

Process Dialog Boxes

• Process meter

Types

• List Boxes – Scrollable sequence of users choices – Contents are usually dynamic – Frequently search cability exists

• Entry Boxes – Allows user to enter data – May be one line (as in form field) or multi-line – Supports full editing

Airfields:

Chicago

Delhi

Dulles

Guam

Jakarta

Kuwait

Label

List Box

Example list box in Motif

Airfields:

Delhi

Dulles

Guam

Jakarta

Kuwait

London

Manila

Search for:

DE

Example list and text box used in an incremental

search in Motif

Chicago

Delhi

Dulles

Guam

Jakarta

Kuwait

ChicagoAirfields:ChicagoAirfields:

Label Textarea

Arrowbutton List

box

Example drop-down list box in Motif

Airfields:

Chicago

Delhi

Dulles

Guam

Jakarta

Kuwait

ChicagoLabel Text box

List box

Example combo box in Motif

Chicago

Delhi

Guam

Jakarta

Kuwait

DuAirfields:ChicagoAirfields:

DullesLabel

List box

Text box

Arrowbutton

Example drop-down combo box in MS Windows

Altitude (in feet):40000

LabelText area

Arrowbuttons

Example spin box in Motif

Types

• Message Boxes – Usually created by system (not at user

request) – Contains information from user and

allows limited interaction

Types

• Dialogue Boxes – Composite interaction object that contains

other interaction objects. – Typically part of user task sequence – Group various, related functions – Modal dialogues grab the user focus and

require the user to resolve before continuing – Modeless allows user to interact with other

window without finishing it

Drafter/Title:

TEST.MSG

Label

Text Box

_

Example text box and label in MS Windows

Date:

Distance:

Frequency:

SSN:

Miles

MHz

(YYYYMMDD)

Example text box labels providing format cues

Guidelines• Use brief but comprehensible instructions – Because of potential complexity of boxes,

instructions should be provided

• Use carefully worded messages • Use logical groupings and orderings of

objects in a box • Use visual cues to delineate groupings

within boxes • Keep layout consistent and visually

appealing

Guidelines

• Make defaults visually distinctive • Menu selections that lead to dialogue

boxes should contain a visual cue • Boxes should disappear under user

control – Windows that appear and disappear

``magically'' confuse the user – Exception is for boxes displaying status

information

Scroll bar shaft

Scroll arrow

Scroll box

Scroll arrow

Split box

Components of a scroll bar in MS Windows

SashSeparator

Example sash in Motif

Font: Size:Style:Font

Times Regular 12

ArialGenevaHelveticaTimes

BoldItalicBold ItalicRegular

8101214

Alignment

ApplyCancelOK

Font Properties ?

Tab

Tabbedpage

Actionarea

Example tabbed pages in MS Windows

Database Notification (Minutes):

0 60

10

Scale barIndicator

Label

Example scale in Motif

Files remaining to be copied: 50

Reading: TEST50.DOC

Example gauge in Motif

Dialog Box Etiquette

Design Tips

• All dialog boxes should have caption bars

• Use verbs in function dialog caption bars

• Use object names in property dialog caption bars

• Dialog boxes should be as small as possible but no smaller

Reduce Excise

Terminating Commands for Modal Dialog Boxes

• Offer OK and CANCEL buttons on all modal dialog boxes– CANCEL good for pedagogical purposes– Bulletin dialog boxes (errors) can get away

with just an OK– Process dialogs need a CANCEL to stop a time

consuming process

• Never user terminating words in dialog boxes (CLOSE)

The Close Box

• Don’t put close boxes on modal dialogs– disposition of changes is unclear– changes accepted or rejected?

Tabbed Dialog

• Sometimes called “multi-pane” dialog• Panes and tabs• Helps with size and complexity• Follows the users mental model for how

things are stored– monocline grouping (one level deep)

• Content must have meaningful rational

Tabbed Dialogs

Tabbed area

Un-tabbed area

Put terminating buttons in un-tabbed areaPut terminating buttons in un-tabbed area

Extreme Case of Tabbed Dialogs

All idioms haveAll idioms havepractical limitspractical limits

Don’t stack tabsDon’t stack tabs

Directed Dialogs

• Changes and adapts its suite of gizmos based on some user input

• Programming these can get complicated

• May be confusing to the user• Effective when user is entering

settings in a clearly sequenced manner

Directed Dialogs

Typed-Command Languages

Description

• Earliest form of communication

• Can be very efficient to use, popular with frequent users

• Requires extensive training and knowledge of syntax

Guidelines

• Use a consistent rule of formation for entering commands – Since learning is more difficult,

consistency is essential – Typical formation is ``action-modifier(s)-

object(s)''

Guidelines

• Choose meaningful, specific, distinctive command names – Can be very difficult since all

commands are typically visible at once –May permit abbreviations, but that can

cause additional confusion – Use diametrical opposites for

commands that are logically opposite (e.g. create/destroy)

Guidelines

• Apply consistent rules for abbreviating commands – Single characters may work for small

command sets – For larger, truncation appears best (over such

techniques as dropping vowels, first and last letter, etc)

• Allow easy correction of typing errors – Do not force user to retype lines that had

errors, but allow editing.

Guidelines

• Allow frequent users to develop macros – Geared towards frequent users – Allows for increased speed and

customization

Graphical Interfaces

Description

• The term Graphical User Interface (GUI) has come to represent interaction objects such as windows, buttons, etc.

• Generally use direct manipulation with an object-action paradigm and visual feedback

• This is just a subset of various ways to use graphics to communicate. Call that superset graphical interfaces.

Types

• Data and Scientific Visualization – This includes charts, graphs, plots, etc. – Widely used in the scientific community to

gain insight into large amounts of data (numbers)

• Visual Databases – Store visual images much as you would store

text – Use stored images to construct simulations

Types

• Animation – Effective for simulating various

scenarios – Also, like visualization, can show

temporal relationships

• Video – Combine audio/video with other

windows – Requires more skill to design effectively

Types• Multimedia and Hypermedia

– The integration of graphical, audio and video information with associative links

– Links provide simple navigation through ``hyperspace''

– Navigation must be designed carefully

• Virtual Reality – Represents a greater immersion into the

application with various sensory devices – Still very expensive with much still in

development stage

Guidelines

• Since many of these interaction styles are very new, there is little in the way of hard evidence. The following are heuristics based on common sense and experience

• Use real-world analogies as much as possible – Since systems tend to model the real

world, these analogies work best

Guidelines

• Keep the visual presentation as simple as possible – Avoid the tendency to do too much, just

because you can

Guidelines

• Show different views of the same visual object

• Use color sparingly and meaningfully

• Use video sparingly – Only high-quality video should be used,

and that is difficult to produce