OECD eXplorer tool now live

A screenshot from the OECD eXplorer tool.

The OECD eXplorer tool, which I mentioned in a previous post, is now live and available at the following addresses:

• Version with small regions: http://stats.oecd.org/OECDregionalstatistics/indexTL3.html
• Version with large regions: http://stats.oecd.org/OECDregionalstatistics/indexTL2.html

This tool has been developed by the NCVA, the Swedish National Center for Visual Analytics, at Linköping University.

OECD GDP growth projections 2008-2010

OECD GDP growth projections

The OECD released yesterday one of its flagship publications, the Economic Outlook.

This book makes projections about the economies of the 30 OECD member countries, as well as major non-OECD countries like China or India. In this context of uncertainty, it was highly anticipated.

This maps summarizes the GDP yearly growth projections for 2009. Under the EO hypotheses, most OECD countries will experience recession (blue = GDP drops) during this year, but growth should be back in 2010.

You can get more information by clicking on the map or by checking the Economic Outlook website which contains more data.

New visualization tool for OECD regional statistics

A new direction in which data visualization is progressing fast is the display of local statistics. 

Many national statistics offices have launched fascinating initiatives based on local data. Take, for instance, CommuterView from the British ONS, or Statistics Netherlands’s CBS in uw burt (Statistics Netherlands in your neighborhood). And all the work done around Mapresso, a Java applet for generating cartograms, sponsored by the Swiss Federal Statistics Office. (here are some interesting examples with official data).

A map generated with Mapresso. This one shows the families with 2 children as a percentage of all families with children.

Official data providers are not the only ones to showcase sub-national data, see for instance the works of Dataplace.

Population density in the USA using dataplace. Data is at the county level.

Presenting data at a sub-national level is relevant, because for most indicators, variations within one country are comparable to variations between countries. Take the GDP per capita of the UK, for instance. That of its richest region is much greater than Luxembourg’s, whereas that of its poorest region is comparable to Poland’s. 

The OECD publishes Regions at a glance, which provides an answer to these problems. The organization is now about to go one step further in partnership with Linköping University who has developed the GeoWizard application. When I first saw the GeoWizard in action, it was an offline client.

GeoWizard example with Swedish data

Professor Mikael Jern and his team have turned it into a web application and loaded it with OECD regional data. It will be shortly available on OECD Regional Statistics portal. The GeoWizard combines several data visualizations, a choropleth, a parallel coordinates chart and a third panel which can be a data table or a scatterplot which can display three variables (x- and y- axis, plus radius). 

Here are a few maps obtained with OECD data:

Population over 65 as a percentage of total population. Dark means more

GDP per capita. Blue means more, black means no data available

Population density. Dark means more

Unemployment rates. Red means more, black means no available data.

Official data and copyright

A few months back I have met Hans Rosling, of Gapminder fame. When he learned that I worked at the OECD the conversation steered to access to data and copyright policies. As Mr Rosling vocally claims, the hard part of Gapminder wasn’t to build the software, which took many man-years to produce and fine-tune, but really to access the data. Why?

When I started working in publishing, Eurostat had just decided to stop selling data, and there was a heated  debate between proponents of free data dissemination, and those who prefered the conservative model of selling data to those who used it. This debate and its consequences, which I will probably discuss in another post, clouded the fact that, priced or not,in the vast majority of cases data remained copyrighted. In other words, although you don’t have to buy it, you are not allowed to reuse it without express content of the copyright owner.

How we handled it at the OECD is that we have a rights unit, to which you should send a request, and they came back to you with a contract and a price. In almost every case (personal use, small data sets…) the copyright was waived, but the simple fact that data are protected under the copyright means that people are not allowed to use it directly, even if they didn’t pay to get it. Free is not public.

In a paper Infringement Nation, law professor John Tehranian explains how after an ordinary day, “he has committed at least eighty-three acts of infringement and faces liability in the amount of $12.45 million (to say nothing of potential criminal charges).” – by seemingly innocuous activities like answering emails, taking photographs of people, doodling on his notepad or distributing reading material to his students. Another law professor, Larry Lessig, made this famous presentation describing the impact of ever-stricter enforcement of copyright laws.

What does this mean? That as some copyright owners are more and more prompt to sue them, users are not going to use content if it is not explicitly said that they can. This flies in the face of efforts made by the OECD or others to offer more content for free, which is still copyrighted.

Enters Creative Commons. Creative Commons, initially an initiative by Larry Lessig, is a sensible answer to the problems raised by abuse of copyright law. It’s a flexible license that can be summarized by non-obtrusive symbols. So instead of sporting a (c), a “copyright xxxx”, or “all rights reserved.” on every web page, a content provider can use a Creative commons badge that could say, for instance, free to use and to reproduce for non-commercial use but with attribution to the author. Or, why not, “public” as in, no strings attached.

The problem is that Creative Commons were an American initiative, so the license was inscribed in the American legal context. In the early 2000s CC badges flourished on international blogs, but they were only decorative because the CC licenses had not been localized yet. As of now, Creative Commons International has adapted the project in 43 territories.The Australian Bureau of Statistics, for instance, is moving towards CC.

But that is still not enough to cover intergovernmental organizations. Some of our readers won’t be able to sue us, and we won’t be able to sue them, that kind of thing. So we did the next best thing and we adapted our terms of use.

Under the new terms of use you can do what you want with data or OECD content as long as you’re not reproducing a whole book (but a book minus 10 pages is OK) and it’s not for commercial use, in which case you still have to get explicit consent and fees may apply. But for personal use you can reproduce data and graphs from the OECD without asking.

The only question that remains is the citing of the data. I don’t cite my sources very academically on this blog but I do provide links to where I found the data, which always contain detailed copyright information. The OECD has always provided specifications about how to cite its material, which are IMO too heavy and too complicated not to deter their practical application. Yet, we are opposed to people writing, “source: OECD.” after a graph, without any other mention. Hans Rosling says we should sue those who do. Hmm…

Some people who are notorious for doing that are the respectable Economist. In their daily charts column, another inspiration for this blog, they never acknowledge their sources beyond the name of the institution. Take this chart, for instance. This is about comparing working hours, and the source given is OECD. This is another subject where experts are not too fond of bar charts, because measurement methods vary significantly from country to country and minute comparison are not too accurate. But then again, we publish annual worked hours. The people who made the chart then adapted the data to show hours worked per week, holidays excluded. Many commenters expressed doubt. But it wasn’t possible to check the calculations or to obtain any extra information, because they won’t mention anything beyond the name OECD (other providers don’t enjoy a more favorable treatment). I think it’s only fair to require, for people who cite data online, a link to where data was taken, not necessarily a Harvard-compliant citation.

So, have you had a problem with copyright? data access? what do you think of these issues?

Ageing societies

Ratio of inactive elderly to the total labour force, 2050

Ratio of inactive elderly to the total labour force, 2050 by country

This graph shows the projected ratio between “inactive elderly population” (people aged 65+ that don’t work) and the total labour force in 2050. This ratio is also called the “dependency ratio”.

In almost every OECD country, there will be less than 2 active persons per inactive elderly, except in Iceland, Sweden and Mexico, who will still have dependency ratios above 40% (today, only Italy and Greece have ratios over 40%.). On average, the ratio will be around 2 thirds, or 3 active persons per 2 inactive elderly.

In countries like Spain, Korea, Japan or Italy, the ratio will be over 90% – almost one to one.

Data supporting this graph can be found here

Nuclear energy

Distribution of countries according to the share of nuclear energy in their electricity generation

Countries are positioned in brackets by the share of nuclear energy in their total electricity generation. If a country is between the 50% and 60% lines, this means its share of nuclear energy is between 50 and 60%.

This graph shows how OECD countries differ in their usage of nuclear electricity. Data can be found here.

13 countries out of 30 don’t use it at all (the left-most column at 0%) and 2 others rely on it for less than 5% of their electricity. Another 6 use it for less than 30% of their electricity needs. Only 3 generate more than 50% of their electricity through nuclear power: Belgium (54.4%), Slovak Republic (57.6%) and France (78.1%).

The shape of this distribution is likely to change significantly in the next 10 years. Generally, the interest in nuclear energy, a zero-emission source of energy, is growing. However, Germany will phase out civilian nuclear power by 2020. If John McCain is elected, he intends to build 30 new nuclear plants in the short-term in the United States, followed by another 70 others. Barack Obama hasn’t made such a commitment, although he doesn’t intend to “eliminate nuclear power from the table“.

Outside of the OECD countries, nuclear capacity is growing rapidly in China, India and Russia.

For more information, check out the Nuclear Energy Agency web site and publications, notably Nuclear Energy Data 2008.

Seth Godin on graphs in presentations

A month ago, respected marketer Seth Godin opened a can of worms when he recommended the use of pie charts over bar charts in powerpoint presentations.  Pie charts, he argues, are more obvious and to the point, even though they carry less data.

The reaction of the data visualization community was immediate and harsh. Many graph experts do not use pie charts ever. In Show me the numbers, Stephen Few writes: “I don’t use pie charts, and I strongly recommend you abandon them as well.”. This sentiment is widely spread, because pie charts, which require readers to compare angles, are more difficult to decipher than, say, bar charts.

This is an example adapted from Naomi B. Robbin's Creating More Effective Graphs. Can you tell which wedge is biggest?

My feeling is that pie charts are actually quite good to show 1 data point, that is to show the proportion of one item to a whole. However I wouldn’t use them for more than 1 data points, let alone for 10 or more. And the worst thing you can do with two busy pie charts is putting them side by side and hope that people will able to see changes.

That being said the reactions to Seth’s post were very strong.

Jorge Camoes wrote: No bar charts – a caricature. Jon Peltier: “Pie charts are also abused and overused, and if not forbidden, should be placed on probation.”. Junk Charts: “The advice of No Bar Charts is misguided.. Zach from Juice Analytics: “Pie charts are the most frequently mis-used charts in my experience.” Andreas from More information per pixel wrote that “[...] you would rule out Seth’s pie chart, and use the bar chart in the appropriated business context.”. And Stephen Few himself wrote a post called “Godin’s Silly Rules for Great Graphs”.

All above commenters provided constructive criticism and most often, better versions of the examples that Seth had put up.

However, I sympathise with Seth’s position, because he’s a great speaker and because I feel the world of data visualization and that of presentation, while both belonging to the same greater family of visual thinking, evolve in completely parallel dimensions. Data visualization experts edict laws that are supposed to have an universal reach, but which don’t quite work in some specific contexts. Presentations gurus, apparently, do the same.

But sometimes they coincide. A friend of Seth’s, Garr Reynolds, published this year a fantastic book, Presentation Zen. In it, among very insightful presentation advice, I had the surprise to see a chart from the OECD Factbook 2007 redone!

Garr Reynold's version of the obesity chart.

To be honest, we at the OECD never published the “before” version, partly because we know our name is not OCED. The excel version can be found here. Yet, the new version struck me as an eye-opener. I had overseen the design of most of the original FB charts, and I thought they were clear and legible enough, with the 30 or so countries present on each graph ranked by value. But clearly, not as clear as Reynold’s ! the message is obvious, dramatic and direct.

On that chart, there is absolutely no element that doesn’t support the message, that doesn’t guide the audience to agree with the speaker. In my opinion, this is the role of charts in presentations: show relevant data that support an argument, not show more data or better data or glitzier data.

This before/after slide has been an inspiration for this blog, where I try to provide simpler graphs than those usually found in our publications. That’s why I bring that whole story.

While I cannot support the argument that pie charts do the work better than bar charts even in the presentation context, I agree with Seth that many presenters feel that using bar charts which are often the textbook-correct form, shouldn’t excuse graph authors from other design flows, the most common of which being to try to plot too many series on one single space.

At the end of the day, Seth commented back on Stephen’s blog and both came to an understanding. Seth admitted that if all presenters could do bar charts like Stephen, the world would be a much better place.

Municipal waste

Municipal waste, circa 2005
kg per capita

Municipal waste is waste that is collected by municipalities, by contrast with industrial, construction, hazardous or nuclear waste. It includes waste directly produced in the daily lives of the population (household waste), but also waste from office buildings or small businesses.

This graph shows, for the biggest OECD countries, the amount of waste produced per capita, also called waste generation intensity. Out of 30 OECD countries, there are only 4 that produce more than 700 kg/capita/year of municipal waste. Most are in the 400-600 kg bracket. Poland features the lowest value of the OECD, at 250 kg/capita/year.

India and China, also pictured, have much lower generation intensities than even Poland. In absolute values, the total municipal waste of China (156 million tonnes) and India (108 million tonnes) combined are comparable to that of the United States (223 million tonnes). Collectively, the OECD generates approximately 650 million tonnes of municipal waste.

Please note that these data are difficult to compare due to differences in definition from country to country.

For more information please check the original data set or the OECD Environmental Indicators page.

Evolution of life expectancy in OECD countries

In a previous post we already took a look to life expectancy using Trendalyzer.

Here is a more conventional representation:

made with processing, find the data here

What the graph shows is the following.

In 1960, the difference between the country with the longest life expectancy (then Norway) and the country with the shortest one (Turkey) was over 25 years. Now the difference between the values of Turkey and Japan is only 10 years.

On average, in OECD countries, life expectancy has increased by 10 years over the last 40 years, and the trend is continuing.

For more information on life expectancy check out Health at a Glance 2007, and Health Data 2008.

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.