A swiss railway clock in D3.js

Screen Shot 2015-06-05 at 5.26.54 PM


The other day I saw this cool JavaScript+CSS clock and I immediately thought that I wanted to create an analog clock in D3.js. First of all as an exercise, but also with the aim —perhaps— of smuggling it in to a future dashboard 😉

It seemed straightforward: just paint the clock and re-paint it each second. Right? Well, yes if you’re lazy. The better way is to paint the clock and periodically rotate the hands.

As with most things on the internet, turns out I was late to the party. Some much more clever people have built D3 clocks and even a multi-clock D3 visualization for displaying multiple time zones.

Good. I had some ideas and a starting point.

I’m in love with the Swiss Federal Railways (SBB) clock, designed by Hans Hilfiker. It’s an emblem of the most effective train system in the world, and a testimony of exquisite swiss modernism. I wanted to make that.

There’s already an SVG visualization of the SBB clock (here’s the code). As I was checking it out, it made me realize for the first time that the axis of rotation is not at the end of the hands, but like at 10% of its length. And that extra length is different for the seconds hand. Also, that ball at the end of the seconds hand was going to be tricky.

As with all great designs of that era, everything is proportional in that clock. I noticed that I would be able to derive all the measurements from the width of the minute ticks. So I defined a starting measurement unit and multiplied away!

The key for doing the hands rotation in D3 is to enclose each hand in its own g element and rotate those g elements using setInterval. The rotation of the hands in the SBB clock is smooth, and thankfully D3 offers transitions for seamless interpolations.

The seconds and minutes hands have to rotate 6˚ each time (360˚÷60) and the hours hand has to rotate 30˚. Since the clock shows only 12 hours, you have to multiply 30˚ by the modulo 12 of the hours.

clockHand.transition().duration(1000).ease('linear').attr('transform', function(d,i) {
	if (d.unit==='hours'){
		return 'rotate('+d.numeric%12 * 30+')';
	} else {
		return 'rotate('+d.numeric * 6+')';

I was able to quickly put together a very rudimentary version and tweak the design little by little. Then I decided not to waste my first tests, got a little bit carried away and externalized all the functions that defined the characteristics of the clock. I ended up with a module that enables you to create multiple instances of the clock, each with its own configuration, defined in the ‘face’ variable of the configuration object.

	//date:'Mon May 25 2015 10:09:37',

You can get the code for the library here.

Mind you, this implementation has its differences with the SBB clock (perhaps that will spare me from a takedown notice?):

  • The SBB clock makes a 2 second pause at the end of each rotation. Yes, crazy, look.
  • The hands in the original clock are not rectangles, but very tall truncated triangles.

The stories behind Halt And Catch Fire


Like every other geek, I’m watching AMC’s Halt And Catch Fire and profiting of all the buzz surrounding it.

Over at The Internet History Podcast there was a really cool interview with Rod Canion, one of the co-founders of Compaq, one of the guys who did in real life what the actors in Halt And Catch Fire pretend to do every Sunday. Like jumping through the legal hoops:

What our lawyers told us was that, not only can you not use it [the copyrighted code] anybody that’s even looked at it–glanced at it–could taint the whole project. (…) We had two software people. One guy read the code and generated the functional specifications. So, it was like, reading hieroglyphics. Figuring out what it does, then writing the specification for what it does. Then, once he’s got that specification completed, he sort of hands it through a doorway or a window to another person who’s never seen IBM’s code, and he takes that spec and starts from scratch and writes our own code to be able to do the exact same function.

Canion is also the author of Open: How Compaq Ended IBM’s PC Domination and Helped Invent Modern Computing, one of the many books about the cloning of the IBM PC.

One of the themes of Halt And Catch Fire is the rush to be the first to disrupt a market. I thought the series would make me remember the Macintosh stories of folklore.org, but the book that I’ve thought about the most while watching the series is The Soul of a New Machine, by Tracy Kidder.


It’s about a team of engineers in a race to build a new type of minicomputer in the 70s. It reads like a novel:

Computer engineers, like poets, usually blossom early, and Ed Rasala was at thirty-five an old and experienced tradesman. He was the captain of “the Hardy Boys,” a dozen or so engineers who worked on Eagle’s hardware. When the debugging began, Rasala’s Hardy Boys virtually went to live with the prototype Eagles, in a small and windowless laboratory, behind locked doors, at Data General’s headquarters in Westborough, Massachusetts. Soon most of the crew were spending the majority of their waking hours in the lab, for six days of every week, and even when they went elsewhere, in their minds they continued to grope around inside the new, still defective machine. For the people who were building it, the incipient computer defined a small world. Rasala was the leader of the debugging; it was, in effect; his job to see that this little world was rid of uncertainty.

Innovation is a tricky game and most of the people set out to do something different fail along the way. Even those who work for big, well-funded companies. Like the guys in Fumbling the Future, the story on how Xerox invented the first true user-friendly personal computer and then went to extremes in order not to profit from it.

Another good read is the History of the Amiga series over at Arstechnica. The Amiga team is where a hacker like Cameron in the series would prefer to work, they were trailblazers… underfunded and understaffed trailblazers. The story of how they clawed to create the awesomest machine of the 80s is fascinating.

Amiga, Inc. didn’t have a lot of money left over for shipping its prototype to the show, and the engineers were understandably nervous about putting such a delicate device through the rigors of commercial package transport. Instead, RJ Mical and Dale Luck purchased an extra airline seat between the two of them and wrapped the fledgling Amiga in pillows for extra security. According to airline regulations, the extra “passenger” required a name on the ticket, so the Lorraine became “Joe Pillow,” and the engineers drew a happy face on the front pillowcase and added a tie! They even tried to get an extra meal for Joe, but the flight attendants refused to feed the already-stuffed passenger.

In any case, the first few episodes of Halt and Catch Fire have been a thrill to watch. It’s well written (although sometimes unnecessarily dramatic), the period tech is accurate and almost none of the technical terms are out of place. Also, the title sequence is pure awesomeness. Here’s a feature on the making of by The Art of The Title.

Drawing the world by hand

At Lucerne’s Gletschergarten, among old maps, models and reliefs of the Swiss Alps, we’ll find an expo from Ueli Läuppi, a local cartographer that makes hand drawings and colorings of maps using a particular projection that highlights a thorough representation of the mountains.

Moreover, Läuppi has moved his studio to the museum and on certain days you can actually see him completing a precipitation map from an Asian region using a rapidograph and a box with carefully labeled Caran d’Ache color pencils to differentiate rainfall ranges.

Läuppi’s work is at he crossroads between science and art. His extensive research (documented on video) evidences his background as an engineer, and his will power to temporarily move his studio to the museum borders on performance art.  It’s also evident that Läuppi knows a thing or two about visualization. His maps are very eloquent when it comes to representing data and explaining their meaning.

Personally, I consider that the staging of this desk in the middle of the exhibition with the rest of the unfinished pieces sends a message: maps are made by people and it’s hard to draw maps.

All of this reminded me of a post about the wireframes and skeletons for web apps and pages and the opinions of some experts who believe presenting sketches instead of perfect lines gives your output a “work in progress” feeling, opening the doors for engagement and getting better and more timely feedback from your clients.


In Sketchy Rendering for Information Visualization, Jo Wood, Petra Isenber, Tobias Isenberg, Jason Dykes, Nadia Boukhelifa and Aidan Slingsby, propose drawing visualizations as if they were made with a marker on a board, in order to communicate that the design is not complete, that is open to criticism and changes, and that visualizations and dashboards represent a narrative in progress. Also, unlike architectural drawings or industrial designs, graphics don’t represent tangible objects, so they don’t need to be accurate. Their goal is to help tell a story. Just as the proverbial business plan written in a napkin, graphics with sketches aim to illustrate a point and it’s ok to sacrifice some accuracy.

The imprecision suggested by sketchy features may reinforce perceptions of simplicity and thus reduce the expectation of cognitive effort required to interpret the visual scene

As part of the method illustrated on paper, authors have created a free library to be used with Processing that provides astonishing results:

They seem hand-drawn, right?

And maybe there’s another key: just as with Läuppi’s maps, these graphics convey the idea that visualization was thought out and made by a human and that there’s meticulous work behind them.

A Handsome Atlas gathers visualizations completed at the end of the XIX century for the US census. These are graphics of great beauty, charts that tell a story and that are truly different from the automatic output done on excel.

We forget that graphics need to be well-thought; that they should communicate something, be memorable and situate themselves between art and science.  And although a computer does the rendering job on the screen, when visualizing data we’re also drawing the world by hand.

Läuppi’s expo will be displayed at the Glacier Garden until September 15th of 2013.


Sparklines and datawords


We have seen a lot of sparklines over the last few years. They’re one of the most used high-density charts out there and, if applied properly, they can be a killer feature of any dashboard or report.

The sheer amount of information that can be condensed into sparklines makes them a viable resource to provide a quick at-a-glance story of the evolution of a measurement.The best are the ones which provide additional context, like the normal range, filled with gray in the following charts:


But it wasn’t until I read Beautiful Evidence by sparklines inventor Edward Tufte, that I discovered that these charts were originally designed to be inserted within a text. Becoming datawords, a beautiful term:


If they’re not abused, datawords can be extremely helpful to illustrate points made in the text.

This reminded me of the explorable explanations and reactive documents by Bret Victor. A very clever way of inserting what-if explorations within a text. Test it below by clicking and dragging over the number of cookies:


When you eat cookies, you consume calories. That's % of your recommended daily calories.


I think datawords and explorable explanations (explorable datawords?) go together quite nicely. Don’t you?



Beautiful Evidence also provides some tips on the correct usage of sparklines. Some of those examples can be found in this page.

Some tips samples on how to create and use sparklines in Excel. More samples here.

Tangle, a javascript framework for creating reactive documents.

jQuery plugin to create sparklines


How to create a dashboard

Consider the dashboard of a car: in it, the driver can see the most important data: speed, RPM, mileage, etc. The dashboard displays decision-making information, in a graphical manner, in a single place.

The information dashboards should comply with the same requirements:

Although not necessarily copying the model of a car! This is a mistake. There are better ways to graphically display information.

CIO Dashboard, a Stephen Few classic

So, we take a few charts, some tables and we throw them all together in one screen, right?

Uh… nope.


What makes a good dashboard?

  • It contains the requested information (obvious? Not always!)
  • It has readable text with high contrast (black over white, or some other light shading).
  • It highlights the key information.
    • Charts are easy to find.
    • The problems are marked with icons or in bold letters.
    • The important information is generally at the upper left or lower right side.
  • It has no more than 5 or 6 data containers.
  • It displays useful data to make decisions.
    • Comparisons against goals, previously set standards or historical data.
  • It doesn’t require vertical or horizontal scrolling. All the information is shown in the same screen.
    • If you have a lot of information, you can use tabs.
    • If you must, use multiple screens. But remember: the key is to keep all the data related to each other in the same screen.
  • Its graphics have a high data/ink ratio without chartjunk.
  • It displays the right charts according to the type of data.
  • What seems interactive, is interactive. The charts offer details and drill-down when you click on them.

But I think the most important thing is that the dashboard tells a story, or helps you tell a story and, above all else, is esthetically simple. No color degradations or images with shading or use of 3D. Imagine for a second that your car displayed your speed with a 3D chart, would you be able to read it so easily? Would you be able to make right decisions? I don’t think so. Have that in mind when designing a dashboard.


At Excelcharts you can get various dashboard examples made in excel. If you need a little more spiritual aid, I recommend Information Dashboard Design, de Stephen Few.  A short and easy to read book; ruthless when it comes to tearing down old notions and clear when teaching the principles of good design for dashboards and reports in general.

Although it has some things specific to their product, the Tableau Visual Guidebook is an excellent guide on the basics of producing a good data visualization. The last pages contain a great checklist that you should complete before deploying your visualization.