I attended the CultureCode Hack run by CodeWorks on the 24/25 March 2012. I will blog about my personal experience at the event in good time. Or, when I can find some time. In the meantime I will offer some notes on the project that I worked on, specifically the technical aspects of it.
The project involved taking book loan data from Newcastle Libraries, and plotting the distance those books were taken to the homes of the borrowers. The idea was to look for patterns in the data that were not obvious in any other form, to see if it could be used to help distribute the books between the libraries in a more relevant way.
I worked mainly on the front end (graphical visualisation) while Peter Bull @RoguePlanetoid worked on the back end (ASP.net data delivery).
One of the first things I needed to decide, was what visualisation library we were going to use. I had never used any before, so needed to chose the one that would offer the least resistance to learning.
The three main contenders were:
- Processing (JavaScript port being processing.js)
- Raphaël
- Paper.js
All three seem to do much the same thing. The main differentiating features we identified are:
- Processing is driven from its own language. The other two are driven from JavaScript by using and manipulating JavaScript objects directly.
- Raphaël supports older browsers than the other two. This was not particularly important to us. However, Raphaël does not support Android due to the way it relies on SVG. This was a little more important.
- Raphaël and Paper.js both support object-base interaction. By clicking on a visual object, it is easy to interact with it. This is much more difficult in Processing.
- Paper.js and Processing both use canvas, so will support IE from 9 onwards.
In the end paper.js won. Putting a quick visualisation together that worked across all the browsers we were using and did not involve learning too many new languages and language constructs, is why it stood out.
One thing all three had in common was the difficulty in finding worked examples. Nearly all example code we found were compact and certainly showed the frameworks off, but were seldom commented to explain what they did and how they worked. That was a shame, as it slowed down our learning somewhat. People were kind enough to put examples up for us to see, but five more minutes to add half a dozen lines of comments would have really added the cherry on the top.
This excellent article gives a great summary of these packages, comparing features in a very visual way, while getting right to the bottom line of why you would chose one over another:
http://coding.smashingmagazine.com/2012/02/22/web-drawing-throwdown-paper-processing-raphael/
[to be continued]
No comments yet.