Yogiisms - PowerPoint PPT Presentation

Title: Yogiisms


1
Yogi-isms

• "If you can't imitate him, don't copy him."
• "Baseball is 90 percent mental. The other half is
  physical."
• "You can observe a lot by watching."
• "In baseball, you don't know nothing."
• "A nickel ain't worth a dime anymore."
• "It's deja vu all over again."
• "If you come to a fork in the road, take it."
• "I usually take a two-hour nap, from one o'clock
  to four."
• "If the people don't want to come out to the
  park, nobody's going to stop them."
• "Why buy good luggage? You only use it when you
  travel."
• "Think! How the hell are you gonna think and hit
  at the same time?"
• "I didn't really say everything I said."

2
Exam 1

• Feb 12.
• Practice exam will be posted later this week
• What is the goal of the Task-Centered Design
  Process? Briefly describe each step of the
  process noting how each step contributes to this
  goal.
• Email to ogden_at_nmsu.edu
• Names of your group members
• Possible topics

3
Homework

• Pick a common task
• Start a car. Microwave some popcorn.. Etc.
• List all the steps necessary to complete the task
• Watch someone do the task
• Did what they do match your task description?

4
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

5
The Task-Centered Design Process

• figure out who's going to use the system to do
  what
• choose representative tasks for task-centered
  design
• Plagiarize (intelligent borrowing)
• rough out a design
• think about it
• create a mock-up or prototype

6
Learning About the Users' Tasks

• Once you have some people to talk with, develop
  CONCRETE, DETAILED EXAMPLES of tasks they perform
  or want to perform that your system should
  support.
• E.g
• Change the speed limit on Canyon Boulevard
  eastbound between Arapahoe and 9th.
• Calculate projected traffic flows on Arapahoe
  west of 6th assuming Canyon speeds between 25 and
  55 in increments of 5 mph.

7
Learning About the Users' Tasks

• Develop lists of things the users would like to
  do
• Say what the user is doing, not how they do it
• Be specific with details.
• Describe the complete job
• key point because transition between tasks are
  covered
• The tasks should say who the users are

8
Task Inventory

• What is a task?
• It has an observable action with a beginning and
  end
• What level of granularity?
• Make dinner? or Peel Potatoes?
• Make it a reasonable length
• 7 2 ? Probably 10-20

9
Partial task list for e-mail program

• Write a message
• Send a message
• Receive a message
• Read a message that you received
• Reply to a message
• Save a message to look at it later
• Forward a message to someone else
• Send a formatted file with the message
• Send the same message to several people
• Keep an address book

10
Detail task list for e-mail program

• Write and send a message to ogden_at_nmsu.edu about
  missing class
• Forward the message sent to ogden to someone else
  in the class.
• Send the same message to everyone in the class.

11
Task analysis

• Task descriptions are often used to envision new
  systems or devices
• Task analysis is used mainly to investigate an
  existing situation
• It is important not to focus on superficial
  activities What are people trying to achieve?
  Why are they trying to achieve it? How are
  they going about it?
• Many techniques, the most popular is Hierarchical
  Task Analysis (HTA)

12
Hierarchical Task Analysis

• Involves breaking a task down into subtasks, then
  sub-sub-tasks and so on. These are grouped as
  plans which specify how the tasks might be
  performed in practice
• HTA focuses on physical and observable actions,
  and includes looking at actions not related to
  software or an interaction device
• Start with a user goal which is examined and the
  main tasks for achieving it are identified
• Tasks are sub-divided into sub-tasks

13
Example Hierarchical Task Analysis
0. In order to borrow a book from the library
1. go to the library 2. find the required
book 2.1 access library catalogue 2.2 access
the search screen 2.3 enter search
criteria 2.4 identify required book 2.5 note
location 3. go to correct shelf and retrieve
book 4. take book to checkout counter
14
Example Hierarchical Task Analysis (plans)
plan 0 do 1-3-4. If book isnt on the shelf
expected, do 2-3-4. plan 2 do 2.1-2.4-2.5. If
book not identified do 2.2-2.3-2.4.
15
Example Hierarchical Task Analysis (graphical)
Borrow a book from the library
0
plan 0 do 1-3-4. If book isnt on the shelf
expected, do 2-3-4.
go to the library
find required book
retrieve book from shelf
take book to counter
3
2
1
4
plan 2 do 2.1-2.4-2.5. If book not identified
from information available, do 2.2-2.3-2.4-2.5
access search screen
enter search criteria
identify required book
access catalog
note location
2.1
2.2
2.3
2.4
2.5
16
Example task analysis

• Buy An Anvil
• Find The Anvil
• Search For Anvil
• Type in "anvil" in Search box
• Read results
• Browse the Store
• View anvil
• Purchase The Anvil

17
Scenarios should

• Say who the users are personas
• What their goals are
• When they are using your interface
• What other people, objects they interact within
  the same time frame.

18
Task Inventory

• What is a task?
• It has an observable action with a beginning and
  end
• What level of granularity?
• Make dinner? or Peel Potatoes?
• Make it a reasonable length
• 7 2 ? Probably 10-20

19
Using the Tasks in Design

• Send task descriptions to the users
• develop a DESIGN SCENARIO for each task
• these are design specific
• discuss these with the users and designers
• gives CONTEX to the discussions.
• Represented with STORYBOARDS (sequences of
  sketches showing what the screen shows and
  actions taken)

20
Personas

• Archetypal characters created to represent the
  needs and goals of the people for whom the
  product will be designed.
• Defining functionality to satisfy the goals of a
  real person, rather than an abstract notion of
  "the user," enables you to avoid development
  roadblocks caused by personal preferences or
  biases.

21
Personas

• Describe how people behave not job
  descriptions.
• Multiple persons w/same job or same person
  w/multiple jobs.
• Add life to the personas, but remember they're
  design tools first
• Use the right goals
• Life goals (e.g. retire at 50)
• Use rarely
• Experience goals (e.g. avoid feeling stupid)
• Use when specific to the interface product
• End goals ( e.g. produce nice looking report)
• Should be the main focus
• Perfecting your personas
• Origin of Personas

22
Persona-based vs Use case

• Use cases are expressed at the fuctional/
  transactional level.
• Low level User action System action
• Persona-based are expressed at the behavioral
  level
• How the system needs to order the presentation
  and react to user input is more important.

23
Use Case
A use case is a sequence of actions that
provide a measurable value to an actor. Another
way to look at it is a use case describes a way
in which a real-world actor interacts with the
system. In a system use case you include
high-level implementation decisions. System use
cases can be written in both an informal manner
and a formal manner.  Techniques for identifying
use cases are discussed as well as how to remain
agile when writing use cases.
From http//www.agilemodeling.com/artifacts/system
UseCase.htm
24
The Task-Centered Design Process

• figure out who's going to use the system to do
  what
• choose representative tasks for task-centered
  design
• Plagiarize (intelligent borrowing)
• rough out a design
• think about it
• create a mock-up or prototype

25
Creating the Initial Design

• The foundation of good interface design is
  INTELLIGENT BORROWING.
• Reasons
• unlikely that ideas you come up with will be as
  good as the best ideas you could borrow
• many of your users may already understand
  interface features that you borrow
• save you tremendous effort in design and
  implementation and often in maintenance as well

26
Legal issues

• Things you certainly can copy (unless rights have
  been sold)
• Anything produced by your company
• Things you've written earlier for the your
  current company
• Things recommended in the style guide for the
  system you're developing under
• Things supplied as examples/prototypes in a
  commercial toolkit, programming language, or
  user-interface management system

27
Legal issues

• Things you can probably copy
• Common'' ideas, such as windows as the
  boundaries of concurrent work sessions, menus for
  selecting commands, an arrow-shaped pointer
  controlled by a mouse, graphical icons to
  represent software objects
• Sequences or arrangements of menu items,
  commands, screens, etc., if the original program
  clearly orders the sequence to improve usability
  or if there is only one or a very few other ways
  that it could be arranged
• Icons ideas, commands, menu items, or other words
  that are obvious choices for the function they
  represent

28
Legal issues

• Things you can probably not copy
• Sequences or arrangements of menu items,
  commands, screens, etc., if you're only copying
  the sequence order because it will make it easier
  for users of someone else's existing program to
  use your new program.
• Iconns, commands, menu items, or other words that
  are not an obvious choice to describe their
  function, even if they would make your program
  more usable for users of the original program.

29
Legal issues

• Things you can certainly not copy (unless you get
  permission)
• Things you've written earlier for a different
  company
• An entire interface from another company's
  program, even if you implement it with all new
  code
• An entire detailed screen from another company's
  program
• Source code or object code from another company's
  program, even if you translate it into a
  different language
• Trademarks from other companies.
• Patented features. Unfortunately, there's no
  easy way to discover what's patented
• Exact bitmaps of icons, words, or fonts
• Graphic details that define an interface's
  aesthetic look.

30
(No Transcript)
31
Work Within Existing Interface Frameworks

• such as Macintosh, Motif, Windows, (Java for all)
  Manufactures encourage this.
• advantages of working in an existing framework
  are overwhelming - think twice about
  participating in a project where you won't be
  using one
• STYLE GUIDE describes the various interface
  features of the framework, such as menus,
  buttons, standard editable fields and the like

Microsoft Guidelines
32
Make Use of Existing Applications

• e.g. make your interface on top of Excel or Dbase