My presentation from 360|Flex – Getting the most out of Axiis

On Wednesday I presented “Getting the most out of Axiis” at 360|Flex. I made some pretty significant changes to the slides between when the thumb drives were prepared and the actual presentation. The new slides are available here. During the talk I demonstrated some of the major features of Axiis through a series of code examples that built on one another. Here’s what the final product looked like:

Get Adobe Flash player

Source for all the examples

The session was recorded, so once the video is online, I’ll post it here to give some more context to the examples.

You can download the session video here. Just do a ctrl+f for my name. Looks like the screen recording didn’t go as planned, but they got the audio.

Posted in Uncategorized | Comments closed

I’m speaking at 360|Flex!

I’m pleased to announce that I will be speaking at 360|Flex next month alongside some of the best talent in the Flex community. I’ll be filling the time slot that originally belonged to Tom Gonzalez with a session titled Getting the most out of Axiis.

At the last 360 Tom gave a talk that accompanied the alpha release of Axiis, and I did some on-stage coding, demonstrating how to build a custom visualization. A few months later we gave a similar talk at CFUnited about a more polished beta release, and Tom gave a solo talk about the framework at MAX. I want this coming session to be accessible to people who didn’t attend those talks but still be interesting to our previous audience members and users. I’ll briefly cover the back-story (what Axiis is and what problems it solves) and the basics of the framework to bring everyone up to speed, but the meat of the session will be about usage tips and tricks. My hope is that regardless of experience, everyone comes out to the session with a stronger sense of what they can accomplish with Axiis and how.

Here’s the description as it appears on the schedule:

During this session we’ll dive headfirst into the Axiis data visualization framework. We’ll start with the basics — the Axiis render cycle and using the built in visualizations — and get into more advanced topics — creating custom visualizations, adding interactivity, and addressing performance bottlenecks. No prior knowledge of Axiis is required.

The session is at 4:30 on the last day of the conference. See you there!

Posted in Uncategorized | Comments closed

Axiis Tech Demo: Visualizing Historic Browser Statistics

For the beta release of Axiis I prepared a visualization showing the historical browser breakdown of visitors to  I wouldn’t consider it a useful data visualization by any stretch of the imagination (pie charts are not a great idea, and concentric pie charts… oh my!), but it does demonstrate how easy it is to get started with Axiis and build something complex in a few lines of mark-up. Since the beta release I added the ability to filter by browser type, and Tom lent his artistic eye and did a little restyling.  Although the number of Axiis tutorials out there is growing steadily, there are still very few, so I’ll dive deep and explain exactly how this visualization works.  Check it out here.

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 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.

  <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"/>

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"
		<axiis:ConcentricWedgeLayout id="radialLayout"
			height="{dc.height - 10}"

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"
<axiis:BaseLayout id="arcLayout"
	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"
	startAngle="{270 + currentArc - arcScale.valueToLayout(arcLayout.currentDatum.share)}"

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.

	<degrafa:SolidFill id="wedgeFill"
	<degrafa:SolidStroke id="wedgeStroke"

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"

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"
	height="{legendLayout.itemCount * 18}"
		<axiis:VBoxLayout id="legendLayout"
				<axiis:State enterStateEvent="selected"

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!

Posted in Axiis, Flex, Information Visualization | Comments closed

CFUnited Demo – Axiis Treemaps

Yesterday Tom Gonzalez and I gave a presentation on Axiis at CFUnited. After Tom reviewed the concepts behind the framework, I demonstrated how to build a custom visualization. The resulting application showed a squarified treemap representing the make up of Axiis, Degrafa, Flex, and the Flex Data Visualization framework. I cleaned up the code from the presentation, added some pretty fills, and committed it to the development branch of the repository. You can view the results here and the source here.

In the treemap, the area of the main rectangle represents the number of lines of code in the selected framework, and the smaller rectangles are sized proportionally based on the number of lines of code in each class. The rectangles are colored based on the percentage of methods marked private. Red rectangles represent classes that are mostly private while green rectangles show classes that are more public or protected. The more intense the color, the further the classes is from being 50% private. It’s a pretty meaningless metric, but it demonstrates what the treemap can do.

Posted in Axiis, Flex, Information Visualization | Comments closed

Axiis Video Tutorial

An experimental alpha release of Axiis has been available since 360|Flex Indy.  I put together this screencast to help people get up and running with the framework.

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] or direct a tweet towards @Axiis_DataViz.

Posted in Axiis, Flex, Information Visualization | Comments closed

Axiis – A different kind of data visualization framework

Last week Tom Gonzalez wrote a blog post announcing Axiis, the open-source data visualization framework we’ve been developing. Tom goes into a good deal of depth about how the system works, so I won’t rehash all those specifics here. I just wanted to share my take on what Axiis is meant to do at a high level.

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.

Posted in Axiis, Flex, Information Visualization | Comments closed

Hit detection on graphics primitives: Speeding up the Parallel Coordinates Plot

In my last post I mentioned that I had rewritten the Parallel Coordinates Plot to achieve a pretty drastic speed up. Before I get into the graphics hit detection trick at the heart of the performance boost, I’d like to explain the problem with the original implementation. The main thing that dragged down the first version was the fact that each line drawn on the plot was handled by a separate UIComponent.  I knew that that was bad idea going in, but I went with it anyway. My reasons for subclassing UIComponent were pretty weak…

  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:

but the user sees this:

I’ve put together an example that demonstrates the new and improved Parallel Coordinates Plot. I didn’t run any metrics to try and compare the performance with the older sample I put together, but in terms of responsiveness, the new version blows the old one out of the water.  The source for the new sample is available here. The color hashing occurs within the internal FieldValuePairColorHash class at the bottom of the ParallelCoordinatePlot class.

Posted in BirdEye, Flex, Information Visualization | Comments closed

Collaborating with BirdEye

BirdEye is a project that aims to be a comprehensive collection of visualization components, and I was recently asked to join the team.  I’ve added my components into the appropriate sub-projects; The Heat Map is in GeoVis and the Comparison Matrix and Parallel Coordinates Plot are in QaVis.  During the migration process I fixed a few bugs, and overhauled the Parallel Coordinate Plot entirely (more about that in a future post).  All future development on these components will occur within BirdEye, so that’s where you’ll want to go to get the freshest code.

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

Posted in BirdEye, Flex, Information Visualization | Comments closed

What I’m doing with my final semester

I’ll be receiving my MS degree in Computer Science at the end of this semester.  I finished my degree requirements last semester, but my timing on some of those requirements was a little funny, so I wasn’t eligible for graduation at the time.  In order to graduate this semester, the University requires that I be enrolled in at least one course, and there are no restrictions as to what that course has to be.  Back in my undergraduate days I worked with Doug Hamilton in the Astronomy Department on a solar system visualization, and to fill that one course requirement, I’m going to be bringing that project into the third dimension.

I was in registration limbo with the Astronomy Department for a few weeks, so I registered for PHYS104 How Things Work: Science Foundations as a safety course.  PHYS104 would have been *entertaining*, but suffice it to say, I’m glad to be doing something useful with my time.

I’m still working with the CATT Lab as a research assistant, but at 20 hours/week I have a lot more time on my hands than I’m used to.  I’ve been able to pick up some contracting work here and there, and I’m getting a bit more involved in some projects in the Flex community.

It’s going to be a fun couple of months.

Posted in School | Comments closed

Visualizing the 2008 NFL Season

Super Bowl XLIII is less than two weeks away, so it feels like an appropriate time to look back at the statistics that were so diligently recorded during this past football season.  I’ve put together a comparison matrix based on data from  For first time visitors, a comparison matrix processes multidimensional statistics, looking for correlations, and lays out the results in a color-coded grid.  In this example, red indicates a positive correlation between the two crossed fields and blue indicates negative.  The deeper the color, the stronger the relationship between the two fields being compared.

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.

Posted in Flex, Information Visualization | Comments closed