1. Tomorrow is October

3. Project Plan  Plan for the whole semester  Expect more detail closer in  Expect more accuracy closer in  Expect individual detail  Questions it will help answer Demos, slack time, early warnings

5. Test Plan  How are you planning to test?  What tools are you going to use?  How are you going to generate test cases? … starting the conversation …

6. User Manuals  Next level of detail from functional spec  What you plan to build  Can be in any form: FAQ, read.me, tool tips, doc.  Focus on end users, not admins

7. Demos Next Week  7 per day  Random draw  If you have a team member missing one day, let me know

8. Demos  What you are building  How you are building it  Demo

9. Tech Talks  Next week walkthrough with me Language game Road Amico Bricks Red Ribbon (Oct 12 okay)

10. Walkthroughs  Presentation and demo planned Who is going to speak Content of visuals  Give me the presentation

11. Presentation Reminders  You can use two projectors  Have something interesting for people to look at  Do not wing it  Look at Presentation Tips on the class site  Google Death by Powerpoint One of my favorites

13. Types of Interfaces  Computer-Computer Program APIs Network flows Files  Human-Computer Command line Graphical

15. Visualization and Information Design  How to present results Visualization usually refers to dynamically created results ○ Data ○ Information Information design usually refers to crafted piece ○ Edward Tufte Edward Tufte

16. Minard: Napoleon’s March to Moscow - Width of band shows size of army at each position. - Black band shows retreat tied to temperature and time

18. Program APIs  When do you need them? Should you build them into all systems? Consequences of not having them  Needed characteristics Backward compatibility: how do you extend? Checking: caller or callee?  Appropriate scope One with parameters or many?

19. Network Flows  Same considerations as APIs, but more so  Different machines will upgrade at different times  No control over the other side  Always identify level and negotiate support Base and towers  Use well-supported protocols FTTP, sockets, web-sockets, JSON, …

20. Files  See prior two pages: all the same  Added problems Files corrupted Files deleted Files edited  Use extensible formats preferably with readily available parsers

22. User Interfaces  “Human error” caused by bad design  Disasters 1987 Therac-25: too many messages => ignored the important ones 1995 airline crash: chose the wrong landing plan 2009 airline crash: pilot and co-pilot controls not connected

23. TextOther  Command line  Question and answer  Form based  Menu  Natural language  Speech  GUI  Gesture  Virtual reality  Augmented reality  Ubiquitous (unaware)  Perceptual Interaction Styles

24. GUI or not to GUI?  How often is the task done?  How many objects are handled at a time?  Physical limitations  Environment

25. What Makes a Good Design?  Consider designs you like (we know web designs, but the principles apply to any interface)  … and those you don’t  The Ugly Top 20 list Biggest Mistakes

27. The UI Iceberg Visuals InteractionTechniques Object Model Feel 30% Look 10% The things you use 60%  Toolkits and style guides help with look and feel, the tip of the usability iceberg.  Real usability gains come from system and application objects perceived by users.

28. Consider well-known sites  What is the object model? Ebay Amazon Facebook

29. User Interface Models  Object-action Choose the object and then the action to perform Windows GUI: select the file, right click for actions  Action-object Choose the action and then the object Windows command line: “copy” file_a file_b

30. Fundamental Concepts  What the user needs to do  The order that he does it  Is it natural?  How much does he have to remember?

32. 32 An Interaction Framework Output Input the system’s capability to output information Presentation the user’s ability to understand the output Observation the system’s ability to accept the input Performance the user’s ability to do the input Articulation images from www.dilbert.com and www.palm.comwww.dilbert.com

33. 33 Human traits Incredibly slow Error-prone Irrational Emotional Inferential Random Unpredictable Ethical Intelligent Computers and Humans Computer traits Incredibly fast Error-free Deterministic Apathetic Literal Sequential Predictable Amoral Stupid ideas from from The Inmates are Running the Asylum, A. Cooper, images from www.dilbert.com

35. 35 Memory  Human memory is limited  Miller's magical number 7 (+-2)

36. 36 Motor Skills  Easiest screen locations to point to?  Fitt’s Law – The time to acquire a target is a function of the distance to and size of the target.  Why do pop-ups work?

37. 37 Reasoning  Humans are not consistently logical.  Wason's cards 4E7K Given cards with: a letter on one side a number on the other Does a vowel on one side  an even # on the other side? What cards do you have to turn over to check this?

38. 38 Perception  Using Color: Some people are colorblind. Design in black and white.  Using Fonts: Make capital letters 2.3-5.2 mm high, lines ≤ 60 chars wide, & use ragged right. Use dark letters (not blue) on a light background. BLOCK CAPS only for non- words illustrations from Spoelsky, 2001 and www.innergeek.com

39. 39  Humanity is diverse.  People have different: languages cultural expectations color perception ergonomic needs abilities/disabilities ages Diversity

41. Disability Challenges  Visual Text color and size, contrast, eye-hand coordination  Movement Simultaneous key strokes, mistaken strokes  Hearing Audio cues  Cognitive and Language Complex or inconsistent displays, word selection  Seizures Light and sound patterns

42. General Requirements  Undo  Restore defaults  Minimize memory load  Easy access to frequent functions  Avoid unnecessary steps  NOT JUST ACCESSIBILITY ISSUES!

43. Keyboards  Keyboard shortcuts vs mouse  Changeable shortcut combinations  Tabbing order and items  Multi-key strokes

44. Mouse  Cancellable  Visual feedback  Target size

45. Graphics and Text  Customizable  Easily identifiable  Space between

46. Displays  Do not interfere with screen readers or accessibility tools  Make labels consistent and obvious Position Style Stand-alone and consistent  Screen-reader friendly Order  Do not depend on color

47. Other  Audio adjustable  Animation optional  Avoid flashing and blinking  Make focus clear  Clear indication of erroneous keystroke  Adjustable timing

48. Just good interface practices

50. 50 Jakob Nielsen Discount Usability (1993)  Basic elements: User/Task Observation Scenarios Heuristic Evaluation Simplified Thinking-Aloud Le mieux est l'ennemi du bien Voltaire, 1764 images from www.useit.com

51. 51 User Task Observation  Nielsen doesn’t explicitly list this step; he assumes it.  Customer Anthropology – the study of your customers' people and behaviours in their 'natural habitat'. “Customer Anthropology is a lot like birdwatching in that you want to try to make yourself invisible to those you're watching - Dave Pollard, salon.com image from www.salon.com

52. 52 Scenarios  Nielsen sees this as a form of prototyping.  He suggests using either mockups or prototypes, provided that they are small.

53. 53 Heuristic Evaluation  Usability experts can review a design with respect to: Interface style guides General usability guidelines  Base the review on either: Mock-ups Prototypes  Approaches: Cognitive Walkthough

54. 54 Thinking-Aloud Protocols  Watch real users do real tasks using the system.  Have them talk about what they are doing and why. “A user interface is well designed when the program behaves exactly how the user thought it would.” - Joel Spolsky, UIDP image from joel.spolsky.com

56. 56 Interface Design Principles  Help the user learn the interface.  Put the user in control of the interface.  Make the interface robust.

57. 57 Learnability  The interface is useless if it is unusable.  Principles: Be consistent. Plagiarize. Establish meaningful defaults. Make functions visible or memorable. Make the mapping from control to goal clear. Encapsulate action sequences.

58. 58 Control  Users, particularly experienced users, want to be in control.  Principles: Allow the user to be efficient. Enable shortcuts and customizations. Cluster common features together. Give appropriate feedback. Reduce short-term memory load.

59. 59 Robustness  The system must deal with error.  Principles: Offer error prevention and handling. Support undo and redo. Provide good help and error messages.

60. Good Screen Design  Consistency: use of pull-downs vs. entry  Starting in the upper left corner: first thing to fill in  Simple navigation Grouping and alignment Keep related issues together  Hierarchy for importance  Pleasing visuals  Captions for clarity

61. TypecheckingsavingmmfCD BranchMain St. Elm St.High St. Privilegesnewsletter discountsquick loans First name Middle name Last name Street City State/county OK Apply CancelHelp Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. The content is all there…

62. checking OKApplyCancelHelp Account typePrivileges saving money market CD newsletter discounts quick loans Branch Main St. Elm St. High St. New Customers Name First Middle Last Address Street City State/county Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. But it can be better

63. Use of White Space  More advice than you could ever want Active and passive Classy vs. mass-produced Clutter or incomplete …

64. Mobile Apps  Examples that are Easy to use Hard to use  Errors Not knowing your audience Making it difficult to touch/manipulate Trying to do too much 64

66. Three Types of Windows Properties of automobile 189 PropertyValue BrandToyota ModelCamry ID893-8913-789014 Help Word ___________________ This screen All screens ABC alert message Caution: “age” must be < 120 OK Property – information only Dialogue – input from user and subsequent action Alert – information that needs to be seen before continuing. Developer determined.

67. Why Classify?  Use the right type of window  Consider purpose when designing Example: alert window must be seen; property window not as critical

68. Rollovers  Information that is optional and selected by the user  But it often can’t be copied.  It doesn’t remain visible.  Are those important for this usage? This is a rollover window, designed to provide on-the-fly amplification

69. 69 Multi-Level Undo  Problem The user makes a mistake in a more involved task and needs to back the changes out.  Solution Provide a multi-level undo capability. Pattern from Tidwell, 2005

70. 70 Progress  Problem The user is performing a process and would like to know how far they are.  Solution Build a progress bar that indicates the percentage completion of the task at 2 second intervals. Pattern from van Welie, 2000

71. 71 Wizard  Problem The user must perform an unfamiliar and involved task.  Solution Build a graphical, step-by- step widget that takes the user through the task, indicating progress along the way. Pattern from van Welie, 2000

72. 72 Preferences  Problem The user would like to control the general feel of an interface.  Solution Provide a parameterized way to tailor the interface in pre-specified ways. Pattern from van Welie, 2000

73. 73 Fisheye  Problem The user is working on parts of a large artifact and has trouble “seeing” it all.  Solution Provide a graphical view of the artifact that shows all parts, but magnifies specific ones. Pattern from salaakso, 2003

75. GUI Screen Design Process  Know Your User or Client  Understand the Business Function  Understand the Principles of Good Screen Design  Select the Proper Kinds of Windows  Develop System Menus  Select the Proper Device-Based Controls  Select the Proper Screen-Based Controls  Organize and Lay Out Windows  Choose the Proper Colors  Create Meaningful Icons  Provide Effective Messages, Feedback, Guidance, and Language Translation  Test, Test, and Retest Wilbert Galitz

76. 76 Joel Spolsky (2001) Joel on Software Usability, fundamentally, is a matter of bringing a bit of human rights into the world of computer- human interaction. images from www.joelonsoftware.com What’s the Big Idea