Dead Ink Vinyl

Nat Torkington at O’Reilly Radar feels that the New York Times is deliberately distorting the housing market bubble by representing the cost of homes as a line graph in this info-graphic. Nat, and many of the people who have posted comments in response to Nat’s observation, apparently do not understand the difference between line graphs and bar graphs. Nat complains the graphic is misleading because it tries to help the viewer contextualize the information by labeling the starting point, the price of a home in 1987, as “100” so that the viewer would be able to immediately grasp that a $100k house then would worth $160k today. (The graph is adjusted for inflation, so the line represents change relative to inflation.) Instead, the graph could have labeled “100” as “+0” and adjusted the other vertical labels accordingly (“160” becomes “+60%”, etc.) so as not to confuse Nat. Then the graph would have looked like a stock price comparison graph.

Speaking of stock market price graphs, have you ever noticed that they are always presented as line graphs and never go down to 0? That’s because line graphs aren’t intended to show absolute value—that’s the responsibility of bar graphs. Instead, line graphs are used to show the direct relationship between one quantity and another and are often used to represent change over time.

In the case of stock price graphs, the graph shows the relationship of a stock price relative to its starting price over time. In the case of the New York Times info-graphic, the line graph shows the relationship of home price relative to inflation (inflation being the “100” line) over time.

For a line graph, space above the maximum value or below the minimum value (which is what Nat is advocating) is wasted and can be misleading because the added space distorts the relative change that is occurring by flattening the line. Consequently, I find nothing wrong with the New York Times graphic and I believe that Nat’s ideas to improve the graph would only harm it.

If there is an argument to be made about the graph being designed to over-emphasize the bubble, it would the vertical orientation of the map, since line graphs are traditionally wider than they are tall. The placement of text above the peak on the right of the graph also contributes to an exaggerated perception of growth since January, 2000.

My computer bag, a Brenthaven backpack I’ve used since my original 17” PowerBook, has gotten insanely heavy over the course of this week. I pulled eveything out to take a look at what has been adding load.

The first items aren’t that interesting. A 360|Flex folder and an Effective UI graph pad I picked up off a table while at that conference (thanks, guys!). I plan to use the graph pad to layout some screens for an upcoming project at work and want to keep it handy in case inspiration strikes. I’m still waiting for that inspiration.

Then I pulled out a two inch thick collection of papers I’d printed (duplex, to conserve paper). On top of the stack is D-Click’s Adobe Flex Coding Guidelines. I really don’t like placing opening braces on their own line. Drives me nuts. (For my money, the Sun Java Coding Conventions can’t be beat.) But, when in Rome, do as the Romans do. I recognize that being consistent (especially across developers on the same team) is more important than the merits of any single convention, so I’m trying to learn new habits.

Next up are printouts of six chapters from Adobe’s Building and Deploying Flex Applications (PDF here). I have only built Flex apps inside of Flex Builder, so I still need to learn the command line tools. My company is big on “repeatable builds”—meaning that any interally-developed production applications should be easy to regenerate from source without developer involvement. In practice, this means that the application must be built with a command line build script (Make, Ant, etc.). Besides, I get nervous when I’m overly dependent on an IDE. I like code completion, syntax highlighting, and refactoring, but I really like to know that I can do it all from vi or Notepad and the raw Flex SDK if desired or needed. Hence my interest in the Building and Deploying Flex Applications book. And I mean book! A full printout would weigh in at 400+ pages! So I picked the most important parts to me and just printed those.

The first chapter is Chapter 3 (Flex Application Structure). I just finished reading this chapter last night. Not a lot to say here. It’s good to have the layout with which I was familiar due to Flex Builder reinforced in print. Next up are Chapter 4 (Applying Flex Security), Chapter 7 (Building Overview), Chapter 9 (Using the Flex Compilers), Chapter 13 (Using ASDoc), and Chapter 14 (Creating Applications for Testing).

Then I come to printouts of various O’Reilly articles about Ruby on Rails that I intend to read Any Day Now™. Rolling with Ruby on Rails Revisited, Cookin’ with Ruby on Rails: May, Cookin’ with Ruby on Rails: Designing for Testability, Cookin’ with Ruby on Rails: More Designing for Testability.

And finally, I have Greg Hamer’s presentation slides for introducing Cairngorm at 360|Flex. I suppose I can take this out of my bag. I have the general idea of how Cairngorm works. I’m still waiting to write an app large enough to make playing with Cairngorm worthwhile. Okay, that’s not quite right. I’m still working on my first Flex app ever. I’m plugging into the 37signals Backpack API. When I’m done with that, I might look at refactoring it for Cairngorm just to get that experience under my belt.

And that’s wy my computer bag weighs a ton. What’s in your computer bag?