Responsive graphs (not very slight return)

A responsive graph, yesterday.

My last post was about making interactive visualisations (mainly graphs) work on mobiles as well as desktops and laptops. The idea was that the graph should work as a static exhibit with extra interactive functionality should you need it. In that way, the fact that the interaction can be tricky on mobiles doesn’t mean that the mobile version is pointless, just not quite as good.

This was mainly a design issue – make stuff clearer, have a story or finding more prominent in the viz, that kind of thing. But there is a substantial technical task around making the viz responsive – that is, the right size and shape for the device you’re on. Most websites themselves are responsive now – this one is, for instance. If you’re reading on your desktop, there will be around 12-14 words per line. On a mobile, it’s more like 8-10.

The thing is, the graphs themselves come from elsewhere, pulled in using an iframe, and they are not responsive. So every device is trying to draw them as if they were a desktop, meaning on a mobile, the graphs are massive. You can get round that by pinching and dragging etc but firstly that’s really annoying and secondly it means the text, which is responsive, is all unaligned and the whole thing is a mess.

I have tried making responsive graphs before and attempts sit a in a rather large file of “Stuff I tried that didn’t work at all”. (There’s a rather curt post about them here, which you can see demonstrates the point). That was a bit over a year ago, and obviously I wasn’t happy with the solution I found. But one of the things about using D3 is how quickly it’s moving on, how many more people are using it, and so how much better the solutions (free, natch) become.

Some pretty easy googling came up with this piece by Peter le Bek which sets out pretty clearly how to go about it. The idea is dead simple. When you draw graphs, you need to define a space into which you are drawing it – a sort of canvas for it. The dimensions for that canvas are set in pixels. But rather than giving a set number of pixels – it would be around 600 wide for the desktop version of the site, and 360 for the mobile version and now you’re seeing the problem – you can just set the width to be the width of whatever container you’re working in. (Obviously if you want you could set it to be some fraction of that, too). The height then can be set accordingly – you might not want to end up drawing weird looking long and thin graphs for mobiles all the time.

I should point out that the canvas is set according to the website you’re working on, not the device, which is even better. So you can use the same graph across different websites which are sized ever so slightly differently and it adjusts accordingly, just as it would adjust between a desktop and a mobile.

And everything follows from that. So whereas before I was writing code that said (for example) “My canvas is 500 pixels wide and I want my y axis to be 100 pixels from the left” it now says “My canvas is as wide as the website will let it be and I want my y axis to be at 20% of that width”.

That’s all fairly straightforward, but what Peter le Bek suggests is something a bit more interesting. Now that you know how big the container is you’re working in, you can do some very different things according to the device. In his example, he removes all the gridlines and axes for the mobile version to unclutter the viz. I was a bit less ambitious, and just moved the axes a little and adjusted the font size. Anyway, here’s the graph I was working on before, now properly responsive. If you hover over any part of the graph, the title changes to tell you the values you’re looking at.

The same principles can apply to maps, too, so here’s a map from our recent Monitoring Poverty and Social Exclusion report (full report here, with a couple more responsive graphs on the landing page and about a hundred more unresponsive ones in the pdf). If you hover over the map you can seed the value for each area roughly where Ireland ought to be.

So there we go. What I’ve got now is a decent template for graphs that interact if you want them to but don’t have to, and can sit on any device. It’s still fiddlier than I’d like, mainly because labelling the axes and naming the series can vary quite a lot from graph to graph and you need to make allowance for that. So it could be a bit more standardised and I need to work on that.

But the process has been quite revealing and the main thing is about the tooltip. For me, the advantage of looking at graphs on a website is that you can interact with them, and the most basic way of doing that is with a tooltip – hover over the graph, see the value. What I’ve ended up doing, sort of by default, sort of through trial and error, is to promote the tooltip and turn it into a changing title for the graph. The advantage of that is that you can explain a bit better what the numbers mean – it’s this many people in this year, or this proportion of people in this part of the country. So taking the example from the top of the page, if you hover over the dots, rather than a little box popping up with a number in it, there’s a full sentence at the top of the graph explaining what you’re looking at -ie there are more words. Here it is again

So I think I’ve learned two things here. Firstly, by thinking more about the device people use to look at the graphs, I’ve changed the approach for all devices. Secondly, I’ve realised that one of the key things in data visualisation is how you use words alongside the pictures.

Post script: As if to make the point, if you go to this site on a mobile (i.e. the whole site, not just this one post) it’s one thin, unreadable strip. That’s because the other graphs aren’t responsive, so the screen and the rest of the post resizes to it, rather than vice versa. I could go and change all the old graphs to make everything fit. But I have decided to leave them there as a Warning To Others. Also I am too lazy to change them, it’s loads of work, honestly.

Comments are closed.