Different learning curves • We want the learning curve to go up as quickly as possible • This indicates user are achieving competency quickly • If competency is not achieved quickly enough, user may become frustrated and abandon the software UWO Computer Science Department 11

Screen Shots • Give a reader/implementer an idea of the “look” of the system • Can be done with graphics, just ASCII text, hand-drawn, etc. • Generally a static screen shot by itself not very informative • Designer may know what everything on screen means • Reader does not necessarily know • Thus, have to describe what the reader is seeing in text accompanying screen shot UWO Computer Science 33

Screen Shot Example: Calendar Program Graphical Interface User clicks on day to select day Current month and year Selected day highlighted Buttons to select type of list display List Display User clicks on line to highlight line Add/delete/modify line UWO In your screen shots, indicate what each part of the screen is used for. Computer Science 34

Text vs. Graphical User Interface Text used to be the only mode of interaction with computers In early 1980 s • Computers became fast enough to do fast graphics • Designers at Xerox produced Star computer (1981) ($16, 000) —Introduced desktop metaphor, used windows —Apple built on these ideas in Macintosh (1984) —Windows, icons, menus, pointers (WIMP) became standard vocabulary —Idea of a graphical user interface (GUI) was born Advantages of GUIs • All controls visible or easily accessible —Hence, better for novice or intermittent user • Designer can use visual and tactile metaphors —Examples: Screen = desktop in Macintosh, mouse = spray can in Paint applications —Helps user build up a correct user model quickly UWO Computer Science 36

But Text Interfaces are Useful Too • Level of difficulty of using text vs. graphical interfaces • Can be about the same for expert users • Text interfaces can be used without hands leaving keyboard • Hence, Windows “power users” prefer to use keyboard commands over menus and icons for many things; e. g. copy and paste • In many places, text is necessary or far superior; e. g. • Specifying formula for cell on spreadsheet • Selecting a pattern of file names —E. g. *UI*. ps for all file names containing string UI and ending in. ps • Thus, many GUIs have to use text in some places • Text interfaces are often easier to program • A bad GUI is worse than a good text interface • A GUI can still hinder the user from achieving their goals UWO Computer Science 37

Help the User by being Consistent Famous example of inconsistency • How do we eject a floppy disk on a Macintosh? • First version of interface (1984): —Select “eject”; causes disk icon to be grayed out —Drag grayed-out icon in trash if not needed • Second version: —Just drag disk to trash! —Inconsistent – looks like we are throwing away all data on disk Another example from hypothetical system: • Command “d” means display in one context, delete in another. • Postini at Western • Could easily lead to user deleting things they wanted to display • Also, if command syntax not consistent throughout, system will seem unpredictable: e. g. in pine: page up/down commands are mode dependent Moral: without a consistent interface: • Users find it hard to build up correct user model • Users can make errors of intention UWO Computer Science 38

Text Interfaces Choose Good Command Names DO NOT use numbers as command names • They are hard to remember • Hard to find in lists • Easy to make mistakes when typing • Just generally extremely irritating to the user Don’t use meaningless letters either • E. g. a= move forward; b=move back; c=add Use command names which indicate what commands do! E. g. • Forward = move forward • Backward = move backward • Add = add When might you use number? • When choosing among items of the same type • e. g. selecting a particular appointment in a list UWO Computer Science 39

Let the User Control Things! Always let the user be the one choosing what happens next Example of a bad system: to enter appointment: • • • User: System: User: System: add Enter start time. 11: 00 Enter finish time (realizes start time was wrong, presses enter) Invalid time entered. Enter finish time 11: 30 Enter description • … In above example, user has no control over what happens next for a short time • User must enter meaningless answers to questions • User becomes frustrated • System is hindering user from doing what they want Note, this loss of control can happen in a GUI too • Example: system pops up sequence of confusing boxes UWO Computer Science 40

User Control Better: let the user enter all information themselves, on the command line • Text example: add 10 am 11 am Board Meeting • Graphical example, box with controls for the three inputs (start time, end time, description) —Controls for times can be either input fields or more graphical • Both allow user to select inputs on their own time • Text example allows them to edit line before entering If the system must ask the user a question: • Let the user “cancel out” or “select default” in some natural way —E. g. typing “return”, clicking “Cancel” button • Give example of legal and sensible (default) input value • Example: see example of text user case —User just enters start time for appointment —Can easily select 1 hour appointment or enter more info to change length UWO Computer Science 41

Give Meaningful Feedback Basically two kinds of feedback: immediate and state feedback: • Immediate: Reaction at the time the user does something —Examples: - GUI button acting like it has been pushed - Text response confirming action has been completed —Without immediate feedback, user can’t tell whether what they have done has worked • State: tells the user what state the system is in. —Examples: - Different screen layout when in “weekly goals” mode - Paint program cursor taking different shape when user selects different icon —Helps user maintain accurate model of status of system. UWO Computer Science 42

Feedback Example: Processing Delays Assume that: • User does some action • System has to do a lot of processing before getting back to the user. System might just do nothing when user does action • User wouldn’t be able to tell whether it’s processing or if their action “didn’t work” One solution for text interfaces: • Print prompt (e. g. >) whenever ready for command • Until user sees prompt, user knows system is processing • Could also display message indicating a delay Loading, please wait … One solution for graphical interfaces: • Make a change indicating passage of time —Cursor becomes hourglass, icon shows falling stars, displays a percent done bar, etc. • Change back when processing done UWO Computer Science 43

React Well to Errors There are many ways (good and bad) that a system can react to errors Example error (in day planner system): • User tries to move past last valid day of calendar Examples of good reactions: • Helpful messages: e. g. “Cannot move past last day” —Allows the user to see what they did wrong —Decreases the severity of the error • Helpful suggestion: e. g. “See your systems administrator to extend timeline of calendar” —May help user achieve real goals —May help user learn • Use auditory feedback where appropriate (e. g. beep) —Good if user recognizes that this means something like “You’ve tried to go past the boundaries” UWO Computer Science 44

Errors Example: Bad Reactions Bad examples: • Useless message; e. g. Traversal error 42 – huh? ? —Uses obscure jargon, code numbers —Gives no indication of what went wrong —User can’t tell if error is severe or not —User doesn’t learn much • No response —Difficult for user to understand what happened —frustration • System crash —Obviously not a good thing • Incorrect non-crash behaviour; e. g. moving to year 0 —User might not see that something has gone wrong —System might go on for a while, then crash —User has no chance to learn what went wrong —System has prevented user from doing what they want • This last reaction is possibly the worst • Good reactions take more programming, but are much easier on the users UWO Computer Science 45

Evaluating User Interfaces Produce detailed screen shots Produce detailed use cases Keeping in mind design guidelines, ask yourself: • Does the interface help the user achieve their goals? • Does it avoid hindering the user? • Does it make errors more avoidable, less serious? • Does it help the user learn? • Does it encourage a consistent user model? If we can answer yes to all of these, interface will be useful Alternative to screenshots and use cases: a prototype for the customer to try out • Mock up of final product • Simulates look and feel of the user interface • Brings many complex interaction problems to light • Still time to redesign based on customer reaction UWO Computer Science 47