The big difference is that sometimes users will expect a certain complexity or some unnecessary steps, so providing a way to do that will keep them from being surprised and make their existing training work.
I don't think so. It's about consistency, not about limiting complexity.
The creator of Ruby, Yukihiro Matsumoto, was clear about his placing value in the 'principle of least surprise', presumably referring to the same idea. Few modern languages are truly simple - in practice that's likely to mean making the language anaemic - but consistency in languages is still something to aim for.
I can see the similarity, though Git seems like an interesting differentiating example. Technically, it is extremely simple. A commit is a file tree with content stored in blobs along with a reference to the previous commit. A branch is the id of the blob containing the commit. Yet, it is frequently astonishing. The layers of porcelain over the plumbing are testament to the fact that the underlying model does not map to how you expect to work with a version control system, whether that's due to previous experience to due to an "impedance mismatch" with the way people actually work.
Don't get me wrong, I happily use Git since I'm willing to bend my will to the machine in this way. It does realize its promise.
A great example that's in the intersection of both is copy/cut/paste. That was the result of a user study for the Alto, I believe, watching real copyeditors doing their work. And it's technically straightforward.
In contrast, the Emacs kill ring and undo system, together, trip me up even after years of use. They are technically elegant, but together create some astonishing situations. Like Git, all are easily fixable, yet still there is some friction.
The PoLA, in its best form, seems to me to be about whether a user's will can be realized in as direct a way as possible. This might, potentially, have a very complicated implementation.
Git, when explained properly, should be intuitive. This follows the Principle.
The lack of explanation, or the complexity that arise in real life, may be problematic. If git has problems in this area, it is because of lack of proper communication.
This is an interesting principle which I understand the power of but feel is sometimes detrimental because it treats all surprises are equally bad.
Surprises can also be delightful. (It might be arguable that delight even requires surprise.)
That is perhaps the most extreme counterexample, but the point here is that we should treat very differently things that are "surprising, but easily recoverable" from things that are "surprising, and disorienting", "surprising, and makes you want to flip tables", or "surprising, and life-threatening".
Taken to an extreme, this principle leads you to stagnant designs, because you're afraid of modest innovations giving users a mild surprise. Or, your product fundamentally doesn't quite work the way most users expect it to work, so in order to avoid giving users a surprise, you do cosmetic things to paper over it...
Tldr: use at your own risk and remember you're at the wheel, not your principles
"If a necessary feature has a high astonishment factor, it MAY be necessary to redesign the feature" - emphasis added.
But, they're related, as you note. This is specifically referencing surprise in the sense of "What, no, that was not what I intended to do!", not in "Ha! That was exactly what I wanted to do; I can't believe it was that easy!"
The reality is that latter is very, very rare in UI/UX (more commonly, successful actions don't even register to the user, even if it's slightly novel; it 'just works'). The former...very common, and a thing to avoid.
This comment, the other comments, and amount of article points, speaks Volumes about the current state of development.
Principle of least astonishment (or equally: "principle of least surprise") should've been familiar to all Builders, but clearly it is not.
Maybe the phrase or naming of convention is off mark, but it should really be self-explanatory, at least to creators: If what one intended, do not happen as intended, astonishment is always bad. We don't treat machines as Englightened beings after all, we expect them to perform exactly as specified. The work is, as has always been, imperative, in whatever form and shape.
So, what should the phrase be, so that programmers might understand their ultimate objective end goal (and limitation)?
11 comments
[ 2.9 ms ] story [ 35.4 ms ] threadThe creator of Ruby, Yukihiro Matsumoto, was clear about his placing value in the 'principle of least surprise', presumably referring to the same idea. Few modern languages are truly simple - in practice that's likely to mean making the language anaemic - but consistency in languages is still something to aim for.
Don't get me wrong, I happily use Git since I'm willing to bend my will to the machine in this way. It does realize its promise.
A great example that's in the intersection of both is copy/cut/paste. That was the result of a user study for the Alto, I believe, watching real copyeditors doing their work. And it's technically straightforward.
In contrast, the Emacs kill ring and undo system, together, trip me up even after years of use. They are technically elegant, but together create some astonishing situations. Like Git, all are easily fixable, yet still there is some friction.
The PoLA, in its best form, seems to me to be about whether a user's will can be realized in as direct a way as possible. This might, potentially, have a very complicated implementation.
The lack of explanation, or the complexity that arise in real life, may be problematic. If git has problems in this area, it is because of lack of proper communication.
Surprises can also be delightful. (It might be arguable that delight even requires surprise.)
That is perhaps the most extreme counterexample, but the point here is that we should treat very differently things that are "surprising, but easily recoverable" from things that are "surprising, and disorienting", "surprising, and makes you want to flip tables", or "surprising, and life-threatening".
Taken to an extreme, this principle leads you to stagnant designs, because you're afraid of modest innovations giving users a mild surprise. Or, your product fundamentally doesn't quite work the way most users expect it to work, so in order to avoid giving users a surprise, you do cosmetic things to paper over it...
Tldr: use at your own risk and remember you're at the wheel, not your principles
But, they're related, as you note. This is specifically referencing surprise in the sense of "What, no, that was not what I intended to do!", not in "Ha! That was exactly what I wanted to do; I can't believe it was that easy!"
The reality is that latter is very, very rare in UI/UX (more commonly, successful actions don't even register to the user, even if it's slightly novel; it 'just works'). The former...very common, and a thing to avoid.
Principle of least astonishment (or equally: "principle of least surprise") should've been familiar to all Builders, but clearly it is not.
Maybe the phrase or naming of convention is off mark, but it should really be self-explanatory, at least to creators: If what one intended, do not happen as intended, astonishment is always bad. We don't treat machines as Englightened beings after all, we expect them to perform exactly as specified. The work is, as has always been, imperative, in whatever form and shape.
So, what should the phrase be, so that programmers might understand their ultimate objective end goal (and limitation)?
Most Advanced Yet Acceptable (MAYA)
https://www.theatlantic.com/magazine/archive/2017/01/what-ma...
Repeats are fine after a year or so but we need more astonishment before then (https://news.ycombinator.com/newsfaq.html).