This article presents a critique of radar charts, a chart type commonly used to display multivariate data, highlighting how they are poorly designed to effectively communicate information in the underlying data, and presents a number of more effective alternatives

Introduction

Radar charts, sometimes known as spider, start or web charts, are a two-dimensional chart type designed to plot one or more series of values over multiple common quantitative variables by providing an axis for each variable, arranged radially as equi-angular spokes around a central point. The values for adjacent variables in a single series are connected by lines, and, frequently, the polygonal shape created by these lines in filled with a colour. Beyond this there are many subtle variations that have different consequences with respect to the efficacy of the chart. These variations will be covered at appropriate points in the following critique.

Chart 1: Radar chart from Wikipedia

Critique

Axes and Values

The axes of radar charts represent independent scales for each of the quantitative variables under consideration. Therefore, barring occlusion, comparing values for a single variable between series is straightforward and relatively effortless since it merely consists of assessing their position along a line, something we are able to do without any thought. However, a number of distinct issues arise when attempting to compare values across different axes.

Firstly (and most easily grasped), by definition there is nothing prohibiting axes representing wildly different scales since they are nominally independent. This is shown at its extreme in Chart 2. Clearly comparison across variables is pointless in this case, yet it is something a radar chart is designed to encourage us to do. Hopefully from this extreme example you are also able to appreciate that even in subtler cases where the scales are genuinely independent, whether that be the inversion of the scale on one axis or slightly different ranges of values being represented, comparison is rather absurd. So much so that very few charting libraries or applications support this in any way.

Chart 2: Artificial radar chart by Stephen Few to show independent axis scales

Unfortunately, even with a common scale between axes, comparing values across them remains cumbersome and error-prone. This is because rather than the simple straight-line comparison our visual perception is hard-wired to perform that is found in “conventional” chart types, comparison in radar charts requires conscious thought to mentally project a sort of arc of rotation to map a value from one axis onto another, something we are not particularly adept at.

Chart 3: Radar chart byVisiblox

In order to help general perception and, in particular, comparison across axes, radar charts usually display gridlines connecting axes when they share a common scale (giving them their traditional spider-web-like appearance). However, even with these gridlines it remains cumbersome to compare values on non-adjacent axes. For example, try comparing the Space and Comfort scores for Monster Truck in Chart 3. It requires a surprising amount of conscious effort, doesn’t it?

Chart 4: Radar chart by Kap Lab

Aside from the non-data ink gridlines inevitably add, they also introduce further issues to radar charts. Mainly, they tend to add confusion around axis value labelling by breaking the association by proximity used to associate a particular value label with a mark on an axis. This is very clearly demonstrated in Chart 1. It requires active thought to disassociate the labels from the gridlines over which they inadvertently lie. For example, what is actually the $60 gridline appears to be labelled $50 instead. Chart 3 demonstrates a commonly attempted solution to this problem that unfortunately makes the chart just as difficult to read, only in a different way. Here the labels are so far away from the axis that, once again, conscious effort is required to comprehend what should be an inconspicuous, almost sub-conscious interpretation aide for the chart.

Chart 5: Radar chart by Dundas Data Visualisation

Occasionally the gridlines on a radar chart are presented as circles rather than straight connecting lines between equivalent values on adjacent axes, as in Chart 5. Conceptually, I do not understand how a chart can combine circular connections between axis values and straight line connections between series values. Surely they must adhere to the same notional underlying data space?! Otherwise the chart is fundamentally broken. If anyone feels like creating a radar chart using strictly polar data space for both gridlines and series shapes, could you please send me a link? I’ve never actually seen one, and always like a giggle…

Connecting Lines and Nominal Scales

The quantitative variables and their values represented on the various axes of a radar chart are, with the exception of some less common cases such as when plotting timeseries data, distinct and unrelated. Yet, by design, radar charts force the suggestion of some relationship between the variables by having a connecting line between values on different axis in order to create the series grouping, thereby misleading the user. To help clarify this point, the chart below is identical to Chart 5 except that the information is plotted using “conventional” cartesian coordinates rather than the (pseudo-)polar coordinates of a radar chart.

In this more familiar, non-circular format it is hopefully much more obvious that we are in fact dealing with a nominal scale on the x axis. That is, the categories on the x axis are simply named entities that have no intrinsic order and do not represent quantitative values. As such, the relationship and incline or decline in value the connecting line implies is grossly misleading since we could arbitrarily change the relationships by rearranging the categories (something we are free to do because of their lack of intrinsic ordering). When shown this way, many of you will recognise that this kind of information is likely to be best presented as a bar chart in some form, depending on the specific purpose of the chart, as shown for

Occlusion

Occlusion, in data visualisation, refers to the phenomenon where a part of the visualisation obscures another part. Clearly this should be avoided, or at least minimised, since hidden visuals prevents you from interpreting the information correctly. Unfortunately, the design of radar charts means significant occlusion is inevitable when multiple series are plotted, since they must be “on top” of each other. In cases where the fill colour of the shape of a series is relatively or completely opaque, such as Chart 5, it can be nigh on impossible to see particular values. In these cases, the gridlines are also at best partially obscured, thereby making it even more cumbersome to discern the value any any given point. In Chart 5 this is has been somewhat overcome by adding tick marks on top of the series, which, unfortunately, also adds to the overall clutter on the chart.

When transparency is used to circumvent the problems caused by solid fill colours it creates a new problem: the unavoidable tinting effect can make differentiating the underlying series or matching them to a legend very difficult. As such, the approach that suffers least from occlusion is when no fill colour is used, as in Chart 1.

Shapes

One argument given by proponents of radar charts is that we are naturally adept at seeing and evaluating simple shapes. Although this is true, it overlooks the major issue that the overall shape presented for a series on a radar chart does not leverage any of the pre-attentive attributes we perceive quantitatively. In essence, this means we are unable to attribute much genuine meaning to the shape of a series. The only patterns our visual perception can really discern in a data set presented as a radar chart are similarity and extreme outliers. Both patterns are just as easy, if not easier, to recognise in more effective alternative visualisations, such as line and bar charts, where the shapes also have quantitative perception. Consider the example radar charts above, can you reliably say anything useful about the respective series based on their shapes other than where they are similar or there is an outlier?

A further issue with the shapes presented by radar charts are that the area of the shapes increases as a square of the values rather than linearly. This can cause us to misinterpret the data since a small difference in values results in a significant difference in area, thereby exaggerating any difference when we follow our natural inclination to compare the size of the shapes.

Alternatives

There are numerous more effective alternatives to radar charts, depending on the information being presented. These include bar charts, as shown above, line charts (particularly for timeseries data), parallel coordinates charts and, quite simply, tables showing the raw figures. The latter is commonly overlooked, but when dealing with relatively small, simple data sets it is frequently the most immediate and clear way to represent the information. In more complex cases, a more effective alternative to a radar chart can be to use a concept called small multiples, devised by Edward Tufte, in conjunction with bar charts. Using this approach, individual series are separated onto individual charts, all sharing a common x and/or y axis scale to enable meaningful comparison across them. This way it is easier to gain both a higher level overview and investigate at more detail because the clutter, occlusion and related issues common to complex charts, and particularly radar charts, are removed. The following chart is a redesign of

Note that the x axis scale labels have been omitted because they were not present in the original example and, even after a little background research, I was unable to deduce them. As far as I can tell, the data used to create the original chart is fictional. If the genuine figures are of interest, I would suggest using Google’s Public Data Explorer.

An immediate advantage of using tables, bar columns or small multiples is that they naturally support ordering. With a radar chart, introducing ordering would require the starting point and direction to be explicitly indicated somehow since neither can be inherently deduced from the radar chart design. In the aforementioned alternatives, left-to-right or top-to-bottom ordering is immediately evident. Although ordering is rarely a strict necessity for a chart with a nominal scale, it can provide useful structure to the information that reinforces or enhances the story being told. For example, an ordering of best to worst for some value can add a great deal of clarity to a chart.

Worked Example

Based on what has been explained so far, it is hopefully clear that there are many more effective ways to represent the information shown in radar charts. To further underscore this and to show how a little more thought and effort put into the design of a chart can have a significant effect on its efficacy, here follows a worked example based on Chart 1.

As previously highlighted, the axis categories of a radar chart are frequently a nominal scale, meaning there is no relationship between their respective values. Therefore, it is immediately clear that a bar chart would be a better representation of the data shown in Chart 1.

In the particular case of Chart 1, it is a fairly safe assumption to say that the chart is ultimately trying to convey the over- and under-spend of the respective departments. As such, the following redesign focuses on the more important value, the actual spending, and its relationship to the budget, by reducing the visual salience of the budget values.

Furthermore, it can be assumed that in this case the relative over- and under-spend of the respective departments is the primary concern. By charting this difference as a percentage of the original budget and ordering the resulting bar chart from biggest overspend to biggest underspend, we have a very clear story of which departments are the worst offenders at both ends of the scale.

Conclusion

Hopefully it is clear that radar charts, despite the initial appeal due to their interesting appearance, are ultimately useless, in that they are unable to efficiently and effectively communicate information to users. Regrettably, many vendors of charting products continue to include them and users seem more interested in that first 5-second “cool” reaction than their ability to serve their purpose. Furthermore, vendors are, quite justifiably, assumed to be experts in their field, or at least to have more expertise than consumers. Therefore, so long as vendors of charting products continue to support and encourage fundamentally flawed features like radar charts, users will, unless educated otherwise, understandably continue to assume these features are perfectly suitable. Vendors then often argue that consumers request these features. And so a feedback loop of delusion has developed…

So I implore vendors of charting products to take a “brave” stance: please stop pointlessly including functionality that allows users to create flawed visualisations. Or, at the very least, stop implying they are good practice by featuring them on your websites and marketing material. You are collectively undermining the power of data visualisation by encouraging users towards cumbersome, frustrating charts that do not work, when really you should know better.

In a previous post I presented a library of sparkline implementations for Flex 3. I have finally gotten round to updating it for Flex 4. The new source code, documentation and pre-compiled swf (namespace: http://www.scottlogic.com/sparkline) can be obtained from here. As before, the components are being made available under the GNU General Public License.

As you can see, the versions appear identical:

Flex 3

Flex 4

Updating to Flex 4

For those of you interested in some of the changes required to migrate code from Flex 3 to Flex 4, here follow some of the details required to update this particular code.

The main change was due to Flex 4 essentially deprecating the StyleManager class and its static methods in order to provide mechanisms allowing modules to have independent style declarations. At the forefront of this change is the new IStyleManager2 interface, an instance of which can be obtained from the static getStyleManager method on StyleManager or, preferably, the styleManager property of UIComponent. In practice, using the Sparkline class as an example, this means changing from the static Flex 3 style declaration approach:

public class Sparkline extends SparklineBase
{
    /**
     *  @private
     */
    private static var stylesInited:Boolean = initStyles();
    /**
     *  @private
     */
    private static function initStyles():Boolean
    {
        var sd:CSSStyleDeclaration = StyleManager.getStyleDeclaration("Sparkline");
        if (!sd)
        {
            sd = new CSSStyleDeclaration();
            StyleManager.setStyleDeclaration("Sparkline", sd, false);
        }
 
        sd.defaultFactory = function():void
        {
            this.lineStroke = new Stroke(0x828282, 1);
            this.markerFill = new SolidColor(0x2963a3);
            this.markerStroke = new Stroke(0x2963a3, 0, 0);
            this.markerRadius = 2;
            this.normalRangeFill = new SolidColor(0x000000, 0.1);
        }
 
        return true;
    }
 
    ...
 
}

To overriding UIComponent‘s moduleFactory property to provide the “hook” for invoking the style declaration:

public class Sparkline extends SparklineBase
{
    /**
     * @private
     */
    private var _moduleFactoryInitialized:Boolean;
 
    /**
     * @private
     */
    public override function set moduleFactory(factory:IFlexModuleFactory):void
    {
        super.moduleFactory = factory;
        if (_moduleFactoryInitialized)
            return;
        _moduleFactoryInitialized = true;
        initStyles();
    }
 
    /**
     * @private
     */
    private function initStyles():void
    {
        var sd:CSSStyleDeclaration = styleManager.getStyleDeclaration("com.scottlogic.sparkline.Sparkline");
        if (!sd)
        {
            sd = new CSSStyleDeclaration();
            styleManager.setStyleDeclaration("com.scottlogic.sparkline.Sparkline", sd, false);
        }
        sd.defaultFactory = function():void
        {
            this.lineStroke = new SolidColorStroke(0x828282, 1);
            this.markerFill = new SolidColor(0x2963a3);
            this.markerStroke = new SolidColorStroke(0x2963a3, 0, 0);
            this.markerRadius = 2;
            this.normalRangeFill = new SolidColor(0x000000, 0.1);
        }
    }
 
    ...
 
}

You will also see that as of Flex 4, getting style declarations now requires a fully qualified class name rather than just the name of the class, e.g. com.scottlogic.sparkline.Sparkline rather than Sparkline. As before, this change is required due to the underlying shift in the approach used for style management by the framework in order to support independence between modules.

The other update required was due to the changed IFill and IStroke interfaces. In particular, the begin method on IFill takes an additional targetOrigin argument of type Point that specifies intended origin of the shape drawing. Similarly, IStroke‘s apply method now takes two additional arguments, targetBounds and targetOrigin, to provide the same drawing manipulation/restriction as IFill. Fortunately, the SDK team appear to have anticipated the potential complications and frustrations arising from these changes and have implemented them so that specifying a null value for the additional arguments results in identical behaviour to that which would have occurred in the Flex 3 code.

This post follows on from the comparison of two Silverlight chart libraries produced by my colleague, Colin Eberhardt, by adding an implementation of the simple image processing tool in Flex using the Flex Charting library to the comparison. The results show that the Flex Charts perform easily as well as the Visiblox charts without the need to specifically consider performance.

Since Colin produced his comparison of the Silverlight Toolkit and Visiblox charts there has been some noted interest in how Flash stacks up against them. This seems to be part of a general drive across the development community to gain a better understanding of the relative strengths of Flash/Flex, Silverlight and HTML5. In order to contribute a little to this, I produced a comparable application to those of Colin using the charting library that is part of the free, open-source Flex 4 SDK.

Here are my Flex application and the “winning” application from Colin’s investigation side-by-side. Click and drag a line across the image to plot the RGB pixel intensities along the line in the chart above. From these examples, it is clear that there is little to differentiate them performance-wise.

Flex Chart	Visiblox Chart

[Squirrel image used royalty free from stock.xchng; hare image used under CC licence from flickr]

Implementation

For details of the implementation of the Visiblox example above, see the original post. The mark-up for the Flex example above is as follows:

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
               xmlns:s="library://ns.adobe.com/flex/spark"
               xmlns:mx="library://ns.adobe.com/flex/mx" >
    <s:layout>
        <s:VerticalLayout />
    </s:layout>
 
    <fx:Declarations>
        <s:SolidColorStroke id="axisStroke" color="#cccccc" weight="1" />
    </fx:Declarations>
 
    <s:Group width="100%" height="100%">
        <mx:CartesianChart id="chart" width="100%" height="100%" visible="false">
            <mx:horizontalAxis>
                <mx:LinearAxis id="xAxis" />
            </mx:horizontalAxis>
            <mx:horizontalAxisRenderers>
                <mx:AxisRenderer axis="{xAxis}" axisStroke="{axisStroke}"
                                 showLabels="false" tickPlacement="none" />
            </mx:horizontalAxisRenderers>
            <mx:verticalAxis>
                <mx:LinearAxis id="yAxis" />
            </mx:verticalAxis>
            <mx:verticalAxisRenderers>
                <mx:AxisRenderer axis="{yAxis}" axisStroke="{axisStroke}"
                                 tickPlacement="outside" tickStroke="{axisStroke}" />
            </mx:verticalAxisRenderers>
            <mx:series>
                <mx:LineSeries yField="red">
                    <mx:lineStroke>
                        <s:SolidColorStroke color="#aa0000" weight="1" />
                    </mx:lineStroke>
                </mx:LineSeries>
                <mx:LineSeries yField="green">
                    <mx:lineStroke>
                        <s:SolidColorStroke color="#00aa00" weight="1" />
                    </mx:lineStroke>
                </mx:LineSeries>
                <mx:LineSeries yField="blue">
                    <mx:lineStroke>
                        <s:SolidColorStroke color="#0000aa" weight="1" />
                    </mx:lineStroke>
                </mx:LineSeries>
            </mx:series>
        </mx:CartesianChart>
 
        <s:Label id="instructions" visible="{!chart.visible}"
                 horizontalCenter="0" verticalCenter="0"
                 fontSize="9" color="#cccccc"
                 text="Use the mouse to 'drag' a line across the image below." />
    </s:Group>
 
    <s:Group>
        <mx:Image id="image"
                  source="@Embed(source='squirrel.jpg')"
                  mouseDown="imageMouseDownHandler(event)"
                  mouseUp="imageMouseUpHandler(event)"
                  mouseMove="imageMouseMoveHandler(event)" />
        <s:Line id="line">
            <s:stroke>
                <s:SolidColorStroke color="#000000" weight="3" />
            </s:stroke>
        </s:Line>
    </s:Group>
</s:Application>

The above mark-up creates two Groups: one containing the CartesianChart and instructions, and the other the Image and Line. This is remarkably similar to the mark-up of Colin’s Silverlight examples, if slightly more verbose. The verboseness is the result of both Flex technicalities and my overriding the rather ugly default styles axis styles for aesthetic reasons. Note that the CartesianChart was used rather than LineChart purely because of the LineChart using the ugly ShadowLineRenderer by default for LineSeries (the CartesianChart uses the simple LineRenderer).

Unlike in Silverlight, there is no need to do anything funky with mouse event handling Flex, as the Flex component lifecycle means the UI will always have a chance to render. This means a simple mouse move event handler can be used to construct the chart’s data:

private function imageMouseMoveHandler(event:MouseEvent):void
{
	if (!_mouseDown)
		return;
 
	line.xTo = event.localX;
	line.yTo = event.localY;
 
	// compute length of line
	var length:int = Math.sqrt(Math.pow(line.xFrom - line.xTo, 2) +
				   Math.pow(line.yFrom - line.yTo, 2));
 
	// build the chart data
	var bitmapData:BitmapData = Bitmap(image.content).bitmapData;
	var chartData:Array = [];
	var xIndex:int;
	var yIndex:int;
	var pixel:uint;
	var point:Object;
	for (var i:int = 0; i < length; i++)
	{
		point= {};
		xIndex = line.xFrom + (line.xTo - line.xFrom) * i / length;
		yIndex = line.yFrom + (line.yTo - line.yFrom) * i / length;
		pixel = bitmapData.getPixel(xIndex, yIndex);
		point.red = pixel & 0xff;
		pixel >>= 8;
		point.green = pixel & 0xff;
		pixel >>= 8;
		point.blue = pixel & 0xff;
		chartData.push(value);
	}
 
	chart.dataProvider = chartData;
}

Once again, this code is very similar to that used in the Silverlight examples to construct chart data. However, notice that here we can choose to take advantage of ActionScript 3′s dynamic objects to drive our chart for simplicity’s sake. Furthermore, there has also been no need to pre-process the image data to obtain pixel information since the Image, Bitmap and BitmapData classes are designed and optimised for exactly this kind of pixel-level manipulation.

Conclusions

From the above examples it is apparent that there is little, if anything, to differentiate their relative performance. Furthermore, it would be fair to say that the outright technology choice of Flash/Flex or Silverlight has not differentiated these examples. Rather, the choice of charting library in either technology is far more significant with respect to performance. Therefore, in this case, the technology choice would have to be driven by some other factor than performance, for example, plug-in penetration, cost or existing developer expertise.

However, at a more technical level there are some interesting points to consider alongside the comparative performance of the two applications. The Silverlight examples were created with specific techniques for improving their performance. The implication is that a naive Silverlight implementation of the application is likely to have noticeable performance issues. In contrast, the Flex example has purposefully been created without any of the known performance improvement techniques, yet is still as responsive.

It is also worthwhile contrasting the respective charting libraries. The Visiblox charting library has specifically been designed for performance over flexibility, where as the Flex charting library is the opposite. The result is that although they are roughly equal in performance, the Flex charting library has many more options for customisation and extension than the Visiblox charting library. However, it should be noted that the Flex charting library is relatively mature (~4 years old) compared to the Visiblox charts (~2 months old).

You can download the full source code for the Flex example given in this blog post here: FlexChartPerformance.zip; and the full source code for the Silverlight examples given in Colin’s blog post here: ChartPerformance.zip

Last week I attended a series of information visualisation workshops run by Stephen Few. The classes were based around his three books to date: Show Me The Numbers, Information Dashboard Design and Now You See It. Here follows an overview of the material covered and my thoughts on the event.

Show Me The Numbers

Day one of the workshops was titled “Designing Tables and Graphs to Enlighten” and focused on how to effectively communicate a single story in a data set using a table or graph. The starting point was to highlight that the Gricean Maxims apply equally well to the communication of quantitative data as they do conversational communication, i.e. information visualisation should:

• be as informative as necessary but not more informative than necessary (maxim of quantity)
• not convey any message that is believed to be false or for which there is a lack of evidence (maxim of quality)
• be relevant (maxim of relation)
• be brief and orderly, avoiding ambiguity and obscurity of expression

Fundamentally, to achieve this, Stephen Few proposes 2 major steps. First, you should determine the medium that tells the story best. (Should you use a table or a graph? If a graph, then which kind of graph?) Then you must design the chosen component so that the story is told clearly.

For the first step, the relative strengths and weaknesses of tables and graphs and different graph types were presented. Regarding graphs, Stephen presented what he considers to be the 7 relationships commonly displayed in graphs – time-series, ranking, part-to-whole, deviation, distribution, correlation and nominal comparison – and which graph types most concisely convey these relationships. Unsurprisingly, pie charts were a graph type singled out for their general ineffectiveness (see Save The Pies For Dessert for details). In addition to graph types, the concept of small multiples was highlighted as a simple technique for improving the affordance of graphs that endeavour to compare across data that differs only along a single variable.

Oh, and 3D charts, where to begin… The almost guaranteed occlusion (where something is hidden behind something else) meaning it is impossible to see the entire picture at once? The inability to directly compare values, sizes and/or positions due to depth? The colour variation due to “lovely” lighting effects?

With determining the appropriate medium covered, a range of techniques and areas for consideration were introduced with the aim of maximising the effectiveness of the chosen component(s). Edward Tufte‘s argument that the “data-ink ratio” should be maximised by removing, de-emphasising and/or regularising the unnecessary and emphasising the most important was introduced as the foundation of good table and graph design. Additionally, the fundementals of visual perception were considered and how they can be harnessed to improve the clarity of the story being portrayed. In particular, attributes such as size, shape, orientation and colour are processed pre-attentively. That is, we perceive and process them instantaneously, in a highly parallelised fashion and without conscious thought, thereby laying down an immediate interpretation before conscious thought is required. Further to this, the pre-attentive attributes of length, 2-dimensional position, width, size and colour intensity are perceived quantitatively, i.e. some values are greater than others, and are therefore powerful building blocks for data visualisation.

As well as covering areas such as where best to locate the scale, how to arrange the visualisation to avoid label rotation and how to minimise problems associated with legends, there was an emphasis on the importance of colour, from when and where it is (not) required to palette choice. A fair amount of Stephen‘s thoughts on colour are covered in his article Rules for Using Color. A couple of useful links that came up were Cynthia Brewer‘s Color Brewer, a tool for colour palette choice, and VisCheck, a tool for simulating colour blindness.

Information Dashboard Design

The 2nd day of the workshops, “Dashboard Design for at-a-glance monitoring”, built heavily on the first day’s lessons and focused on techniques and constructs that are of use when designing dashboards. First up was the problem that the term “dashboard” is used for all manner of products. Stephen defines a dashboard as “a visual display of the most important information needed to achieve one or more objectives that has been consolidated on a single computer screen so it can be monitored and understood at a glance” and states that “dashboards are not comprehensive tools for analysis, decision making or management“. The monitoring requirement suggests that to some extent there must be a “live” element to the screen, while their not being comprehensive tools suggests that there should not be an abundance of controls to facilitate filtering, etc. In my opinion Stephen is potentially limiting his audience with this, as most of what he presents under the context of dashboard design is just as valuable to report design and data presentation and/or analysis applications in general.

We started by focussing on the common mistakes made in dashboard design, such as introducing meaningless variety, arranging data poorly, misusing or overusing colour and introducing useless decoration. Unfortunately, many of these problems appear to stem from vendors. They are (understandably) assumed to be experts, yet their examples are usually little more than marketing fluff, so their designs are usually more concerned with graphical glitz than the actual intended purpose of a dashboard: communication.

Moving on to considering the techniques and practices that will improve dashboard design, the core idea was once again Tufte‘s “data-ink ratio” argument: “reduce the non-data ink; enhance the data ink“. A number of objectives specifically for the visual design of dashboards were also prescribed: eliminate clutter and distraction, group data into logical sections, highlight what’s most important, support meaningful comparisons and discourage meaningless comparisons. Each of 6 categories of dashboard display mechanisms (graphs, icons, text, images, drawings and organisers) was considered with the aim of achieving these goals. The most time was spent addressing graphs; re-iterating some of the previous day’s content and introducing a couple of graph types more specifically designed for the dashboard context: bullet graphs (see image below) and sparklines. Bullet graphs are Stephen Few‘s own development to address the requirement (unfortunately) usually fulfilled using gauges, i.e. the display of a single quantitative value against one or more comparative measures within the context of some qualitative ranges, e.g. poor, satisfactory, good. The benefits that bullet graphs have over gauges are numerous, but in particular they take up significantly less space and are more conducive to the aforementioned objectives. Sparklines, on the other hand, were introduced by Tufte in his book The Visual Display of Quantitative Information, and are designed to present trends or variations in a simple, space-saving way.

After touching on the importance of the aesthetics of the design (it should look appealing without impeding the aforementioned visual design objectives), we moved to critiqueing dashboard examples submitted by attendees. This proved to be a good exercise of the day’s lessons both for the submitters and class as a whole.

Now You See It

The final day, titled “Simple Visualisation Techniques for Quantitative Analysis”, was quite different to the preceeding days as it was focused on how to gain an understanding of and insights into data sets, rather than the communication of existing understanding. As a basis for the rest of the day’s material, the power of sight compared to our other senses was introduced and used as the argument for why data visualisation is a vital tool for exploring and understanding data sets. This was followed by a brief history of data visualisation, from the first evidence of tabular arrangement of data in the 2nd Century, through William Playfair‘s invention of line charts, bar charts and pie charts, to the spread of home computers in the 1980s and beyond.

The traits of a skilled data analyst and characteristics of good data were considered before emphasising the necessity for a solid understanding of visual perception and cognition to be able to take advantage of those traits and characteristics through visual analysis. Consequently, some time was then spent introducing a number of core aspects of visual perception and cognition. As during the previous classes, it was highlighted that visual perception is selective, meaning that we must encode data in such a way that what is potentially interesting or meaningful pops out by contrasting with the norm. Pre-attentive visual attributes were again introduced as the means by which this can be achieved, with length, 2-dimensional position, width, size and colour intensity able to encode quantitative values and shape and colour hue ideal for indicating categorisation. The limitations of perception were highlighted, with particular emphasis on the issue of inattentional blindness (the fun examples caught most of us out). Finally, some attention was given to the meaningful characteristics of data: trends, patterns and outliers; how to highlight those characteristics; and, which patterns and comparisons in data are meaningful, e.g. steep vs gradual and random vs repeating.

The final stretch of the class focused on techniques for performing meaningful data analysis by attempting to bring the characteristics and patterns introduced in the preceeding material to the fore. First we considered the various types of useful analytical interactions, such as comparing, filtering, aggregating, drilling and zooming/panning. Specific analysis techniques were then introduced for each of 7 categories of data analysis: time series, ranking and part-to-whole, deviation, distribution, correlation, multivariate and geospatial. Stephen used a number of different analytical tools – Spotfire, Tableau and Panopticon – to demonstrate not only some of these techniques, but also the state of what he considers to be the best of the current crop of data analysis tools. This crossed over into discussion of what the ultimate data analysis tool would provide: a tool that provides the appropriate set of visualisations and aforementioned analytical interactions that has no distracting lag between seeing something, thinking about it and manipulating it.

Closing Thoughts

My overall reaction to the workshops is definitely positive. Stephen Few is an engaging presenter who is able to eloquently convey many practical techniques and principles for information visualisation. The workshops appropriately complement the corresponding books by presenting similar material in a different way, with the group exercises and interactivity of the classes more actively re-inforcing the concepts.

The minor negative I would highlight about both his books and the workshops is that they appear to overly target the business intelligence domain. This in itself is not a problem, but I think it potentially sells short some of the ideas and information in the material, as I believe they are potentially much further reaching. Many of the fundemental concepts he teaches are too frequently ignored or simply not appreciated by those producing even the most basic of data visualisations. Moreover, visualisation and visual perception are key to other areas such as user experience and human-computer interaction, so it is unsurprising that most of his lessons cross over to such areas.

For those who like the sound of this course, it is being run again later in the year in London, as well as in the States and Australasia.

Sparklines are described by their inventor, Edward Tufte, as “data-intense, design-simple, word-sized graphics”. They are an ideal tool for displaying trends for single entries within large data sets, for example, stock prices. As well as the standard miniature line series, Tufte’s original specification introduces a ternary sparkline, a.k.a. win-loss sparkline, where small columns are used to indicate “win” or “loss” and no column to indicate “draw”.

This article is intended to present, and distribute, Flex implementations of sparklines, win-loss sparklines and another common variation, column sparklines. The Flex 3 version of the code and documentation can be obtained from here, while the Flex 4 version can be found here. The following is an example showing some of the variations available:

The Sparkline, TernarySparkline and ColumnSparkline classes are all implemented using core Flex functionality, i.e. there are no dependencies. They all implement IListItemRenderer and IDropInListItemRenderer interfaces, so can readily be used as standalone components or as item renderers in a DataGrid or other list control. Based on the original specification, the Sparkline allows the user to optionally show a normal range, x-axis min and max points and y-axis min and max points. All of these features and the line itself can be styled. Similarly, the TernarySparkline and ColumnSparkline allow the user to specify the “zero” value, and style positive, negative and zero styles independently. A final feature of the sparklines is that they will update automatically based on dataProvider updates, as shown in the following example, which plots a constantly-updating, randomly generated series of numbers:

It is worth noting that there are a number of alternative Flex implementations available. However, they all have further dependencies, potentially making them more heavyweight. For example, Tom Gonzalez and Andrew Trice both present implementations using the Degrafa graphics framework. Because of their use of Degrafa, these implementations inherently allow users to easily use any number of extravagant styling. Although potentially initially appealing, this goes against the good data visualisation practices suggested by experts such as Stephen Few and Tufte himself; “eloquence through simplicity”[ref]. Lucas Pereira and Sherlock Informatics both present implementations using the Flex Data Visualization library. The charts contained in the library are wonderfully feature-rich and flexible. However, this means that they are also rather heavyweight components and, therefore, using a large number of these as item renderers in an application is likely to use a lot of memory and/or make the application non-performant. A final potential alternative are the micro-charts available in the BirdEye visualisation library. Much like the examples using the Flex Data Visualization library, these can be perfect in situations where small numbers of instances are present, but again they introduce features that cause them to be more heavyweight than necessary.

The components are being made available under the GNU General Public License and can be obtained from here (Flex 3) or here (Flex 4). The zips also include some documentation and a pre-compiled swc of components, using the namespace http://www.scottlogic.com/sparkline.

UPDATE 19/04/2011: I have created an updated version of the library that is Flex 4 compatible. This is available here and a short article detailing the migratory changes can be found here.

An oddness in default behaviour that can throw those new to Flex Charting is that segments in charts that should correspond to a data point are missing. By this I mean charts like those in the following example:

When what is actually desired is the following:

This is achieved by setting the filterData property on the Series to false, for example:

<mx:LineSeries filterData="false" />

However, it is worth understanding the functionality that ties in with this property to appreciate the potential consequences. Adobe states:

When possible, set the filterData property to false. In the transformation from data to screen coordinates, the various series types filter the incoming data to remove any missing values that are outside the range of the chart; missing values would render incorrectly if drawn to the screen. For example, a chart that represents vacation time for each week in 2003 might not have a value for the July fourth weekend because the company was closed. If you know your data model will not have any missing values at run time, or values that fall outside the chart’s data range, you can instruct a series to explicitly skip the filtering step by setting its filterData property to false. [ref]

What is actually happening under the covers is that the series a collection of “all the data points” and a collection of “all the data points I think I want to draw”. When filterData is true, i.e. by default, the series creates the collection of “all the data points I think I want to draw” by iterating through the collection of “all the data points” and throwing away any that are null or NaN or that fall outside the axes minimum and maximum values. By contrast, when filterData is false, the two collections are identical. Knowing this it is obvious why the segments are missing in the example above: with the LineSeries if a data point is not to be drawn then the line segments to that data point will not be drawn; with the ColumnSeries if a data point is not to be drawn then the column representing that data point will not be drawn.

Performance-wise, it is worth noting that performance gained by the removal of data point filtering step by setting the filterData property to false will be offset against the performance lost by drawing data points that have no bearing on the view of the chart, i.e. data points that are one or two data points removed from those around the axes maximums. As such, the performance gain/loss and appearance gain/loss should be considered on a case by case basis.

An approach that can be used to get the best of both worlds is to extend the applicable series class and override the updateFilter method to ensure that data points that have no bearing on the view of the chart are filtered out, but any others aren’t. This could, for example, amount to filtering out any data points that do not lie in the range of the x-axis and that are not adjacent in the x-axis to a data point that does lie in the range of the x-axis.

An unfortunate note about the filterData property is that there is a bug when setting it to false on a LineSeries no data tips will show on the series (as can be seen in the example above). The bug has been filed with Adobe and has recently been marked fixed, however, the fix has not yet been released. The bug report details the relatively simple but somewhat nasty workaround that can be used in the meantime.

At Scott Logic the functionality relating to the filterData property as well as the property itself have been carefully manipulated to produce the various zooming and panning capabilities in our Hindsight application and the research charts available through our Market Overview pages.

The source code is now available.

The number of frustrating decisions in Flex’s charting API is minimal, but high up on my list is a strange decision that prevents developers from accessing information that is frequently desirable for custom data tips in stacked area, bar and column charts. The default data tips for stacked charts display, amongst other things, the total of the values for all the series at a specific point along the x-axis and the percentage the highlighted segment forms of this total, as shown in the following example (source code):

If you wanted to customise the data tips and still include information such as the total and percentage values then you would be out of luck. This why I consider the decision to give the necessary information protected scope in the relevant classes in the charting API as strange. Fortunately circumnavigating this issue only requires a little bit of dirty work…

But first, a brief diversion to provide a little background…
The code used to create a stacked column chart generally takes the following form:

<mx:ColumnChart type="stacked">
    <mx:series>
        <mx:ColumnSeries />
        ...
    </mx:series>
</mx:ColumnChart>

This is in fact a shortcut syntax. The ColumnChart automatically wraps the array of series into a ColumnSet with type “stacked”, as it is the ColumnSet class that takes care of the stacking and associated behaviour rather than the ColumnChart class. The same pattern occurs in stacked AreaChart or BarChart. Consequently, the following MXML produces the same end result:

<mx:ColumnChart>
    <mx:series>
        <mx:ColumnSet type="stacked">
            <mx:ColumnSeries />
            ...
        </mx:ColumnSet>
    </mx:series>
</mx:ColumnChart>

When wanting to create more complex combinations of stacking, clustering and overlaying in charts, this can only be achieved by explicitly introducing (and nesting) sets – as in the second code snippet. For further details on this see Adobe’s Stacking Charts article.
Diversion over…

To be able to display customised data tips that include information relating to the stacking in a stacked ColumnChart, BarChart or AreaChart we can take one of two approaches. Both approaches involve extending the ColumnSet, BarSet or AreaSet class (depending on the desired chart type) as it is the protected-scoped negTotalsByPrimaryAxis, posTotalsByPrimaryAxis, stackedMaximum and stackedMinimum properties that contain the interesting information. The first approach is to override the formatDataTip method in the extended class, resulting in something along the following lines:

/**
 * ColumnSet extension to introduce custom data tips.
 */
public class ColumnSet extends mx.charts.series.ColumnSet
{
    /**
     * @inheritDoc
     */
    override protected function formatDataTip(hd:HitData):String
    {
        // build up the custom data tip
        var tip:String = "";
        ...
        return tip;
    }
}

However, I think that this approach is slightly short-sighted because it means that for every customisation of the data tips you would create a new extension. The other, and in my opinion more reusable, approach is to expose the aforementioned properties publicly in extensions to the ColumnSet, BarSet and AreaSet classes. By creating these extensions, the standard approach to customising data tips can be used, i.e. a method with the appropriate signature is passed to the chart’s dataTipFunction property. The classes resulting from this approach would be something along the following lines:

/**
 * ColumnSet extension to expose the stack totals for public 
 * use, e.g. in a data tip function.
 */
public class ColumnSet extends mx.charts.series.ColumnSet
{        
    /**
     * @see StackedSeries.posTotalsByPrimaryAxis
     */
    public function get positiveTotalsByAxis():Dictionary
    {
        return posTotalsByPrimaryAxis;
    }
 
    ...
}

The minor downside to this approach is that the shortcut syntax for achieving stacked series, as used in the first example and explained above, cannot be used. The explicit syntax must be used to ensure that the extended version of the relevant StackedSeries extension is used.

The following example uses the approach presented above to provide customised data tips in the chart. The source code for the example includes the necessary extensions to the ColumnSet, BarSet and AreaSet classes, so feel free to use them.

The ability to allow a user to save a Flex chart, or in fact any Flex UI component, as an image has popped up on my radar several times over the last few years.  Solutions to the problem have generally involved producing a pop-up window with the UI component as an image that the user can then save, either by bouncing the information off a server (James Ward – RIA Cowboy and Flex Cookbook) or interacting with JavaScript (Doug McCune).  However, additions made to the framework in Flex 3 combined with new features of Flash Player 10 have made these cumbersome techniques redundant.  It is now possible to provide this functionality directly from your Flex application in two simple steps.

The first step involves capturing the UI component’s bitmap information.  The Flex 3 API introduced the ImageSnapshot class specifically to simplify this process.  The following line of code is sufficient to capture the image data:

ImageSnapshot.captureImage(myChart);

However, we are able to control the image capturing more precisely by using some of the method’s optional parameters. These allow us to specify the target resolution in dots per inch and the image encoder to use (the Flex 3 API provides a PNGEncoder and a JPEGEncoder).  So, for example, the following line of code would capture a chart as a PNG image at a  resolution of 300dpi:

ImageSnapshot.captureImage(myChart, 300, new PNGEncoder());

Now that we have captured the image data all that remains is the second, and last, step: saving the image data to the user’s file-system. Flash Player 10 introduced a number of changes to its security sandbox, principally the ability to programmatically prompt the user
to save a file to their file-system. This is done using the FileReference class, as shown in the following lines of code:

var file:FileReference = new FileReference();
file.save(image.data, "chart.png");

So, putting the steps together results in a method along the lines of the following code snippet:

/**
 * Attempts to save the chart to the user's file-system.
 */
private function saveChart():void
{
    var image:ImageSnapshot = ImageSnapshot.captureImage(myChart, 300, new PNGEncoder());
    var file:FileReference = new FileReference();
    file.save(image.data, "chart.png");
}

The application below shows this code in action. The values in the data grid can be changed,
with the changes reflected in the chart (just to show that I’m not cheating).

The source code is now available.