Advanced HCI Exploring Design Ideas

1
Advanced HCIExploring Design Ideas

• How do designers explore design ideas?
• What methods are available and what problems
  might be associated with them?
• We review 3 different approaches to the same
  problem
• How can designers provide dynamic information
  about buses to people on the move?

2
Some ways of exploring design (not exhaustive)

• Use Cases
• allow description of sequences of events that,
  taken together, lead to a system doing something
  useful (Bittner Spence, 2002)
• Scenarios
• a narrative describing foreseeable interactions
  of types of users (characters) and the system or
  between two software components. They include
  information about goals, expectations, actions
  and reactions. Scenarios are neither predictions
  nor forecasts.
• Storyboards
• a series of annotated illustrations displayed in
  sequence for the purpose of previsualizing an
  interaction sequence.
• Low Fidelity Prototypes
• provide designers with a "working model" for
  demonstration or use by customers, and other team
  members to confirm or make changes to
  requirements, help define interfaces etc.

3
Some ways of exploring design

• Walkthrough
• is a usability inspection method used to identify
  usability issues in a proposed system, focusing
  on how easy it is for new users to accomplish
  tasks with the system. Walkthroughs often use
  prototypes or storyboards in conjunction with
  scenarios to enact the activities described
  therein.
• Simulation
• an imitation of some real thing, state of
  affairs, or process. In design terms this may
  involve development of a prototype that behaves
  like the proposed system or the enactment of a
  proposed interaction sequence.

4
Case Studies

• Fluidtime
• Mobile phone based information system
• Provides users with real-time information
  embedded within services
• RESCUE
• Requirements Engineering with Scenarios for a
  User-centred Environment
• A method for specifying reqs for complex
  socio-technical systems
• Example Countdown
• System used by London buses to provide bus
  arrival times on indicators at bus stops
• Experience design
• Analysis of BLISS
• Bus Location and Information SubSystem

5
Fluidtime
Double-click on box to start movie Business
video Fluidtime 4minshttp//business.fluidtime.c
om/index.php?idbusiness_video
6
Assumptions

• Presenting with/without scenarios justifies
  solution
• Equates to worst/best scenarios

• 1325 presentation has been postponed enough
  time to finish the agenda
• Who updates the system? Can they be relied
  upon to do so?

• 1436 for orientation, a glance at the map
• What is the viability of digitising all the
  possible xmaps that anyone might need?
• Will the map have the information you need?
• Are there potential resolution problems with
  maps xdisplayed on mobile phones? Range
  variation of potential target displays?
• If a map changes Who updates the system? Can
  they be relied upon to do so?

Images from http//business.fluidtime.com/index.ph
p?idbusiness_video
7
Assumptions

• 1600 departure is delayedxxback to the
  presentation
• Would all airlines be automatically linked?
  Who updates the system? Can they be relied
  upon to do so?
• Will the service be automatically available in
  xa foreign country? i.e. will your phone
  xcontract cover destination x or will you be
  xcharged premium rates?

Image from http//business.fluidtime.com/index.php
?idbusiness_video

• Simulations are effective - but may not reveal
  complexity or hidden dependencies
• Convincing presentation can blind both clients
  (and designers) to actual viability and problems
  later on
• In reality may be little more than an animated
  use case diagram(not infallible) and may contain
  huge assumptions

8
Use Cases

• We cannot specify a new system to support work
  without understanding how that work is currently
  done
• We cannot write detailed use cases without
• establishing the system boundaries
• knowing about dependencies between actors
  described in the use cases
• making at least some high-level design decisions
• We cannot write testable requirements without
  knowing the context in which those requirements
  arise (Jones Maiden, 2004)
• RESCUE (Requirements Engineering with Scenarios
  for a User-centred Environment)
• Method for specifying requirements for complex
  sociotechnical systems
• Integrates human activity modelling, creative
  design workshops, system goal modelling
  systemic scenario walkthroughs

9
RESCUE
System Goal Modelling (i)
Use Case Modelling
Requirements Management
Activity Modelling
Image after Jones Maiden, 2004
Gather dataon humanprocesses
Definesystem level requirements
Determinesystemboundaries
Developuse casemodel
Use cases
Context model
Use case diagram anduse case summaries
System-level requirementsin VOLERE shell
Descriptions of humanactivities
Context model
Creativedesign workshops
Extendeduse cases
First synchronisation point
Requirements
Determine systemdependencies,goals
andrationale
Model human activity
Define anddocumentrequirements
Describeuse cases
System-level requirementsand associated use cases
Use case descriptions
i SD and SR models
Human activity model
Second synchronisation point
Refine systemdependencies,goals andrationale
Define anddocumentrequirements
Specify usecases
Use cases associated withrequirements
Use case specifications
Refined i SD and SR models
Third synchronisation point
Define anddocumentrequirements
Walkthroughscenarios
Scenarios associated withrequirements
Fourth synchronisation point
Refine andchange requirements
Impactanalysis
Fifth synchronisation point
10
Countdown

• System used by London buses to provide bus
  arrival times on indicators at bus stops

Base-line messages
A bus stop indicator
11
Countdown Human activity description
12
Countdown Use Case description
 
 
13
Countdown Walkthrough

• Facilitators walk through the scenario with
  relevant stakeholders
• consider each normal course and each alternative
  linked course in turn
• Same scenario considered in a number of different
  walkthrough contexts
• stakeholders make different assumptions about
  human or environmental context in which it takes
  place
• e.g. considering how passengers may act
  differently at night or in bad weather
• Scribe documents all requirements and comments
  relating to each event
• e.g. when considering the event The passenger
  looks at the Countdown display and the
  alternative What if passenger has some unusual
  physical characteristics that affect his/her
  behaviour during this action?
• the scribe adds a new functional requirement
  The Countdown system shall provide an audio
  facility.

14
Experiencing BLISS

• Dave had seen people at bus stops of course,
  bitter, stonyfaced, peering longingly down the
  road, but hed not been on a bus for years. He
  far preferred the warmth and comfort of his car,
  the freedom to jump in and go wherever he liked
  by himself. His conscience about having two cars
  in the family had got the better of him though,
  and now he was left with two choices, either
  cycle or catch the bus.
• Dave was cold and wet the rain had chosen
  precisely the moment he stepped out of the door
  to join forces with the strong wind. He arrived
  at the bus stop only to find several 9.00 am
  commuters waiting
• Once Dave had figured out where to stand, that
  didnt offend anyone, but was still sufficiently
  sheltered from the rain, it dawned on him that
  the only thing left to do was wait, - he wasnt
  very good at waiting.
• Has the bus gone, he wonders, how would I know?
  He looks around there are three other people at
  the stop, they look relaxed, there must be a bus
  on its way.

15
Experiencing BLISS

• Dave had heard that the bus he was trying to
  catch was supposed to be every eight minutes,
  but here he was, and he is sure that hes been
  here for more than eight minutes. He wished he
  hasnt tried the bus, how much warmer, calmer and
  in control he would be, if he was in his car
  right now.
• Dave did have experience of information panels.
  The city had put some up on the way into town,
  each morning he had passed a large electronic
  sign reading HAVE YOU THOUGHT ABOUT THE BUS. To
  him they had always seemed rather bossy, and he
  had amused himself by composing responses OF
  COURSE, WHY DO YOU THINK IM IN MY CAR?

16
Experiencing BLISS
Image from Reed Wright (2006)

• Well at least they are putting money into the
  buses, he thinks. Looking up Dave is immediately
  confronted with location and the time, never mind
  that he didnt know that the side road was called
  East Cottages, or that his own watch said half
  past three.
• Suddenly the text 2 City Centre DUE appears at
  the top of the screen, and Dave is immediately
  relieved. Sure enough he can see the Park and
  Ride bus through the scratched plastic side of
  the bus stop. Its only when hes seated on the
  bus that he wonders what the point was. He could
  see the bus, the sign didnt tell him anything
  that he didnt know. So much for the flashy sign.

17
The disappearing bus
1519
10 City Centre
1459
10 City Centre
1519
1539
Time 1450
Time 1451
Time 1452
Time 1453
Time 1454
Time 1455
Time 1456
Time 1457
Time 1458
Time 1459
Time 1500
Plantation Drive
Time 1449

• Oh OK, ten minutes to go, thats good. And look
  theres another one, erm nineteen, plus one, oh
  twenty minutes later, good. The sign content is
  reassuring for a number of reasons. It looks
  detailed and therefore authoritative no one
  would make up 1459 as a bus arrival time, would
  they? It sets out choices and in that it is
  static, it seems reliable.

• Dave looks up the road and can see no bus what
  happened?
• Has he missed it? Maybe it went past
• did he have to put his hand out? Everyone else
  must be waiting for a different bus.

18
Extract from a BLOG about BLISS

• Tuesday, November 7thThe York FTR A ride on
  York's new purple bus / tram, the FTR, was
  memorable more for the wait than the ride. At
  York Uni is what they call a "super stop" with a
  large silver infotainment column. This provides
  real-time bus information as you'd expect, but
  also has a multifunctional touchscreen. This
  includes a multimaps style map of York
  (navigation around the map by direction arrows)
  which lets you print a map (almost illegible due
  to ink running out) on cash machine type paper,
  and also included a number of games. (Annoying if
  someone is playing one and you want to use the
  map urgently). There are also links to BBC pages,
  and promotional stuff about the FTR. The FTR
  looks quite sleek, it's quiet for a bus, and the
  seating is plastic and tram-like with a large
  standing area around the articulated part. It was
  hard to get much of a feel for the priority
  traffic signalling from a single journey. There
  was the usual heavy braking and jerky gear
  changes of bus travel, and hopefully First are
  taking driver training seriously. 07.11.06 _at_
  0736 PM CST
• (http//www.daveches.co.uk/blog/index)

19
Fluidtime (reprise)

• Not just a simulation
• Research team developed
• Mobile phone-based time information system
• Number of interface prototypes

20
Images from http//business.fluidtime.com/
21
User experience trials

• Qualitative user study
• Turin, May June 2003
• Main objective to understand
• How system can be integrated in users lives
• How system impacts on users organisation of time
• service-based wireless devices influenced by
  dynamic environmental and social conditions that
  cannot be reproduced in an experimental context
• Experimental subjects
• Daily users of public transport
• 4 young professionals (2m 2f different routes)
• Used for a month
• Post-trial interviews
• Interviews
• Usability, pleasantness of use, aesthetic appeal?
• Influence on habits, use of time, value in daily
  life?

22
Fluidtime - Usability

• To access information about bus status
• Users must know and remember the number of the
  stop (location code)
• Which is completely arbitrary (!)
• Prototype did not allow storage of frequently
  used bus routes and stops
• Information had to be entered every time
• 3 of 4 test subjects would not adopt system
• TakeThree Interface
• Allows user to define up to 3 different routes
  up to 3 different stops
• For travellers who need to change buses orwhere
  there is an option to walk to two different
  stops
• Too much effort on daily basis
• Users want exact number of minutes

23
Summary

• All systematic approaches yield benefits
• Although some are more productive than others
• Some are economic others more expensive
• Every project is different
• Designers have to decide best method of exploring
  design
• Experience is key here
• Which is why study of hci is important

24
References

• Bittner, K. Spence, I. (2002). Use Case
  Modeling. Addison Wesley Professional, 2-3.
• Jones, S. Maiden, N.A.M., (2004), 'RESCUE An
  Integrated Method for Specifying Requirements for
  Complex Socio-Technical Systems', to appear in
  Mate, J.L. and Silva, A. (eds) Requirements
  Engineering for Sociotechnical Systems, Idea
  Group Inc., 2004.
• Kieslinger, M. Polazzi, L. (2004). Supporting
  Time-based Coordination in Everyday Service
  Interactions the Fluidtime System. Proc ACM
  Designing Interactive Systems 2004, 225-232.
• Reed, D.J. Wright, P. (2006). Experiencing
  BLISS When Becoming a Bus Passenger. In
  Proceedings of DIS '06. ACM Press, New York, NY,
  291-300.