Principle of Least Astonishment

"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)?

Raymond Loewy coined a phrase for this, wrote whole books about it

Most Advanced Yet Acceptable (MAYA)

https://www.theatlantic.com/magazine/archive/2017/01/what-ma...

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.