Using responsive design to make websites readable across devices and screen resolutions grew from cutting-edge experiments to a core requirement in just a few years. Not a month goes by without some publisher announcing their latest responsive redesign. As we’re writing this, the latest algorithmic change by Google has been dubbed “Mobilegeddon” by commentators, rather than Google’s self-anointed #mobilefriendly. That’s quite a reflection of the trepidation currently surrounding this topic!
Whether fears of a biblical upheaval of mobile search results are founded remains to be seen, but anyone who has not yet made their website mobile friendly is probably working double shifts right now! As the screenshot above shows, Google is now explicitly highlighting those sites that they deem mobile friendly. (The orange box is ours, for emphasis.)
We have been working on responsive websites for years as have many forward-looking organizations, so we’re less concerned about Google’s latest fluctuations, and more about applying a fundamental user-centric focus to designing online products. There are very good reasons to integrate mobile friendliness in any publishing effort, regardless of how high Google tells the world to jump. In this entry we’ll assume you are sold on responsiveness, and we’ll drill down on the specifics of how responsive, data-rich and visual websites are best built.
At their core, responsive web designs focus on navigation (think top navbar vs. hamburger menu), typography, and layout (typically using grid systems), which is plenty of work in its own right. How to handle images adds another layer of headaches challenges, made even worse more interesting when graphics and tables are thrown in the mix!
Luckily, as more and more teams tackle these issues, solutions are on the way. Here is a review of how publishers do it, what solutions may be offered by visualization tools, and our recommendations for best practices.
Should You Use Interactive or Static Graphics?
The low tech approach to responsive charts is to turn them into static images. This is how Vox.com chose to use the Datawrapper library, precisely to fit within their responsive design. But the devil is in the details: when Vox launched in April 2014 their initial charts confused readers because hyperlinks that only made sense in the original interactive charts had been left in static screenshots.
Vox easily fixed this by adding a bit of image editing to their workflow before integrating charts to articles. Eventually the publication split its logo and created a separate HTML area so that they could feature actual hyperlinks to their data sources, as pictured below:
Vox.com chart – screenshot by Needle Stacker
It’s a radical choice to forego interactive charts entirely, especially when these charts are authored with a tool that supports interactivity. Vox is aiming to attract a large crowd of younger readers who presumably have fleeting, mobile-centric media consumption habits. Older, at-work audiences of professionals remain much more inclined to consume content from their desktops and laptops where interactive experiences work best.
On the other end of the tech spectrum, Tableau Public has found traction with many publishers, and for good reasons. Tableau has made their dashboards usable on tablets by supporting touch events, but the main bottleneck is screen real estate and how visualizations should adapt to arbitrary resolutions. Tableau Public objects are not natively responsive, nor are its dashboards. There are workarounds involving the creation of separate charts or dashboards, if one is able and willing to spend the extra time (we’ll come back later to that trade-off) and wander off the beaten path.
August 2016 update: the new Tableau 10 includes a device designer that lets you define separate views for smaller devices, such as stripped-down charts that can be seen on a phone held vertically.
More importantly, by their nature Tableau visualizations tend to feature a lot of detail that will be best experienced on a widescreen desktop. In the end this is more about human factors than technology per se. Even if and when Tableau embeds end up being responsive, small and simplified interactives may defeat the richness and depth that is their very purpose. Desktop computers are not going to disappear from the workplace anytime soon, especially to perform analytical work.
Somewhere between static graphics and high-end business intelligence can be found a variety of web-friendly charting/tabling libraries, mostly using client-side javascript. Let’s have a look of how they might handle responsive requirements.
Responsiveness is Becoming Embedded in More Tools
As Interhacktives noted last year, delivering data journalism on mobiles has been a challenge even for newsrooms reputed for their digital savvy. This review can’t be exhaustive, but we’ll highlight a few libraries and software packages to see how the visualization market is tackling responsiveness.
- Chartist.js is an open-source library that uses SVG, CSS, and media queries to provide a better responsive experience than most other similar solutions. This project was introduced in August 2014 but it seems to already have strong momentum on Github. For the technically inclined here’s a 5mn video and a good article from Smashing Magazine going through implementation details.
Adaptive axes and chart types using media queries with Chartist.js
- Chart.js added responsive support a few months ago. It uses Canvas rather than SVG and seems less ambitious in the way it’s pursuing responsiveness.
- Datatables.net is one of the most mature and best supported open source libraries to create sortable, searchable tables. We have used it in several projects and like its flexibility and power. Its creator introduced support for responsiveness in July 2014. Since then integration with the popular Bootstrap framework has made things even better.
Datatables can be configured to hide less essential columns in narrower resolutions (left)
- Tabulizer is similar in scope to Datatables and has responsive patterns built in. A big difference is that it’s a closed-source commercial product.
- Responsive Table Generator is a more lightweight tool that works with Google Spreadsheet as a source. Intended for much smaller tables.
- Google Charts API is not natively responsive but it can be forced into submission. Ditto with Highcharts and Fusion Charts.
- chartd is a newer tool to generate “responsive, retina-compatible charts with just an img tag.”
- On the other hand Amcharts introduced native responsiveness in January 2015. Other commercial libraries with native responsive capabilities include CanvasJS and ZingChart.
In summary responsiveness is on the radar of most charting/tabling toolmakers, but some are tackling this functional need heads-on while others put the onus on developers to hack their way to full responsive designs.
Best Practices: Retain Legibility Across Sizes, Weigh Cost/Benefit of Alternate Charts
At the very least, any responsive design worth its salt needs to handle images in a way that preserves their aspect ratio, otherwise proportions will be completely off. A letterbox chart crammed into a square thumbnail will be hard to read and may even look unintentionally funny and unprofessional.
Assuming the design’s responsiveness properly handles images, posting charts as static files has the benefit of being the solution with the broadest device compatibility and fastest loading speed. To deliver on that speed promise, charts have to saved in the appropriate file format, either as GIF or PNG with the appropriate bit depth. The JPG format on the other hand should be reserved for pictures and will be either too bulky or look blurry for graphics. How to optimize images depends on your toolset and workflow, but this should be documented for systematic replication, rather than left out to chance.
Static, optimized, and resized images is also the way to go to surface up charts in email newsletters. People increasingly read their email on mobile devices, and even newsletter templates – known to necessitate horrendous HTML code because of how email clients work – can be made responsive with a bit of elbow grease.
How to handle complex charts?
More complex charts can have fairly high information density, and items such as legends and titles risk being unreadable in smaller sizes. Even charts that have been made with great care to remove any unneeded flourish won’t degrade gracefully past a certain degree of shrinkage. Ideally this will be addressed by producing:
- Cropped/zoomed thumbnails that focus on a salient detail of the full-size chart
- A much simpler version of the chart whose sole intent is to hint at the broad shape/trend of the full thing
- Images displaying just one or two leading numbers revealed by the chart
- Or a combination of the above
Here is an example charted by JC Lupis here at Needle Stacker, first at full size:
Includes axes, legend, title, sources, gridlines, and branding
(charts we make for our customers bear their logo)
And here is how that chart looks like when scaled down to 300 pixels and 150 pixels in width, versus two simplified charts made on purpose for these respective thumbnail sizes:
Suggestions for thumbnails optimized for their respective sizes
(best solutions on the right, with green borders)
These simplified charts don’t try to do everything that their full-sized parent can, but they still convey some of the narrative or trend highlights, within much tougher constraints. They retain informational value and work better to pull people in than big charts crushed to fit in a small box. We not only removed many chart elements, but also changed colors, fonts, which datapoints are displayed, and even the timeframe. It’s all about starting from the available space and adapting content to that constraint. This is exactly what the just-redesigned Wall Street Journal does here:
WSJ.com charts – screenshots by Needlestacker
This approach obviously involves more production work, which is why we obsess about honing productive workflows that scale beyond ad hoc charting. The production of separate thumbnails is both an editorial decision and a user experience concern. In the end it’s also a business decision where resources are weighed against benefits. Most publishers don’t have the wherewithal and economies of scale that a title like the WSJ can bring to bear.
An acceptable compromise is to crop charts so that the overall shape of a chart remains apparent, even if its details cannot be read. This works as an appetizer to get people to click (“hey, there’s data in there, looks like a pretty volatile series!”), as seen in the example below:
The Economist’s square thumbnails only take 90×90 pixels – screenshot by Needle Stacker
Such workarounds become mandatory to surface up large interactive visualizations, as done by the New York Times and Le Monde below:
lemonde.fr and nyt.com charts – screenshots by Needle Stacker
What’s the right trade-off for you?
Delivering the user-centric “ideal” is not always economically viable, and to what extent mobile trends should influence chart/image production is the kind of trade-off we discuss with our customers. Publications with a heavy focus on mobile readership should pay heed to legibility at smaller sizes, which can rarely be achieved by simply resizing bigger charts. Besides, smaller chart versions may also be useful for print, though they’ll have their own set of production values, e.g. by using more elegant, serif fonts that wouldn’t read well on cheaper phones.
Yet in some cases, simpler techniques such as resizing, cropping and zooming graphics remain a perfectly valid choice. There is no one-size-fits-all solution to this, but rather a set of guiding principles to be pondered against specific business goals and audience expectations.
Organizations that want to develop visualizations while capturing more mobile readers are very welcome to contact us. Let us worry about all of the above while you focus on your core editorial and marketing functions!