SFU CMPT-363 2004-2 week 2 Manuel Zahariev E-mail: manuelz@cs.sfu.ca Based on course material from Arthur Kirkpatrick May 12, 2004 "!$#!% Historical phases of usability: Usability Engineering (history) 1980s: Adding cognitive scientists to development teams Early 1990s: Inserting usability methods into conventional development processes Early 2000s: Structuring the development cycle around usability Observation 1 The integration of usability engineering with software engineering is not yet complete. 1 2 Usability engineering (objectives) (Some) Key questions Set measurable goals Systematic process Milestones and deliverables Usability inspection (without users) Usability testing (with users) How do we design to support learning? What are the characteristics of skilled human performance? How do we design to support both first-time and skilled users? How do humans coordinate group activity? What makes something fun to use? How does culture influence one s perception of a tool? 3 4 Human-centered design Observation 2 Human-centered design is about dealing with the needs/wants of humans, and not about accommodating specific software or hardware architectures (machine-centered design). Human-cantered design answers the following questions: Is it usable? Is it learnable? Is it fun? Human-cantered design does not answer the questions: Is it multitasking? Is it Java/C++/Perl...? 5 (Raskin, 2000, pg.2): Interface The interface is the way you accomplish tasks with a product. More than just peanut butter... (Raskin, 2000, pg.5) (emphasis added): As far as the user is concerned, the interface is the product. Observation 3 User interface design should drive every technical decision. 6
Usability Definition 1 (Usability) Usability is the effectiveness, efficiency, and satisfaction with which specified users can achieve specified goals in particular environments (ISO DIS 9241-11). Effectiveness: The extent to which the goal is achieved. Efficiency: How much effort is required. Satisfaction: Enjoyment and comfort users feel. Usefulness Does the product help the user achieve something important to them? Much harder to measure and predict. Contradictory, when looking at different categories of users. Note 1 Usability is not Usefulness. 7 8 Development models: waterfall Waterfall: Successive phases, each one complete before moving on to the next Requirements analysis Design Implementation Testing Maintenance Note 2 (Software design vs. User Interface design) Software design (e.g. in the waterfall model) is not user interface design. What makes interactive software different? Predictive theories are limited You can only get it right through iteration. The system you build is not the system you originally planned. Early and continual focus on users (Gould and Lewis, 1985). Start by understanding the users. Test it with the users. 9 10 Software development (a developer-centered view) : 2 Software development (a developer-centered view) : 1 Software development falls into two extreme categories: services products Software development services are contracted by organizations, in order to fill internal needs, and result in custom solutions. Observation 4 (Services) Software services are centered on existing, known customers, who state a need and initiate a purchase process (e.g. request for proposal, bidding). Software products are initiated by software companies, in an attempt to fill a generic need of [ideally] large numbers of customers. Observation 5 (Products) Software products are centered around mental representations of future, unknown, potential customers, who may decide to initiate a software evaluation and acquisition process to fill internal needs. 11 12
Software development (a developer-centered view) : 3 Software development (a developer-centered view) : 4 Note 3 (Build vs. Buy) The customers (e.g. IT departments) decide on Build: contracting out services (or building in-house) vs. Buy: purchasing Products. Observation 6 (Products AND services) In reality, most software development involves both the development of products and services. The typical life-cycle of most software companies is: 1. development of services for clients 2. creation of products for a given vertical 3. creation of horizontal infrastructure products When developing services, you are dealing with representatives of the Customer, e.g. members of their IT Team. Note 4 Customers of services are problem experts, and many times domain experts, but usually are not solution experts. When developing products, you are usually dealing with members of a Marketing Department, usually Product Managers. Note 5 Product Managers are domain experts, problem experts, and sometimes solution experts. They have a thorough understanding of all business aspects of the product. Note 6 Developers are generally only solution technology experts. 13 14 Software development (a developer-centered view) : 5 Development models: spiral Note 7 The biggest problem in software development is: What to build? Who has the answer? Services: the Customer and the Developer Products: the Product Manager and the Developer Note 8 The biggest challenge in software development: communication. Observation 7 Communication can only happen at the level of the greatest common denominator of the backgrounds of parties involved. Iterative development. Thorough prototyping Example: extreme Programming (XP). Build system incrementally. Users stories motivate design and testing. Note 9 This course focuses on scenario-based methods. 15 16 Scenario-based design Stories of use (greatest common denominator) More or less abstract Used throughout development cycle Easily changed Claims: positive and negative outcomes of main design decisions Future visions of computing Mobile/Wearable Invisible Tangible Collaborative Context-aware Common-sensical Playful/Creative 17 18
Requirements Analysis Goal: Decide what the product has to do. What functions What social processes Use other methods for: Amount of data Hardware Speed... Components Who is doing this? What is it they do? What objects do they use? Who are their coworkers? 19 20 Requirements Analysis in Waterfall development process Requirements Analysis in Iterative development process Requirements Analysis Design Implementation Testing (Rosson and Carroll, 2002, Figure 1.6) 21 22 Explicit vs. tacit knowledge Explicit business process: Procedures manual Job titles and descriptions Business plan Tacit business process: Who will you call? Incidental conversations. Categorizing the difficult cases. Requirements Analysis process (Rosson and Carroll, 2002, Figure 2.3) 23 24
Example: Bioinformatics database (root concept) Vision: Scientists contribute and retrieve research results from all over the world. Rationale: Disseminate experimental results quickly One location for all results of zebrafish research Assumptions: Web-based Multimedia, object-oriented database Requirements analysis Stakeholders Research scientists ( principal investigators : PIs) Funding agencies (NSF, NIH, NSERC, CMHRC, others) Trainees (Post docs, grad students, undergrads) Journal publishers and editors Providers of other biological databases (mouse, worm, fly, plant, protein, sequence,... ) 25 26 Field study methods Stakeholder profile for PI Attending weekly group meetings (5 PIs, 30 students) Reading journal articles Observing experiments Practicing using the language Playing bridge, having lunch together,... Age : 35-60, more than 21 years of education Fluent in English Modest computer use (but some quite proficient) Runs lab of 10-30 people Lab annual budget for software $200,000 / yr 27 28 Typical tasks for PIs Writing grant proposals or reports. Maintaining resume (CV). Managing lab. Editing papers. Interviewing potential hires. Networking with colleagues. PI scenario Edna, a full professor at the University of Victoria, is editing a paper drafted by one of her doctoral students, Vicki. The article continues some research that has been going on in Edna s lab for 8 years on the developmental impact of Sonic Hedgehog (shh). At the most recent biennial Cold Spring Harbor conference, Edna learned that her colleague Albert at the University of Kansas is doing some related work on Goosecoid (gsc). Edna checks the recent publications on Albert s Web site and finds one that seems appropriate. She makes a note for Vicki to get a copy and cite it in the paper. 29 30
Course project The term project is to develop a system for organizing ad hoc ride sharing among registered human participants. Participation to the system will be open, while the organization of specific rides will involve individual participation and consent from all involved users. The system shall support (assumptions): the ability to access the system through the Internet from a PC the ability to access the system from mobile devices (e.g. cellular phones, PDA s) Ethics in studies with human participants : 1 Participants vs. Subjects: Signifies an attitude more than different wording. Language acknowledges participation. There are differences between US and Canada/UK. Include in Acknowledgements section of paper. 31 32 Ethics in studies with human participants : 2 Principles of ethical treatment: Disclosure Tell participants as much as possible, as soon as possible. Privacy Minimize amount of information revealed about participants. Individual consent Participants must knowingly agree to participate. Organizational consent (where applicable) Managerial consent may be required (e.g. for employees). Ethics in studies with human participants : 3 Levels of invasiveness: Questionnaire Phone survey Visit to home / workplace Audio recording Video recording Physiological measurement 33 34 Ethics in studies with human participants : 4 Levels of possible injury: Information apparent to a casual observer whose presence is known. Opinions about products. Personal values, controversial opinions. Some risk of physical injury. Significant risk of physical injury Ethics in studies with human participants : 5 Levels of concealment from participant: Aware of goals, hypotheses. Naïve about study s purpose, but fully informed about task. Misled about the nature of the task. 35 36
Ethics in studies with human participants : 6 Ethics in studies with human participants : 7 Levels of distribution: Design team, destroyed afterwards. Whole implementation team. Internally archived for ongoing work. Distribution to select colleagues outside the team. Published (including available on a computer network). Special groups (require special permission): First Nations members on tribal lands. Pregnant women. Convicts. Minors (under 19 in BC); note extension to University students over 17. Mentally incompetent. 37 38 References Ethics in studies with human participants : 8 Rewarding participation: Access to results. Prize(s) for high(er) performance. Payment for time. Sense of contribution. (Sometimes) Sense of contribution over work/play environment. References [Gould and Lewis1985] John D. Gould and Clayton Lewis. 1985. Designing usability: Key principles and what designers think. Communications of the ACM, 2(3):300 311. [Raskin2000] Jef Raskin. 2000. The Humane Interface. Addison-Wesley. [Rosson and Carroll2002] Mary Beth Rosson and John M. Carroll. 2002. Usability Engineering. Morgan Kaufman. 39 40