CSSE 574 Intro to Usability Bass s perspective and the ID book s perspective

Transcription

1 Steve Chenoweth Week 9 CSSE 574 Intro to Usability Bass s perspective and the ID book s perspective Right Desktop computer usability metaphor, from 1

2 Usability Software usability from Bass s perspective SA Ch 11 Lots and lots in the ID book, which we ll also highlight Bass is an expert on usability and architecture. See publications at Right - Ballbarrow in the 1970 s, ball vacuum 30 years later! Both James Dyson designs. From gizmodo.com/345918/. 2

3 Usability is last in Bass s QA list Bass s list of the seven big ones: Availability Interoperability Modifiability Performance Security Testability Usability Not this Bass After this, you ll have a full grip on Bass 3

4 What s Bass say about this QA? Problem How easily can a user accomplish a desired task? This needs to be attacked systematically: E.g., a consistent user interface Architectural choices about what data is available when & where Goals Both efficiency and effectiveness For heads down users time is money For power users can they do novel / infrequent things? Motivation The system is often sold based on gains in user efficiency or effectiveness. Scenarios What you need to develop, to understand how usability affects your system. What is Usability about? What are some good tactics? Or this Bass 4

5 Bass s usability scenarios Source: end user Stimulus: wish to learn/use/minimize errors/adapt/feel comfortable Artifact: system Environment: configuration or runtime Response: provide ability or anticipate Measure: task time, number of errors, user satisfaction, efficiency Or this Bass 5

6 Example scenario Source: Users Stimulus: Minimize impact of errors Artifact: System Environment: At runtime Response: Wishes to cancel current operations Response Measure: Cancellation takes less than one second Heavens! Not this Bass 6

7 Which brings up How do you tuna Bass? Not even a little bass. 7

8 Usability situations A runtime attribute: Learning Using efficiently Minimizing errors Adapting to user needs Increasing confidence and satisfaction Probably too optimistic To be a software architect. (Lance Bass of N Sync.) 8

9 Bass s tactics to achieve usability Strategies: Design time Separate UI from rest of system [sound familiar?] Client / server Model-view-controller Presentation-abstraction-control Seeheim and Arch/Slinky See Patterns.pdf. Runtime Support user initiative Cancel, Undo usability commands System must listen for these Can t be blocked by ongoing actions Feedback on what s happening Support system initiative User/System/Task models (that s 3 different ones!) What is the user expecting to happen? Predict user intent or response Encapsulating such things, so as to change the models easily Tailoring dynamically based on past user behavior Wait That s him! 9

10 Ideas from the ID book Usability is an inexact science Always requires direct study of the intended users! Maybe their thumbs aren t opposing? The ID book is Interaction Design: Beyond Human-Computer Interaction, 3 rd Ed, by Rogers, Sharp and Preece (Wiley, 2011). Right Funny watering can, from 04/nokia-menu-usability/. Could it work for us? 10

11 Typical usability design strategy 1. (Re)guess the model in the users head. 2. Build a system prototype based on that. 3. Try it out on them. a. Get feedback on what they really are thinking. b. Analyze your model. Graphic from Model from 11

12 What s the model look like? Your predictive model should discuss the following aspects of users: How they will understand the problem space. What they will say their usability goals are? What interface metaphor describes your system? What design principles are a part of your interface, which you think users will notice or like? Which of the four interaction types did you use, and why did you believe this was a good choice, based on the problem space? What aspects of cognition will predominate in user activity? How do aspects of Norman's mental model apply? Ease of use: How readily you believe they will be able to work with your system, with minimal help. What mistakes do you think they will make, if any? 12

13 What should your interview questions look like? Leading to confirming or denying the model! There are 3 parts to each interview: Part 1, before showing them your system, Part 2, where they try using your system, Part 3, after working on your system. So there s a slightly different flavor to questions for each! E.g., in Part 1, try hard not to bias them Typical - target 20 minutes per subject, for a simple system. 13

14 Back to building the model A few key tips from the ID book about this task How they will understand the problem space. What they will say their usability goals are? What interface metaphor describes your system? What design principles are a part of your interface, which you think users will notice or like? Which of the four interaction types did you use, and why did you believe this was a good choice, based on the problem space? What aspects of cognition will predominate in user activity? How do aspects of Norman's mental model apply? Ease of use: How readily you believe they will be able to work with your system, with minimal help. What mistakes do you think they will make, if any? 14

15 How users will understand the problem space You may think this is clear, because You ve been working on a particular solution for a while now, And so you ve assumed what the proper problem is, that this solves. But, you need to write this problem def down, to start your model. (A sentence or two.) And in your questions, you need to open with some question like, So, what overall problem does a cell phone really solve for you? See Sec 2.2 in the ID book for more ideas. 15

16 What they will say their usability goals are Consider general areas like: Effectiveness Efficiency Safety Utility Learnability Memorability And the related questions for users: Along the lines of, Then, what in particular would you use a cell phone for, if you could? An equally valid usability goal? Fun! See Sec in the ID book for more ideas. New Yorker cartoon from 16

17 What interface metaphor describes your system? In your model, try to phrase it in terms a user might say, so you can compare later. It s like a telephone, only you can walk around with it and text with it. Or, drive and crash your car See Sec in the ID book for more ideas. New Yorker cartoon from 17

18 What design principles are a part of your interface, which you think users will notice or like? Visibility Feedback Constraints Consistency Affordances Some attribute of your system gives clues on how to use it like a area of the screen looks like a button Left - IWC Skeleton Watch too much Visibility? See See Sec 1.6.3, pp , in the ID book for more ideas. 18

19 Which of the four interaction types did you use, and why did you believe this was a good choice, based on the problem space? Instructing The users issue the instructions Conversing Like a phone call Manipulating Like drawing in Photoshop Exploring Like 3D worlds, or Googling Which one? See Sec in the ID book for more ideas. 19

20 What aspects of cognition will predominate in user activity? All the things your users will do in their heads as they use your system. Describing this the core of your mental model. Try to describe what they will think in terms you can compare to what they say as they use it. See Sec 3.2 in the ID book for more ideas. 20

21 How do aspects of Norman's* mental model apply? Sec 3.3 has a bunch of these formal models. I just picked one for you to try out. Norman says users go through 7 stages of an activity: Establish a goal Form an intention Specify an action sequence Execute an action Perceive the system state Evaluate the system state with respect to the goals and intentions See Sec in the ID book for more ideas. *Donald Norman wrote a great book The Design of Everyday Things (1988). 21

22 Ease of use: How readily you believe they will be able to work with your system, with minimal help. What mistakes do you think they will make, if any? This really is a bunch of topics in the ID book, like: How efficient or effective to use Easy to learn Easy to remember Fun Not ambiguous Try to guess about this ahead of time, in your model. The users will try out your system during the interviews. This will give you ideas for improvements. See Sec in the ID book for more ideas. Right Chindogu tools always a riot! From 22