LECTURE 8, SOFTWARE SYSTEMS PROBLEM/USER ANALYSIS

Transcription

1 September 29, 2014 LECTURE 8, SOFTWARE SYSTEMS PROBLEM/USER ANALYSIS 1

2 Recapitulation Lecture #7 Windowing Systems Room Building concept Windows Widget Set Event Handling, Event Based programming Model View Controller Architecture Icons Types Meaningfulness Classification Other Iconic representations 2

3 Icons Classification (ISO/IEC Based) Icons Interactive Non-interactive Object Pointer Control Tool Status indicator Container Data Device Folder In-basket Document Chart Spreadsheet Printer Phone Selection Text Graphics Cut/copy/paste Spell-check Up/down arrow Fill Eraser Pencil Hourglass LEDs Examples 3

4 Iconic Messengers, Attention Aids Structured abstract messages to communicate complex information to either of the senses of the users Icons visual Earcons audio attention Tacticons haptic appeal to a known touch Emoticons emotion convey emotional state Micon dynamic process visibility Gesticons dynamic indicate a state change Kineticons dynamic state change, process Some are more suitable to (visually) impaired users 4

5 Icons in a GUI Good Practice Sufficiently Large: Finger-operated UI, Pointing Device-operated UI Icons save space; compact toolbars Fast to recognize Standard Icons International Avoid cultural differences Visual Pleasing Product Family 5

6 Iconic Messages & Affordance Icons give rise to a perceived affordance Tactons/Earcons trigger actions Kineticons trigger signal in interactivity Affordance Visibility Iconic Messages Crucial interactive elements Important for interface, enhance experience 6

7 Using Icons to enhance Metaphor The BumpTop interface Pile as organizational entity Icon to invoke physical interaction Pen/Gesture based Appeals on gestalt of physical entities on desk Physical properties of icons 7

8 Example: Icon Affordance 8

9 Gestures and Affordance Relation of Object with Gesture Could do with object Would do with object Affordances Visibility Consistency Mapping Do we have a Gesture Alphabet? Device consistent Transferable, from one device to next 9

10 Leap Motion, Gesture Input 10

11 Example: Application of Gestures Fitz Law: 11

12 THE SOFTWARE LIFE-CYCLE 12

13 The software lifecycle Systems development Waterfall Lifecycle model Spiral Lifecycle model Star Lifecycle model HCI and software development User Centered design User analysis, Task analysis Prototyping, Dialog analysis Evaluation, Usability testing 13

14 Fundamental Activities of Interactive System Design 1. Information gathering and model building 2. Synthesis (or enhancement) of a solution 3. Analysis (or evaluation) of a solution 1-3 are iterated activities 14

15 Balance in Efforts Detailed design 10% 30% 60% Conceptual design Presentation ( Look ) Visual representations Aesthetics Interaction ( Feel ) Interaction techniques Standard menus Conceptual ( Ideas ) Metaphors Object attributes Relationships Behaviours Design proceeds mainly from the bottom level up 15

16 Traditional Approaches SADM = System Analysis Design Methods Number of stages: process in linear fashion problem definition information gathering (conceptual models) synthesis of solution + implementation evaluation of solution Examples Waterfall model Spiral model 16

17 6 phases in software lifecycle 1. Requirements definition 2. Specification 3. Implementation 4. Testing 5. Installation 6. Maintenance 17

18 HCI Life-Cycle Design = process of developing Artefacts = various representations of artefacts during design Look at user-centred design and the HCI lifecycle focusing on development and design Development = producing range of representations until suitable artefacts is built Representations (models): formal + informal Users Model of users Look at several models for the design process 18

19 Watch what happens 19

20 Watch what happens 20

21 What did we learn... How do we need to obtain requirements? Who is in controll of the process? Who is involved in the process? Final state, what to deliver... We have to accept that software development is iterative and involves end-users Different models of software life cycle Style of Managing the development process 21

22 Can we better control software development and thereby user interaction 22

23 Waterfall Lifecycle Model Each step contains validation and verification Validation: check product to ensure results are conform requirements Verification: correct/consistent representation of previous stage Typically contract model Sensitive to ambiguity (natural language) Not embedded in Organization Not sensitive for organizational changes due to introduction of system Initiated by board and/or corporate management 23

24 The Waterfall Model Validation and Verification at each representation step. 24

25 Spiral Lifecycle model Introduces concept of iteration Iteration Introduces concept of prototyping Prototyping, understanding requirements for next stage Offers solutions to management Risk management Which elements have highest probability of not being correct Which elements have highest cost for correcting Controls problems 25

26 The Spiral Model 26

27 But, the question remains, where is the user in this story? 27

28 Where is the User? In traditional design, Users play a minor role Emphasis on technological technical aspects Prescriptive in sequence HCI requires User-Centered design Emphasis on user and usability Requires user evaluation after each developmental phase Star Model: Descriptive rather than Prescriptive 28

29 The Star Model problem idea Task analysis / Implementation Functional analysis Prototyping (USER) Evaluation Requirements specifications Conceptual design / Formal design 29

30 The Star Lifecycle model No predetermined starting/end point Each of the activities Each activity has evaluation: including users! Based on iteration Order of the activities not fixed Reflects actual practice User Centered Design Professionals Rapid prototyping Alternating waves (bottom up - top-down etc.) 30

31 Typical HCI Approach Identify issues of practical effectiveness Identify usability factors Speed Error rates No formal system Prototype Sketch design For design components formal systems are used Concentrate of Interface & Interaction Quality 31

32 Low-Fidelity Prototype 32

33 HCI Design & Life Cycle U s e r P a r t i ci p a t i o n Problem statement Systems Analysis (incl. user and task analysis) Requirements spec. (incl. usability specs.) User object modelling System design spec. (inc. Interface design spec.) User s conceptual model design / Interaction style Interaction design / Presentation design Prototype (inc. online help) Evaluation (Analytical, Empirical) Analysis Definition Design Implementation 33

34 Systems Analysis ~ HCI Systems Analysis Identifies entities of significance to system Functionally oriented, data driven Design notation: to be understood by systems analysts Dataflow diagrams Entity relation diagrams Resistance by future users HCI perspective Identifies issues of practical effectiveness Usability oriented, user driven Design notation: to be understood by users Task diagrams Scenarios Screen sketch Prototype 34

35 Interaction Design = Designing interactive products to support people in their everyday and working lives. Design vs. software engineering? architects vs. civil engineers Concerned with designing good interface (cf. chap.14) what is good? take into account where will it be used? who will use it? (what are they good at, what do they do now, what do they want, use tried and tested techniques, etc.) prototyping evaluation: user centered! usability testing 35

36 Two Crucial Errors Assume all users are alike User Centered means that we accept that people differ in cultural background, physical ability, etc Assume all users are like the designer Also consider the discrepancy in engineering and designing Therefore: User in center of development 36

37 Review #8a Software lifecycle Effort spend on design HCI lifecycle Waterfall, Spiral, Star Model Perspective for HCI: User Centered design User analysis, Task analysis Prototyping, Dialog analysis Evaluation, Usability testing 37

38 38

39 Including the user in the development loop USER DRIVEN SYSTEMS ANALYSIS 39

40 Design & Analysis Design process of developing artefacts (lecture 9,10) various representations of artefacts during design achieving goals with constraints For design analysis is required Analysis Bring about the key issues of artifact User involvement Use Personas, Scenarios, Storyboarding Look broad: Stakeholders 40

41 Design Conceptual Design Physical Design Operational design Representational design Interaction design Envisionment Evaluation (typically the Star Model) Implementation 41

42 Conceptual Design Considering Information and Functions Making abstractions Whatdo we expect from the user Communication of Conceptualization = Mental Model Metaphoric concepts Modeling 42

43 Physical Design How is it going to work Can lead to a detailed look and feel Structuring interaction Logical sequences Allocation of functions Requirements for Software and Hardware Tasking activities 3 sub components 43

44 Physical Design Components Operational design How everything works How everything is structured/stored Representational design Shapes, Icons, Colors; Style Aestatics Information layout Interaction design Allocation of function to Human/Technology Structuring Relates to Envisionment 44

45 Interaction Design Interaction design concerned with : allocation of functions to human agency or to technology the structuring and sequencing of interactions. Allocation of functions has a significant impact on how easy and enjoyable a system is to use. Designers create tasks for people by the way they allocate functions 45

46 Interactive System Development User: Domain expert Interaction design User Interaction developer User Interface software developer 46

47 Stakeholders Anyone affected by success/failure of system. Primary stakeholders End users Secondary stakeholders Input/output related; do not use system, get output Tertiary stakeholders Management level, i.e. directly affected Customers Competitors Facilitating Design, development, maintenance 47

48 MODEL USER: THE PERSONA 48

49 Persona s Hypothetical Archetypes Archetype: An original model or type after which other similar things are patterned; a prototype An ideal example of a type; quintessence A precise description of a user and what they want to accomplish Imaginary, but precise Specific, but stereotyped Real people have non-representative quirks 49

50 Persona s in Essence Describe a person in terms of their: goals in life (relating to a project) capabilities, inclinations, and background People have a visceral ability to generalize about real and fictional people detailed discussions about what e.g. James Bond, will think or do. not 100% accurate, but it feels natural to think about people this way 50

51 Motivation for Persona s A compromise design pleases no-one The broader you aim, the more likely to miss the bulls-eye Every time you extend functionality to include another constituency, you put another speed bump of features and controls across every other user s road. There is no such thing as an average user Avoid elastic user unspecific description tends to suit the design needs of the moment Persona helps to prevent designer and/or programmer from imagining they are the user 51

52 Persona s Tom Jos Henk Toos(aka Ingrid) Design Team, Evaluation Team 52

53 Example Persona Ingrid is 37 years old, She has been Warehouse Manager for five years and worked for Simpkins Brothers Engineering for twelve years. She didn t go to university, but has studied in her evenings for a business diploma. She has two children aged 15 and 7 and does not like to work late. She did part of an introductory in-house computer course some years ago, but it was interrupted when she was promoted and could no longer afford to take the time. Her vision is perfect, but her right-hand movement is slightly restricted following an industrial accident 3 years ago. She is enthusiastic about her work and is happy to delegate responsibility and take suggestions from her staff. However, she does feel threatened by the introduction of yet another newcomputersystem(thethirdinhertimeatsbe). 53

54 MODEL OF SYSTEMS USE: SCENARIO 54

55 Scenario Definition: informal narrative description describing human activities/tasks With respect to requirements and context a scenario allows: Exploration Discussion Can be understood by all stakeholders 55

56 Scenario's Scenario's are stories of rich design Simples design representation Flexible Powerful Short Scenarios: single situation Descriptive for whole interaction Force think about design in detail Notice potential problems Conflicts 56

57 Scenarios in Systems Analysis Adding detail What does the user want What is the user intending with this particular action in relation to this aims What is the system doing now How should a system respond Is the ideal response part of out design Are all tasks accounted for 57

58 Using Scenario's Communicate with others designers, clients, users Prevent misunderstanding / mismatching Validate other models Use scenario in formal approaches Express dynamics Introduce behaviour of the system Scenarios are linear (and so is time) Single path in the system Often there are more routes! Explore this 58

59 Scenario movie player Brian would like to see the new film Moments of Significance and wants to invite Alison, but he knows she doesn t like arty films. He decides to take a look at it to see if she would like it and so connects to one of the movie sharing networks. He uses his work machine as it has a higher bandwidth connection, but feels a bit guilty. He knows he will be getting an illegal copy of the film, but decides it is OK as he is intending to go to the cinemato watch it. After it downloads tohismachinehe takes out his new personal movie player. He presses the menu button and on the small LCD screen he scrolls using the arrow keys to bluetooth connect and presses the select button. On his computer the movie download program now has an icon showing that it has recognized a compatible device and he drags the icon of the film over the icon for the player. On the player the LCD screen says downloading now, a percent done indicator and small whirling icon. 59

60 Scenario movie player Brian would like to see the new film Moments of Significance and wants to invite Alison, but he knows she doesn t like arty films. He decides to take a look at it to see if she would like it and so connects to one of the movie sharing networks. He uses his work machine as it has a higher bandwidth connection, but feels a bit guilty. He knows he will be getting an illegal copy of the film, but decides it is OK as he is intending to go to the cinemato watch it. After it downloads tohismachinehe takes out his new personal movie player. He presses the menu button and on the small LCD screen he scrolls using the arrow keys to bluetooth connect and presses the select button. On his computer the movie download program now has an icon showing that it has recognized a compatible device and he drags the icon of the film over the icon for the player. On the player the LCD screen says downloading now, a percent done indicator and small whirling icon. 60

61 Scenarios: Text Video based Example, uni.me Question: What if a mobile phone could provide easily glance-able information of people s availability? Designed in 2006 Ana Camila Pinho Amorim uni.me, a new mobile communication service centered on people s availability 61

62 Scenario in uni.me mobile system 62

63 Types of Scenarios (4 types) Stories Real world experiences, ideas, anecdotes Capture snippets of activities Conceptual Scenarios Abstraction, to understand design/requirements Stories with context stripped away Concrete Scenarios From a conceptual scenario Onset of interface design; Function allocation Use cases Reports about use of the system and interaction Different context Specification of functional design. 63

64 Make sure we can get concrete... PROBLEM STATEMENT 64

65 What is it all about really! 65

66 Problem Statement Human activity: what activity is supported Users Level of support to be provided Form of solution Statement of overall goal of whole system in a single phrase or sentence Aim: show clear understanding of what is needed Main assumptions should be separately stated System evolves from problem statement 66

67 Problem Statement Example Design a cashing register that can be used in the student faculty bar (aka foo-bar), inexpensive, maintainable, easy to learn, wet environment Supported activity Cashing, Accounting, Users Students that work in the bar Level of support to be provided Register Payments Register Accounts for Events: operation(s) Add, Modify, Delete, View, Send accounts Connect with the mp3-player system Form of solution PC based, Touch screen, not too expensive 67

68 User Analysis (1) What is the level of expertise Novice Intermittent Frequent What is the familiarity with specific hardware and software What is the software they are familiar with Operating system Should they be exposed to the OS? 68

69 User Analysis (2) What is the job-related information access requirement Detailed information ~ Summaries What are the computing skills of users Typing, Texting What is the general educational level On the level of the organization: Users knowledge of the organization Users experience in the organization 69

70 User Analysis Example Bar Cash Register System User characteristics University Students in Math, CS, Physics, Astronomy Reasonable calculus skills No complete knowledge of everything offered. Only once in a while when they operate the bar Skills High general skill level (often) Very computer skilled Not all will have great keyboard skills Conclusions Keep it simple Functionality and usability greater than classical cashing register Minimize typing, and be quick and easy to learn (retention) 70

71 Cash-Register Example - Solution HCI project (rietveld-waaijer) Foobar Leiden Form of Solution: Touch screen Software on Mac, Touch screen based Interviews with users Observational studies flow & Task analysis 71

72 Register Foobar : FooCash 72

73 73

74 74

75 75

76 Data gathering: Conventional + HCI Read background material Guided tour of work environment Interviews Observation Questionnaires Forms analysis Verbal protocol Tape / Video recording / Transcript 76

77 Verbal Protocol - Video Recording 77

78 ANALYSIS FOR USER CENTERED DESIGN 78

79 People The PACT system Physical characteristics; Psychological differences Activities Temporal aspects Cooperative complexity Context Physical, social, organizational Technologies What i/o devices for communication/content 79

80 PACT Helps to understand the system From the design point of view Questions What people will use a system What activities people want to undertake What is the context of these activities What interactive technology Answers Make a relation between Activity and Technology 80

81 Spetember 29, 2014 STANDARDS & GUIDELINES 81

82 What are Standards? Standards: Proclaimed and introduced by international bodies Ensure compliance by large designers community Require sound underlying theory & slowly changing technology Hardware (common), Software HCI: ISO 9241 standard on Usability usability is defined as effectiveness, efficiency and satisfaction with which users accomplish tasks 82

83 Guidelines More suggestive and general Many textbooks and reports full of guidelines Principles: abstract guidelines applicable during early life cycle activities Style Guides: detailed guidelines applicable during later life cycle activities Acceptance guidelines: helps in finding a solution or resolving conflicts Let us do it by the book 83

84 Golden rules and heuristics Broad brush design rules Useful check list for good design Better design using these than using nothing! Different collections e.g. Shneiderman s 8 Golden Rules Norman s 7 Principles Nielsen s 10 Heuristics (usability related) 84

85 Shneiderman s 8 Golden Rules 1. Strive for consistency 2. Enable frequent users to use shortcuts 3. Offer informative feedback 4. Design dialogs to yield closure 5. Offer error prevention and simple error handling 6. Permit easy reversal of actions 7. Support internal locus of control 8. Reduce short-term memory load 85

86 Norman s 7 Principles 1. Use both knowledge in the world and knowledge in the head. 2. Simplify the structure of tasks. 3. Make things visible: bridge the gulfs of Execution and Evaluation. 4. Get the mappings right. 5. Exploit the power of constraints, both natural and artificial. 6. Design for error. 7. When all else fails, standardize. 86

87 Stakeholders Persona & Scenario Problem statement User analysis Introduction to PACT Design Guidelines To Do Review #8b Systems for Abstraction/Analysis Task analysis, Cognitive analysis, Dialogue analysis 87

88 Human (Computer*Computer) 88