Envisioning Information by Edward R. Tufte

I’ve been dancing around this guys work for a couple of years now – it gets cited, I take a look, and then I go “eh…” and move on. Not today. In my usual whim-like fashion, I picked up a copy of Envisioning Information at a Barnes and Noble and have been idly flipping around the pages.

It’s really a weird mix between graphic design and data. He does a good job sort of describing what works and what doesn’t for conveying information in succinct visual forms. Another one of his concepts is Sparklines, which have been interesting me for the name of them if nothing else. They seem like in the right instance, they’d be just damn near perfect for conveying relevant information. I haven’t found the right place though…

My favorite tool for information display right now is RRDtool – mostly because I seem drawn to looking at data over time, and it does a pretty darn good job of making pretty pictures about data over time. But lately I’ve been weirdly obsessing about other kinds of information that aren’t so easily displayed over time. Watching a source code/project tree and the edits to that tree has been in my mind. Can you make a useful visualization of it modelled from a living tree – maybe shading the “leaf nodes” into colors of green based on age and continued development, with sections that are unchaning over time dimming to brown, or even going grey with age. It sounds all cool – but would it be useful? And how would you really get useful information from that view over time? A snapshot view with coloration on the tree (maybe some interesting wrangling of Graphviz would enable that) might be a really interesting thing. The graphs that you find in CruiseControl these days, under metrics, hold a lot of interesting information to me as well. You can see clustering of development and effort for the project that it’s building – get a sense of what’s happening over time.

Here’s one project I’ve been keeping my eye on:

The information doesn’t really give me anything “actionable”, so there’s an argument for its general superflousness. I don’t agree – but I don’t immediately have a good argument towards the pro. Some folks are making pay-for tools that introspect your source code tree as a means of deriving metrics and health – so there is at least someone (I would think) paying for this information. And if someone will pay for the tools, you’d think they’d probably see some value there. Eh – I guess that’s rather the definition of paying for the tools though. Heh.

Published by heckj

Developer, author, and life-long student. Writes online at https://rhonabwy.com/.

%d bloggers like this: