Visualization Critique 1

Good Example - Landing distance chart

Explanation

There are a great number of variables that impact an aircraft's performance, and many of them - the weight of the plane's cargo, the outside temperature, altitude above sea level, barometric pressure, etc - are constantly changing. Because these variables change so often and have such great effects on how a plane flies, it is important for pilots to be able to calculate their effects on maneuvers where performance is critical. One of the most best examples of this is the case of landing the airplane. A useful measure to have in this case is the distance that is required to transition from flying 50 feet above the ground, to safely on the ground at a full stop. To that end, many pilots use "Landing distance charts" to help them identify this number. Here is an example of one such chart.

(FAR/AIM 2004 - Federal Aviation Regulations / Aeronautical Information Manual)

The basic idea behind the chart is this: a pilot starts at a point on the left of the chart and based on the values of specific variables (temperature, pressure altitude, weight, and wind conditions) that he knows he is able to trace a line across the chart that, when it reaches the right side, will given him the value of the variable he doesn't know (distance required to clear a 50ft obstacle and then land.) Because this specific image is from a manual on how to use a chart of this type, it has an example of this line superimposed on the chart (this is the line with arrowheads on it moving from the left side to the right). It also shows places where the pilot uses his readings to effect the path of the line (for example, the line flattens out over the "32" because the plane weighs 3200lbs with cargo) as arrows coming up from the bottom of the chart. The technical reasons for why this chart works are somewhat beyond the scope of this discussion, but this should be enough detail for the reader to have an understanding of the purpose of the chart and how it is used.

Deconstruction

This visualization is not focused just on displaying existing information, it also helps the pilot synthesize new information based on existing data. There is some information already built into the chart that is fixed by the physical properties of the aircraft, not the environment it exists in. The slopes of the lines and scales are very specific to each aircraft model. The slopes of the lines tell us information such as how true airspeed changes in response to differing air conditions, how weight affects glide slope and stopping distance, and how headwinds will effect ground speed. Likewise, the information in the scales tells us about the valid operating temperature ranges for the plane, its operating weight ranges, and winds that it is rated to land in. An interesting thing about the lines on the chart is that they do not communicate the values of the variables they represent in any explicit way. It is not really easy to come away from the chart with a number representing any of these variables - but yet the user can interact with the encoded values without having to decode them. The scales are present to help the pilot know how to encode other data that they know (outside temperature, pressure altitude, weight, and wind conditions) into positions on the chart which helps them create a line which makes the solution to their problem obvious. In this way the users interaction with the chart consists mainly of encoding data representing their problem, decoding it only at the end.

It should also be noted that at the top of the graphic there is a table with information assumed by the chart itself. This too presents useful data about how the plane should be flown to achieve the the landing distance the chart will give them. So it not only tells them how far it will take them to land, but also to some extent how to land (what speed and power setting to use).

Critique

Landing distance charts of this kind are very powerful, they deal with a lot of variables (at least 9), and make what could be very complex calculations relatively simple. They are accurate and do a good job of using terminology and information that is well understood and available to all pilots. One of the biggest problems with this visualization is that is not intuitively obvious. While it would be possible for someone who possessed the knowledge about the kinds of variables the chart deals with to figure out how to use it, it would not be a trivial task to do so. For the most part pilots must be trained how to use it, but once they have been trained they find it both easy to use and useful. As a visualization tool that displays (very) multivariate data it does a remarkably good job.

That said, an argument could be made that making some tweaks to the chart could help make it better. Lightening the minor grid lines could help make it easier to see what is going on in the chart. Also, the display of the labels for pressure altitude is cluttered at the moment, by moving the labels to the left of the chart we could help eliminate some confuse I believe. This particular image shows some example data, which I feel gets mixed in with the chart itself. Using color to distinguish between the chart itself and what the pilot in this example drew onto the chart while performing the calculations would go a long way towards separating these two out again.

Bad Example - Triathlon Training Plan

Explanation

(Runner's Wold - July 2006)

This visualization is for a 12 week plan to prepare readers of Runner's Wold for a Triathlon. It alternates between types of workouts based on the day of the week, Tuesdays and Fridays are for swimming, Wednesdays and Saturdays for cycling, and Thursdays and Sundays for running. Mondays are assigned as rest days to let your body recover. The plan proscribes a different set of requirements for each day of the 12 weeks, and has two paths (labeled as "a" and "b"), one of which is more aggressive than the other.

Deconstruction

This chart has essentially four variables, day of the plan (1-84), workout, and workout type (swimming/cycling/running), and the track. The day in this case is ordinal data, with one day following after the other. The workout type is also clearly categorical, with one of three options. On the other hand the track is ordinal with the second of the two options, track b, being more difficult than the first. The actual proscribed workout for a given day is somewhat harder to classify, because it often consists of many smaller tasks (e.g. do x 3 times, y 4 times, and z 6 times), though those tasks vary by type and number. I believe that it is basically a nominal description of the workout itself.

They chose to encode the first variable (day) as the combination of a week and a day within that week (example: week 9, Tuesday), representing them as cells within a table, with day of the week forming columns and weeks forming rows. Each day is then a cell and the table can be read left to right, top to bottom. Each cell in the table is then split in half diagonally - one half is assigned to track a, and the other to track b. The difference between the two tracks is encoded with the darkness of their half of the cell, with white being track b and a colored half representing track a. They also are encoded with position, with track a in the top left of each cell and track b in the bottom right. The color used in the track A half depends on whether that day is a running, cycling, or swimming day. This is interesting because that variable is also encoded by using the columns up at the top and labeling each column as one of the tree activity types. The actual workout is then simply specified as text within the half of a cell assigned to its day and track.

Critique

I do like that the design laid the days out by week, that enables it to be broken into smaller sub-plans that are easier to keep track of for an individual. It also allows the type of activity (e.g. swimming) to be encoded along with day of the week in the columns of the table, which strikes me as a good way of doing things. I do find it curious however that they choose to encoded the type of activity twice, especially when the second time it is encoded with color hue. The color here is completely unnecessary and distracts from the data itself. It's a waste of ink that I don't think Tufte would like much either. Likewise, they encoded the track of each workout twice (with value and position). If we limit it to position (the better of the two encodings), then we can have each box divided in half with a simple diagonal line.

That brings me to me next complaint. The design suffers because of the diagonal divisions of each day's cell. It means they need to fit the text for the day in an awkward triangular shape, which causes the text to wrap in un-natural ways. Also, it means the table takes up much more space, because a lot of the space in the table cannot be used. I see no reason why the chart could not be split into two separate charts, one for each track. This would allow more compact cells that would have text that wrapped cleanly, and would allow them to be more clearly separated. I suspect that if they were to do this it would actually have used less space on the page, not more.

The descriptions of each workout are somewhat unclear, they are heavily abbreviated and not well labeled. However, I suspect that the intended audience for this chart would have no problem understanding exactly what they mean, and the text surrounding this graphic includes a description of how to interpret the text. My final complaint about the current layout is that Monday is treated very differently (visually) than the rest of the days of the weak, it is thinner and blurred into one solid line. I would have preferred that the display were arranged more like a calendar - though if the other recommendations I proposed were implemented I feel that this might not be a significant problem.