Archive for July 23, 2006

Sunday, July 23, 2006

Quantitative Design

Humanized has an interesting article about measuring interface efficiency using information theory (via Daniel Jalkut). It’s an idea that deserves some thought, but for the moment I’m unconvinced. The thesis seems reasonable, but the model doesn’t capture the nuances of the real-world examples and therefore it makes predictions that seem intuitively wrong.

The natural language examples make me suspicious right off the bat. The author does draw a distinction between information and meaning, but subsequent paragraphs sometimes conflate these ideas.

Why is efficiency, defined as the amount of information entered, important? There are so many other factors to consider (including time spent waiting, cognitive load, propensity for errors, and ease of error recovery). My first reaction is that it’s better to bundle all the known and unknown factors together and measure efficiency using the time to complete the task.

In the real world, we rarely start from scratch and try to set a specific time. The initial state of the watch and the shape of the delta matter. Usually, we want to adjust the watch a few minutes forward or backward if it’s gained or lost time. Or we want to leave the minutes alone and shift the hours to account for daylight savings time or traveling through a time zone. My digital watch lets me do the daylight savings adjustment using three button presses. Does that make it more than 100% efficient?

Analog watches also make it easy to make small changes to the time, although sometimes the only way to go backwards a few minutes is to go forwards nearly a whole day. Surely these factors matter, but the model doesn’t capture them.

The article asserts that turning the crown of an analog watch represents 9.5 bits because there are 720 possible times. The way this is presented seems like reasoning backwards to me.

What if an analog watch had two knobs to turn, one for each hand. There are 12 positions for the hour hand and 60 for the minute hand. In the real world, this makes it much easier to set the time because you don’t have to go around and around to get to the right hour. But according to the model, the efficiency has gone down because we’re still choosing one of 720 possible times, only now we have to choose between two knobs, too. After all, the digital watch was penalized for having two untouched buttons while in the quasimode of advancing the hour.

Here are two designs that the model predicts would be good:

HashLife

DDJ on how Gosper used a clever representation and memoization of multiple levels of calls to get a huge speedup:

Making a slow program fast can lead to both joy and frustration. Frequently, the best you can do is a low-level trick to double or maybe quadruple the speed of a program; for instance, many readers may have implemented John Conway’s “Game of Life” using bit-level operations for a significant speedup. But sometimes a whole new approach, combining just a few ideas, yields amazing improvements. A simple algorithm called “HashLife,” invented by William Gosper (“Exploiting Regularities in Large Cellular Spaces,” Physica 10D, 1984), combines quadtrees and memoization to yield astronomical speedup to the Game of Life. In this article, I evolve the simplest Life implementation into this algorithm, explain how it works, and run some universes for trillions of generations as they grow to billions of cells.