1 / 48

CS 522: Human-Computer Interaction Mid-term Review

CS 522: Human-Computer Interaction Mid-term Review. Dr. Debaleena Chattopadhyay Department of Computer Science debchatt@uic.edu debaleena.com. Mid-term Syllabus. Shneiderman et al., 2017 Chapters 4, 5, 7, 8, and 9 Proctor & Zandt, 2008. Chapters 3, 4, and 9 Buxton, 2007

ondrea
Download Presentation

CS 522: Human-Computer Interaction Mid-term Review

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CS 522: Human-Computer InteractionMid-term Review Dr. Debaleena Chattopadhyay Department of Computer Science debchatt@uic.edu debaleena.com

  2. Mid-term Syllabus Shneiderman et al., 2017 Chapters 4, 5, 7, 8, and 9 Proctor & Zandt, 2008. Chapters 3, 4, and 9 Buxton, 2007 pp. 105—151.

  3. Mid-term Syllabus (handouts?) • Review the conceptualization example. • Review the design of experiments handout • Review metaphorsand affordances

  4. Mid-term format • 1 hour exam • Short answer + multiple-choice questions • Students may bring a single A4 page cheat sheet to the exam (double-sided, hand-written or printed). No books, articles, or internet sources should be used. • This will be a paper-based exam. Bring pen & pencils.

  5. Review

  6. Requirements

  7. Notes on Establishing Requirements • Requirements engineering is founded on the awareness of a variety of stakeholders relevant to the design process • Stakeholders represent all those who are affected by or have an interest in the product in all its ramifications.

  8. Requirement Elicitation • Problem-driven inquiry, conceptualization at hand • Interviews to users to qualitatively explore issues of relevant activity, emerging problems and expectations • Surveys (for large sample) to gather quantitative results on detailed items • Ethnographic approach (Observation) • Exploratory workshops and use of technology probes. • Scenario development and storyboarding/ personas

  9. Persona Creation • Who are your typical users? • What are the representative aspects of each type of users? • Example: Imagine you will be redesigning the AT&T website. Who are your typical users?

  10. Persona Professional User: Steve Spellman Age: 34 Professional: senior HR manager Service Subscription: wireless (one iPhone, one blackberry) User Goal: Constantly informed or recommended about AT&T’s new features and services that are customizable to his own profile Make efficient AT&T service upgrades/change and can easily get started on these newly added

  11. Persona (continued) Family User: Jennifer Minnelli Age: 41 Professional: Reference librarian, mom to two children Service Subscription : Home phone, digital TV, internet User Goal: Easily manage various AT&T bills, including those of the family members’ Comprehensible and effective troubleshooting

  12. Persona (continued) Student User: Jennifer Minnelli Age: 23 Professional: Graduate student of Art History Service Subscription: U-Verse Internet (shared with roommates), wireless User Goal: Easily compare different service plans and learn about their features through personalized suggestions related to her situation(budget, constraints) Get special offer information to save

  13. User Interview – for requirement elicitation Do’s and Don’ts.

  14. General attitude of interviewer: • YES: Learning, understanding, identifying, discovering, unveiling, clarifying (= open to change) • NO: confirming, demonstrating, re-assuring, achieving consensus, discussing opinions (= closed to change) • Key test of a good requirements interview: • What are the 3-4 key things that you have learned (that you did not know before)? • Focus your questions on the experience • Not projection, prediction, extrapolation, “thoughts” • NO: Is this a useful application? • YES: Is this application valuable to the work you do right now? How? Why?

  15. Focus on immediate experience • Capture current behavior • NO: Is this product <interesting> for you? • YES: If it were available right now, would you use it? Why? How? • Non-judgmental attitude • Do not convey in any way that you are expecting a certain answer… • NO: Don’t you think this feature would be better if available also as a iPad application? • YES: Is there any other way you’d like to use a feature like this in your current work? How? Why?

  16. Keep each question focused on a single topic • Avoid using AND / OR in your questions (linking more statements together) • NO: How would you use this app at school or at work, for example? • YES: • How would you use this app at school? • How would you use this app at work? • Provide a way out from your options • Even in close-ended questions, give the possibility of expressing things outside the available options • NO: which of the following feature is most important to you? [what if no one is important?] • YES: Rate from 1 to 5 how important each feature is for you, where 1 is least important, 5 is most important. Put 0 if a feature is irrelevant for you.

  17. Avoid binary questions • Do not force black/white commitments on the “whole” • Elicit “analytical” feedback on specific elements • NO: Is this product useful? • YES: What, if anything, do you find useful about this product? Why?

  18. Requirements Specification - Abstraction • Purpose: The requirements analysis must produce a readable and clear, documented SET of requirements that informs the design activity • Focus: Requirements should be expressed at a level of detail which is appropriate for leaving room for alternative design exploration (within the frame established by the requirements) • NO: user sees a pop-up asking to register, he enters user name and password, click on submit and the pop-up close, showing a page with the top navigation bar and in the center a dashboard with all the personalized information displayed in a grid metaphor…. • YES: • User access the personal app upon authentication • A personalized dashboard displays high-priority tasks • Dashboard layout follow common patterns of…

  19. Human Error

  20. Error Taxonomies • What are the taxonomies for error classification? • Action classification • Failure classification • Processing classification • Intentional classification

  21. Error Taxonomies • What are the taxonomies for error classification? • Action classification • Errors of omission, commission, timing, sequence, selection, and quantitative errors.

  22. Error Taxonomies • What are the taxonomies for error classification? • Failure classification • Recoverable, irrecoverable, operator, assembly, installation/maintenance errors. • Example? Make connectors of different sizes to avoid miswiring the fire warning panel on Boeing 737s.

  23. Error Taxonomies • What are the taxonomies for error classification? • Processing classification • Input/perceptual, output/motor, mediation/cognitive, and communication errors

  24. Error Taxonomies • What are the taxonomies for error classification? • Intentional classification • Mistake (error in planning), slip (error in execution) • Which is harder to detect?

  25. Reliability Analysis: System Reliability What is reliability? • The probability that a system or subsystem will operate adequately in its intended application for a specified period of time.

  26. System Reliability • What does this reliability measure tell us about how the components are arranged in the system? In other words, how are the components arranged? • In parallel

  27. System Reliability (cont...) • What does this reliability measure tell us about how the components are arranged in the system? In other words, how are the components arranged? • In series • Is it advisable to link low-reliability components in series?

  28. Human Reliability • Pr(operator error) = # of errors made / # of opportunities to err Human reliability = 1 – Pr(operator error)

  29. User Evaluation

  30. Controlled Psychologically-oriented Experiments • Controlled experiments can help fine-tuning the human-computer interface of actively used systems • Particular aspects of a UI, such as interaction modality or interaction technique is manipulated across users: independent variable • Performance could be compared with the control group • Dependent measures could include performance times, user-subjective satisfaction, error rates, and user retention over time

  31. Formative vs. Summative Evaluation Usability Evaluation: Any analysis or empirical study of the usability of a prototype or system Formative: during development, guides process What to redesign? How to redesign? Inform the design and prototyping activities Summative: after development, or at a checkpoint How well did we do? Lessons learned

  32. Usability 101 • ISO 9241: The effectiveness, efficiency and satisfaction with which specified users achieve specified goals in particular environments. • effectiveness: the accuracy and completeness with which specified users can achieve specified goals in particular environments • efficiency: the resources expended in relation to the accuracy and completeness of goals achieved  • satisfaction: the comfort and acceptability of the work system to its users and other people affected by its use Traditionally, while evaluating usability these are measured as follows: Effectiveness: Task success, number of errors while completing a task Efficiency: Time taken to complete a task Satisfaction: Interviews/ surveys/ mental workload assessment. User Testing Objective Subjective Reference: Tullis, T., & Albert, W. (2010). Measuring the user experience: collecting, analyzing, and presenting usability metrics. Morgan Kaufmann.

  33. Nielsen’s 10 Heuristics: Re-visited 1. Visibility of the system status 2. Match between system and mental model 3. User Control and Freedom 4. Consistency and Standards 5. Error Prevention 6. Recognition rather than recall 7. Flexibility and efficiency of use 8. Aesthetic and minimalist design 9. Help users recognize, diagnose, and recover from errors 10. Help and Documentation

  34. Gulf of execution and evaluation • There is often a gap between how a system is built to operate, and how users understand how it operates. Gulf of execution Users System Gulf of evaluation

  35. User Navigation

  36. Principles of Direct Manipulation • Continuous representations of the objects and actions of interest with meaningful visual metaphors. • Physical actions or presses of labeled buttons, instead of complex syntax. • Rapid, incremental, reversible actions whose effects on the objects of interest are visible immediately.

  37. Attributes of Direct Manipulation • Novices can learn basic functionality quickly, usually through a demonstration by a more experienced user • Experts can work rapidly to carry out a wide range of tasks, even defining new functions and features • Users • Immediately see whether their actions are furthering their goals, and, if the actions are counterproductive, they can simply change the direction of their activity • Experience less anxiety because the interface is comprehensible and because actions can be reversed easily • Gain a sense of confidence and mastery because they are the initiators of action, they feel in control, and they can predict the interface’s responses

  38. Design issues in Navigation Effective interfaces emerge only after careful consideration of and testing for numerous design issues, such as: • task-related organization • phrasing of items • sequence of items • graphic layout and design • responsive design to adapt to various sizes of devices • shortcuts for knowledgeable frequent users • online help and easy error correction

  39. Layout • Techniques to indicate position in the menu structure can be useful • When users want to do a traversal back up the tree or to an adjoining menu at the same level, they will feel confident about what action to take

  40. Command Languages • Command languages are often preferred by expert users who do not want to drag and drop items for repeated steps. • A command language example is the Unix command used to delete blank lines from a file • grep -v ^$ filea > fileb • Casual users favor GUIs but both styles of interface can be made available successfully • Other examples that behave like command languages: • Web addresses (URLs) can be seen as a form of command language • Twitter addresses • Database query languages

  41. Designing spoken interaction • Initiation • Knowing what to say • Recognition errors • Correcting errors • Mapping to possible actions • Feedback and dialogs

  42. Sketching User Interaction

  43. Why Sketch? • Create • early ideation • think openly about ideas • think through ideas • forceyou to visualize how things come together • brainstorming: generate abundant ideas without worrying about quality • invent and explore concepts • Record • ideas you develop • ideas that you come across • archive ideas for later reflection • Reflect, share, critique, decide • communicate ideas to others • invite responses, criticisms, and alternatives; • choose ideas worth pursuing

  44. Elaboration and Reduction Elaborationopportunity seeking Reductiondecision-making • Elaborate - generate solutions. These are the opportunities • Reduce - decide on the ones worth pursuing • Repeat - elaborate and reduce again on those solutions Design process Source: Laseau,P. (1980) Graphic Thinking for Architects & Designers. John Wiley and Sons

  45. Elaboration and Reduction Design is choice. There are two places where there is room for creativity • creativity you bring to enumerating meaningfully distinct options from which to choose • creativity you bring to defining the criteria, or heuristics, according to which you make your choices. Source: Laseau,P. (1980) Graphic Thinking for Architects & Designers. John Wiley and Sons

  46. The Design Funnel • Alternate generation of ideas and convergence until resolution Modified from Pugh, S. (1990) Total design: Integrated methods for successful products engineering. Addison-Wesley. P. 75

  47. To do: • Midterm – 10/17 • Req. specs + sketching – 10/31 • Good luck!

More Related