The iOS #calculator meme that’s going around where “50+50×2=” yields 150 and not 200, is a great example of hidden states in UX design.
Low-cost desktop calculators perform (most) operations strictly left-to-right: press any operator button (+-×÷), and the display is updated to show the result of the calculation so far, and that result becomes an operand for the operation. There is no other state “inside” the calculator that affects the solution—what you see is all you get.
On the iOS calculator, you’re entering the entire expression into a hidden buffer. You can’t really see what you entered (and there’s no option to make it visible, as far as I can tell), and the final result is only shown when you press =. The confusion arises because a user’s mental model may not correspond to the hidden model used for the computation.
All this is to say that hidden states often break #UX expectations. Making hidden state visible goes a long way to remove confusion (see how PCalc does it in the second image).
@drahardja I thought showing the paper tape would be better, but it is much, much worse. It literally shows the same two expression with different answers.
@drahardja this feels to me more like the schism between scientific and business calculators. Hardware scientific calculators respect operator precedence because they are built for people who passed math classes, and hardware business calculators (including actual desktop calculators) are strictly left-to-right because they are built for people that failed math classes.
@joat That’s a weirdly insulting and classist way to put it.
Calculators are tools. They all work around limitations in different ways. “Desktop” calculators that go strictly from left-to-right were made to save parts cost (registers are expensive) so they could be sold cheaply. Other “business” calculators like the famed HP 12C used RPN and an internal stack to eliminate ambiguity, but cost an order of magnitude more.
The resources thing may have once been true but they still sell both business and scientific calculators (mostly for the education market I suspect) and they still behave the same way. I guess for historical reasons... to match the textbook examples?
I have an HP 17B II, an older model but expensive at the time... and when not in rpn mode it's strictly left to right. It definitely has enough resources for a stack but it behaves like business people expect.
@joat Yes, and “user expectations” is definitely a primary concern when designing UX. The iOS Calculator looks like a traditional low-cost desktop calculator, but behaves like a scientific calculator. That breaks expectations, which can be seen through the popularity of this meme.
@drahardja that's a fair point. Very old scientifics didn't show any internal state either, layer models had some sort of "intermediate result" indicator. But I suspect that the presence of ( and ) keys indicated correct expression order, which the iOS calc doesn't have.
I just tried the standard Android calculator and it more clearly shows what's going on, so good on Google I guess.
@drahardja as an aside, it always bothered me on older scientific calcs that they had a weird semi-rpn style for many functions. So unlike modern calcs where you would enter 1 + 2 × sin( 30 ) = you would instead use sin as a postfix operator and do 1 + 2 × 30 sin =
@joat They did that to make all single-operand operators work the same way, e.g. the x² operator. A big problem arises when you have multi-parameter functions of course (e.g. TVM computation)…
@drahardja@joat The UX of TVM solving on the HP calculators, like the HP12c, is so beautifully refined. The very simple idea that if you are pressing two variable buttons consecutively, it means you are asking for it to solve is genius.
@drahardja talking about expectations, I guess the × key on a scientific calculator is understood to mean "do whatever internal magic is required to preserve operator precedence" while on a business calculator it means "= and then multiply by the next number". An = key isn't actually required on a calculator that works that way so it's surprising they didn't save money back in the day by just removing it.
@drahardja I'd take the argument further... the existence of the = key implies operator precedence in the same way that ( ) do, so any calculator that has either and doesn't respect operator precedence is broken.
@aardvark Yeah that behavior is the same one that every other desktop calculator exhibited in 1984. The behavior of the iOS calculator is surprising, because it looks like an old calculator, but behaves like a newer one, without any indication of its internal state.
Add comment