iNode: Nota Bene

(March 23 2006)

Sparklines are “Intense Word-Sized Graphics” – a compact graphical representation of data influentially described by Edward Tufte but exemplified by Galileo.

There are nice on-screen implementations out there (although Tufte's position is that only the high resolution print medium brings enough detail for “true” sparklines) – Nicholas Bissantz has an interesting-looking combination of a TrueType font and SparkMaker, a .NET framework integration to MS Office. And there is James Byers' PHP library.

But, I'm interested in Ruby at the moment, so I haven't looked at either of those two in detail yet. Instead, I went straight to the sparklines gem (bypassing Why's “minimal” implementation) from Geoffrey Grosenbach (note that the name of the module and class has subsequently changed from just “spark” to “sparklines” …)

This gives us a really easy way to generate the sparklines, with just :-

    #!/usr/bin/env ruby
    require 'rubygems'
    require 'sparklines'
    Sparklines.plot_to_file('sparkpie.png',[12,34,56], :type => 'pie')

sparkpie.png :

    # Generate some random data (but with an increasing series)
    random_data=[]
    (0..99).collect { |x| random_data[x]=rand(x) }

    # Use it to create a 'smooth' line, then a 'discrete' line
    Sparklines.plot_to_file('sparksmooth.png', random_data,
            :type => 'smooth')

sparksmooth.png :

    # Create a 'discrete' spark, where it is easier to distinguish items
    Sparklines.plot_to_file('sparkdiscrete.png', random_data,
            :type => 'discrete')

sparkdiscrete.png :

    # Create another 'smooth' line with more options :-
    Sparklines.plot_to_file('sparksmooth2.png', random_data,
            {:type => 'smooth', :has_min => true, :has_max => true,
             :has_last => true, :height => 40})

sparksmooth2.png :

At this stage in the module's existance, you don't get very many options, and there is an assumption that you are dealing exclusively with data representing percentage points – if you have different data it shouldn't be too difficult to munge it into this form, but it's an extra step that arguably could reside within the module.

The actual data

You need to carefully consider the aspect ratio of sparklines, it has been found that a hill-slope average of 45 degrees does best. They should be longer than they are high (and arguably need to have the same height as the text that they live in, to be correctly considered as words).

Some sparklines may benefit from dequantification, where you introduce some indication of scale and/or value … but going overboard is counterproductive.

As for the actual data to present – sparklines don't expect to have explicit axes and labels, so the meaning of the data should be easy to work out. Most of the examples I've seen present the X axis as a time series, or some other entropic value, and the Y axis generally needs to be explained with textual evaluation.

So, if you have time-related data (in the computer world I'd suggest system resource tracking, like CPU usage, as an ideal candidate), consider sparklines as a compact overview of your more detailed presentation elsewhere.

The ugly truth

However, we must remember that the computer display resolution is probably not good enough to render a “real” sparkline. One possible approach would be to create a very high (data-)resolution sparkline in SVG, and encourage the interface to allow a zoom-in operation, interactively, perhaps as simply as responding to a mouseover. Obviously there will be other issues to consider here, such as the allocation of sufficient real-estate for the larger display. But I'd love to see a proof-of-concept for this!