Computational tricycle or bicycle?
Paul Saffo's latest column on his web notepad interestingly deal with the "bicycle versus tricycle" design issue:
"Hewlett Packard’s announcement last month of a “Retro” edition of its HP35S calculator highlights another interface that is an even greater lost opportunity -- Reverse Polish Notation. Invented in the 1950s by Australian computer Scientist Charles Hamblin, RPN was adopted by HP as the interface for all of its calculators back when calculators began appearing in the early 1970s. RPN is a vastly more efficient way to enter problems on a calculator than the standard infix method used on virtually every calculator sold then -- and today. For example, if one wished to add 3 to 4, with infix on a conventional calculator, the keystroke sequence is , [+], , [=], while with RPN on the HP35S, one enters , [ENTER], , [+]. (...) Borrowing an analogy told to me by Doug Engelbart, RPN is to infix as a 2-wheeler bike is to a tricycle: The tricycle has no learning curve, but it will never go fast. In contrast, the two-wheeler takes some practice, but once one learns, the bike is a high-performance tool. (...) Unfortunately, RPN never caught on widely and even HP lost its nerve and abandoned RPN for most of its calculators. As a consequence calculator users today have no choice but to purchase computational tricycles. But try RPN and you will never go back."
Why do I blog this? I am often intrigued by examples of the "bicycle versus tricycle" issue in design and how different shape of the learning curve can influence the user experience in the long run.