1. User interface design A software engineering perspective Soren Lauesen Slides for Chapter 1 November 2004 © 2005, Pearson Education retains the copyright to the slides, but allows restricted copying for teaching purposes only. It is a condition that the source and copyright notice is preserved on all the material. The approach is virtual window interface The virtual windows are an early graphical realization of the data presentation

2. Courses? Manual? Hotline? Fig 1.1A System interfaces System User interfaces Accounting system Technical interfaces Factory The GUI is also calle the HCI = Human computer interface

3. All factors important. Hard to measure, but possible. Fig 1.1B Quality factors Easy to make a user interface: Just give access to the database Hard to make a good user interface Quality factors: Correctness Availability Performance Security Ease of use Maintainability... Functionality: Necessary features see, edit create, delete Database

4. Max three menu levels On-line help Windows standard ?? Fig 1.2 What is usability? Usability factors: a.Fit for use (adequate functionality) Ease of use: b.Ease of learning c.Task efficiency d.Ease of remembering e.Subjective satisfaction f.Understandability Measurable Priorities vary Responsibility? Programmers? Other developers? User department? Game programs: a.??

5. Examples: The system works as intended by the programmer, but the user: P1.Cannot figure out how to start the search. Finally finds out to use F10. P2. Believes he has completed the task, but forgot to push Update. P3. Sees the discount code field, but cannot figure out which code to use. P4. Says it is crazy to use six screens to fill in ten fields. P5.Wants to print a list of discount codes, but the system cannot do it. Fig 1.3 Usability problems Severity classes: 1Missing functionality 2Task failure 3Annoying 4Medium problem (succeeds after long time) 5Minor problem (succeeds after short time) Critical problem = Missing functionality, task failure, or annoying

6. Userbility test methods Think aloud Heuristic Evaluation Task Time Problem counts Keystroke Counts Opinion Poll Score for Understanding Guideline

7. Purpose: Find usability problems Fig 1.4 Usability test - think aloud User Performs tasks Thinks aloud Logkeeper Listens Records problems Facilitator Listens Asks as needed I try this because... User doesn’t notice...

8. Plan Test-users: Test-tasks: Study system yourself Carry out Explain purpose: -Find problems when using the system -System’s fault - not yours Give task - think aloud, please Observe, listen, note down Ask cautiously: -what are you looking for? -why... ? Help users out when they are surely lost Reporting List the usability problems - within 12 hours (Fig 1.4 cont.)

9. Purpose: Find usability problems Usability specialist looks at system using common sense and/or guidelines The specialist lists problems (Consults with other experts) Fig 1.5 Heuristic evaluation First law of usability: Heuristic evaluation has only 50% hitrate Actual problems Predicted problems False problems Missed problems Expert - reviewer

10. ATM Users:20 bank customers, random selection. Task 1:Withdraw $100 from ATM. No instructions. Measure:How many succeed in 2 min? Task 2:Withdraw as much as possible ($174) Measure:How many succeed in 5 min? Reqs:Task 1: 18 succeed. Task 2: 12 succeed. How to measure What to measure Requirement - target Fig 1.6A Measuring usability - task time (performance) Pros:Classic approach. Good when buying. Cons:Not good for development. Not possible early. Little feedback. Internal ordering system Users:5 secretaries in the company. Have tried the internal ordering system. Have not used it for a month. Task 1:Order two boxes of letter paper +... Measure:Average time per user. Reqs:Average time below 5 min. What to measure Risky!

11. Users:20 bank customers... Measure:In 2 min? Reqs:Task 1: 18 succeed. Task 2: 12 succeed. Fig 1.6B Choosing the numbers Why 20? Cost versus reliability. During development: One, later two, later... Why 2 mins? Best practice, ideal way... Why 18? 90% of customers should succeed. Task 2 harder. Open target Reqs:18 out of 20 must succeed within ____ min. We expect around 2 min. Specify how, what, and expectations. Wait and see what is possible.

12. Users:3 potential users. Think-aloud test. Record usability problems. Task 1:Order two boxes of letter paper +... Task 2:... Measure:Number of critical problems per user. Number of medium problems on list. Reqs:Max one user encounters critical problems. Max 5 medium problems on the list. What to measure Requirement Fig 1.6C Measuring usability - Problem counts Pros:Possible early - mockup sufficient. Good feedback to developers. Cons:Best for ease of learning. Only indications for other factors. How to measure

13. Task 1:Withdraw a standard amount from ATM. Task 2:... Measure:Number of keystrokes and mouse clicks. Reqs:Max keystrokes 6 - incl. PIN code. Total system response time max 8 s. How to measure What to measure Requirement Fig 1.6D Measuring usability - Keystroke counts Pros:No users needed. Possible early - mockup sufficient. Cons:Not sure users find the fast way. Only task efficiency. Total task time 6 keystrokes @ 0.6 s3.6 s total system response time 8.0 s Total task time11.6 s Plus other user actions?

14. Ask 20 novice users to complete the questionnaire. Measure:Count number of entries per box. Reqs:80% find system easy to learn. 50% will recommend it to others. How to measure What to measure Requirement Fig 1.6E Measuring usability - Opinion poll Pros:Widely used. You may ask for any usability factor. Cons:Doesn’t match objective evidence. Only indications during development. Little feedback to developers. Questionnaire agreeneutraldisagree The system was easy to learn The system is easy to use The system helps me... It is fun to use I will recommend it to others

15. Ask 5 potential ATM users what these error messages mean: Amount too large PIN code invalid... Ask them also: What would the system do if... Measure:Assess answers on scale A-D. Reqs:80% of answers marked A or B. How to measure What to measure Requirement Fig 1.6F Measuring usability - Score for understanding Pros:Easy way to test understandability. Best way to cover error messages. Useful both early and late in development. Cons:Only measures understandability..

16. Ask an expert to review the user interface and identify deviations from guideline X. (Or ask two experts to come up with a joint list.) Measure:Number of deviations per screen. Reqs:At most one deviation per screen. How to measure What to measure Requirement Fig 1.6G Measuring usability - Guideline adherence Pros:Adherence helps users switch between systems. Company-specific guidelines for internal systems can help even more. Cons:Cannot guarantee high usability. Developers find guidelines hard to follow - examples help best.

17. Fig 1.6H Which usability measure? Task time Problem counts Keystroke counts Opinion poll Score for underst. Guidelines Fit for use Ease of learning Task efficiency Ease of remember Subjective satisf. Understandability ?? Highly useful Some use Indications only Development, early Development, late Buying a system