July 2013

Volume 28 Number 7

Don't Get Me Started - Activation Energy

By David Platt | July 2013

Regular readers of this column know how I love analogies. Here’s another good one: You can understand user needs and user acceptance of your UI strategies by applying a concept from chemical engineering—activation energy versus released energy.

Both coal and paper will burn, releasing energy, as shown in Figure 1. But you need to supply some energy to start the process. My hot air probably will not ignite the paper magazine in your hand; for that, you need a match. The activation energy for coal is higher. You need to get it hotter, perhaps by starting a small fire with paper and then adding some kindling. On the other hand, the energy released by burning coal is greater than that released by burning paper, which is why we burn coal in power plants.

Figure 1 Higher Initial Energy Input Can Yield Greater Overall Energy Release

Your users’ operations are also governed by the calculus of activation energy versus released energy. Consider airlines. The ones that are making money (or at least losing it more slowly than the others) are the ones that sell the greatest proportion of their tickets online. The easiest way to do this is a simple browser interface. Just type delta.com into your address bar, and there it is, asking where you want to go and when. That activation energy is about as low as it gets. The released energy isn’t bad, although you’re subject to a browser interface’s foibles, such as not using the back button where you’re not supposed to.

Now suppose you had to download and install some sort of add-in before Delta would talk to you. Who would bother? You’d go to Orbitz, or you’d pick a different airline that valued its users’ time. The success of this casual e-commerce scenario is very much limited by the height of the activation energy hump. You need a paper fire, because you have to light many new ones every day.

Now suppose you were a travel agent, writing airline tickets for a living: 10 minutes each, six per hour, 48 per day. Suppose that a rich client application could lower this to eight minutes per ticket, improving your productivity from 48 tickets per day to 60. The app would have a higher activation energy: time to download and install, and you might also need some training. But you’d be willing to pay that higher activation energy price (or perhaps tunnel through it—see last month’s column on Heisenberg at msdn.microsoft.com/magazine/dn201756) because you harvest that released-­energy advantage with each ticket you write. Once you’ve gotten the coal fire burning, it’s easy to keep going.

A mobile app occupies an interesting middle ground. The brutal size constraints of smartphones often render a browser interface unusable, even one that’s tailored for mobile. Users are comfortable with the idea of downloading and installing apps. Furthermore, a user’s needs on the mobile platform often require more intimate control of the hardware than a browser allows. For example, the Amazon mobile-oriented Web site strives mightily to offer good service. But one of the main things mobile Amazon users do is comparison shop in physical stores before ordering online—a process called “showrooming” that’s now killing stores such as Best Buy. The Amazon mobile app lets you find a price by scanning an item’s UPC code or even just snapping a picture of the item.

MS-DOS had a high activation energy. You had to learn the basic DOS commands, and then the different commands for each program you ran. Windows was better because you didn’t have to memorize as much to get started. Menus showed you what programs could do, and each program worked sort of like the other ones. So the activation energy was lower.

Now comes Windows 8. It’s harder to learn because less of it is visible. The activation energy is higher than that of an iPad, for example. But the released energy is higher in Windows 8, with standardization of common application features such as searching and sharing. Microsoft desperately hopes that the promise of greater released energy will cause users to swallow the greater activation energy. The question is, will they?

David S. Platt teaches programming .NET at Harvard University Extension School and at companies all over the world. He’s the author of 11 programming books, including “Why Software Sucks” (Addison-Wesley Professional, 2006) and “Introducing Microsoft .NET” (Microsoft Press, 2002). Microsoft named him a Software Legend in 2002. He wonders whether he should tape down two of his daughter’s fingers so she learns how to count in octal. You can contact him at rollthunder.com.