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

2.  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?

3.  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

4.  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

5.  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!

6.  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!

7.  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?

8.  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

9.  Less is more ◦ Minimal interfaces

10.  Less is more ◦ Minimal interfaces ◦ Example (both from end of 1998)

11.  Less is more ◦ Minimal interfaces  Service not discussion ◦ User wants to direct software, not talk to it

12.  Less is more ◦ Minimal interfaces  Service not discussion ◦ User wants to direct software, not talk to it ◦ Not: this

13.  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

14.  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

15.  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.

16.  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

17.  Graphical input/ direct manipulation ◦ Microsoft Paint, Firefox: ◦ Improvement: drag edges ◦ Can have both:

18.  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; }; 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... } void readFile() { WaitCursor wait; ifstream in("file");... process in... }

19.  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

20.  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!

21.  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

22.  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

23.  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

24.  Posture ◦ Sovereign, transient, daemonic, auxiliary  Flow, orchestration, transparency  Next: Eliminating Excise