Quelltext der Seite Principle of Least Surprise

Das '''Principle of Least Surprise''' ({{deS|Prinzip der geringsten Überraschung}}), auch unter der Abkürzung '''POLS''' bekannt, ist eine goldene Regel in der [[Software-Ergonomie]], der [[Mensch-Computer-Interaktion]] und dem [[Interfacedesign]]. Diese Regel wurde z.&nbsp;B. 1987 von Geoffrey James in seinem Buch ''The Tao of Programming'' als '''''Law of Least Astonishment''''' formuliert (Absatz 4.1). Sie besagt, dass eine [[Benutzerschnittstelle]] so ausgelegt werden sollte, dass der [[Benutzer]] möglichst wenige Überraschungen erlebt. Allgemein kann man somit folgende Regel formulieren:

{{Zitat
 |Text=Never surprise the user!
 |Sprache=en
 |Übersetzung=Überrasche niemals den Benutzer!}}

== Anwendung auf Quellcode ==
Das {{lang|en|Principle of Least Surprise}} wird auch auf den [[Quelltext|Quellcode]] von Anwendungen erweitert. Hierbei sollen Objekte wie Variablen, Funktionen, Methoden, Klassen und dergleichen derart benannt werden, dass deren Funktion und mögliche [[Wirkung (Informatik)|Nebenwirkungen]] klar erkenntlich sind.

Beispiele:
; <syntaxhighlight lang="csharp">Customer getCustomer(int customerId)</syntaxhighlight>: Gibt einen Kunden anhand einer eindeutigen Identifikationsnummer zurück. Sollte der Kunde nicht gefunden werden, tritt eine [[Ausnahmebehandlung|Ausnahme]] auf. Die Methode besitzt keine Nebenwirkungen.
; <syntaxhighlight lang="csharp">Customer getCustomerOrNull(int customerId)</syntaxhighlight> : Gibt einen Kunden anhand einer eindeutigen Identifikationsnummer zurück. Sollte der Kunde nicht gefunden werden, wird der [[Nullwert]] zurückgeliefert. Im Fehlerfall tritt eine Ausnahme auf. Die Methode besitzt keine Nebenwirkungen.
; <syntaxhighlight lang="csharp">Customer getCustomerOrDefault(int customerId)</syntaxhighlight> : Gibt einen Kunden anhand einer eindeutigen Identifikationsnummer zurück. Sollte der Kunde nicht gefunden werden, wird ein Kundenobjekt mit Standardwerten zurückgeliefert. Im Fehlerfall tritt eine Ausnahme auf. Die Methode besitzt keine Nebenwirkungen.
; <syntaxhighlight lang="csharp">bool tryGetCustomer(int customerId, out Customer customer)</syntaxhighlight>: Gibt <code>true</code> zurück, falls der Kunde gefunden wurde. Gibt <code>false</code> zurück, falls der Kunde nicht gefunden wurde oder ein Fehler aufgetreten ist. Die Methode liefert zudem den Kunden in der Variable <code>customer</code> zurück, falls der Kunde gefunden wird. Andernfalls wird die Variable <code>customer</code> auf den Nullwert gesetzt. Die Methode besitzt keine Nebenwirkungen.
; <syntaxhighlight lang="csharp">void saveCustomer(Customer customer)</syntaxhighlight>: Speichert das Kundenobjekt und weist somit Nebenwirkungen auf. Im Fehlerfall tritt eine [[Ausnahmebehandlung|Ausnahme]] auf.
; <syntaxhighlight lang="csharp">async int addCustomerAndReturnCustomerIdAsync(Customer customer)</syntaxhighlight>: Speichert das Kundenobjekt und weist somit Nebenwirkungen auf. Anschließend wird die Identifikationsnummer des Kundenobjekts in einem [[Continuation Task]] zurückgeliefert. Im Fehlerfall tritt eine [[Ausnahmebehandlung|Ausnahme]] auf.

Das bei vielen Frameworks verwendete Designparadigma [[Konvention vor Konfiguration]] (englisch Convention over Configuration) basiert auf dem Prinzip der geringsten Überraschung. So reicht es beispielsweise in [[Spring (Framework)|Spring Data]], [[Repository (Entwurfsmuster)|Repository Interfaces]] mit entsprechenden Methoden zu versehen, und das Framework kümmert sich um die entsprechenden Datenbankabfragen. Beispielsweise wird <code>List<Customer> findByLastnameAndAgeGreaterThan(String lastname, int age);</code> alle Kunden mit passendem Namen und Alter finden, ohne Code schreiben zu müssen.

== Beispiele ==
* Software, insbesondere Chat-Software, etwa bei Eintreffen einer neuen Nachricht, sollte nicht ungefragt den Tastaturfokus übernehmen. Der Benutzer könnte gerade dabei sein, sein Kennwort in ein Formular einzugeben und durch blindes Tippen sein Kennwort stattdessen in das gerade erschienene Chatfenster eingeben und versehentlich an andere Personen schicken.
* Eine Software, die Tastatureingaben aufzeichnet ([[Makro#Makros in Anwendungsprogrammen|Makro-Recorder]]), sollte auch Tastenkombinationen aufzeichnen können, die gängigerweise zum Beenden von Software verwendet werden, wie Cmd-Q, Strg-Q oder Alt-F4. Hierdurch sollte der Makroaufzeichnungsprozess nicht beendet werden und das noch nicht gespeicherte Makro nicht verloren gehen. Die Software sollte stattdessen eine erkennbare Möglichkeit zum Beenden des Aufzeichnungsprozesses anbieten und danach sollten die üblichen Tastenkombinationen wieder aktiv sein.
* Generell sollte Software niemals Daten entfernen, die möglicherweise noch benötigt werden, etwa Konfigurationsoptionen, die im momentanen Zustand der Anwendung keine Wirksamkeit haben, aber bei anderer Verwendung später wieder relevant werden könnten. Ein Beispiel wären hier Stromsparoptionen für den Akkubetrieb, während ein Notebook am Stromnetz angeschlossen ist, oder Druckeinstellungen eines Dokumentes, auch wenn man den Druckdialog wieder schließt, ohne zu drucken.

== Problematik ==
Die Problematik bei der Anwendung dieser Regel ist, dass der [[Softwareentwickler|Programmierer]] oft nicht vorhersagen kann, was den Benutzer überrascht, da er eine systemnähere Denkweise hat und nicht wissen kann, was genau der Benutzer erwartet. Außerdem können verschiedene Benutzer höchst unterschiedliche Erwartungen haben. Oft erscheint auch gerade ein Verhalten, das dem Programmierer konsistent erscheint, einem Benutzer ungewohnt oder merkwürdig. Daher ist es wichtig, schon während der Entstehung einer Software oder der Bedienoberfläche eines Gerätes Rückmeldungen von zukünftigen Benutzern zu bekommen. Siehe dazu auch [[Extreme Programming]].

== Gezielte Verstöße ==
Besonders in der [[Werbetechnik]] wird oft gezielt gegen die Regel verstoßen, um den Anwender zu einer Aktion zu bewegen, die er im Normalfall nicht begehen würde. So wird bei [[Layer Ad]]s häufig die Schaltfläche zum Öffnen der Anzeige mit einem X versehen und in einer oberen Ecke platziert, was der Erwartung des Benutzers widerspricht, da ein X konventionell die Schaltfläche zum Schließen eines Fensters markiert.

[[Scherzanwendung]]en basieren häufig auf einem Verstoß gegen diese Vorschriften, indem zwei gegensätzliche Schaltflächen (z.&nbsp;B. „Ja“ und „Nein“) beim Daraufzeigen mit dem Mauszeiger (hover) ihre Beschriftungen tauschen oder verschwinden oder indem Schaltflächen, die eigentlich eine Aktion ausführen sollen, einfach gar nichts bewirken.

== Weblinks ==
* Geoffrey James: [http://www.canonical.org/~kragen/tao-of-programming.html ''The Tao of Programming.''] 1987 (1996).
* E. S. Raymond: {{Webarchiv |url=http://www.faqs.org/docs/artu/ch11s01.html |text=''Applying the principle of least surprise.'' |wayback=20191016211018}} In: ''The Art of Unix Programming.'' 2003
* [http://wiki.c2.com/?PrincipleOfLeastAstonishment ''Principle Of Least Astonishment.''] Portland Pattern Repository WikiWikiWeb

{{Navigationsleiste Prinzipien objektorientierten Designs}}

[[Kategorie:Benutzerschnittstelle]]