Stamen - Data n(arr)atives

Notes from Stamen's About Our Stuff talk by Eric Rodenbeck, Michal Migurski and Tom Carden, 14 May 07 at the National Maritime Museum, London. Organised by NMM's Foe Romeo.

My own comments and asides in [square brackets].

Data viz is a medium.
Data viz is not primarily tooling, technology or methodology.

They work with live/vast/deep data, but increasingly the live.

Earlier projects:

• EricR's history at Quokka: sailing has clearly been like most sports for years now - the data and its understanding/visualisation happens outside the athlete and their immediate tools-of-trade, in a support boat, [or in the F1 pits, or at the side of the pitch.]
• Graffiti archaeology: layers
• Moveon: helping the community get a live sense of itself
• Flickr/Mappr: use of tags to anonymously aggregate information - participants don't know each 0ther. But once they learn of aggregating tools they may change their behaviour (eg users deliberately adding more tags)
• [there's a strong a thread here about making an activity understandable by making it visible, turning it into a graspable story. Data narratives.]

Digg R&D:

• wanted more distance from their data in order to be able to see it clearly (and act upon its stories). "mile high view".
• Digg Swarm: mesmeric realtime data viz: stories surrounded by dancing, moving users.
• [interesting visual metaphor: they look like sunflowers in which the petals - the users, round yellow dots - are also the bees pollinating the flower]

Cabspotting:

• With Scott Snibbe, [whose Myrmegraph is still a delight 8 years on]
• background layer of aggregated historical data building up, foreground layer of live activity.
• [GPS is good for stuff that remains outdoors most of the time: vehicles]
• When Cabs changed their GPS timings and tech methods, the viz broke slightly: eg 1 GPS fix per 3 min (instead of per 1 min) suddenly meant that the street grids itself (the right angles) was no longer being described.or broke completely: becomes completely meaningless [though still attractive to look at].
• [So there's a need here to fit the viz to the data. Don't show the street map underneath if the data on it doesn't fit. Also: be more aware of what services (the infoviz) depend on the data underneath]

Oakland crime maps:

• pulling together data from public sources, releasing functionality part by part [this is a great project, and we must see whether it can be done in the UK/Eu too]
• modest maps
  • Flash code to pull in map elements from other providers eg Google, MS etc. BSD licence.
  • Great for projects that need higher level of control than Google provides. Not so great for getting-going-really-fast.
• side effects: start to expose patterns of policing behaviour: eg prostitution is policed in periodic sweeps rather than a background no-broken-windows activity
• interoperation: SF and Oakland refer to same crimes with different names [no-one involved in inter-agency criminal justice and policing will be particularly surprised at this]

Indiana 911 service:

• live viz shows which call centres in Indiana are taking 911 emergency calls [surprised that one state has seems to have 20+ call centres, even though it's 6+m ppl]
• One metropolitan call centre has so much activity that some visualisations aren't able to handle it - a heatmap had this one call centre literally eclipsing others. (a problem of both scaling and viz type).
• important: showing clarity/meaning in the data they already have, not offering a predictive capability.
• [this project looks really impressive, but I imagine selling clarifiying-your-existing-data can be hard.]

Varying precision [a topic close to my heart recently]:

• "odessa" vs "odessa, texas, zipcode, latlong" - use the input to zoom in but how to express the degree of confidence?
• Oakland: literally blurring the data points. Also showing social shadows or "residual hauntings": something that implies a trailing impact historically after a crime incident [so this is a metaphor, right? It's not a description of some measured quanta of social impact, but a metaphor for it - it reminds us that there are downstream effects.]
• Cabspotting: because the Bay bridge is on two decks, they have good GPS data for the top, E->W deck (the taxis follow the line of the bridge, but on the lower, W->E deck the taxis appear to shortcut across the water as there are fewer GPS data points recorded to connect up.

[So there's a sense there that when we step back [oh look! Another metaphor - they're everywhere aren't they?] from "raw data" to something more like an abstracted, approximation visually we can sometimes better understand it. A visual metaphor. Become less precise in order to get a better view. If metaphors are useful for understanding or for decision support when do they go too far and become mere ornament?]

[This is an interesting area. We're currently working on how to present information in ways that don't immediately break when you mix consistent and precise data together with inconsistent and vague data. The other day I described this to Eric as "making apps that were all about the 'probably'."]

Other stuff:

• How much data do we need for it to be meaningful? Personal relevance/knowledge of the domain/locale means often very little.
• communicability: making urls still relevant and pinpoint even when user pan-drags a map.
• notion of increasing visualisation literacy/expectation
• Carden: viz serves the data; viz as a way into the data, not the end result of the data.

[Smart guys, and great to meet them.]