Designing Usable Systems

Gary Marsden Slide 1University of Cape Town

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– Essay on programming language or Web sites

• Due soonish

– Analysis of a gadget• Presentation (week of 27th Sept.)

• 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– 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


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

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

l

t

– 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

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?

l


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.

Gary Gary GaryGary

Gary

Button Graphic Traditional Rollover No affordance


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


Cognitive dimensions (Thomas Green)

• Viscosity– Ability of the system to be changed to meet new

criteria

• Premature Commitment– How early the user must commit to a decision

• Role Expressiveness– Does the interface adequately express the

concepts of the target domain

To be honest, I am not sure these are useful, but I know the guy who thought them up and thought I better include

them.


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.


Results

Long battery life is important– for men– for experienced users

Smaller and lighter are good, unless:– you are an experienced user– you are a kid

Too small is badBigger displays important

– especially to elderly


Conclusions

• Manufacturers must resist “Swiss Army” phones– creeping featurisim– features as rewards like Nintendo

• Touch screens seem way forward• Usability must improve to reduce calls to support

line but increase calls to vertical services

• Network suppliers are not happy with usability• Handset manufacturers are more likely to listen to

service providers than individual customers


Using Design Rules

Attempt to provide designers with information about impact of their designs

Always a trade-off - the more general the rule, the more chance it conflicts with another rule

We can make a vague distinction between:

– Guidelines• vague, need to know

theoretical underpinning

– Standards• can be very specific, e.g

3-button mice used

Guidelines

Standards

Authority

Generality


Standards

Usually set by international committee– Hardware standards more specific than

software– Hardware less likely to change

• Strength lies in forcing a large community to follow standard

• Currently not much for promoting usability: tend towards ‘de facto’ standards


Guidelines

Style guides published by Apple, Sun etc.Tend to be generalisations - the more

general, the earlier they should be in the design process

Can range from:– Users must initiate all dialog (Apple)to– Use white space between long groups of menu

controls (Open Look)


Summary

Standards

•High authority

•Little overlap

•Limited application

•Minimal interpretation

Guidelines

•Lower Authority

•Conflicts / overlap / trade-

off•Less focused

•Interpretation required - HCI background


Web Guides

For the coursework, you will need to find a style guide for the site design

As there are so many styles of site, make sure you find one which suits the site you are interested in

I will give you a list of style guides, but here are some good design rules from Jakob Nielsen (Web guru)

http://www.useit.com


To 10 points of bad design

• Breaking the back button• Opening browser windows• Non-standard use of widgets• Lack of biography• No archives• Moving URL’s• “Smart” headlines• Buzzwording• Slow sites• Any advertising, or similar graphic


Writing for the Web

• Simplicity and informality• Credibility• Outbound links for credibility• Low humour• Speed• Scanable text (bullet points)• Concise (half word count of other media)• Summaries / Inverted pyramid• Graphics and text integrated

Check Strunk and White

Date post:	15-Jan-2016
Category:	Documents
Upload:	dahlia
View:	25 times
Download:	0 times

Designing Usable Systems

Documents