CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 8B.1 Software Engineering: Analysis...
-
date post
19-Dec-2015 -
Category
Documents
-
view
221 -
download
0
Transcript of CSE3308 - Software Engineering: Analysis and Design, 2002Lecture 8B.1 Software Engineering: Analysis...
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.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.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)