Designing Usable Systems

Designing Usable Systems • This course should enable you to design and implement better user interfaces • We will look at case studies in • Web browsing • Cellular Telephones • VCR’s • Programming Languages

Why are you here? • Because I needed the credits

Why am I here? • Because I’m paid to be here…

What do we know? • HTML • Tcl • Java • Graph Theory • State Transition Diagrams / Finite State Automata • State Charts (Harel)

Course Assessment • Two parts • Evaluation of usability • Due soonish • Analysis of a gadget • Presentation • Analysis • Simulation

Reading list • No set text • Handouts • P.O.E.T - Don Norman • State charts - best book is Ian Horrocks • My book

Course in a nutshell • Here are some assumptions I am working on, and will give you an idea where I am coming from • Gadgets and software are badly designed and everyone accepts this as normal* (Dilbert) • HCI does little to help programmers engineer usable systems • Most HCI is post disaster finger wagging and relies on there being an artefact to evaluate • This is a slight rant, but I am happy to discuss any point with you.

Usability - does it exist? • Before we can look at usability, we have to look at how it is currently perceived • To do this, we need to analyse how users know that a product is ‘usable’ • This is not as easy as it sounds. A good place to start looking is by analysing the tasks products are designed to solve.

Task types - external • For some products, it is easy to see how well they fulfil their role: • chair, car, hi-fi, television • This type of product is designed to fulfil some need that exists in the physical world. • This type of task we shall call “external” and is not interesting to our discussion.

Task types - internal • The other type of task is an “internal” task. • Here a device is built to solve a problem which exists only because the device exists! • With these internal tasks, the problem is defined in terms of the device created to solve the problem – this makes assessing task performance incredibly difficult.

Visibility - Physical and DM • Another problem in assessing usability is the lack of visibility in electronic devices • Physical devices have visible qualities which we can assess • Software can be visible (Direct Manipulation) but also invisible (DOS) • Electronics have physical attributes which are not worth investigating

Direct Manipulation (Ben Shneiderman) • From studies on video games, decided that: • Users should see objects • Objects should be controlled directly • State is always visible • This led to interfaces such as the Star, Lisa and Macintosh

Visibility - gadget • Direct manipulation has helped with software, but most computers are sold in embedded systems • Cellular handsets etc. have limited interfaces • This was OK when processors were under powered, not acceptable now

Masochism • Before we go on to look at usable systems, it is worth mentioning that some people like unusable systems • Computer games rely on having obscure interfaces • The World Wide Web it is fun to just surf around hoping to bump into something interesting

Introducing usability to products • I hope I have convinced you in the first lecturer that devices are not as usable as they might be • One possible explanation for this is that the technology is not mature enough yet to allow usability it to develop

Mature technology • Let us switch briefly to an more mature technology as a case study: cars • Originally sold on the fact they worked • Later came technologies (“Balanced Power”) • Ultimately came safety and usability • Ralph Nader changed perception of this

Electronic maturity l t • So is the electronic industry in a mature state? • To answer this we need to look at Christensen’s ideas (MIT professor looking at “disruptive” technology • He assumes that technology develops over time and eventually reaches some level where it is sufficient for a task • This is true for “external” tasks

Internal task maturity l • This time, the graph looks a little different • The curve never meets the task line, as the line changes to keep ahead of the curve • What is going on?

Capitalism • Companies exist to make money for their share holders. This means that they need to keep selling products to the same consumers • Unlike cars (or other physical products), software (and electronics) does not ware out • Therefore, companies must make you want to buy new products - the technology curve cannot be allowed to cross the task line.

Task stepping • There are many ways to produce a stepped task curve. Here are three: • Forwards compatibility • Having software versions which are incompatible • Processor exploitation • Here is a quote from a Microsoft executive: • “if we hadn’t brought your processor to its knees, why else would you get a new one.” • Snobbery • Word processing - “font-itis”, “clipart-itis” etc.

Usability exploitation • Companies can also exploit usability to step the task line using marketing and drama • Drama • Exploits the fact that products can be made to look easy to use at purchase time • Sales people use “demo” buttons or careful walkthroughs • This is backed by marketing • Microsoft head of marketing “perception is reality” • Techno-centric focus (“Super-Intelligent control”)

Complicity • Most users are happy to be exploited in this way for many reasons • Don’t want to admit they have made a bad decision • Enjoy the kudos that comes from knowing a system and helping others • Early adopters buy for fashion purposes • Moreover, users do not know that there are better ways of doing things • as the technology is hard to understand, users assume un-usability is essential

Increasing usability awareness • Before we start to look at how programmers improve usability, it is worth considering how usability awareness can be raised • Commercial • new user groups and applications, esp. cellular phones • little need whilst still selling • Academic • little impact in three decades • Consumer groups • need to develop usability standards (I have done a lot of work here)

Building better systems • There has been much work in HCI on principles for interface design • We shall look at a few of these and see how they can be applied to common systems • Remember these are principles for programmers - there is much more to HCI especially in prototyping, evaluation and user centred design

Affordance (Don Norman) • Affordances of an object are those properties of the object which give users clues as to how the device is used • Good examples include push buttons and levers • Bad examples: • Pet hate is Web site design where links are not underlined and give no indication of how they should be used. Button Graphic Traditional Rollover No affordance Gary Gary Gary Gary Gary

Affordance examples (UCT)

Mapping (Don Norman) • Mapping is concerned with ensuring that there is a natural correlation between objects and the interface controlling them • This crops up with oven controls, light switches and, our old friend, the car radio • Beware of cultural mappings as opposed to ‘real’ mappings

Constraints (Don Norman) • Constraining a design so that it can only be used the correct way • Lego • 3.5” disks • Greyed menu options

Visualising (Don Norman / Ben Shneiderman) • Features should be made visible - we talked about this earlier • Bad (usually impoverished interface) • Command lines • Cellular phone menus • Good • Direct Manipulation • Menu systems

Memory (Don Norman & many others) • Essentially memory comes in two flavours • Short term • Long term • Short term memory is like RAM and can hold 7±2 items at a time. This impacts issues like menu design • Long term is like hard disk. Too complicated to go into here • Also linked to cognitive models

Knowledge & Chunking (Don Norman etc.) • To improve on memory, we tend to chunk actions • Chunking works by grouping actions into a lump • Seek for meaningful relationships. Here is my UK cellphone number written two ways: • 0976 609766 • 09766 09766 • To help, we need to differentiate “knowledge in head” and “knowledge in world” • Display based action • Recognition vs. recall

Conceptual Models and task analysis (Don Norman etc.) • Task analysis techniques like GOMS, which you have covered already, help programmers think about the user goals and task closure • ATM machines fail on the closure test • Conceptual models require the programmer to think about how the user is conceptualising a problem and build an accurate representation • When the user model and the computer model do not match, we have “cognitive dissonance”

Reverse Turing test (Harold Thimbleby) • Humans should be treated at least as well as computers • Explains why direct manipulation better than guided dialog (as per VCR timer recording) • Sounds obvious, but this has huge impact on interface design • We will look at this point a lot more in the case studies

Role Integrity (Harold Thimbleby) • Interfaces should not mislead users about what the computer is capable of • This usually applies to hidden limits such as • Midi sequencers coping with only eight tracks • Generally limits should be zero, one or infinity • If the interface is capable of specifying a task, the computer should be able to complete it

Simpler is not always better (Harold Thimbleby) • Einstein’s “Everything should be made as simple as possible, but not simpler” • Fewer buttons often seen as simpler, but not always the case • Overloading buttons with modes • Typewriters are easy to use • My Navi-key Nokia is not • Complex looking buttons can be hid under a lid

Principle of least astonishment (Harold Thimbleby) • Consistency is obviously a key goal in interface design. • This has been stated as • “The principle of least astonishment” • Consistency applies to functionality and form • The car radio displays both types of inconsistency • Button layout on face / button layout on remote control • Functionality of RDS modes

Modes (Harold Thimbleby etc.) • Modes allows different behaviours from the same interface features • Not necessarily bad, but linked to poor feedback, can be awful • Buttons 7-12 on the radio • For users who are not aware that the mode has changed, this makes the device appear non-deterministic • Polya’s principle of “Non-sufficient reason” - if there is no reason to believe things are different, they aren’t

Equal opportunity (Harold Thimbleby & Andy Monk) • Equal opportunity states that there should be no difference between input and output values (or known / unknown) - one can be substituted for the other. • Good examples include: • Spreadsheets - cells are neither input or output exclusively • Camera aperture / shutter speed • Zloof Query by Example

Principle of least effort (Harold Thimbleby) • Zipf’s principle of least effort can be rewritten as: • “Make frequent things easy, unlikely things harder” • Similar to the simplicity idea, this manifests in the following ways • Morse code ‘E’ is only one dot, apostrophe is 6 dots and dashes • Menus organised to common things at top • “Dangerous” operations could be heavily nested or require many clicks or presses

Feedback (Harold Thimbleby & Isaac Newton) • Newton taught us that every action in nature is met with a reaction - this is not always the case in interfaces • Every user action needs the interface to react so that the user knows the action is complete • this can be tricky in multi-tasking systems • Especially important for displaying modal information

Fitts’ Law • “The time taken to acquire a target is a function of the distance to and size of the target” • For a target of size S, a distance D from the pointer, time is • a+b*log2(D/S + 1) (a and b depend on device characteristics) • This has big implications for items such as menu design

Bruce “Tog” Tognazzini • Somewhat of a character, Tog is well known as an outspoken proponent of good interface design • Almost unique in HCI community he worked for a real company (Apple) and was responsible for designing real products (System 7 among them) • He is not a whinge-bag

Tog’s ideas • Anticipation / Autonomy • Do not try to guess what your users want • Give them some room to explore (more than an ATM, less than UNIX) • Colour Blindness • Never use as a primary queue • Consistency • Inconsistency just as important • Defaults • Never called “Default” – easy to over-ride

Tog continued • User efficiency • Do not confuse machine with user efficiency • Latency reduction • Use threads! • Use metaphors • but not too much (what the heck is an analogy?) • Protect your users

Genuine Usability • We are going to look at some results from a usability test on mobile phones conducted by US-West • Before we look at the results, what do you think of handset usability and how practice, age and instruction might affect it? • Interesting study as purchasers are not the end user

Usability experiment • US-West carried out a series of tests with a diversity of subjects • They had to complete 28 tasks on 3 different handsets. Times were measured and compared • Subjects were also interviewed about phone preferences

Task results • Similar usability • Plenty of “room for improvement” • Varied success • basic features good • advanced / vertical services were awful • Practice doesn’t help much • Very poor feedback • possibly a problem of handset and network feature confusion • Age makes a big difference

Consequences • Reduced network usage • Speed dials; 16% success • Save from call log; 25% success • many don’t try • Reduced usage of vertical services • Vulnerability to competition

Manuals & Instruction • Can help with success • Need to be tailored for age / gender etc. • Fonts hard to read for elderly • Poorly optimised dialog • “Call forwarding is on” Vs. • “Your feature has been activated” Vs • stutter dialtone • Instructions are age related • “Nintendo effect” cross over point

Second experiment • A second experiment was conducted to check physical attribute preference • Before looking at the next page, what do you think are the attributes people look for • size • colour • battery life • Are attributes the same for different groups of people.

Designing Usable Systems