Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

24
UX Note 2 Copyright © Robert W. Hasker, 2005- 2015 Based on About Face 3: Cooper, Reimann, Cronin

Transcript of Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Page 1: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

UX Note 2

Copyright © Robert W. Hasker, 2005-2015Based on About Face 3: Cooper, Reimann, Cronin

Page 2: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

About Face 3: Ch. 9 Posture: how software application presents

itself to the user ◦ Example: sovereign – occupy whole desktop◦ What other postures would you identify?

Software Posture

Page 3: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

About Face 3: Ch. 9 Posture: how software application presents

itself to the user Desktop applications:

◦ sovereign posture: software covers whole screen, work with system for hours at a time

◦ transient posture: pop up, get work done, go away

◦ daemonic posture: run in background, little/no interaction with user

◦ auxiliary posture: continuously present, but only in a supporting role

Software Posture

Page 4: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Sovereign◦ (monopolizes attention, maximal work space)◦ Exercise: observe Eclipse, Word

All document-centric applications! What do you notice about color? Input styles?

Observations◦ Color: used sparingly; muted◦ Inputs: rich variety◦ Screen: little wasted space, maximal use of

“dusty corners”; most beginners will maximize window

How posture affects interface

Page 5: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Usage model:◦ Called when needed, performs operation, quickly

leaves so user can get back to "real" work Examples:

◦ volume controls, alarm clock, juke box Usage: 1/month, week, day

◦ Usage must be obvious – no artsy controls!◦ Fine control not an option: oversized buttons

Bold graphics/high color ◦ Helps orient user ◦ Useful for differentiating transient from sovereign!

Transient Posture

Page 6: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Daemon (Unix term; also Windows services): software continually running in background, typically a controller

Examples: printer driver, power management, virus scanner, spell checker

Dont's ◦ No full-screen panels!

Just get the job done, don't be noisy about it ◦ No pop-up status reports unless critical

Context for interactions even more important here ◦ No icons - especially in the Windows Bar!

Access through control panel should be sufficient! Watch out for overuse of system tray!

Daemonic Posture

Page 7: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Blend of sovereign and transient Continuously present, but only there for

support ◦ eg: task bar, clocks, performance monitors,

instant messaging Be respectful of sovereign's rights

First step in design: what posture is appropriate? ◦ where does our project fit in?

Auxiliary Posture

Page 8: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

About Face 3: Ch. 10 “In the flow” – on task, highly productive Breaking flow lowers productivity Related issues

◦ Transparency: unaware of interface◦ Orchestration: “harmonious organization”

Goal: create, maintain flow Starting point: follow user’s mental model

Flow, Orchestration, and Transparency

Page 9: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Less is more◦ Minimal interfaces

Principles for Improving flow

Page 10: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Less is more◦ Minimal interfaces◦ Example

Principles for Improving flow

vs.

(both from end of 1998)

Page 11: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Less is more◦ Minimal interfaces

Service not discussion◦ User wants to direct

software, not talk to it

Principles for Improving flow

Page 12: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Less is more◦ Minimal interfaces

Service not discussion◦ User wants to direct

software, not talk to it◦ Not: this

Principles for Improving flow

Page 13: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Less is more◦ Minimal interfaces

Service not discussion◦ User wants to direct

software, not talk to it◦ Not: this or even this◦ Common fix: provide

direct manipulation

Principles for Improving flow

Page 14: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Keep tools close at hand◦ Tools introduce modes of interaction - minimize◦ Finding tools: breaks concentration◦ Common tools must be easy to access◦ Don’t require user to dismiss tools

Modeless feedback◦ Feedback critical for tools◦ Pop-ops: break flow – user has to dismiss◦ Status should be at edges of screen

Improving flow, cont.

Page 15: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Design for the probable, not the possible

◦ Example: Deletion dialog in Excel 4 Popped up when delete a cell Asked if wanted to delete all/format/formula/notes

90% of time: delete formula

◦ Example: Word before 2007: multiple cuts pop up second window to manage cut buffers

◦ Separate low-probability actions from high prob.◦ Design for the probable case, provide for the

possible.

Page 16: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Qualitative views of data◦ This: not:

But can the left be improved?

◦ Windows 3.x file manager Free space display: "1,234,234 Kb free"

◦ Comparisons easier: 23% free, visual image

Page 17: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Graphical input/direct manipulation

◦ Microsoft Paint,Firefox:

◦ Improvement: drag edges

◦ Canhaveboth:

Page 18: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Reflect program status◦ Every command should have a visible response◦ Gray out unavailable menu items◦ Icon changes, progress bars, cursors

Useful tool: “Bomb” pattern, with use

General principle: single function showing status

class WaitCursor {public: WaitCursor() { saved = Screen->Cursor; Screen->Cursor = crHourGlass; } ~WaitCursor() { Screen->Cursor = saved; }Private: Controls::TCursor saved;};

void readFile() { WaitCursor wait; ifstream in("file"); ... process in ... }

Page 19: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Avoid unnecessary reporting◦ Example: running status such as “connecting…

primary server offline…connected to secondary…end transaction” Confusing at best Written for debugging! If really needed, only display on command

◦ Don’t use dialogs to report normal status

◦ Don’t interrupt user with non-serious problems Make “good” choice, let user refine Example: web browser response to missing image

Page 20: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Avoid blank slates◦ Empty screen is pretty intimidating!◦ Non-solution: “friendly” setup dialogs

Users don’t want to answer lots of questions Example: Rational Rose startup dialog for language

◦ Place objects in reasonable way, let user refine It’s easier to refine than start from scratch Example: Word starts with preset margins, styles Use past history!

Flow, continued

Page 21: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Provide choices, not questions◦ Developers: questions are good – they give users

options, puts them in control◦ Users: may be intimidated

Cultural issue: person asking questions often seen as superior, the answerer as inferior Questions may not be empowering May feel ignorant, forgetful, weak, unable to fend for

self, harassed

◦ Dialogs: ask questions; toolbars: provide choices Especially true for confirmation dialogs! Toolbar: politely offering services

Page 22: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Hide ejector seat levers◦ Careful placement in cockpit – can’t pull by

mistake◦ Consider

◦ Software examples: One-time configuration for corporate environment Uninstall – why in Start menu?? Removing buttons from the screen Counterexample: WinSCP synchronization button

Page 23: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Follow mental models Less is more Service, not discussion Tools close at hand Modeless feedback Design for the

probable, not for the possible

Qualitative views Graphical input, direct

manipulation Show status on screen No unnecessary

reporting Avoid blank slates Provide choices, not

questions Hide ejector seat

levers

Review: Flow, Orchestration, Transparency

Page 24: Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.

Posture◦ Sovereign, transient, daemonic, auxiliary

Flow, orchestration, transparency Next: Eliminating Excise

Review