Software Engineering: Analysis and Design - CSE3308

1. CSE3308/DMS/2005/5 Monash University - School of Computer Science and Software Engineering Software Engineering: Analysis and Design - CSE3308 Technical Issues in User Interface Design

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 • Help Systems and Documentation

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

4. The MagiCap Interface An interface bent to fit the metaphor

5. An Idiomatic Design The symbol is easily learnt and distinctive, therefore hard to forget

6. The Limits of GUIs • The other reason for the success of GUIs is the limited vocabulary of action they provide The GUI Vocabulary of Action IDIOMS Application-specific commands and feedback Scrolling, Sorting, Dialogs Delete, Create, Draw COMPOUNDS generic input and output actions and symbols Double-Click, ButtonClick, Selection Edit Fields, Checkboxes, Highlighting PRIMITIVES Smallest indivisible actions and feedback mechanisms Click, Drag, Keypress Cursor, Text INPUT OUTPUT

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

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, WinZip • 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

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. 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

10. Documenting the user interface • No universally accepted method of documentation • No formal method of specifying user interfaces • Possibilities: • 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 a standard use of interaction diagrams

11. Help-Contents :Help Contents Window :OrderEntryWindow Window - Close Show Customer Details Button :CustomerDetail Window A Collaboration Diagram used for GUI documentation Window Close

12. Evaluating User Interfaces • Evaluation can be both expensive and difficult • Techniques include • Experimentation • Questionnaires • Direct Observation • Indirect Observation (Video) • Automatic Data Collection

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

14. Specific User Interface Areas • Dialog Boxes • Error Messages • Help Systems and User Documentation

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

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 unrequested dialog boxes as far as possible

17. Error Messages

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

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

20. A better error message

21. 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”, or “context-sensitive help” • Aim to provide • minimum amount of material on a topic to achieve the goals of the user • Help tailored to tasks user is currently performing • Avoid lengthy expositions on the topic • Modern help systems are generally predicated on this idea (e.g. Help Wizards, F1)