GOV.UK Performance provides a growing number of dashboards for government services. These dashboards track and show how well services are doing. This is vital information that helps those providing the services to improve further. The dashboards present data in many ways, including tables and interactive charts.
This post explains why we developed Spotlight.
A bit of history
We have been developing GOV.UK Performance since early 2013. Originally, we developed the frontend as a Ruby on Rails project. Rails is an integral part of the GOV.UK software stack, which allowed us to deploy the Performance Platform easily. That rails app acted as the main client of our backend data API.
Unfortunately, this approach meant that you did not have access to our content if you:
- used an older browser
- had additional accessibility requirements
That may have been okay for a prototype but as we started to roll out dashboards for real users it wasn't good enough. We were breaking:
- a fundamental principle of good software for the web – that content should be available to as many people as possible
- our own design principles
Worse still, our primary users – service managers, people responsible for the success of the services - are often primarily using legacy browsers and so could not access all our content. This meant that we had to rethink how we made our data available to the world.
We had learned more about the needs of our users, and how we should meet them. But we did not want to:
- lose the flexibility of the existing solution
- increase our development effort by developing a completely separate server-side layer
Fight fire with fire
The code is built on top of the Backbone.js library and follows an MVC-like structure. We call our core abstraction a module, with each module providing a specific type of visualisation. A collection of modules makes up a dashboard. The typical rendering process for a Spotlight page looks like this:
First, find out which modules constitute the requested dashboard and instantiate each module. Next each module retrieves the required data from the data backend and renders the visualisation.
The event-driven nature of Node.js has proven a great match with this approach. Once all modules have finished rendering, the server can send the page back to the client.
An extra benefit of this structure is that modules are standalone things in their own right. This gives us more flexibility in the ways we visualise data. For instance, it's now much easier for us to show a summary version of a module on a dashboard and then link to a page where the module expands out to show the concept in question in greater detail. This is something we're looking to build on over the coming months.
A few minor modifications were necessary to make the existing client-side code compatible with Node.js.
- Second, our rendering code assumes a browser to be available to build up DOM elements. While Node.js does not provide a DOM implementation out of the box, the jsdom fills this gap very well.
Almost all our code works on both server and client, and we ensure this by running our Jasmine-based test suite in Node.js and PhantomJS as part of our continuous integration process. There are only few places where we had to create explicit client or server specific branches. The biggest difference between client and server code is that we need to react to user interaction on the client. On the server, we register these event handlers regardless but they simply do not get triggered.
Using the same code on both client and server side is still an emerging approach. It seemed promising enough to be worth some effort and we were pleasantly surprised by how straightforward it was to achieve the transition. We released our first Spotlight-based dashboard in November and are converting our other dashboards. We're pleased with our experience so far and would encourage others to consider this approach.
Oliver Spindler has now left GDS but kindly wrote the above in order to document and explain the work he did whilst he was here.
If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.