Copyright © Robert W. Hasker, 2005-2015 Based on About Face 3: Cooper, Reimann, Cronin.
-
Upload
pauline-simon -
Category
Documents
-
view
217 -
download
0
Transcript of 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
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
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
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
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
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
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
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
Less is more◦ Minimal interfaces
Principles for Improving flow
Less is more◦ Minimal interfaces◦ Example
Principles for Improving flow
vs.
(both from end of 1998)
Less is more◦ Minimal interfaces
Service not discussion◦ User wants to direct
software, not talk to it
Principles for Improving flow
Less is more◦ Minimal interfaces
Service not discussion◦ User wants to direct
software, not talk to it◦ Not: this
Principles for Improving flow
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
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.
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.
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
Graphical input/direct manipulation
◦ Microsoft Paint,Firefox:
◦ Improvement: drag edges
◦ Canhaveboth:
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 ... }
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
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
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
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
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
Posture◦ Sovereign, transient, daemonic, auxiliary
Flow, orchestration, transparency Next: Eliminating Excise
Review