CS 350 COMPUTER/HUMAN INTERACTION

Transcription

1 CS 350 COMPUTER/HUMAN INTERACTION Lecture 27 Includes selected slides from the companion website for Hartson & Pyla, The UX Book, MKP, All rights reserved. Used with permission

2 Notes Questions about the group project? IOTA course evaluations Schedule reminders: Next Tuesday, April 24, is final presentation day and the last class. Final report (in hardcopy) and code (installed on csserver) due by Tuesday, May 1, at 4pm (end of scheduled final exam period for this class). NO LATE WORK ACCEPTED. Final grades should be posted by Friday, May 4. 2

3 Outline Chapter 21 Interaction Cycle Chapter 22 UX Design Guidelines Planning Translation Overall guidelines Wrap-up 3

4 The Interaction Cycle Adaptation of Norman s stages-of-action model Characterizes sequences of user actions typically occurring in interaction Between human user and almost any kind of machine 4

5 Norman s stages-of-action model 5

6 The gulf of execution Language gap from user to system Desired effect (user goals and intentions) known in work domain What to do in system to make it happen? Need translation to convert From intentions in work domain To actions on objects in system domain 6

7 The gulf of evaluation Language gap from system back to user Observe system feedback about what happened in the system What does that mean in terms of meeting user goals? Need translation to convert From state changes in system To assessing outcome in work domain 7

8 The Interaction Cycle, an adaptation of Norman s model 8

9 Scope and universality Graphical user interfaces (GUIs) Web pages Hand-held or mobile devices ATMs, elevator buttons, highway signage Almost any kind of device or system 9

10 Planning Help users understand what system features exist and how they can be used in their work context Make clear all possibilities for what users can do at every point Help users plan most efficient ways to complete their tasks 10

11 Planning Design helping user know what to do User model and high-level understanding of system User goal decomposition Task/step structuring and sequencing, workflow Supporting learning at planning level 11

12 Planning Example: Tabs at top digital library Website pages not well organized by task 12

13 Planning Keep users aware of task progress, what has been done and what is left to do Provide cognitive affordances to remind users to complete transaction Example: Hey, don t forget your tickets 13

14 Translation Provide effective cognitive affordances that help users get access to system functionality Help users know/learn what actions are needed to carry out intentions Help users predict outcome of actions 14

15 Translation Design helping user know how to do something Existence of cognitive affordance Presentation of cognitive affordance (issues about noticeability, legibility) Content, meaning of cognitive affordance (issues about clarity, precision) Task structures for flexibility and efficiency 15

16 Existence of cognitive affordance Help users determine how to get started 16

17 Presentation of cognitive affordance About how cognitive affordances appear to users Not about how they convey meaning 17

18 Presentation of cognitive affordance Make cognitive affordances noticeable Status message lines often do not work Pop-up message next to cursor will be far more noticeable Make text legible, readable Mainly about font size, color, contrast with background 18

19 Presentation of cognitive affordances Give similar cognitive affordances consistent appearance in presentation Example: Original Gmail Archive button jumps around 19

20 Presentation of cognitive affordances 20

21 Content and meaning of cognitive affordance Use precise wording for clarity in labels, menu titles, menu choices, icons, data fields Example: adapt label to system state ( Marked for Deletion ) Label is declarative whether box is checked or not Better if label changes when checkbox state changes 21

22 Content and meaning of cognitive affordance 22

23 Content and meaning of cognitive affordance Provide cognitive affordances to indicate formatting within data fields What is the format for the effective date? 23

24 Content and meaning of cognitive affordance Make choices distinguishable Example: Tragic airplane crash unfortunate, but true, story October 31, 1999 EgyptAir Flight 990 airliner crash traced directly to poor usability in cockpit controls design 24

25 Make choices distinguishable Two sets of switches Similar in appearance Similar labels: Cut out and Cut off Located relatively close to each other Both switches are used infrequently, only under (different) unusual flight conditions Even highly-trained expert pilots would not be experienced with these switches Therefore, higher importance of cognitive affordances in the labels 25

26 Make choices distinguishable Theory of crash (from blackbox data) Hit a downdraft Attempted to pull plane out of unexpected dive Intended to set Cut out switches to stabilizer trim But accidentally set Cut off switches, shutting off fuel to both engines 26

27 Design issues Distinguishability of labeling, especially under conditions of stress and infrequent use Solution: add distinguishability by making labels more complete (add all-important noun) Cut out trim versus Cut off fuel Putting noun first even better: Fuel off and Trim out 27

28 Design issues Physical proximity of the two controls Inviting physical slip of grabbing wrong one despite knowing difference Stabilizer trim and fuel functions are completely unrelated Solution: Separate and regroup with related functions Further: Protect Fuel off switch; require additional physical action to access 28

29 Do not use multiple synonyms for same thing Consistency of cognitive affordance wording to convey meaning Use consistent wording in labels for menus, buttons, icons, fields Use similar names for similar kinds of things 29

30 Do not use multiple synonyms for same thing 30

31 Use consistent way for user to express similar kinds of choices Example: Circle all selections, but size choice is by check boxes 31

32 Control complexity with layout and grouping by function Do not group together objects and design elements associated with different tasks or objects 32

33 Content and meaning of cognitive affordance Be complete in your design of cognitive affordances Include enough information for users to determine correct action Use enough words for unambiguous labels Long labels are not necessarily bad Adding words can add precision 33

34 Content and meaning of cognitive affordance Example: what does revert mean and what are consequences of reverting? 34

35 Content and meaning of cognitive affordance Example: urgent but unclear question But what are the consequences? 35

36 Usage centeredness in cognitive affordances Employ usage-centered wording, language of user and work context Example: toaster system (at Harlaxton!) Users put bread on input side of a conveyor belt going in Inside, overhead heating coils Bread comes out other end as toast 36

37 Usage centeredness in cognitive affordances Some toaster systems Single control, a knob labeled Speed Additional labels Faster (clockwise rotation of knob) Slower (counterclockwise rotation) Translation across gulf of execution Slower moving belt makes darker toast because bread is under heating coils longer Faster movement means lighter toast 37

38 Usage centeredness in cognitive affordances Often observed confusion and amusement Concept of speed doesn't match mental model of toast making Why do we have a knob to control toaster speed? Why would anyone wait to make toast slowly when they could get it faster? Easy solution Use labels in user s work domain rather than in system domain Lighter and darker 38

39 Anticipate and avoid user errors with cognitive affordances in design Shampoo and conditioner 39

40 Anticipate and avoid user errors with cognitive affordances in design User-created affordances 40

41 Anticipate and avoid user errors with cognitive affordances in design Another design approach 41

42 Anticipate and avoid user errors with cognitive affordances in design Help users avoid inappropriate and erroneous choices Disable buttons, menu choices to make inappropriate choices unavailable Gray out to make inappropriate choices appear unavailable But help users understand why a choice is unavailable 42

43 Cognitive affordances for error recovery Provide a clear way to undo and reverse actions Offer constructive help for error recovery 43

44 Design task structure for flexibility and efficiency Provide alternative ways to perform tasks Provide shortcuts Provide keyboard alternatives to avoid physical switching actions But don t overload the possibilities Avoid grouping of objects and functions that need to be dealt with separately 44

45 Design task structure for flexibility and efficiency Task thread continuity Anticipate most likely next action, step, or task path If you tell them what they should do, help them get there Example: dialogue box message Tells user that page margins are too wide for printed page Suggests resetting page margins so document can be printed Therefore, follow up with button to go directly to page setup screen 45

46 Design task structure for flexibility and efficiency Efficiency Do not make user redo any work, reenter data Retain user state information Example: having to find folder you are working in, over and over 46

47 Design task structure for flexibility and efficiency Keeping users in control Maddening when applications or webpages steal focus with no indication of what happened Control jerked away and working context disappears Takes extra cognitive energy and physical actions to get back Can happen repeatedly 47

48 Physical actions Design helping user do actions Manipulating UI objects, making physical actions Fitts' law issues Issues of awkwardness and fatigue Haptics and physicality Accommodate physical disabilities Not all human users have same physical abilities Range of motion, fine motor control, vision, or hearing 48

49 Outcomes Internal, invisible effect/result within system Outcomes must be revealed to user via system feedback Where usefulness lives Functional affordance of non-userinterface system functionality Issues are about computational errors, software bugs 49

50 Assessment Design helping user know if interaction was successful Existence of feedback Presentation of feedback Content, meaning of feedback 50

51 Overall guidelines Simplicity Do not try to achieve appearance of simplicity by just reducing usefulness Organize complex systems to make most frequent operations simple Examples: phone systems, car radios Simple things should stay simple "For emergency road information, go to 1620 on your AM dial" 51

52 Overall guidelines Consistency Be consistent is one of most often quoted guidelines Things that work same way in one place as they do in another Just makes logical sense Not always clear what consistency means in given design situation Maintain custom style guide to support consistency 52

53 Overall guidelines Consistency Do same kind of thing the same way in different places Example: Next and Previous buttons for photo gallery These buttons are opposite in meaning But both are similar kind of thing, symmetric Go forward and Previous picture are not symmetric 53

54 Overall guidelines Consistency Consistency is not absolute Consistency can work against innovation Being the same all the time is not necessarily best 54

55 Overall guidelines Avoid poor attempts at humor Avoid use of anthropomorphism Avoid using first-person speech in system dialogue 55

56 Overall guidelines Avoid condescending offers to help Examples: Clippy and Bob 56

57 Overall guidelines Use positive psychological tone in dialogue Avoid violent, negative, demeaning terms Avoid use of psychologically threatening terms, such as illegal, invalid, and abort Avoid use of term hit ; instead use press or click 57

58 Overall guidelines Use of sound and color Avoid irritating and annoying sound and color in displays Use color conservatively Use pastels, not bright colors 58

59 Overall guidelines Use of color Be aware of color conventions (e.g., avoid red, except for urgency) Example: Am I on land or at sea? 59

60 Overall guidelines Use of color Watch out for chromostereopsis Focusing problem with red and blue At opposite ends of visual frequency spectrum Focus at slightly different depths within eye Difficult to focus on both at same time 60

61 Overall guidelines Example: chromostereopsis 61

62 Overall guidelines Text legibility Make font size large enough for all users Use good contrast with background Amazing how often this rule is broken in real designs Use both color and intensity to provide contrast Use mixed case for extensive text, not all caps 62

63 Overall guidelines Text legibility Avoid too many different fonts, sizes Use legible fonts Try Arial, sans serif Verdana, or Georgia for online reading Use color other than blue for text It is difficult for human retina to focus on pure blue for reading 63

64 Overall guidelines Accommodate sensory disabilities and limitations Support visually challenged, color blind users Allow user settings, preference options to control presentational parameters Accommodate different levels of expertise/experience with preferences 64

65 Overall guidelines Lead, follow, and get out of the way Lead novice users with adequate cognitive affordances Follow intermediate users with lots of feedback to keep them on track Get out of the way of expert users Don t let affordances for new users be performance barriers to experienced users 65

66 Conclusions Be cautious using guidelines Use careful thought and interpretation In application, guidelines can conflict and overlap Guidelines do not guarantee a good user experience Using guidelines does NOT eliminate need for UX evaluation 66

67 Wrap up: Connection with software engineering Three scenarios SE as primary product architects UX comes in at the end when it is difficult to change Easy to use is often is NOT easy to implement UX as primary product architects Designs can be blue sky, either pushing SE to update technology or resort to hacking existing infrastructure SE and UX as collaborators Both roles are essential and complementary Update each other during development/design process 67

68 Foundations for success in SE-UX development Communication Needs to be structured and managed Coordination Avoid duplicate work, e.g., interviewing users Avoid incompatible specifications 68

69 Foundations for success in SE-UX development Synchronization Early and often Implementation time is too late Dependency and constraint enforcement UX task requires SE specification SE specification reflects need for UX task 69