How to publish charts in blogs and websites?

Everyday, bloggers and site editors use statistics to prove a point. How convenient would it be if they could easily support their argument with a chart. This is the type of thing that goes without saying in the print world, but is not that obvious on the web and on blogs.

Here is a little review of the options.

To insert a graph you have the choice between 3 strategies.

The first is to upload an image file. You can use whatever means to create your image, including offline tools, image editors and the like, then you take it online. The problem is that the quality of the image can be poor, and the more operations it has to go through, the worse the image will be, especially if:

• the original image is in a lossy format, like low-quality jpeg or gif,
• it contains text.

The second is to generate it on the fly on the server side. That can be done by scripts that sit on your server, or one someone else’s.  Those scripts can generate an image that fits your specifications. Because this image is designed to be published online, it will look crisp in any circumstances. But then, you won’t be able to touch it up using image editors, or to do anything that the server code that generated it won’t allow.

The last option is to create the graph on the client side, using technologies like Java or Flash and embedding the result on the page. The downside of these solutions is the loading times, but in exchange they can provide interactivity. There are also javascript- and even CSS-based solutions, although this can be an issue for bloggers on hosted plaforms like this one where I have access to neither.

The other problem of the two latter options is that they can require a certain degree of coding by the editor.

So that being said, let’s review the solutions exist, and how would they handle the graph in my last post.

1. Excel + Flickr.

For better or for worse, Excel is a de facto standard when it comes to analysis and graphing. If anything, Excel is versatile and flexible, and is an environment many feel comfortable with. My main gripe with Excel, though, is that many graphs are designed to look good in Excel, and end up being completely wrong, or flawed, or inefficient. That being said, for our example, I started by doing my graph in Excel.

Excel comes with a variety of options to export a graph to an image. The crudest of all is the good old screenshot. Cropped in MS Paint, it can then be directly uploaded to the web as a file, or stored on a image-sharing platform, such as Flickr, then linked to by blogs and websites, who can suffer from storage limitations.

The good side is that this requires little technical skills, and that you can do whatever you can do with Excel.

Different graph exporting option exist from Excel. While they usually give better results than just capturing a screenshot, none of them really gives perfect results. It is possible to export charts to GIF format through Visual Basic. You can copy the chart and paste it in an image editor, or copy it “as a picture” if you prefer.

Screen capture, cropped in an image editor, then saved as PNG.

Exported to GIF using VBA.

Copied from Excel, then pasted in an image editor and saved as PNG.

Copied as a picture, then pasted in an image editor and saved as PNG.

In that case the difference in quality is pretty striking. The solid colours have been lost in the GIF version. The text is edgy in the screenshot and in the copied as a picture versions. The best output is the 3rd one, where I just copied the excel chart in the image editor. Also note that in the GIF version, elements which were not part of the graph proper (text boxes which had been added to the graph) have been lost altogether.

In these versions, the picture has never been resized. But this is a common operation, as graphs often have to fit in a given template, and considering that Excel doesn’t give the possibility of controlling the exact size of the output. So let’s see what happens to our best version if it’s resized to 300px:

copied from Excel in an image editor, then resized (403px to 300px) and saved as PNG.

And there we are: the text (title, series and axis labels) becomes all blurry and difficult to read. Axis ticks are also barely legible.

Another problem is that all you have is an image. No data, no nothing.

Flickr is a notorious chart repository, notorious because it is really not designed for that. Charts which are deposited in flickr become mere images, severed from their data. Plus, the flickr environment assumes that images stored therein can be resized, which is often not good for statistical charts. That being said, as Flickr is the prime internet image repository, it is used a lot with that purpose. See for example this chart from Flickr user .rxequo:

Excel + Flickr. A common combination.

2. Google spreadsheet and Zoho

Google spreadsheet and Zoho are online competitors to the Office suite. Open an account, then you can work online from your browser and share your work, including your graphs. Since you have to give the spreadsheet data to make the graph from, this data is stored online and you can easily share it along the graph.

Graphing with Google Spreadsheet and Zoho is as easy as with Excel. However, the options are more limited: those who took for granted that you can change the font of the axis or the colour of the series are in for a disappointment. From a developer’s point of view this can seem like a detail but from a designer’s perspective, being able to display one x-axis label every 3 years would have allowed me to display my first and my last year. Here, I have to live with the default options.

A Google spreadsheet version of the graph. Forget formatting axis or choosing colours.

And this is the Zoho sheet version of the graph.

3. Swivel and Many-eyes.

I’m a big fan of Swivel and Many-eyes and I use them as often as I can. They have both been designed to solve this specific problem elegantly. Like Google Spreadsheet and Zoho, they let users share data along graphs, but in a much more integrated and powerful way. Users can manage datasets which can be described and tagged, then create graphs from those datasets. And because both are web applications, they have been built to work well in a browser environment.

The problem is that like Zoho, options are limited.

The Swivel version of the graph, which is the one I published. For extra clarity I chose to represent one variable only. However I would have liked to format my Y-axis, 5% and 0.05 are not the same thing.

In Swivel, there are a very small number of graphs: scatter plot, horizontal or vertical bars, pie charts and line charts. If you read Stephen Few a bit too quickly, you can assume that it’s all you’d ever need. But it’s a fundamental error: to make a point, you absolutely need to be able to control every aspect of your graph, even if its form remains familiar: combine series, group or highlight some datapoints, format axis, and so on.

The whole design idea that “our machine builds graphs, you choose which you like best”, which all now agree was flawed, makes it difficult to plot slightly complex graphs, such as charts with two series. While it is possible, it is not easy to find the steps that will generate what you want. Like google spreadsheet or zoho, Swivel lacks formatting niceties that people are used to with Excel.

Where Swivel absolutely shines, however, is its export options. Once you are happy with your graph in Swivel, you can export it to any size you like, and you can choose all the elements that will be exported – titles, axis, you name it – they can all go. The export is really a link to the Swivel servers, so it is dynamic, should the graph change. Because you control the output size, text will always remain as legible as can be. Moreover, swivel is an integrated service. When you click on the graph, you go straight to an environment when you can access and manipulate the data, and get more information as available.

Now Many-Eyes, while its mission statement is comparable to Swivel’s, doesn’t have the same strengths and weaknesses. Many-Eyes offers many more graph types than Swivel, many of which are interactive – isn’t it what the web is all about? Still, Many-Eyes export options are far less convincing. There are only 2 available sizes and they don’t really do justice to the charts. Plus, they require javascript, which is not an option on platforms like WordPress. So when I need to link to a many-eyes chart, I create an image and link it to the chart on the many-eyes portal. Not an ideal solution, but it works better than the standard option.

When you create a visualization that you like, Many-Eyes offers you to share it. This is what you get for your blog, 200px wide.

This is the Many-Eyes graph, touched up in an offline image editor.

4. Processing

People who think that Excel is the most versatile graphing solution obviously don’t know Processing, where the only limits are not even those of your imagination, but those of all of its users collective imagination, which can be pretty far-fetched.

Processing can do any kind of graph you can think of. On top of that, it supports interactivity – key presses, mouse controls, etc. The intended use of processing is to create java applets. Now this can cause problems on sites and blogs. Applets, as we all know, take a few seconds to load, which can be too much for a casual visitor. But processing sketches can also easily be exported to static formats, like images or PDF documents. And recently, processing.js was released, a port of the processing framework to Javascript. Most functions have been astutely ported, the result is very fast and impressive.

This is a PNG image which has been created by processing.

Due to the limitation of the WordPress.com platform, I can’t show you interactivity on either a javascript or a java version. This is also a concern and a constraint. I did a simple mouse-over thing when moving your mouse over the graph would highlight the current year and show the number. So all I can do is provide a screenshot and ask you to imagine this moving until I change hosts:

OK. now imagine this column is moving with your mouse.

Now while programming processing is relatively accessible, it still requires programming. Most significantly, Processing is intended to make you think every new project from scratch, and create the ideal solution for your need. Obviously, you can also come up with generic, reusable Processing sketches. But the point is, working on a processing solution can take time especially for a non-specialist.

5. jpGraph and google chart API

jpGraph is a popular php library for creating graphs. it is powerful and very versatile, as every element of a graph can be controlled. But it requires being able to upload it on a php-capable server, which is not something offered by free blog platforms. And also, it requires some programming capacities. The output of jpGraph is a generated image, so it can be used as such wherever an image can be put. Also, the size of the final image can be controlled, so there are little risks of presenting a distorted chart.

The graph rendered with jpGraph. To be honest I'm really not good at jpGraph so imagine it much nicer.

The google chart API has quite similar functions to jpGraph, although its syntax is different. Rather than requiring users to code a php page, they must pass arguments to a web address. The result behaves like an image. So anyone can use the google chart API no matter their platform and technical limitations, as long as they can link to images. The API has its limitations, starting with the number of graph types. It is also complicated to pass all the arguments, especially encoding data. But it can be a relevant situation in many contexts.

And this is the Google chart API version. Strangely, we get more control than in the Google Sheets version.

6. The yahoo UI chart API

This solution relies on javascript and flash, so it’s a no-no on wordpress platform. And it’s too bad, because it is quite interesting. Its flash format gives it two advantages: it is vectorial and can therefore be presented in any size, and it is interactive. YUI charts function in a similar way to jpGraph, that is, the user has to specify all the details of a graph in script, then it is rendered. Now the downsize is that YUI is a 50Mb install, and a fairly heavy-duty solution. This rules it out, I’d say, for virtually all bloggers. Add to that that charts are still considered experimental. That being said, considering the possibility it offers, it’s really worth keeping an eye on.

Because I can’t include an example here, here’s a link to one put up by the developers.

7. Other solutions

As I said in the introduction, there are a number of solutions to create graphs in javascript only, such as this one or this one. And there are other solutions to do graphs with CSS. Just enter values in a normal HTML table, and see the result being turned into a bar graph. There are also solutions to create CSS line charts.

8. An ideal world?

Currently, only Swivel and Many-eyes offer an integrated environment with an interface to upload the data you want, describe it, then create the graph you want, and give your readers the possibility to access it all in one click. That alone puts them far ahead of the other solutions.

Obviously, they are not without problems: Swivel’s lack of graph flexibility makes it close to useless when it comes to representing non-trivial graphs, and Many-Eyes sub-par blog integration is really a bottleneck to an otherwise fantastic service. Despite having more graph types than Swivel, Many-Eyes could provide some more options, especially in axis formatting or colour choices. That wouldn’t ruin the whole experience.

Google chart API is a great idea, because it has no technical requirements for the user. Who cannot link to an image sitting on another server? When you’re in the need for a quick graph, where accuracy is not essential (and it shouldn’t be, else: use a table), it can provide excellent results. What baffles me is that with the relative complexity of the parameters format, the developers haven’t provided a form where users could input their parameters in a sensible way, and get code as an output.

YUI charts has perhaps the greatest potential, but it’s not practical yet. If it were possible to send parameters to a server sitting at Yahoo, like for Google chart API, that could lift some barriers.

Among the solutions that require programming, processing is fantastic because there is nothing it cannot do. It’s fairly easy to replicate what Excel can do in processing, then tweak it. I mean, you shouldn’t have to center the title of your graph if you don’t want to, right? Plus, it allows you to produce an image of the size you need, so no more resizing. What’s more, processing engages you to think beyond Excel and bar charts to find a visualization that’s right for you. The problem is that you need time. And processing will create an image, or an interactive graph, but it won’t publish data like Swivel or Many-eyes. Still, it’s worth trying when you have a vision and you can’t make it happen with the usual tools.

jpGraph is interesting if you have a php-enabled site, as you can pass parameters from the web context (like, you can interact with forms). By contrast, processing is more of a stand-alone solution.

I’m not convinced by zoho or google docs for publishing graphs, although give them a couple of years and they’ll probably be able to do whatever office is doing. Then, I’ll be more than happy to reconsider.

Screenshots from Excel, especially lossy ones, are still the most common solution and that’s too bad. People who would like to publish simple bar or line charts should really try Swivel instead.

Now if I were to design a solution for that problem, I would consider 5 aspects.

• the graph has to look crisp at any size. This begs for a vectorial solution.
• the graph should provide interactivity. At the very least, it would provide infotips.
• the solution shouldn’t have any technical requirements from the environment it will be posted on.
• no programming. not even a little bit.
• the graph should be published with the data.

The simplest way to make this happen is through a flash/flex solution hosted on a third-party server.

You create your graph there, in return you get code to paste into your blog, like an image and a link. The type of thing that any blogging platform or content management system would accept.

From there, you are taken to the server that hosts your interactive graphs and you can do whatever you want.

Other experiences? agree? disagree? Please share in the comments.