In a world where all our online interactions – and increasingly offline ones too – are logged and measured, how do designers integrate and present this information in a meaningful way? Whether it be real-time Twitter search results, Last.fm listening history or personal Fitbit stats, we now expect services to serve up, compare and contextualize the most interesting bits of our behaviour from the scores of data they collect about us. If you want to add stats, graphs and other bits of lifestream data to your web app, this workshop is for you. Leave with an understanding of how to wrestle with interaction design challenges such as: dealing with too much/too little user-generated data; what to show different user types (e.g. logged in/out users); when to show aggregate vs. individual datasets and more.

1. Information Design for an
Instrumented World
Hannah Donovan, 10 October 2011

2. Hello! I’m Hannah

3. Who are you?

4. I have a secret to tell you.

5. “The solution is the problem.”

6. What about you?

7. What you’re not going to learn this morning.

9. By albyantoniazzi on flickr

10. We need to stop grasping for the
perfect visualization and return to
the basic language of charts and
graphs. Only then can we begin to
uncover the relationships the data
has to offer.
– Brian Suda
Photo credit: andré.luís on Flickr

11. Photo credit: Alex Pounds

12. Olivier Gillet says:
MAKE
Photo credit: Alex Pounds

13. Olivier Gillet says:
MAKE A
Photo credit: Alex Pounds

14. Olivier Gillet says:
MAKE A POINT.
Photo credit: Alex Pounds

15. So what are we going to explore today?

16. The details.

17. The details are not the details. They make the design.
– Charles Eames

18. We people, we have a lot of details now. We
live in an instrumented world

19. Most of our instrumented world is measured
in terms of attention data.

20. ACTIVE PASSIVE
posting scrobbling
checking in location tracking
tweeting health monitoring

27. You guys…
This is kind of crazy.

28. New conceptual breakthroughs are
invariably driven by the
development of new technologies.
– Don Norman
Photo credit: Piemont Share on Flickr

29. ~2005
~2010

30. ~2005 Web APIs become popular
~2010

31. ~2005 Web APIs become popular
Moore’s law applied to data storage
~2010

32. ~2005 Web APIs become popular
Moore’s law applied to data storage
Big data
~2010

33. ~2005 Web APIs become popular
Moore’s law applied to data storage
Big data
Ability to build real-time interfaces
~2010

34. ~2005 Web APIs become popular
Moore’s law applied to data storage
Big data
Ability to build real-time interfaces
~2010 Cloud computing

35. Our job is to make sense of this
instrumented world and all the
information in it.

36. 1.
COMMON FORMATS AND PATTERNS
ARE EMERGING

37. For us: be aware and inquisitive, so we can
choose the right tool for the job
For users: they will expect certain things to
work in certain ways

38. 2.
THE AMOUNT OF PERSONAL DATA
CAN BE OVERWHELMING

39. For us: spoiled for choice, we have more
decisions to make than ever before.
For users: signal vs. noise is becoming a
common problem.

40. 3.
DATA HAS DISTINCT TIMING

41. For us: we need to have sharp presentation
skills for conveying the speed of the data
For users: they care, and will often expect
things to be in real-time.

42. 4.
OUR DATA TRAILS ARE STARTING TO
GET LONG

43. For us: we’re faced with a new challenge of
how to reflect this meaningfully to users
For users: they are becoming increasingly
aware of their history

44. OUR TOOLKIT
Part I

45. 1.
UNDERSTANDING THE DATA

46. Use the WW brief:
What do you want, and why do you want it?

47. Use the WW brief:
What do you want, and why do you want it?
(It’s your job to figure out how to do it).

48. WHAT WHY
the goal use case
evidence
hunch etc.

49. 2.
GETTING THE DATA

50. Is it a data dump or is it live?
If it is live, then you are probably relying on
an API (your own or external).

51. An API:
Collectively, an API is a bit like a
“styleguide” — it defines vocabularies and
conventions

52. Basically, “Here’s the stuff you can get, and
the format you’ll get it in”

53. Getting the stuff you want out:
An API allows you to call methods. A
method is a structured way for asking for a
particular bit of information from an online
service.

54. Something like, “Hey, I want some info about
this thing” “How many?” “10, and be sure to
include the picture bits”

56. Don’t clean up API vomit!

57. If the service is currently being worked
on by your team, establish a dialogue
with them about this.

58. Types of questions I like to ask:
What parameters can it have?
How expensive is this?
What can we compare this against?

59. If the answer is “no”…
Explain what you want and why you
want it. Let them figure out how ;-)

60. 3.
DESIGNING THE DATA

61. 1. Sketch UI with pen & paper
2. Get the data in-page
3. Design the UI in-page

62. Design patterns for
visualising personal data
Part II
Photo credit: number657 on Flickr

63. Feeds
Answers the question “what’s been
happening recently?”

64. Twitter, Facebook

65. Ranked Lists & Leaderboards
Answers the question “who’s winning?”

66. Ranked lists & leaderboards: Foursquare, Last.fm

67. User-facing Stats
Good for showing a user’s overall
performance/usage and answers the
question “How am I doing?”

68. User facing statistics: Flickr Pro, Amazon Author Central

69. Counters
Good for showing less than three key
statistics about a user, and answers the
question “How am I doing?” at a glance.

70. Counters: Hype Machine, Twitter, Foursquare, Dribble, Lanyrd

71. Sparklines
Good for showing a huge amount of data in
small space, and can answer questions about
trends within a sentence.

72. Sparklines: From Edward Tufte’s ‘Beautiful Evidence’, Flickr, Amazon

73. Line Graphs
Good for showing continuous data and
visualising trends. Line graphs are good for
answering questions like “How did it look
during ____?”

74. Line graph: Run Keeper, Withings Body Scale

75. Bar Charts
Good for visually comparing discreet data
and very versatile as the data in a bar chart
can be ordered however you want. Great for
answering questions like, “which one is___?”

76. Bar chart: Last.fm, Nike+, Brian Suda’s ‘Designing with Data’

77. Sentence (yes, the sentence!)
Good for contextualising data in a
conversational tone. Great for answering
questions that could use a bit of personality.

78. Sentence: Huffduffer, Last.fm

79. Realtime Search
Good for filtering out signal in vast amounts
of real-time noise. Answers the question
“what is happening with x right now?”

80. Sentence: Twitter, Google

81. Favlikelovestar+1
Good for services that have lifestream data
that people want to hug; use these for that
visceral “I want to keep this! I love this!”
response.

82. Favlikelovestar+1: Instagram, Favstar, Spotify

83. Reblah
Good for services that want to cater to lazy
usage. Responds to the impulse “I want to
make this part of my identity too”

84. Reblah: Tumblr, Twitter

85. Thumbs & Stars
Good for services that depend on ratings for
good content to bubble to the top. Answers
the question “what do people think is best”?

86. Thumbs & Stars: eBay, iTunes store, YouTube, Last.fm images

87. Notifications
Good for important bits of real-time activity
people don’t want to miss out on. Often
fosters serendipity.

88. Notifications: Facebook, Google+, Android, Email

89. And remember to layer:
At first sight, reveal the bare minimum
With contextual UI, reveal more
For the discerning, link to the source

90. What: re-envision Shazam’s tagged track UI,
using some of the patterns we just talked
about.
Why: we could use any music API out there
to show more relevant data about what you
just found/remembered. IT !
C H
ET
S K

91. T !
I
C H
ET
S K

92. T !
I
C H
ET
S K

93. T !
I
C H
ET
S K

94. Personal & profile data
Part III

95. 1.
IN ‘N OUT DATA

96. Home: reflecting incoming data

97. Home: Feedville. Population, all of us.

98. Profile: reflecting outgoing data

99. Profile: new Facebook

100. Take a minute to remember personal
editorial.

101. Take a minute to remember personal
editorial.
Profile: MySpace circa 2006

102. 2.
IT’S ALL CONTEXT, BABY

103. ON:
Goal-driven device
phone
PC
ds up rk
ABOUT THE:
ien ro et wo
me fr g n
Individual Aggregate
iPad
TV
Browse-based device

104. 2.
CASES

105. ANONYMOUS MINE SOMEONE ELSE
DATA IS Logged out, looking Logged in, looking at Logged in, looking at
PRESENT at some data my data someone else’s data
NO DATA Logged in, looking at
YET! Logged out, looking Logged in, looking at
where someone else’s
at no data (yet) where my data will go
data will go

106. Tip for dealing with cases:
Keep your own UI gallery

107. Cases: Logged in, looking at where my data will go

108. Cases: logged in, looking at my data

109. Cases: logged in, looking at someone else with no data yet

110. Another tip:
Lay off the lorum ipsum.

111. What: re-envision an eBay seller profile
screen, for at least 2 cases.
Why: There’s a ton of data at hand, and very
little revealed about this person you’re about
to fork over cash money to.
T !
I
C H
ET
S K

114. Time
Part IV
Photo credit: alphadesigner on Flickr

115. Joined
History (archives)
Past (~1 week ago)
Recent past (~1 day ago)
Now Real time

116. Realtime

117. Recent past & Past

118. History

119. Time shifting

120. What: would Twitter look like if it showed
what you’d been up to for the last few
months as well?
Why: because nobody’s done it yet :)
T !
I
C H
ET
S K

121. Our data trails are getting
long
Part V
Photo credit: Gonzak on Flickr

122. How do we organise these long data trails?

123. We’ve all been so
distracted by The Now
that we’ve hardly noticed
the beautiful comet tails
of personal history
trailing in our wake.
– Matthew Ogle

124. We need to curate, look again.

125. Architecture of
serendipity
– Frank Chimero

126. A final challenge…

127. 1.
THEMES

129. 2.
ANNOTATIONS

131. 3.
RELATIONSHIPS

133. 4.
ARRANGEMENT

134. 5.
MAINTENANCE

135. Thanks for coming along!

136. Contact & questions:
Real-time: @han
Archival: han@hannahdonovan.com