Information Design for an Instrumented World

D4826161fa269cd6afc1239757cf0d45?s=47 Hannah Donovan
October 12, 2011

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.

D4826161fa269cd6afc1239757cf0d45?s=128

Hannah Donovan

October 12, 2011
Tweet

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.

  8. None
  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
  21. None
  22. None
  23. None
  24. None
  25. None
  26. None
  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”
  55. None
  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.
  112. None
  113. None
  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

  128. None
  129. 2. ANNOTATIONS

  130. None
  131. 3. RELATIONSHIPS

  132. None
  133. 4. ARRANGEMENT

  134. 5. MAINTENANCE

  135. Thanks for coming along!

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