1 / 44

CPIS 354 - Principle of Human Computer Interaction

CPIS 354 - Principle of Human Computer Interaction. Department of Information Systems Faculty of Computing and Information Technology King Abdul Aziz University Khalid Al-Omar. 1. 1. Previous lecture. What is the difference between unstructured interview and structured interview?

andren
Download Presentation

CPIS 354 - Principle of Human Computer Interaction

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. CPIS 354 - Principle of Human Computer Interaction Department of Information Systems Faculty of Computing and Information Technology King Abdul Aziz University Khalid Al-Omar 1 1

  2. Previous lecture • What is the difference between unstructured interview and structured interview? • What is the difference between direct observation and indirect observation? • Understand the users? Why • Usable? Why • After understanding users, tasks, and environment. What we need? Why?

  3. Requirements and Task Analysis Lecture 9 3 3

  4. Overview • What are requirements? • The importance of requirements • Different types of requirements • Task descriptions: • Scenarios • Use Cases • Task analysis • HTA

  5. What are requirements? • Requirement is a statement about an intended product that specifies what it should do and how it should perform. • Requirement activity aim is to make requirements as specific, and clear as possible. Why? • For example: • User need to login • In the website the time to download any complete page is less than 5 seconds • Children should find the website attractive

  6. Requirements what, how, when • What are we trying to achieve in the requirements activity? • 1. Understand as much as possible about users, task, and environment • 2. Produce a stable set of requirements • How can we achieve this? • Data gathering, analysis, and interpretation

  7. Requirements..(cont.) • Why bother? The important to getting • the requirements right? • Significant Cost of fixing errors in later stage

  8. Different kinds of requirements • Functional: • What the system should do • Understanding the functional requirements for interactive system is essential • Example: login, logout • Non-functional: • memory size, response time, Usability, Security…

  9. Different kinds of requirements • Technical requirements: • What technologies will be used or available? • What technologies will the product run on or need to be compatible with? • What technologies limitations might be

  10. Different kinds of requirements • Physical requirements: dusty? noisy? vibration? light? heat? humidity? …. (e.g. ATM) • Social requirements: sharing of data, work individually, privacy for clients • Organisational requirements: IT department’s attitude, user support, availability of training

  11. Different kinds of requirements • Users requirements: • Characteristics: • ability, limitation, background, experience, knowledge, preferences, attitude to computers • System use: • novice, expert, frequent, infrequent

  12. Different kinds of requirements • Novice: step-by-step, need constrained interaction with clear information • Expert: flexible interaction with more control • Frequent: short cuts • Infrequent: clear instructions, e.g. menu paths • home>your profile>personal info

  13. Some basic guidelines for requirements • Focus on identifying the stakeholders’ needs • Involve all the stakeholder groups • Involve more than one representative from each stakeholder group • Use a combination of data gathering techniques • Support the process with props such as prototypes and task descriptions • Run a pilot session • Consider carefully how to record the data

  14. Task Analysis 14 14

  15. Tasks • A task is a unit of human activity, carried out in order to achieve a specific goal. • A more complex situation may need several related tasks to be carried out. All tasks must be completed in order to achieve the goal. Each task has a separate goal.

  16. Complex tasks • Examples of complex tasks which have been simplified or reduced to a single task by the use of interactive systems include: • starting a car - electronic ignition requires only the turn of a key • international telephone calls - direct dialling removes the need for an operator • online airline reservations provide instant information on flight availability • Can you think of any others?

  17. Task descriptions • Task descriptions are used as part of a user-centred approach to design and development, from early analysis activities through prototyping and evaluation. • Task descriptions may describe: • existing tasks, to help developers to understand what users currently do • proposed tasks, to help designers to describe how users will use new interactive systems • There is no single agreed way to describe and analyse tasks.

  18. Task descriptions • Task descriptions may take one or more of the following forms: • Scenarios • an informal narrative story, simple, ‘natural’, personal • Use cases • assume interaction with a system • assume detailed understanding of the interaction

  19. Scenarios • What is a Scenario? • A scenario is a description of a person’s interaction with a system. • Telling a story is a natural way for people to explain what they are doing or how to achieve something. • Scenarios provided by users, maybe in an interview or workshop session. Not intended to be a complete description • Help designers to identify users’ goals

  20. Scenarios • When are scenarios appropriate? • whenever you need to describe a system interaction from the user’s perspective. • They are particularly useful when you need to remove focus from the technology in order to open up design possibilities • So designers concentrate on the human activity rather than the technology

  21. Scenarios • Advantages • Help designers to identify users’ goals • Understand why people do things as they do • What they are trying to achieve

  22. Scenario for ATM “It’s Friday afternoon and Jon is flying to Sydney. He doesn’t have enough money for a taxi to the airport, and he’s running late. He goes to the local ATM and identifies himself. The machine welcome him and asked Jon to choose the language he prefer. Jon get angry because he doesn’t have enough time!. However, he chosen the language. He specifies that he wants $100 from his savings account. He’d like the money in $20 notes so that he can give the taxi driver the correct change. He doesn’t want a printed receipt, as he doesn’t bother keeping track of transactions in this account …”

  23. Scenario for ATM • This scenario declare: • The ATM should check users details • The ATM should check users preferable language and store it to next time. In addition, it should provide the option to change it at anytime. • The ATM should provide the option to allow users to choose the type of change the users need. • The ATM should provide the option to print out the receipt.

  24. Use case • Another way of describing tasks, borrowed from object-oriented approaches to system development • Use cases are associated with actors, and capture the actor’s goal in using the system • A use case is a more formal task description than a scenario

  25. Example use case diagram for ATM

  26. Use case for ATM The user entered his card. The system prompts for password. User enters password. The system verifies password. The system prompts for language types. User chooses language. System displays the main menu. User chooses the cash option. System displays the different amounts. User chooses the amount. System displays the option to print out the receipt. User chooses not to print the receipt. System display the card and then the money

  27. Task analysis • Task descriptions are often used to envision new systems or devices • Task analysis is used mainly to investigate an existing situation • Many techniques, the most popular is Hierarchical Task Analysis (HTA)

  28. Hierarchical Task Analysis • Breaking a task down into its steps, or sub-tasks and then grouping them to show how the tasks are performed in the actual situation. • It focuses on the actions that are performed by users • These are grouped as plans which specify how the tasks might be performed in practice

  29. Why Hierarchical Task Analysis? • It provides knowledge of the tasks that the user wishes to perform • It is a cost-saving exercise. • 3. It enables us to specify the functions to be included within the system and the user interface more accurately • 4. It makes it possible to design an efficient tasks.

  30. Generating the hierarchy • get list of tasks • group tasks into higher level tasks • decompose lowest level tasks further • Stopping rulesHow do we know when to stop?Is “logout” simple enough?

  31. Example Hierarchical Task Analysis 0. In order to purchase items from the internet

  32. Example Hierarchical Task Analysis 0. In order to purchase items from the internet 1. go to the website 2. search for the required items 3. add item to basket 4. purchase the item and checkout

  33. Example Hierarchical Task Analysis 0. In order to purchase items from the internet 1. go to the website 2. search for the required items 3. add item to basket 4. purchase the item and checkout plan 0: do 1-2-3-4. What about if item located on the main screen. do 1-3-4

  34. Example Hierarchical Task Analysis 0. In order to purchase items from the internet 1. go to the website 2. search for the required items 3. add item to basket 4. purchase the item and checkout What about if user want to select more than one items??!! do 2-3 until you select all items you want

  35. Example Hierarchical Task Analysis 0. In order to purchase items from the internet 1. go to the website 2. search for the required items 3. select the item 4. purchase the item and checkout plan 0: do 1-2-3-4. if item located on the main screen do 1-3-4. if purchasing more than one item do 1- do 2-3 until you select all items you want - then 4

  36. Example Hierarchical Task Analysis 36

  37. Example Hierarchical Task Analysis 0. In order to login to email via E-services at KAU 1. go to the website 2. go to e-services 3. select category “employee” or “students” 4. Click “KAU email” 5. select category “employee” or “students” 6. Insert username and password 7. Click “login” 37

  38. Textual HTA Hierarchy description ... 0. in order to clean the house 1. get the vacuum cleaner out 2. get the appropriate attachment 3. clean the rooms 4. empty the dust bag 5. put vacuum cleaner and attachments away

  39. Textual HTA Hierarchy description ... 0. in order to clean the house 1. get the vacuum cleaner out 2. get the appropriate attachment 3. clean the rooms 4. empty the dust bag 5. put vacuum cleaner and attachments away ... and plans Plan 0: do 1 - 2 - 3 - 5 in that order.when the dust bag gets full do 4

  40. Textual HTA Hierarchy description ... 0. in order to clean the house 1. get the vacuum cleaner out 2. get the appropriate attachment 3. clean the rooms 3.1. clean the hall 3.2. clean the living rooms 3.3. clean the bedrooms 4. empty the dust bag 5. put vacuum cleaner and attachments away ... and plans Plan 0: do 1 - 2 - 3 - 5 in that order.when the dust bag gets full do 4 Plan 3: do any of 3.1, 3.2 or 3.3 in any orderdepending on which rooms need cleaning Level 1 Level 2

  41. DiagrammaticHTA

  42. Diagrammatic HTA What is missing!! 42

  43. Summary • Getting requirements right is crucial • There are different kinds of requirement, each is significant for interaction design • The most commonly-used techniques for data gathering are: questionnaires, interviews, focus groups, direct observation, studying documentation and researching similar products • Scenarios, use cases and essential use cases can be used to articulate existing and envisioned work practices. • Task analysis techniques such as HTA help to investigate existing systems and practices

  44. References • Based on the slide available at www.id-book.com • http://www.infodesign.com.au/ftp/Scenarios.pdf

More Related