principle of least astonishment

Have you ever heard of the “principle of least astonishment” (POLA)? It is also known as the “principle of least surprise”. Right away I don’t remember hearing about this principle. Maybe I just forgot about it. If you feel the same way, here is the Wikipedia article. Although the principle can be formulated with the simple words “Never surprise the user (negatively)!”, its compliance is a complex task.

Let’s have a look at transaction MIR4 (show incoming invoice) as an example. When starting the transaction, you have to enter the document number and the document year on a dynpro. If the document is available, it will be displayed in another dynpro by pressing the enter key. If you use the F3 key here to return to the previous screen for entering another document number and year, you end up immediately in the SAP Easy Access menu. Surprise, because you didn’t expect that … I fall for it regularly 🙂 As a hint: Please try the F12 key.

Since we are not only developers, but also users, everyone can certainly tell at least one similar story. Feel free to use the SCN’s comment function, which, in my experience, works as expected 😉 Conversely, the following also applies: Since we’re developers, it’s up to us to avoid such stories.

This is where the complex task begins. Small, nondescript aspects can mean a lot of work. But they are needed to pay attention to the principle of least astonishment. Once they have been implemented, they can also be a lot of fun – for users and developers.

Sometimes the small aspects are also crucial for purchasing software or hardware. You have the feeling that you can operate the software or hardware intuitively well. Long training isn’t necessary and there is quick success. It remains a “good feeling”. Sometimes you even tell other people about your happiness and thus become an “ambassador”.

How can we comply with the “principle of least astonishment”? There is probably a specific answer for each specific question or situation which depends on many factors. Last but not least, technology sometimes restricts us or gives us the right opportunities to implement our ideas.

Perhaps one can generally say:

1. If there is a known and reasonable standard, then you should apply it. It could already be known to users or there are documents for quick learning. Have a look at “SAP design guidelines and resources“.
2. Sometimes existing standards from other areas can be adopted.
3. If there is no standard, a discussion with users and colleagues may help.
4. <your idea>

At this point I would like to add another principle to the “principle of least astonishment”, the “principle of best possible assistance”. It isn’t a “real” principle, I invented the name just for fun. Therefore I would like to use an example to describe what is meant. You can choose your own name. Perhaps there is already a name?

Here is the example: Let us assume that an application of our SAP ERP system informs about an IDoc error situation by e-mail. This information is very valuable for the IDoc administrator because he can now quickly react. In most cases, he wants to collect more information and then correct the error. This is exactly what a developer could support by implementing a link from the e-mail to the system. The administrator can easily switch to the system and begin with his work. For example, it would make sense to display the IDoc in transaction BD87 or WE05 via link.

Using the example, everyone can certainly enumerate countless situations in which they would have liked a little more assistance. In our own applications, it’s up to us to pay attention to this 🙂