_Mark_ ([info]eichin) wrote,
@ 2004-05-30 03:43:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Current music:a Jane Siberry song that isn't in the itunes store

Synergy (is the way things have to be)
While rummaging around, I ran across a pointer on Scoble to new work by Edward Tufte on "Sparklines" in a preview chapter of his next book, "Beautiful Evidence". Sparklines are basically little "more than words" graphlets, little concentrated bombs of data in an otherwise textual context.

What clicked was that when looking at the examples, I realized that these were quite possibly a good use of data-urls - they're small, they run in-line - and I'd been looking for an excuse to play with PIL (the Python Imaging Library) and it works pretty well - - though in practice I'd need to (1) have a better handle on using them in sentences, like words (2) have actual data, instead of a gaussian random stream (3) have some way to make them work in other browsers; maybe ascii art in alt tags, maybe javascript that detects IE and "fakes" it manually [though that is better suited to a bookmarklet, I think.]

Something to ponder, at least. Might be particularly useful for PDA (ie. small-screen) interfaces, too...




(Post a new comment)


[info]kcr
2004-05-30 09:22 am UTC (link)
I maintain that you're seeing more significance here than is actually there. :->

It seems to me that interpolating graphics into the text will only make it harder to read (by breaking the visual flow of words), and interacts really poorly with environment (like the web) where you can't control the typography.

(Reply to this)

Sparklines...
[info]rjpb
2004-05-30 02:29 pm UTC (link)
Reading the chapter on sparklines was interesting, but I'm not sure I like all of Tufte's examples. I think there is room for improvement in several.

For example, "[data] Glucose 128" has poor flow. In a traditional statement, "Glucose 128" is short for "The Glucose level is 128." Tufte's sparkline of "[data] Glucose 128" has a more awkward interpretation, more passively asserting "Here is some data, which is on Glucose, and has an end value of 128." A better arrangement would be "Glucose [data] 128". The corresponding meaning would be "The Glucose chart is [data] with a latest level of 128."

The layout of "Glucose [data] 128" is also better in terms of flow. It makes sense for the type or title of the data (Glucose) to be presented first so the reader immediately knows what the data concerns. Also, placing the latest value (128) adjacent to the last value of the data ties those together more tightly, making it clearer that the end point and value are the same. I would say that it even eliminates the need to display the end point and value in red, which Tufte does to tie the information together.

I was not sure from the page you cited whether the book was already published, or just in draft stages. Is Tufte still accepting comments?

I agree this could be a good use of data URLs. The first application that comes to my mind is weather reporting, which I'm surprised is not mentioned in the chapter.

(Reply to this) (Thread)

Re: Sparklines...
[info]eichin
2004-05-30 07:52 pm UTC (link)
He's responded to comments in the last day or so, so he's at least reading them; I think the book is still in production, and your input could be useful. I'm certainly not sure about the structure - I can see how he got to [data][label][key value], but more alternatives are worth experimenting with.

(Reply to this) (Parent)


Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…