
Principle of Least Astonishment - kentbrew
https://en.wikipedia.org/wiki/Principle_of_least_astonishment
======
dang
Earlier discussion (earlier Wiki too):
[https://news.ycombinator.com/item?id=22794771](https://news.ycombinator.com/item?id=22794771)

Repeats are fine after a year or so but we need more astonishment before then
([https://news.ycombinator.com/newsfaq.html](https://news.ycombinator.com/newsfaq.html)).

------
ridaj
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

~~~
lostcolony
"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.

------
allard
How many times in a day are you unpleasantly astonished by something made out
of bits? (I'm working around one with a set screw now.)

------
seph-reed
Seems pretty similar to KiSS (Keep it Simple Stupid)

~~~
kmill
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.

~~~
loopz
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.

