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.