Personal Insights
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:
- 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“.
- Sometimes existing standards from other areas can be adopted.
- If there is no standard, a discussion with users and colleagues may help.
- <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 š
What’s your opinion?
Best regards, thanks for reading and have a good time.
Michael
Hi Michael,
nice one. Like the way of thinking. In my personal opinion and also as a result of my previous work the most important step is to talk to endusers. Not only the key-users.. the enduser.
Funny you mention the BD87 and WE05.
An Enduser told me to use the WLF_IDOC... and I even did not know this one š
Happy new Year!
Good note regarding transaction WLF_IDOC.
Your smart end user must have read my IDoc book. š Funny thing: I didn't know myself before that it existed. For some reason SAP doesn't advertise these "little gems" much.
This reminds me of the following situation: "We have had this problem for two years and have no solution". "Well, the solution to this has been in place for 4 years ...". By the way: I got to know transaction ALO1 recently. Another "little gem" (if it works, had some strange results).
Hi Michael,
life is much more simpler not only for end-users also for developers,
when we stick to the principle of least astonishment
when designing GUIs and designing the backendfunctions.
I agree with you wholeheartedly.
Hi Johannes,
I think Your point is very important: as an end user I want the software to be intuitive and as a co-developer I want the code to be intuitive. And for me it means not only design standards like design patterns, but also structuring of code, e.g. when do I leave a blank line between two code lines and when two blank lines, and naming conventions, like when do I talk about id, or number, or key or code.
One thing that happens on SCN that "astonishes" me on a regular basis is that if I post a comment, then I have to press the "back" arrow about five times to get back to the main list of blogs.
Generally on web sites what happens is that you are typing away in a box (usually your password) and another application decides to open and suddenly you are typing in a different box altogether.
Inside SAP the time I was most astonished was many years back when the spool log database table TSP01 filled up. At that time once it hit 100,000 entries the result was not that people could not print things anymore. The result was a total system shutdown of production. I was not expecting that. Luckily that one has been fixed.
FOR ALL ENTRIES is another one that has astonished programmers down the decades when a blank selection table does a full table scan. No matter what SAP says no-one ever expected that behaviour. And now it cannot be fixed because it is not "downward compatible" in case someone somewhere was depending on an obvious bug to get their program to work.
One more ... the good old CALL TRANSACTION WITH AUTHORITY CHECK - what we were expecting to do when an authority check failed was that an error message would be raised by the system saying you are not authorised. Instead you get a run-time error. That astonished us, to put it mildly.
Actually I could go on all day, so i think I will stop here. I look forward to other examples!
Cheersy Cheers
Paul
There is a book called āC Traps and Pitfallsā. If someone writes such a book for ABAP, the instruction āFOR ALL ENTRIESā should have its own chapter. There is a note in the documentation, but the ABAP documentation on help.sap.com is now āgiganticā. You can read a lot and for a long time.
Actually, I was quite surprised that CALL TRANSACTION alone did not execute tcode authorization check. Like what the heck. But I guess it comes from the same twisted minds as FAE with empty table, so should hardly be a surprise.
Ā
Iām just finding out about āCALL TRANSACTION WITH AUTHORITY CHECKā (cause ATC finds some CALL TRANSACTION -statements) and had the same thought when reading the documentation. (Undoubtedly that is a way better time of finding out, compared to e.g. having the dump happen to your users).
What I als find interesting: The examples given in the docs (e.g. https://help.sap.com/doc/abapdocu_752_index_htm/7.52/en-US/index.htm?file=abencall_transaction_abexa.htm ) also donāt show that kind of āget a message to the userā implementation:Ā They just use return.
Taken from the Link above, but also Report demo_call_transaction_spa_gpa
best
Joachim
EDIT: also: why isn't there a AdT-Quickfix for that?!
Hello Michael,
Letās, for example, swap the break and the accelerator in the car. Isnāt it fun? I suppose the driver will be surprised. Or move some equipment handlers to different spots of the airplane cockpit because they fit better there (well, we count so). I can believe the pilot will also appreciate our modern achievements in ergonomics, design, and art intelligence and certainly became astonished. Boeing MAX 8 is a good example ā all modern achievements in one. (sarcasm of course )
Anyway it seems things are going this way in programming industry. Not to adapt software to users but adapt users to software has become a common rule. Itās sad. The new generation of programmers forgot the principles that was discovered in 60-70th yet (firstly so-called KISS principle) and now recovering them again inventing new fashionable terms (like POLA) for old things.
It is so easy, for example, to place the closing cross to left-top corner of a window (as in Ubuntu). What a great achievement of ergonomic! Of course, millions users being used to the MS Windows interface do not matter. And so on.
Ā
Didn't know that the closing cross is in Ubuntu placed to left-top corner of a window. Sounds interesting. What's the benefit (right away I cannot test it)?
Hi Michael, very good post!
There are many examples you can name, as already mentioned by you and Paul. The ones that I find annoying:
Select first and second component of a table and hit the search help button. The dialog for the second component opens. Close it, deselect the second component and hit the button once again. Itās still valid for the second component, which is not selected anymore!
The list of experiences is getting longer. As developers, we can deal with some error situations better than users, but it still remains "annoying" š That being said, even if you constantly need progress, there are some older tools that you have to keep in order. This applies to the software world as well as to craftsmen.
I like the MAYA principle: "most advanced yet acceptable". Makes a lot of sense and could be applied a lot in software development.
Thanks for this post. Now I have another superior principle in my toolbox š