So tired, but had such a great time working with classmates and Syria activist and policy folks at the data-vis hackathon this weekend. I guess I’m really starting to get comfortable with D3 now. Built out a data visualization and analysis UI for data from folks the Syria Crisis Monitor this weekend during a hackathon at SVA. Learned a ton about the conflict and ethics of sense-making. Simply great practise for data-vis skills too. A shame I can’t show any visuals or code, but I should write some thoughts down about data-vis code organization.
(If you’re not interested in code, you can basically stop reading. Have a good day!)
Data, Geometries and Visuals
I have no idea whether this is best practise or not, but I am finding this separation of data, geometries and visuals really productive. The basic idea is to write algorithms that looks at the data, and reduces aspects of it into sets of geometric properties (i.e. coordinates, angles, width, heights, radius, etc.) A lot of that work is done with underscore.js, where I am doing map-reduce-esque work.
D3 then does a great job of straightforwardly drawing SVG shapes based on those geometries. I suspect my code is not the most efficient, but it is very modular and easy to modify, which is great for prototyping UI and experiences.
One Drawing Call
Due to the event driven nature of UI programming, I’ve found that having a single cleanup and animation procedure very useful. Often in UI events, what happens is different events trigger different set of data-to-geometry calculations, but they all act on the same set of visual elements. By having a unified cleanup and animation procedure allows me to do all sorts of calculations and focus on just getting the geometries, knowing that as long as the geometries are correct, drawing will take care of itself.