Copyright © Robert W. Hasker, Based on About Face 4 th Ed: Cooper, Reimann, Cronin

 Excise: actions not contributing to goal ◦ Financial excise: taxes, insurance ◦ Bicycle locks, repairing flats, oiling the chain  Software excise: configuration, manuals  Goal: eliminate excise so user more effective

 GUI excise ◦ Must move/resize window before can do work ◦ Command-line interface excise: learning commands ◦ GUI helps beginner, intermediate; cmd for expert ◦ Solution: provide both GUI and command-line interface  can help in testing!  Training wheels ◦ allow dismissing support for beginners ◦ Android power saver notifier – why?

 Computer excise ◦ Frequent & expensive updates for security features that affect few users.  Visual excise ◦ Work user does to decode visual information ◦ Old software: special icons for beginners  printer icons, fax machines  help beginner, eat screen space for everyone else

Full Page at 33% zoom

Scrolling down several screens:

What makes this cluttered?

 Stopping the proceedings with idiocy ◦ Bugs: break flow  “Impossible” query that hangs system ◦ But also: senseless confirmations

 Stopping the proceedings with idiocy ◦ Bugs: break flow  “Impossible” query that hangs system ◦ But also: senseless confirmations - Why can’t system fix this? - Which saves my rules? - What does Cancel do?

 Stopping the proceedings with idiocy ◦ Bugs: break flow  “Impossible” query that hangs system ◦ But also: senseless confirmations - Why can’t system fix this? - Which saves my rules? - What does Cancel do?  Errors and notifiers ◦ All are excise! ◦ Don’t tell user something they can’t fix

 Confirmations ◦ Must minimize “are you sure?” messages ◦ But don’t make the user ask permission!  i.e.: go through gate-keeper action to get to data change  Example: requiring choosing a menu item to enable modifications to data in table  Passwords – do we need so many?  Undo: addresses various UI problems

 The tool for avoiding "do you really want to do that?" questions  note: users are not thinking in terms of mistakes to be undone ◦ better viewpoint: user tries something, wants to undo it to try something else  a simple trial isn't an error, it's an experiment! ◦ goal of undo: permit exploration

 incremental: apply operation to some piece of data  procedural: apply operation with no specific data; eg, right-aligning whole document  blind undo: undo operations with no indication of what will be undone  explanatory undo: letting user know what will be undone ◦ difficult, but certainly useful!  single vs. multiple undo ◦ can user undo just one operation or many? ◦ single undo should be seen as the minimum ◦ multiple undo usually based on stack (LIFO) - is this the best model?  ok when need to undo one change to get back whole paragraphs  a pain if have to undo several big operations to get back small but important piece of data ◦ multiple undo almost requires a redo operation

 Undo solutions: ◦ Keep copies of states so they can be restored ◦ Versioning systems (CVS, Subversion, StarTeam, etc.)  should probably build more support into products for this! ◦ Command pattern – the solution you’ll use this semester  Should undo be per-session or per-document? ◦ Can simply store the command chains w/ the document ◦ Space is cheap!  Issue: is a stack really the right model? ◦ Easier to implement ◦ Requires user to undo all intervening actions to recover (say) a deleted paragraph ◦ Textbook: provide a menu of undoable operations, allow the user to pick  this notion may need more research  Will use a stack-based model for your project this semester

 Patterns: solutions to common problems  Basic behind command pattern: store commands as objects ◦ base class defines abstract execute() ◦ subclasses: implement execute()  Uses ◦ All menus, buttons, etc. can invoke same action ◦ Stack commands for undo/redo ◦ Share common bits of operations

 Applied to phonebook.java:phonebook.java ◦ Remove, add: core commands ◦ Two lists of commands; clear undone on new cmd

 Implements GUI/policy/data layers  History part of policy layer, encapsulates undo/redo ◦ Handler doesn’t need to track this!  Phonebook: current contents; Map provides lookup  Add: points to entry so can redo the add  Remove: uses entry in undo

 Issues to decide ◦ What data to store? ◦ Have a few “intelligent” commands, or lots of small ones? ◦ Provide way to group commands into a unit? ◦ Need way to save commands without exposing internal details?

 Other ramifications: ◦ Macro = sequence of commands ◦ User might define own commands & assoc w/ menus ◦ Can log commands to handle system crashes, accountability, etc.

 Forcing user to go to another window to perform operation affecting this window:  “Asking permission“: extra steps to change data ◦ Cause: separating output from input because it makes sense to the programmer ◦ Fix: allow user to change the data, provide undo for fixes ◦ Better: "allow input wherever you have output“  Why can't a document name be changed on the menu bar?

 Forcing user to remember where things placed in hierarchical file system ◦ placing projects in folders in "Program Files“  difficult to back up  Forcing user to resize windows unnecessarily ◦ especially an issue in popups ◦ size for contents w/ no wasted space, no scrolling  Forcing user to move windows ◦ use unused desktop space ◦ but how to know what's unused?  Forcing user to reenter personal settings ◦ starting point: window placement ◦ also: fonts, sounds, other options ◦ how to support in multi-computer environment?

 Forcing user to enter data just to increase completeness ◦ allow users to leave blank fields where can provide results ◦ Simple example: surveys  Why not force respondents to answer all questions? ◦ Why do I have to enter my cat’s name to compare foods?

 Forcing user to enter data just to increase completeness ◦ allow users to leave blank fields where can provide results ◦ Simple example: surveys  Why not force respondents to answer all questions? ◦ Why do I have to enter my cat’s name to compare foods? Make all required data entry a business decision!

 Forcing user to confirm actions ◦ Provide undo ◦ Confirmation is necessary when  operation has no inverse: removing table from database  dangerous actions are about to take place (industry, military, etc.): Launch ICBM?  Allowing user's actions to result in an error ◦ eg: being able to check out when ordering cart is empty ◦ Disable actions that make no sense  Unnecessary restrictions ◦ Excel: only allows one file to be open with same name at a time, even if they had different paths ◦ Why even restrict opening same file multiple times?

 Switching windows, finding menu items, browsing for files  All navigation is excise ◦ Remember goal: keep user "in the flow" ◦ Games may be the biggest exception to this… ◦ Cause: restrictions of I/O devices ◦ Navigation is also excise in web sites!  Me: could navigation be the number one user interface problem? ◦ Many applications doing better about flow, orchestration  lots of imaginative tools and feedback in "dusty corners" ◦ Multiple frames, toolbars, menus: users have to search to find needed tools

 Navigation between windows: very disorienting ◦ Multiple windows: hard to keep track of where things are ◦ Increase chances of searching for needed information ◦ Must pay careful attention to what information is where  Navigation between panes: ◦ Better, but many panes = confusion ◦ Splitters: lots of adjustments ◦ But useful: can get all useful information on screen at once

 Tabbed panes ◦ Useful if tab labels are meaningful and displayed well ◦ But consider MS Word 2003:  Clicked all tabs to find settings  Lots of engineering decisions on how to classify items

 Obviously: frequent operations on toolbar ◦ How many use toolbar cut & paste?  Must: minimize mouse movements ◦ Use right mouse button for context-sensitive controls  Hierarchy on toolbars is dangerous ◦ Photoshop elements & hidden paint bucket  Allow toolbars to be reconfigured ◦ Standard: add, remove, reorder items ◦ All operations must be in menus!

 Issue: how to navigate through lots of information? ◦ Scrolling: useful tool, but think before using ◦ Separate pages: good if appropriate for user model  do a cluster analysis - keep most related things together ◦ Linking: visual context cues paramount  In browser: provided by address bar, page style

 Basic principle: navigation is excise  Avoid: navigation between windows  Manageable: navigation between panes  Tools & menus: minimize mouse movements  Information: analyze what’s being presented

 Ways: ◦ Reduce # places to go ◦ Provide signposts ◦ Provide overviews ◦ Map controls to functions carefully ◦ Avoid deep hierarchies  Will consider each…

 Minimize number of pages and windows  Minimize number of panes to be placed adjacent to each other ◦ Visual Studio: makes user work out what's needed!  Limit number of controls on screen to what's really likely to be used ◦ Let user decide…  Minimize scrolling  Avoid zooming; make discretionary, not required  In general: minimize mouse miles and clicks

 Visual cues on page for status, hints on what to do next ◦ Put operations next to data to be manipulated!?  Web pages: make each distinct page look different ◦ Difficult to find a room in a building where all walls are gray!  Common signposts ◦ Menus: reliable, consistent way to get at operations  Generally fix menu content - keep those seat ejectors hidden  If do add to menu on the fly, add at bottom ◦ Toolbars  Caution: protect against removal  Early versions of Netscape allowed accidental removals ◦ Breadcrumb navigation (esp. web pages) Breadcrumb navigation  Overviews – also an effective tool for orienting user ◦ Thumbnails – see lower right corner in Rational Rose diagram editor

 Consider: ◦ Make target of control obvious from control placement  Sorts: separate menus for type, direction ◦ Definitely not: “sort ascending, sort descending” ◦ Better: “oldest first, smallest first, largest first”, etc.

 Deeply nested hierarchies intimidating to most users  Solution: define collections, chose collection first  Some hierarchy is ok! ◦ People understand category & subcategory ◦ Problem: circular reasoning behind “a directory is a folder with files and other folders in it”

 Reduce number of places to go ◦ Minimize pages, windows  Provide signposts ◦ Visual cues for status, context, hints of where to go  Provide overviews  Map controls to function carefully  Avoid deeply nested hierarchies

 Problem: current file/save reflects our model  How to improve? ◦ Auto-save document  Provide (hidden) backup copy for abandoning changes  Support Control-S for the paranoid  EVERYTHING undoable, including abandoning changes ◦ Remove Save As…  Allow user to change name on title bar  Add explicit operation to move file location  Make document format a property

 More improvements ◦ Store revision history with file  Allow user to name milestones in history ◦ Provide publish operation to publish w/o history  New File menu: ◦ New, Open..., Close, Rename/Reposition, Make Snapshot Copy | Print | Make a Milestone, Revert to Milestone | Abandon Changes | Document Properties... | Exit  A good idea? ◦ People resist these sorts of changes!  How many people still complain about the Office ribbons? ◦ Users likely to learn a new model quickly!

 Removing excise ◦ GUI, training, computer, visual, errors, notifiers, confirmations  Implementing undo ◦ Command pattern  Reducing navigational excise ◦ Fewer places to go, signposts, overviews, mapping, avoiding hierarchies  Improvements to File menu