Probably one of the most useful things about Cynthia Brewers color advice for cartography are the multihue color schemes. This post explains how you can create your own, using two new features of chroma.js: Bezier interpolation and automatic lightness correction.
Let’s face it. Relational databases, such as MySQL, SQLite and PostgreSQL, are pretty cool – but nobody actually uses them. At least not in the day-to-day work with small to medium scale datasets. But why is that? Why do we see an awful lot of data stored in static files in CSV or JSON format, even though
- they are hard to query (you need to write a custom script every time)
- they are messy, as they cannot store meta data such as data types
- it is a pain to update them incrementally, say if some record has changed
You can do this using the
colorRampPalette() function that comes with the grDevices package. Calling this function will return another function that you can call to generate the color palette.
If I was asked for the golden rule of information visualization, it would be:
“Show the most important thing first!”
Not second or third, but first! And what is the most important thing to show about the outcome of an election? Who actually won.
In political systems like Germany’s, where we have no party getting anywhere near 50% of the vote, the usual one-bar-per-party bar charts totally fail to answer this most important question.
For example, in the following chart we can see the number of seats won by different political parties – but this does not tell us who won the election.
While working on the soon-to-be-released map widget for Piwik (heck, it’s been over two years since the first sketches!) I implemented two map symbol clustering algorithms into Kartograph.js. Last year I wrote about why this is a good idea, and now I turned that advice into re-usable code.
In this post I want to share my findings after experimenting with different clustering techniques.
Icons are widely used in infographics such as maps and pictographs. So as a visualization designer, you’ll get to the point where you must choose which icons or pictograms to use. But please, choose wisely.
The reason I got to this topic is a recent post by Naomi Robbins about two opinions on the usefulness of pictographs. She reminded my of a critical article by Stephen Few, who stated that unit charts (another term for pictographs) are for kids, but not for serious information displays. My biggest complaint about his article is that he picked some of the worst imaginable examples to back up his arguments.
A few weeks ago, while I was driving several hours towards our camping vacation, I suddenly noticed this beautiful piece of data visualization right in front of me. Actually, I found it that beautiful that I had to remake it in Illustrator:
I was completely stunned by the clean and simple layout of this gauge chart. It shows everything I, as the driver, need to know such as: How fast am I driving at the moment, how far have I’ve been driving at all, when is it time to get a new car.
But then I realized that this tiny chart, despite its useful, intelligent design, violates some of the common rules of data visualization, so I thought it’s a good idea to write about it.
Lately I joined Datawrapper, an open source project that aims to provide simple, embeddable charts for journalists. Really, no fancy stuff here, we’re just talking about line charts and bar charts. Limiting ourself to those types gave us a good opportunity to think about the best of doing them. So it came that this week I was thinking a bit about the perfect line chart.
A while ago I realized that I totally stopped using social bookmarking services since I started tweeting. Whenever I find an interesting link I share it on Twitter. If I find interesting links tweeted by the people I follow I’m most likely to favorite that tweet. I guess that’s the way most people use Twitter. How often did you check someone’s public links on delicious? I rarely did.