CSSE 477 – Intro to Usability Project 6 & what’s in the ID book

1. CSSE 477 – Intro to UsabilityProject 6& what’s inthe ID book Steve Chenoweth Monday, 10/24/11 Week 8, Day 1 Right – Funny watering can, from http://bayramannakov.wordpress.com/2007/06/04/nokia-menu-usability/. Could it work?

2. Today • Intro to Proj 6 • Pick what to do it on – • Your project, or • Something else with more I/D (e.g., Amazon) • Discuss on your team, and with your “implementers,” about “what should be more usable.” • Review of the ID book Right - Ballbarrow in the 1970’s, ball vacuum 30 years later! Both James Dyson designs. From gizmodo.com/345918/ .

3. Coming up… Tomorrow: Bass’s view on usability Time to work on the project First project turnin – what system you picked, your predicted model, plan to test that Thursday: Lots of time to work on the project, Friday: Describe user modelingresults (turnin is following Tues) Last biweekly quiz Right – Chindogu tools – always a riot! From http://www.boingboing.net/2006/05/04/chindogu-anarchic-wh.html.

4. Here’s Project 6, Usability part: I. Usability - Intro • The scheme for this part is as follows, which is notthe same as on projects 1 - 5: • Pick what system to do this study on. • Predict a conceptual model for “what your users are like” and then discover if you're right. The step-by-step description of "How to do the user modeling study" is below the deliverables section in this assignment. • If you still have your Interaction Design (ID) book from 371, this is all in Ch 1 – 3 (what they are), and Ch 8 (on how to analyze). • There’s a summary of all that in http://www.rose-hulman.edu/class/csse/csse477/lectures_377/ID%20mental%20models%20summary.ppt.

5. The arch doc part… II. Architecture document final draftThe idea here is to take the documentation you already have for your system, and do the final two things to it: • Find any places where you or your implementers think more development is needed, if the reader's goal is to be able to develop part of the code. While this is an architecture spec, not a detailed design spec, you still may find these areas. Highlight such changes in what you turn in, to make it easy to tell what you improved. Make at least two such significant changes (a paragraph each). • Clean up the document so all the "boiler plate" is gone and the format is correct. • When you are done, your implementers ought to be able to read the whole thing and "get it." Your clients should be able to read the higher-level parts and "get it"! • Unlike before, where you were adding new material in ways you might not be familiar with, there's only one turnin for this last arch document - the final one.

6. Let’s look more at the usability part Goal: Explore ways to conceptualize users of your system, and make practical use of such concepts: • What you currently believe they think and feel as they use it. • What they think: Their own expressed goals, and how they would try to accomplish those with your system. • How they act when using your system to achieve those goals. • How all the knowledge of all this can be combined into a revised model. • How that model can be used to describe useful changes to your interface. Model: What you think they think as they use your sys What they think they think as… Ideas for a better I/F Ideas for a better model

7. If you are systematic & lucky… • Users will give you some coherent feedback! • You could then use the resulting model of their interactions – • As a part of your design work • Make the right things into OO classes, etc. Real user OO model of user

8. All the detail… See Project 6: • IV. How to do the user modeling study • It’s like 5 pages of guidance & ideas • But it’s not that bad: Scope of this project: In order to leave time for you to work on the term paper and your report, you won't have to implement the changes in your program - just do this usability study. You can write it all up as an addition to your journal.

9. 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? • See examples on the last 4 slides of http://www.rose-hulman.edu/class/csse/csse477/lectures_377/ID%20mental%20models%20summary.ppt.

10. 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… • Target 20 minutes per subject.

11. What are the deliverables? Tomorrow (Tues) 11:55 pm -- • System: Yours or a better one for this, and why • Model: As your system's designers, try to guess the "users' model" of your system - what this will be like for them, as they work with the system. • Plan: Describe a plan for testing this model out with some actual users - at least 5. In the plan here, you should identify the following: • Likely subjects (in some way -- by name or by category - like "3 CS majors and 3 other students. " - More credit for mixing these with a more diverse audience, like non-students!"), • When you think you would do the testing (both people on the team need to be available), and, very importantly, • A list of questions you plan to ask (see "How to do the user modeling study," below). • Turn in your model and the plan to test it, in your “team journal” by 11:55 PM. Note: Nothing due here about the arch doc!

12. And Friday, 10/28, in class -- Before the biweekly quiz, each team will discuss how this went. We'll go around the room: • What mental model did you predict? • How did the interviews go? • What changes were needed to the model? • What else did you learn - like useful changes you could make to your system? Note: If I've wildly underestimated how long this project takes, this will become a time for status reports instead.

13. And Tuesday, 11/1, 11:55 PM – Suggested final turnin, with the following: • The final version of the arch doc, as described on slide 5, above. • Your study results added to your journal: • The model and plan, already in there from Tues. • Discussion of how the interviews went. • Discussion of the model you abstracted from the interviews. • What the major similarities and differences were with your prediction. • What changes you made to your original model, as a result. • The changes you would make to your system, if you could do that next. • Anything else you learned. • Organized interview notes, as an appendix, at the end. Note: If I've wildly underestimated how long this project takes, we'll extend the due date for turning this in.

14. Back to building the model… A few key tips from the ID book about your immediate 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?

15. How users will understand the problem space • You may think this is clear, because…on your system: • 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.

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 1.6.1 in the ID book for more ideas. New Yorker cartoon from http://www.cartoonbank.com/.

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 2.3.3 in the ID book for more ideas. New Yorker cartoon from http://www.cartoonbank.com/.

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. 29-33, in the ID book for more ideas.

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 2.3.4 in the ID book for more ideas.

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.

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 3.3.2. in the ID book for more ideas.

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 1.6.1 in the ID book for more ideas.

23. Finding diverse users to study – easy or hard? • How often do you interact with people who are really different from you in ways you didn’t expect, as you’re doing your projects? • If they are other engineering students, they may be way more like you than your users will be. • Same problem occurs in industry – getting other developers to look at your interfaces, say. If they like them, are they ok? • Where else can you find usersfor this study? Hey – check out this new help feature I added!

24. How common is the problem of diverse users in industry? Most of you will create products for a wide audience, e.g., Rose CSSE alums are working at: • Writing compilers for Green Hills Software • Users are all systems people, but from many different countries • Writing desktop aids for people with disabilities, for Microsoft • Users have a huge range of special needs • Product-managing aircraft control software for Rockwell Collins • The cultures of the aircraft companies who build the planes, and of the people who fly on their planes, is crucial 2 levels of users to consider, in this case!

25. Picking the last of these… • Rockwell Collins offshores some testing to China. This involves interacting with groups of Chinese software engineers as colleagues. • How are these Chinese people different from you, in terms of their values? • Could any of those differences affect how you work together? • Could they affect how you would model Chinese testers as users?

26. Some examples

27. It’s also a boundary problem… • The people actually writing the code don’t get out enough, in most organizations, to interact with their users. • Why is that?

28. So… • Please find a good system for this study (if it’s not your current project), and • See how many different groups of users you can represent in studying their mental models. A handheld device like Kindle, maybe? An ISU student, for comparison, maybe?