4. A Tale of Two User Technology
Missions
• Mars Exploration Rovers,
landed in 2004, 90-day
estimated mission life, one
rover still operational in 2013
• Mission Control Technologies
Wednesday, May 22, 13
5. Mars Exploration
Rovers
• Science Objectives
• Determine the
aqueous, climatic
and geologic
history of a site on
Mars where
conditions may
have been favorable
to the preservation
of evidence of pre-
biotic or biotic
processes
Wednesday, May 22, 13
7. Human Centered
Computing for MER
• We, a division from NASA Ames, proposed
to work with the JPL mission team
• Our proposal was methods, not tools
• A comprehensive look at work practice
using ethnography
Wednesday, May 22, 13
8. Justification
• Increase productivity during surface ops
phase
• Nominal 90-day mission
• Daily surface productivity limitations of a
robotic surrogate
• Mitigate operational error risk
Wednesday, May 22, 13
9. Observations
• Interviews and observations
• Observations were key
• Observations often reveal vast
discrepancies between what people say
they do and what people actually do -
Don Norman
• Difficult to observe processes that don’t
exist yet
Wednesday, May 22, 13
10. What we saw
• Science field
test, roughly
2 years
before
launch
Wednesday, May 22, 13
15. MERBoard Platform
• Hardware
• Flat screen display (new at the time) with
touchscreen overlay
• Software
• Written in Java
• Provided a large touch screen interaction
display with whiteboard, storage space,
screen capture, Screen sharing (VNC)
Wednesday, May 22, 13
24. Personal tools
• Initial MER observations suggest that
scientists default to their own tools
• Use mission tools when they fill a desired
niche, or when required, future mission
systems will benefit from interoperability
Wednesday, May 22, 13
25. Research to Product
• Sol Trees - a clear need and a successful
product
• MERBoard - a general solution to a broad
set of issues and an attempt to do
something new - mixed results
Wednesday, May 22, 13
26. A Lesson Learned
• What do
MERBoard
and a
computer
for the
kitchen
have in
common?
Wednesday, May 22, 13
27. MCT
• A technology approach to a problem class
• Inspired by personal experience, Open
Doc, OS/2 and a particular question about
interoperability from a MER user
Wednesday, May 22, 13
28. Inspirations
• Opendoc
• Star
• “The Xerox Star...it was brilliantly
designed...had ease of use features and
a philosophy that has not been
equaled since. Many of the developers
of systems in the marketplace today
would do well to study the Star.” --
Don Norman, 1998
Wednesday, May 22, 13
29. The Problem
• Applications are walled off worlds
• Users become integrators
• Duplicated functionality
Wednesday, May 22, 13
30. Our Solution
• Mission Control Technologies
• It’s open source, give it a try
• https://github.com/nasa/mct
• https://sites.google.com/site/openmct/
home
Wednesday, May 22, 13
33. User Objects
• All in one integrated environment
• Consistent interactions
• Model their real world domain
counterparts
• The same thing in many views
Wednesday, May 22, 13
34. Putting it all together
• Everything in one
environment
• Everything is an
object with
consistent
behavior
• Objects may be
groups into
collections
• Collections are
user-objects
Wednesday, May 22, 13
35. The Same Thing, ManyViews
AlphaView
PlotView
InfoView
Wednesday, May 22, 13
36. NotebookViews
• This notebook
is a user-
object, with
embedded text
and telemetry
objects
• The same thing
is shown in
two views -
notebook and
Wednesday, May 22, 13
38. A Real World Example - Data
Association
• Current software
• Place a widget on the screen.
• Associate a parameter with it, repeat and re-
check over and over for reuse or different
views
• MCT
• Associate a parameter with a user object once
• Reuse as often as needed, share, change view
live in place
Wednesday, May 22, 13
39. Legacy MCT
Steps 20 8
Manual data entries 5 1
External tools used 1 0
Operator efficiency - Building Displays
BuildTest
BuildTest
Process steps
What actions does it take to build and
test a display?
Process time
How long does it take to accomplish those
steps?
Legacy MCT
Minutes to complete 65 6
90% reduction
in time
60% reduction
in steps
80% reduction in
manual entry
Manual data entry is the
primary source of errors / risk
Wednesday, May 22, 13
40. An Icon
• A purely
technical
approach to
change will
fail
Wednesday, May 22, 13
42. Participatory Design
• We built a unified team across organizations
• Users felt ownership of the design
• User who were not part of the PD process did
not feel a sense of ownership
• User expectations conveyed through hype
and other unofficial means of communications
did not match the reality of the product
Wednesday, May 22, 13
43. Agile + PD
User Feedback
3 Weeks Iteration n
Daily iteration n
Build to
Customer
Test
Feature mods/additions,
bug fixes
Optional Mid-Iteration
Hackathon tests big
features
Pre-Ship
Hackathon
Priorities/JIRA
Rankings
Nightly Build/Internal testing as features roll out
Coding
Issue Tracking Updates/Priorities/Rankings
UE & Tech Spec dates driven by coding dependencies
Deliver
to customer
Agile Development Iteration
Code Freeze
(-3 days)
Feature
Freeze
(-7 days)
Customer triages
issues it discovered
Customer
acceptance test
Customer verification
of closed JIRA issues
Customer
installs
iteration n-1
Optionally, hot
patch
Iteration n+1
Start 24 hour test (-2 day)
Wednesday, May 22, 13
44. User project their wishes onto
software they have not seen yet
• You must fill in the blank
• How you fill in it, and
the level of fidelity,
affects stakeholder
perceptions
Wednesday, May 22, 13
47. Results: Bad
• The tightly integrated developer/customer team
exacerbated a pre-existing polarization that pitted
those who wanted new software “against” those
who did not.
• Our deploy early and often model was
incompatible with the broader user groups mental
model of users not seeing the software until the
final product.
Wednesday, May 22, 13
48. Results:Good
• Through participatory design and agile development
we built a unified team composed of the designers,
developers and users.
• A user object model in which objects behave as
consistent representations of their real world domain
object counterparts - these are not widgets
• We built a modular user-composable software
architecture
Wednesday, May 22, 13
