CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.1

Software Engineering: Analysis and Design - CSE3308

Technical Issues in Human-Computer Interaction

CSE3308/DMS/2002/18

Monash University - School of Computer Science and Software Engineering

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.2

Lecture Outline

The Myth of Metaphor The Limits of GUIs Posture Documenting the User Interface Evaluating User Interfaces Specific User Interface Areas

Dialog Boxes Error Messages Memory Help Systems and Documentation

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.3

The Myth of Metaphor

Macintosh/Windows - built on the desktop metaphor

Commonly said to be the reason for success Yet many aspects of the metaphor are

incomplete and limit the useability of the interface

Metaphor is useful, but not sufficient Never bend your interface to fit a metaphor Instead do idiomatic design, use symbolism

that needs to be learned once

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.4

The MagiCap Interface

An interface bent to fit the

metaphor

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.5

An Idiomatic Design

The symbol is easily learnt and distinctive,therefore hard to forget

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.6

The Limits of GUIs The other reason for the success of GUIs is

the limited vocabulary of action they provide

PRIMITIVESSmallest indivisible

actions and feedback mechanisms

The GUI Vocabulary of Action

COMPOUNDSgeneric input and output

actions and symbols

IDIOMSApplication-specific commands

and feedback

Delete, Create, Draw

Double-Click,ButtonClick, Selection

Click, Drag,Keypress

INPUT OUTPUT

Cursor, Text

Edit Fields, Checkboxes,Highlighting

Scrolling,Sorting, Dialogs

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.7

Posture

Applications can take four main postures Sovereign Posture

Application which monopolises the entire screen for lengthy periods of time

e.g. Word processors, Spreadsheets, Programming Languages

Design for optimal use with experienced users Learning time is relatively small compared to total time

spent using the program Expect to run in a maximised window Keep colours and textures muted and conservative The visual interface can be very rich - e.g. multiple

toolbars and the like

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.8

Posture (2) Transient Posture

Applications which come and go, which perform a single function

Act in a supporting role to sovereign applications e.g. Windows Explorer, WinFTP Users spend far less time with transient applications Should aim to reduce the amount of screen space it uses to

a minimum The visual interface should be simpler and bolder, the user

has far less time to familiarise themselves All the relevant information should be readily apparent Should have the instructions built into the surface Window may not need to be resizable e.g. Windows

Calculator

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.9

Posture (3) Daemonic Posture

Applications which normally do not interact with the user and work in the background normally

e.g. Print Manager, Screen Savers Design as for transient but even more critical Users will rarely see the program’s interface Summon the interface via a method such as a Control Panel,

don’t put an icon on the screen e.g. AfterDark Screensaver

Parasitic Posture Application which is always present, but is small and performs

a supporting role e.g. Windows 3.11 Clock Design must be simple and bold Should use a very small amount of screen space

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.10

Documenting the user interface

No accepted method of documentation No formal method of specifying user

interfaces Screen Displays

document the actual appearance of the screens

Use Cases document the functionality which the screens have to

support

Interaction Diagrams from UML can be used to show the interactions between windows not standard as far as I’m aware

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.11

A Collaboration Diagram

:OrderEntryWindow

:CustomerDetail Window

Show CustomerDetails Button

:Help Contents Window

Help-Contents

Window - Close

WindowClose

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.12

Evaluating User Interfaces

Evaluation can be both expensive and difficult

Techniques include

Experimentation

Questionnaires

Direct Observation

Indirect Observation (Video)

Automatic Data Collection

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.13

What should we evaluate?

Time to learn specific functions

Speed of task performance

Rate of errors

Subjective user satisfaction

Human retention of commands over time

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.14

Specific User Interface Areas

Dialog Boxes

Error Messages

Memory

Help Systems and User Documentation

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.15

Dialog Boxes Dialog Boxes represent a break in the flow of

work and suspend the normal flow of work Instead we should put primary interaction on the

primary window, not in dialog boxes 4 types of Dialog Box

Property - presents the user with the characteristics of a selected object

Function - control a single function like spelling, printing inserting, etc.

Bulletin - gives a brief description of a problem, e.g. many error messages

Process - informs the user that the program is unable to act normally for a period, e.g. when copying in Windows Explorer

Requested

Unrequested

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.16

Dialog Boxes (2) Requested Dialog Boxes may be large and

dominant on the screen Unrequested Dialog Boxes should be smaller

and unobtrusive Dialog Boxes have a transient posture Reduce as far as possible unrequested dialog

boxes

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.17

Error Messages

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.18

Error Messages (2)

Error Message boxes are generally abused We should aim to eliminate all error message

boxes Aim to alter the program so that the error

cannot occur or redefine what we mean by an error

People hate error messages Treat error messages like a GOTO - take the

user to a place where they can fix the error

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.19

Error messages (3)

Where you cannot avoid an error message, make it:

positive

tailored to the context, experience level and the culture of the user

explanatory

offer a solution

polite

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.20

A good error message

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.21

Memory Our programs often lack memory As a a result, our programs have to ask questions a

lot Questions are resented by users and break the flow

of work Reduce questions by giving programs memory

CSE3308 - Software Engineering: Analysis and Design, 2002 Lecture 8B.22

Help Systems and User Documentation

Help and user documentation works best when it is targeted at tasks which they need to perform

This is known as Minimalist Help Aim to provide the minimum amount of

material on a topic to achieve the goals of the user

Avoid lengthy expositions on the topic Modern help systems are generally

predicated on this idea (i.e. Help Wizards)