My CPOSC 2015 Talk for Android developers.
I have a RAZR v3 which features a 3-level battery charge indicator on the UI. Sometimes, the phone indicates a 3/3 charge, but when I plug it in, it shows a 1/3 when it begins to charge back up to full. It’s as if the phone is putting on a brave face while it’s starving, and when you finally feed it, it admits that it was really in bad shape and would have passed out from hunger had you not intervened.
The inconsistency of the indicator between the plugged and unplugged states must be a UI design decision, though the only reason I can fathom for it is that they wanted to give the appearance of long battery life at the expense of an accurate battery charge indicator. If you leave your phone on for a day and it still shows a 3/3 charge, you may extrapolate that you could get at least 3 days of use on a single charge. Uninformed users may compare that pleasant lie with the harsh truth of another phone’s battery indicator and falsely conclude that the lying phone lasts longer.
A reference eludes me at the moment, but IIRC, there was a bit of a kerfluffle over gas gauge indicators when Honda first started selling cars in the US. Honda’s decision was to provide an accurate gas gauge, where empty meant empty, whereas the unspoken rule in US car design was that empty meant “nearly” empty, where “nearly” could sometimes mean 50%. Much hilarity ensued when Americans learned that the gas gauges were “broken” and would no longer lie to them. The unspoken standard may have changed over time, since all the cars I’ve driven recently will activate a Blinkenlight(tm) when the gas is down to 2-4 gallons, depending on the car.
I’m curious to learn what lies you’ve all been told by various UIs that you use.
Personal experience seems to indicate that the best Designs do not need Documentation to be usable, but the worst Designs need pages and pages of Documentation. The heuristic is that the quality of a Design is inversely proportional to the length of the user Documentation.
The problem, of course, is that there’s no guarantee that a poorly-designed product has enough compensatory Documentation. Likewise, someone may have just written lots of Documentation for something that didn’t really need it.
Taken on its own, it’s not perfect, but if you are looking at adopting a product, process, or other technology, you may want to choose the one that, all else being equal, has the slimmest manual.