Charting the Alpha

Guest post from Martin Coulthurst, chief chart-builder and map-maker for the Alpha project..

The Alpha website features interactive, responsive charts as much as has been possible. As with all the decisions we took this was based on a user first approach and for data visualisation, this meant presenting the data visually in an engaging way and providing simple tools to help analyse it. Although it was not directly connected to data visualisation, another important development of the website was providing easy access to the raw data.

The site uses the Highcharts library to produce interactive charts for the time series pages, snapshots for the Statistical Bulletins, as well as the neat spark lines that all help illustrate the changes in headline figures.

The use of spark lines is one aspect of the move to follow the evolving best practice in data visualisation. The homepage has been through a number of versions in an attempt to optimise it to the ONS visitor’s requirements. These included many different approaches to presenting the key figures. The use of spark lines references the work of Edward Tufte, Stephen Few, et al. in working to best practises in minimising ‘chart junk’ and providing easily understood content.

The same approach has been used with the other charts. For historical reasons, work on the charting began before the Alpha, with some prototype tools being designed for the existing website to visualise time series data. One tool was used to chart inflation data. It allowed the user to view the three variations of inflation data and its component parts. As with all aspects of the Alpha, user feedback was invaluable in refining the features, and feedback from this early prototype helped define the features of the final product as it was developed into the generic time-series pages.

One of the first things we carried out was a desktop study of existing sites, with sites like Fred, Census Reporter and OECD standing out as influential in the design work. Also the significant work of the GDS team can’t be overstated.

As part of this ongoing development work, we looked at various technologies, frameworks and libraries for displaying the data. In addition to the websites, we also reviewed a range of charting code libraries to find something suitable to our needs.

The charting toolkit needed to be

• Highly customisable
• Flexible
• Easily styled
• Able to produce very simple charts,
• Able to increase the complexity and include interactivity and annotations.
• Responsive
• Provide cross browser support
• Maintainable code, broad developer community /support
• Ability to provide fixed tools with dynamic data

A quick search of the internet reveals a whole range of tools and a host of open source libraries for charting, with more versions being added all the time. The most flexible library for our requirements was Highcharts, which provided a mature, customisable framework for the charts, together with responsive nature and good support for historic browsers. (I can’t mention browser compatibility, without sparing a thought for the section of our audience in the public sector – all the workers with locked down desktops who are literally forced to use old version of IE). On the negative side, there were some slight concerns about the JQuery requirement and the size of the library and the fact that it was not open source but these where outweighed by the benefits in the short term for the Alpha.

Another consideration when picking the technology was the ease with which the charts could be styled and customised as well as the ability of the team to maintain them in the future.
Another candidate for the charting was to use d3.js and produce a range on of custom charts. This would have meant built a significant amount of the framework ourselves It is likely that future developments take this route, but for the initial work the idea was to provide a basic range of charts that worked on a wide range of devices for as wide a range of visitors as possible.

The future development of the charting components was also a factor in the decision, so using a commercial product had its advantages over creating a custom library.

With this decision to use Highcharts, The next step was to look at the types of charts that are currently used on the ONS site. These are split into the custom interactive data visualisation tools build by the team in Titchfield, and the generic charts that are mainly included in the constant stream of Statistical Bulletins.

Following on from this we produced a core list of charts covering the key statistics: column and bar charts, population pyramids, multi-series charts, tables and interactive maps.
From this list of core charts, we mocked up a page with actual data from stats bulletins. (One lesson learnt from the 49 varieties of homepage was the challenges in use of real data: missing values, zero values, multi-series with same values, and the labelling of charts). This was then refined from a design point of view, with best practice again in mind, to simplify the charts and to standardise their appearance.

This gave us an initial direction ( This was reviewed by CXPartners and proved useful in providing more responsive solutions, especially with responsive tables. After incorporating the changes suggested, the templates for the various charts were used in generating a range of charts for a variety of Statistical Bulletins.

Finally just a note to flag up the clever way the team has implemented access to the raw data. The plan is to make it possible to directly view the time series data by altering the url to include ‘data’: eg from!/economy/inflationandpriceindices/timeseries/d7g7

This then returns the time series data in JSON format and allows people to build their own data visualisation using the data.

2 comments on “Charting the Alpha”

  1. I hope you’re also going to support accessing the raw data in a RESTful way whereby the client can tell the server how it wants the resource to be represented by using the HTTP Accept-Content header, without the URL changing.

    Also, why the tredeger.* URLs in your examples rather than

  2. Re the Tredegar links – that is basically because that is what Martin had access to when he wrote the post and I forgot to update the links!

    As for the RESTful question that is certainly the intention at this point but we have a whole load of re-architecting to do first (assuming we get the nod)

Comments are closed.