Principle of Least Surprise

The Principle of Least Surprise ( German principle of least surprise ), also known by the acronym POLS known is a golden rule in the software ergonomics , the human-computer interaction and interface design . This rule was formulated by Geoffrey James in his book The Tao of Programming as the Law of Least Astonishment (paragraph 4.1). It says that a user interface should be designed in such a way that the user experiences as few surprises as possible. In general, the following rule can be formulated:

"Never surprise the user!"

Application to source code

The Principle of Least Surprise is also extended to the source code of applications. Objects such as variables, functions, methods, classes and the like should be named in such a way that their function and possible side effects are clearly recognizable.

Examples:

Customer GetCustomer(int customerId): Returns a customer based on a unique identification number. If the customer is not found, an exception occurs in the event of an error . The method has no side effects.
Customer GetCustomerOrNull(int customerId): Returns a customer based on a unique identification number. If the customer is not found, the zero value is returned. An exception occurs in the event of an error. The method has no side effects.
Customer GetCustomerOrDefault(int customerId): Returns a customer based on a unique identification number. If the customer is not found, a customer object with standard values is returned. An exception occurs in the event of an error. The method has no side effects.
bool TryGetCustomer(int customerId, out Customer customer): Returns trueif the customer was found. Returns falseif the customer was not found or an error occurred. The method also returns the customer in the variable customerif the customer is found. Otherwise the variable is set customerto zero. The method has no side effects.
void SaveCustomer(Customer customer): Saves the customer object and thus has side effects. An exception occurs in the event of an error .
async int AddCustomerAndReturnCustomerIdAsync(Customer customer): Saves the customer object and thus has side effects. The identification number of the customer object is then returned in a continuation task . An exception occurs in the event of an error .

Examples

Software, especially chat software, for example when a new message arrives, should not take over the keyboard focus without being asked. The user could be about to enter his password into a form and blindly type his password into the chat window that has just appeared and inadvertently send it to other people.
Software that records keystrokes ( macro recorder ) should also be able to record keyboard shortcuts that are commonly used to exit software, such as Cmd-Q, Ctrl-Q, or Alt-F4. This should not end the macro recording process or lose the unsaved macro. Instead, the software should offer a recognizable option to end the recording process and then the usual key combinations should be active again.
In general, software should never remove data that may still be needed, such as configuration options that have no effect in the current state of the application, but could become relevant again later when used in another way. An example here would be power-saving options for battery operation while a notebook is connected to the power supply, or print settings for a document, even if the print dialog is closed again without printing.

Problem

The problem with applying this rule is that the programmer often cannot predict what will surprise the user because he has a more systematic mindset and cannot know what exactly the user is expecting. Also, different users can have vastly different expectations. Often behavior that appears to be consistent to the programmer appears strange or strange to a user. It is therefore important to receive feedback from future users while the software or the user interface of a device is being developed. See also Extreme Programming .

Targeted Violations

In advertising technology in particular, the rule is often deliberately violated in order to induce the user to take an action that he would not normally take. In Layer Ads , for example, the button for opening the ad is often provided with an X and placed in an upper corner, which contradicts the expectations of the user, since an X conventionally marks the button for closing a window.

Joke applications are often based on a violation of these regulations, in that two opposing buttons (e.g. "Yes" and "No") swap their labels or disappear when the mouse pointer (hover) points them or by buttons that are actually supposed to perform an action , just do nothing.

Web links

Geoffrey James: The Tao of Programming . 1987.
ES Raymond: Applying the principle of least surprise . In: The Art of Unix Programming .
Principle Of Least Astonishment . Portland Pattern Repository WikiWikiWeb


SOLID principles	Single Responsibility • Open Closed • Liskov Substitution Principle • Interface Segregation • Dependency Inversion
Further principles	Demeter's law • Design by contract • Data encapsulation • Linguistic Modular Units • Self-Documentation • Uniform Access • Single Choice • Persistence Closure • Command Query Separation • Principle of Least Surprise
Packaging principles	Reuse Release Equivalence • Common Closure • Common Reuse • Acyclic Dependencies • Stable Dependencies • Stable Abstractions