US Trade Deficit Visualized

This data visualization design study is the first in (hopefully) a series of visualizations depicting US and Global Finance information.  My original goal was to tell a compelling story with this visualization, and stay true to many data visualization best practices.   But somewhere along the way, the artist in me became more absorbed in the aesthetics than the underlying story, and I abandoned many of the best practices I had hoped to employ.

As a result I think the data visualization still works for the main trends.  You can see annual trade surplus/deficit information for each of the top 10 countries for each (surplus/deficit.)  The countries that are in surplus (adding cash to the US Economy) are along the top, while the countries along the bottom show the corresponding trade deficits (that are taking cash out of the US Economy.)    It is pretty obvious that overall the US has far more deficit than surplus trade, and by a huge margin, and that in later years the US deficit with China is pretty large.

I did spend a fair amount of time working on a simple algorithm that represents the flow of cash as various weighted lines for each country (as shown in the top right legend.)  Visually I believe you can get a rough at-a-glance view of how much cash is flowing from each country, while still having enough fidelity at the lower volumes to discern differences between those volumes, since in essence it is a log scale in stroke weights.

I had played around with animating the flow of cash monthly so you could see it funneling from the surplus countries to deficit countries, but I started to hit too many performance issues with the animation, and I thought this version was a good stopping point.

On the technical side, this is pretty much pure Degrafa GeometryRepeaters and CubicBezier curves.   One of the most elegant things about this visualization is that the core code that maps the visual structures is less than 60 lines of Degrafa MXML.

At some point in the future (perhaps 360|Flex in Indianapolis) I will open up the source code and walk through how it is done.   Suffice to say that I am 100% convinced that using markup to create your composite visual structures and procedural code to tweak them is a much more effective and intuitive way to code than using a pure procedural/OO approach.

After spending a fair amount of time working with Processing, which is pure OO/Procedural coding, getting back to Degrafa was refreshing change.  Things like the GeometryRepeater class are extremely powerful for this type of work – especially when you bind it to dynamic data sets.   Being able to use markup to make contextual relationships in XML to your visual forms is extremely helpful for keeping all of your abstractions front and center mentally.  With complex visualizations and lots of composite pieces the human brain (especially mine) is limited as to how many abstractions it can keep in working memory at any one given time.   By being able to describe your structures declaratively in a concise amount of space, you can then manipulate specific properties of that structure while still being able to reference the whole.   This allows me to “sketch” in my major graphic forms and then later add details, animation, and styles to each piece of the form.