Library dashboard, continued

https://netfiles.uiuc.edu/pdadamcz/www/museumpipes/GoogleMotionChart-V1.html

The Google motion charts were a breeze. Post the data to a spreadsheet, make sure the data is formatted correctly, and set the spreadsheet as the datasource using the Google visualization code – all there is to it. As always the code and data are open – though most of the code just came from Google’s interactive examples. Motion helps tremendously in observing trends.

Google Motion Chart

Google Motion Chart

My source in the library passed along some circulation statistics which I added to the spreadsheet powering the ManyEyes visualizations. Brilliant stuff. ManyEyes has a treemap comparison option that shows the relative difference between two variables in the hierarchy. Below is a comparison of the Item Count and Circulation Count – the lighter the region, the higher the percentage of books in that category were checked out over the past year, i.e. lightness equates to percent utilization.

Watson Items / Circulation Comparison Treemap

Watson Items / Circulation Comparison Treemap

http://manyeyes.alphaworks.ibm.com/wikified/WatsonStatsTemp/CircLCData:TreeMap

Why all this work on a dashboard, charts, graphs, and so on? The pipes work really started out of a frustration that collections information lived in a vacuum – without any sense of the interconnections between any two object records let alone any material outside the collection. But with internal context now becoming increasingly available and abundant external connections (with relevance still an issue but not a roadblock), the problem is turning into an intriguing special case of a more general problem with a well defined approach from an information visualization perspective: overview first, zoom and filter, then details-on-demand. That mantra is probably best expressed in Ben Shneiderman’s work and many of the visualization projects at the HCIL.

What doesn’t seem to fit is the austerity of the visualizations. Well, that, and the lack of concrete questions that need answering without overspecialized visualizations. The overview, zoom, filter, details approach gives incredibly good exploratory tools but they move too far away from the spirit of the data for my taste. At the other end are the more designer-ly approaches that seem to focus on their own aesthetics rather than reveal more about the data. I don’t want this to sound like the usual data vs. design debate. I think Museum data has the enviable trait of not needing too much abstraction to become compelling – quite the opposite in fact. Maybe its the details-on-demand part that’s the problem? Maybe the details about a given data point just need to bubble up sooner in a Museum context to make for a compelling experience.

I’ve started with library data, I’ll try to move on to aggregate collections information next.

//TODO: Pass along some of the data to the JavaScript InfoVis Toolkit. It has some great demos and the coding looks lightweight; The treemaps aren’t very pretty though. I remember the treemap code in Ben Fry’s Visualizing Data was easy to work with.

Posted in Metropolitan Museum of Art, Visualization Tagged: charts, manyeyes