←back to thread

163 points juancroldan | 1 comments | | HN request time: 0.223s | source
Show context
throw10920 ◴[] No.43632997[source]
I really like the implied general principle of the wall kick - if the user tries to do an action in a state that doesn't allow it, if there's something that's useful and pretty close, do that instead.

For instance, I'm building a tree editor with vim movement keys, and I found that a "j" that brings me up to the first child or next sibling node is strictly more useful than a "j" that only descends to children and a "l" that only goes to the next sibling.

Obviously, you have to be very careful to avoid introducing footguns, but the idea of "don't dogmatically adhere to operation semantics" is good.

replies(1): >>43638102 #
1. munificent ◴[] No.43638102[source]
This is, I think, one of the deepest arts in user experience design. It comes up in games, but I find myself applying it all the time when designing a programming language too.

A human sitting at a machine and pushing buttons is expressing some sort of intention. When the machine can do exactly what they requested, easy, do that.

But what happens if their intentions don't seem to make sense given the current state of the system and/or their previously indicated intentions?

In the context of Tetris, it's them trying to rotate a piece when they've moved it too close to the wall to do that. In a programming language, it can be that they've defined a function that's declared to take a string and then they wrote a call that passes it a number.

Sometimes, you can make a pretty confident guess as to what they are trying to do and have the system either do that instead or at least use that assumption to explain why the system can't do what they requested.

But deciding when a guess is a safe bet for the system to make and when it will be wrong often enough to confuse users is really hard, especially as the complexity of the system and the diversity of the userbase scales up.