What am I looking at exactly?

Each of the concentric rings are essentially pie charts showing the percentage of visitors using each browser for a particular time slice, starting with January 2002 in the center and working out to August 2009.  The numbers on W3schools.com don’t quite add up to 100% because they don’t report on browsers that make up less than 0.5% of their visitors.  This results in a gap at the end of each ring.

How’s it done?

This only took a few hours to construct, and the most time consuming part was parsing the data.  The HTML from W3schools wasn’t valid XHTML, so I couldn’t tear through it using AS3′s E4X parsing without doing some manual manipulation beforehand.  When all was said and done, I ended up formatting the data as XML with a series of “month” elements with “browser” children that detailed the share of each browser for the corresponding time period.  None of the parsing involved any of the Axiis framework — just a few loops and conditionals.

<data>
  <month value="August 2009">
    <browser name="IE7" share="0.151" month="August 2009"/>
    <browser name="IE6" share="0.136" month="August 2009"/>
    <browser name="IE8" share="0.106" month="August 2009"/>
    <browser name="Firefox" share="0.474" month="August 2009"/>
    <browser name="Chrome" share="0.07" month="August 2009"/>
    <browser name="Safari" share="0.033" month="August 2009"/>
    <browser name="Opera" share="0.021" month="August 2009"/>
  </month>
...

Conceptually, there are two parts to the browser visualization: the concentric time slice rings and the wedges that divide the time slices down by browser.  To create this effect, I used Axiis’s embedded layouts.  Layouts loop over a given data provider, manipulate Degrafa geometry based on that data, and draw to the screen.  Layouts can be nested inside on another and behave analogously to nested loops in the programming world; for each iteration of an outer layout, the inner one will loop over all of its data, performing its expected tasks.

The outer layout

<axiis:DataCanvas id="dc"
	width="100%"
	bottom="20"
	top="120">
	<axiis:layouts>
		<axiis:ConcentricWedgeLayout id="radialLayout"
			width="{dc.width}"
			height="{dc.height - 10}"
			innerRadius="52">
...

When the application is done going through its creation process, an event handler is called which parses the XML and passes the resulting ArrayCollection of month Objects to the outer layout, which is an instance of ConcentricWedgeLayout. This type of layout manipulates the inner and outer radii of a Degrafa Wedge such that the during the course of the loop the Wedge will have taken on all the values necessary to fill the space available.  After each iteration, the Wedge and the browser Objects that belong to the current month are passed to the inner layout.

The inner layout

The inner layout was custom-built for this visualization.  It leverages some of the events fired during the layout’s render cycle to adjust the angle of the wedge. The preRender event is fired at the very beginning of the layout’s render cycle, before a single iteration has happened.  During preRender, the currentArc property is set to 0.  This makes sure we’re always starting from the 12:00 position on the visualization.  Since this layout has drawingGeometries defined, the layout dispatches the itemPreDraw event right before drawing them to the screen.  In this example, the itemPreDraw handler updates currentArc to the appropriate value to show the percentage for the browser the layout is currently holding.

<axiis:LinearScale id="arcScale"
	minValue="0"
	maxValue="1"
	minLayout="0"
	maxLayout="359.99"/>
...
<axiis:BaseLayout id="arcLayout"
	dataProvider="{radialLayout.currentDatum.browser}"
	preRender="{currentArc = 0}"
	itemPreDraw="{currentArc += arcScale.valueToLayout(arcLayout.currentDatum.share);}"
...>

Note the use of the LinearScale here.  The Axiis scale classes create a mapping between two data spaces that we call “value” and “layout”.  In this example a linear mapping is created between the range of possible percentages (0 – 1) and the range of possible angles (0 – 359.99). The valueToLayout method does exactly what you’d expect it to.  Given a number from the value space, it will return a corresponding number in the layout space.  This is used to advance the reference Wedge’s angle by the appropriate amount.

Drawing to the screen

Aside from manipulating the angle of the reference Wedge, the inner layout is also responsible for rendering a Wedge to the screen.  The reference Wedge and the drawing Wedge are two separate instances, but the latter derives its properties from the former.

<geometry:Wedge id="wedge"
	centerX="{radialLayout.width/2}"
	centerY="{radialLayout.height/2}"
	innerRadius="{radialLayout.currentReference['innerRadius']}"
	outerRadius="{radialLayout.currentReference['outerRadius']}"
	startAngle="{270 + currentArc - arcScale.valueToLayout(arcLayout.currentDatum.share)}"
	arc="{arcScale.valueToLayout(arcLayout.currentDatum.share)}">
...
</geometry:Wedge>

A mapping of browser names to colors defined at the top of the application is used to determine the fill and stroke applied to the Wedge.

<geometry:fill>
	<degrafa:SolidFill id="wedgeFill"
		color="{browserColors[arcLayout.currentDatum.name]}"/>
</geometry:fill>
<geometry:stroke>
	<degrafa:SolidStroke id="wedgeStroke"
		color="{ColorUtil.adjustBrightness(browserColors[arcLayout.currentDatum.name],-60)}"
		pixelHinting="true"
		alpha=".7"
		weight=".5"/>
</geometry:stroke>

Making  it interactive – States

Axiis states are conceptually similar to Flex’s states; they define alternative properties for the rendered geometries based on certain conditions. When the user interacts with a rendered geometry, some familiar events are dispatched (mouseOver, mouseOut, etc.).  The layouts capture each of these events and if there are any states registered with the event type in question, the state is applied.  This declaration says that when the mouse is over a wedge the wedgeFill should have its color property dimmed and this action should be undone when the mouse is moved off.

<axiis:State enterStateEvent="mouseOver"
	exitStateEvent="mouseOut"
	targets="{[wedgeFill]}"
	properties="{['color']}"
	values="{[ColorUtil.adjustBrightness(int(wedgeStroke.color),-60)]}"/>

The filtering legend

If you followed how the layout routine works in the main visualization, the construction of the legend is a no-brainer.  It’s a VBoxLayout — a layout which spaces out RegularRectangles across its available height — and it draws a colored square and some text to the screen for each browser name.

<axiis:DataCanvas id="legendDC"
	width="200"
	height="{legendLayout.itemCount * 18}"
	bottom="5"
	left="5">
	<axiis:layouts>
		<axiis:VBoxLayout id="legendLayout"
			width="{legendDC.width}"
			height="{legendDC.height}"
			showDataTips="false"
			itemClick="legendLayout_itemClickHandler(event)">
			<axiis:drawingGeometries>
				...
			</axiis:drawingGeometries>
			<axiis:states>
				<axiis:State enterStateEvent="selected"
					exitStateEvent="unselected"
					targets="{[legendMarkerFill,legendLabel]}"
					properties="{['alpha','italic']}"
					values="{[.1,true]}"/>
			</axiis:states>
		</axiis:VBoxLayout>
	</axiis:layouts>
</axiis:DataCanvas>

The visualization allows the user to click on items in the legend to filter out the corresponding browsers.  To do this, there is an handler set up on itemClick event on the legend layout.  itemClick is dispatched when a rendered geometry belonging to the layout is clicked.  The event handler updates the list of browsers to include.  In the declaration for the inner layout on the main visualization, a dataFilterFunction is defined which checks the current browser’s name against the list of included browsers.  Any browsers that fail this test (i.e. the filter function return false) are skipped by the layout.

The state defined on the legend uses two custom event types, “selected” and “unselected”.  The “selected” event is dispatched when a rendered geometry is clicked and the “unselected” event is dispatched when that same geometry is clicked again.  In the selected state the text becomes italicized and the fill for the legend marker becomes more transparent, indicating that the browser has been filtered out.

The filtering feature take advantage of a bug fix that was made after the release of the beta that caused problems when all of the data items were filtered from a layout.  The swc included in the view-source download is compiled from Axiis’s development branch.  We use our repository in a slightly non-traditional manner.  The trunk contains our latest release and our “development” branch contain the latest check-in.  Although the development branch is more or less stable keep in mind that it is where we work out new features, so it may not be completely polished and bug-free.  If you run into any bugs or need help with something, give us a holler on our google group.  Enjoy!

We’ve gotten some feedback from a few people already, and some users have already told us about the awesome stuff they’re making.  Remember during Tom’s presentation when he showed the Smith Chart, the insanely complex ring of circles that motivated some of our work?  Yeah, we never attempted to implement that.  It was just meant to get people thinking about some of the things that can’t easily be done with other frameworks.  Well, Andrew Westberg took that slide as a challenge and has already implemented it!  Seeing what everyone is building makes this all worthwhile!

So as you develop, keep in mind that this is alpha software.  If you’re running into problems with something, please let us know so we can set you on the right path and improve things for the next release.  If you’ve got the Axiis swc sitting on your machine, build something cool, tell us about it, and let us know what went right/wrong.  If you haven’t downloaded the swc, you can get it here.

You can get in contact with us by emailing tom or michael [at] axiis.org or direct a tweet towards @Axiis_DataViz.

Axiis is not a reimagining of the Flex charting framework or any other comparable library.  Axiis can be more accurately described as a data-driven layout engine for Degrafa geometry.  We see the primary use of this engine being data viz, so we’re billing it as a data visualization framework.

So what do I mean when I say “data-driven layout engine?”  When using Axiis, you describe the geometry necessary to render a single element in your data set.  The engine then iterates over the entire data set, creating and laying out all necessary instances of that geometry.  This process allows you to create seeming complex visualizations in a relatively short amount of markup.

Take a column chart as an example.  (Though not all that complex, it still takes a fair bit of code to write a column chart from scratch.)  A column chart is simply a series of rectangles laid out horizontally where each rectangle’s height represents the value it is rendering.  So to create that in Axiis, you declare a horizontal layout with a rectangle geometry.  You then set up a binding expression to compute the height for each rectangle.  As the engine runs the binding expression executes, and the geometries are rendered side by side and with correct heights.  Huzzah!

The column chart is just a basic example.  Axiis is capable of much more than simple Cartesian charts.  Layouts can have child layouts as well.  This allows you to iterate over the top level of your data set in a parent layout and then iterate over another property in the child.  Tack on Degrafa’s ability to compose geometries, and you’ve got the tools to create very expressive visualizations.  Tom has put together an example he calls the Stacked Wedge that demonstrates nested layouts and geometry composition.  It represents data in a way that would be difficult to achieve with other frameworks, it looks beautiful, and the core of it is only 100 lines of markup!

Axiis is under heavy development, and it is rapidly approaching an alpha release.  Keep your eyes here and on Tom’s blog over the next few weeks for news and examples of the full scale of Axiis’ capabilities.

1. I wanted to take advantage of invalidation.
   
   In most cases Parallel Coordinates Plots contain hundreds, if not thousands, of lines. The overhead involved in instantiating and validating thousands of UIComponents outweighs the programming convenience provided by invalidation, especially when all you really want to do is draw a line.
   
   
2. I wanted the lines to have tool tips.
   
   It’s great that UIComponents have tool tip functionality built right in, but again, it’s foolish to take advantage of the niceties of UIComponent at the cost of performance.  The ToolTipManager exists for a reason.
   
   
3. I wanted to allow the user to draw anything they wanted between the axes.
   
   Honestly, Parallel Coordinates Plots are crowded enough by default. I can’t think of a single thing a user would want to do aside from changing the color and thickness of the lines.

So for the most part I made the decision out of laziness.  When I started cleaning up the code to migrate it into BirdEye, I realized that I would have to rewrite the Parallel Coordinates Plot altogether if it was going to be useful to anyone.

Cutting out the bloat

With the overhead of UIComponent mind, it might seem reasonable to just make each line a Sprite and manage rendering manually.  Unfortunately, that probably wouldn’t scale nicely either.  Sprites are lighter than UIComponents, but adding thousands of Sprites to the display list and running graphics operations on them is still a tall order.

Drawing all of the lines to a single Sprite’s graphics property is straightforward enough, but all those graphics operations wear noticeably on performance.  This is the option I ultimately went with, so to get around the performance problem I store the results of the graphics operations to a BitmapData using the BitmapData.draw method and then render the BitmapData to the screen using Graphics.beginBitmapFill.

Unfortunately, this leaves the lines completely non-interactive.  They’re not DisplayObjects anymore, so they can’t dispatch the mouse events needed to support roll over and selection.  But wait…

Supporting bitmap interactivity using picking techniques

3D engines have to deal with this problem all the time.  When you click on the screen in an OpenGL application, the app knows the coordinates of the cursor, but the developer still has to do some leg work to figure out which 3D object those coordinates refer to.  There are a number of techniques used to solve this “picking” problem.  One technique is to render the 3D scene twice: once normally and once with each 3D object colored with a unique color.  The first rendering is presented to the user, while the second is kept invisible.  When the user clicks on a pixel in the first rendering, the program looks up the color at the cooresponding coordinates in the second rendering.  Since the colors are uniquely mapped to the 3D objects, this program can determine which object was clicked based on that color.

This is the same technique that the new Parallel Coordinates Plot uses to determine what the user is interacting with. Each line segment is uniquely identified by two fields and the values in those fields; the fields determine the x coordinates of the line segment’s endpoints and the values determine the y coordinates.

The Parallel Coordinates Plot maintains a hash mapping those four properties to unique colors. When the user clicks on the component, the color under the pointer is extracted, the hash is queried, and the items that match the field-value pairs are returned. In the full implementation there are four bitmaps used in all:

1. The first bitmap contains a line for every item, regardless of selected or rolled over status.
2. The second bitmap only shows lines for rolled over items.  This bitmap is rendered on top of the first bitmap, masking the fact that every item is actually rendered in the first one.
3. The third bitmap shows only the selected items.  Similarly, this is rendered on top of the second bitmap to achieve the same effect.
4. The invisible fourth bitmap used for picking.

It may seem redundant to render lines more times than absolutely necessary, but the extra steps let the Parallel Coordinates Plot save in the long run.  It only needs to redraw the lines that have changed from one moment to the next.  If the contents of the data provider and the width and height remain constant, the first bitmap only needs to be drawn once.

When it all comes together, the Parallel Coordinates Plot looks like this under the hood:

Be sure to check out the QaVis and the GeoVis Explorers.

You can view the interactive version of the matrix here.  View source is enabled.

I’m not much of a football pundit, so I’m not going to try to make too many insights into the data.  It did strike me as interesting that there is a weak or negative correlation between rushing and passing statistics.  It seems that teams with better throwing games tend to prefer to throw the ball over running it.  (Yeah, that was about as insightful as “The team that scores the most points usually ends up winning…”)

In this version of the comparison matrix, I introduced an item renderer which shows a snapshot of each of the plots.  The updated code can be checked out from my repository.

How about an example?

In 2004 Terry F. Pettijohn and Brian J. Jungeberg looked at the relationships between the physical features of Playboy’s playmates of the year and the economy.  I grabbed the csv for the playmate data off of Flowing Data, added a few fields to it, and dropped it into a ComparisonMatrix (view source enabled).  Pink represents a positive correlation while yellow represents negative.  The deeper the color, the stronger the relationship.  You can click on a cell in the matrix to bring up a scatterplot of the data set based on the two selected attributes.

The strongest relationship in the playmate data set is actually between GDP and year, so that makes it somewhat difficult to make any assertions about trends in the playmates’ physical features and the economy while not making the same assertion about those physical features and time.  (The authors of the paper actually used something called the “General Hard Times Measure” to evaluate the economy, and it looks like GDP isn’t really equivalent).  Despite this problem, the ComparisonMatrix still provides some interesting information about the playmates.

• The playmate’s heights, weights, and waists are all correlated.  These women have roughly the same figures, just scaled up and out differently.
• The playmates’ bust to waist ratios have decreased with time while their waist to hip ratios have increased.
• BMI, though being a function of height and weight, is more strongly correlated with hip size than height.
• There is no relationship between the age at which these women claimed their titles and their hip sizes.  That’s right, if you have nice hips, it might not be too late too be a playmate.

Using the ComparisonMatrix

Like all my stuff, the ComparisonMatrix is under the MIT license, so you can use and adapt it in whatever way you like.  The code is documented pretty thoroughly, and the source of the playmate example is pretty useful for getting started.

In terms of usage, all you need to do is supply the ComparisonMatrix with the data set you want to analyze (the dataProvider property) and the array of attributes it should consider (the fields property).  Given those two properties, the ComparisonMatrix will be able to render your data, though there are a bunch of other options available.  Take a look at the documentation in the code for details.

The default comparison function is the correlation coefficent.  As a result, the default behavior is to expect comparison values from -1 to 1.  Since the ComparisonMatrix allows you to plug in your own comparison function, you’ll have to provide your own color and alpha functions if you want to use a different scale.

I made an effort to make the renderers (the actual cells in the grid) as flexible as possible so you can write your own without rewriting the ComparisonMatrix itself.  To do this, write a class that implements the IComparisonRenderer interface and set the comparisonRenderer property to be a factory for that class.

The next step

Statisticians and information visualization researchers have developed a slew of measures for determining interesting relationships between attributes in a data set.  Even though the ComparisonMatrix allows you to plug in whatever comparison function you want, I’ll probably build these in at some point for easy access.  As I make updates to this component, I’ll be committing them to my repository.  As a result, the example here will not always be the most up to date.  For the most up to date code, check here.

I have lofty dreams for this thing.  More later.

UPDATE (January 21, 2009)

I wasn’t kidding.  The ComparisonMatrix has changed a bit.  If you want the best matrix you can get, grab it from the repo, not the source of the swf.

Here’s a little example application using the period table of elements as a data source.  If you’re interested in the details of the implementation you can check out the source.

When I started the project I was concerned that using the charting classes as a base would bulk up the code and ultimately hinder performance, so while the MXML that defines the plot is reminiscent of the charting components, the base is actually UIComponent.  I’ve left plenty of room for extension in the classes that make up the plot.  It’s licensed under MIT, so if you want a different renderer for each axis, you got it.  If you want to draw loops instead of straight lines between the axes, go for it.  I’m going to add the project to my repository, so if you’re interested in any updates that I make to the code, you can check there.

If you need variety, two of the other members of the Fervor team have started open source projects for their own flavors of PCP.  (Swapping the acronym “PCP” in for “parallel coordinates plot” makes sentences more interesting, don’t you think?)  PCPlot belongs to Dasha and contains the code more or less as it appeared in Fervor.  FlexPC is a project Krist started with a couple of developers he met through a flexcoders post about PCP, but that project is still in the planning stage.

I’ve put together my own animation of the WalMart dataset using ModestMaps and the HeatMap component.  The visualization is most impressive when you’ve zoomed in far enough to see all of the major roadways converging on the large cities.  From there you can watch as WalMart takes over the urban areas, turning them red hot while leaving the less populated areas (relatively) cold and blue.

Unfortunately my dataset is somewhat incomplete.  The version I grabbed from Thomas Holmes has addresses for each store, but the geocoding service I used failed to convert about 100 of those addresses to latitude and longitude values.  If anyone can point me towards the complete dataset, I would love to add those missing stores to the visualization.

Before I close I want to give a nod to Universal Mind.  Last week they released SpatialKey, a heavy-duty temporal-spatial visualization tool that really shows off the strengths of heat mapping.  They’ve taken a crack at the WalMart data set as well, and it’s impressive to say the least.  Congratulations on your launch, UM.

Icons by famfamfam.com