Information Design for an Instrumented World

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.

Transcript

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 scrobbling location tracking health monitoring posting checking in tweeting
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. Web APIs become popular ~2005 ~2010
31. Web APIs become popular Moore’s law applied to data storage ~2005 ~2010
32. Web APIs become popular Moore’s law applied to data storage Big data ~2005 ~2010
33. Web APIs become popular Moore’s law applied to data storage Big data Ability to build real-time interfaces ~2005 ~2010
34. Web APIs become popular Moore’s law applied to data storage Big data Ability to build real-time interfaces Cloud computing ~2005 ~2010
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 the goal WHY 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. SKETCH IT!
91. SKETCH IT!
92. SKETCH IT!
93. SKETCH IT!
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. ABOUT THE: Individual Aggregate ON: Goal-driven device Browse-based device phone PC iPad TV me friends group network
104. 2. CASES
105. Logged out, looking at some data Logged in, looking at my data Logged in, looking at someone else’s data Logged out, looking at no data (yet) Logged in, looking at where my data will go Logged in, looking at where someone else’s data will go DATA IS PRESENT NO DATA YET! ANONYMOUS MINE SOMEONE ELSE
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. SKETCH IT! 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.
114. Time Part IV Photo credit: alphadesigner on Flickr
115. Real time Recent past (~1 day ago) Past (~1 week ago) History (archives) Now Joined
116. Realtime
117. Recent past & Past
118. History
119. Time shifting
120. SKETCH IT! 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 :)
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