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
   

   View Slide

2. Hello! I’m Hannah
   

   View Slide

3. Who are you?
   

   View Slide

4. I have a secret to tell you.
   

   View Slide

5. “The solution is the problem.”
   

   View Slide

6. What about you?
   

   View Slide

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

   View Slide

8. View Slide

9. By albyantoniazzi on flickr
   

   View Slide

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
    

    View Slide

11. Photo credit: Alex Pounds
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

15. So what are we going to explore today?
    

    View Slide

16. The details.
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

21. View Slide

22. View Slide

23. View Slide

24. View Slide

25. View Slide

26. View Slide

27. You guys…
    This is kind of crazy.
    

    View Slide

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

    View Slide

29. ~2005
    ~2010
    

    View Slide

30. Web APIs become popular
    ~2005
    ~2010
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

36. 1.
    COMMON FORMATS AND PATTERNS
    ARE EMERGING
    

    View Slide

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
    

    View Slide

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

    View Slide

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.
    

    View Slide

40. 3.
    DATA HAS DISTINCT TIMING
    

    View Slide

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.
    

    View Slide

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

    View Slide

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
    

    View Slide

44. OUR TOOLKIT
    Part I
    

    View Slide

45. 1.
    UNDERSTANDING THE DATA
    

    View Slide

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

    View Slide

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).
    

    View Slide

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

    View Slide

49. 2.
    GETTING THE DATA
    

    View Slide

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).
    

    View Slide

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

    View Slide

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

    View Slide

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.
    

    View Slide

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

    View Slide

55. View Slide

56. Don’t clean up API vomit!
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

60. 3.
    DESIGNING THE DATA
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

64. Twitter, Facebook
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

74. Line graph: Run Keeper, Withings Body Scale
    

    View Slide

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___?”
    

    View Slide

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

    View Slide

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

    View Slide

78. Sentence: Huffduffer, Last.fm
    

    View Slide

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?”
    

    View Slide

80. Sentence: Twitter, Google
    

    View Slide

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.
    

    View Slide

82. Favlikelovestar+1: Instagram, Favstar, Spotify
    

    View Slide

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”
    

    View Slide

84. Reblah: Tumblr, Twitter
    

    View Slide

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”?
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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!
    

    View Slide

91. SKETCH
    IT!
    

    View Slide

92. SKETCH
    IT!
    

    View Slide

93. SKETCH
    IT!
    

    View Slide

94. Personal & profile data
    Part III
    

    View Slide

95. 1.
    IN ‘N OUT DATA
    

    View Slide

96. Home: reflecting incoming data
    

    View Slide

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

    View Slide

98. Profile: reflecting outgoing data
    

    View Slide

99. Profile: new Facebook
    

    View Slide

100. Take a minute to remember personal
     editorial.
     

     View Slide

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

     View Slide

102. 2.
     IT’S ALL CONTEXT, BABY
     

     View Slide

103. ABOUT THE:
     Individual Aggregate
     ON:
     Goal-driven device
     Browse-based device
     phone
     PC
     iPad
     TV
     me friends
     group
     network
     

     View Slide

104. 2.
     CASES
     

     View Slide

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
     

     View Slide

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

     View Slide

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

     View Slide

108. Cases: logged in, looking at my data
     

     View Slide

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

     View Slide

110. Another tip:
     Lay off the lorum ipsum.
     

     View Slide

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.
     

     View Slide

112. View Slide

113. View Slide

114. Time
     Part IV
     Photo credit: alphadesigner on Flickr
     

     View Slide

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

     View Slide

116. Realtime
     

     View Slide

117. Recent past & Past
     

     View Slide

118. History
     

     View Slide

119. Time shifting
     

     View Slide

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 :)
     

     View Slide

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

     View Slide

122. How do we organise these long data trails?
     

     View Slide

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
     

     View Slide

124. We need to curate, look again.
     

     View Slide

125. Architecture of
     serendipity
     – Frank Chimero
     

     View Slide

126. A final challenge…
     

     View Slide

127. 1.
     THEMES
     

     View Slide

128. View Slide

129. 2.
     ANNOTATIONS
     

     View Slide

130. View Slide

131. 3.
     RELATIONSHIPS
     

     View Slide

132. View Slide

133. 4.
     ARRANGEMENT
     

     View Slide

134. 5.
     MAINTENANCE
     

     View Slide

135. Thanks for coming along!
     

     View Slide

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

     View Slide