Eine für Smartphones optmierte Version wird in Kürze verfügbar sein
5.0.UI Patterns    5.3.Rückmeldung und Benachrichtigung

5.3.Rückmeldung und Benachrichtigung

Der Anwender muss immer das „sichere“ Gefühl haben, dass er bei einer Anwendung weiß, ob eine Aktion erfolgreich war oder nicht und wie insbesondere im Fall einer negativen Rückmeldung zu reagieren ist.

 

Hilfreiche Rückmeldungen erleichtern nicht nur die Arbeit mit einer Anwendung, sondern sind auch relevant für die Anwendung selbst. Wenn sich ein Anwender darüber im Unklaren ist, ob eine Aktion ausgeführt wurde oder nicht, können z.B. Mehrfachklicks auf kritische Funktionen oder hektische Seiten-Reloads inkonsistente Daten oder einen diffusen Applikations-Status hervorrufen (z.B. eine Bestellung wird mehrfach abgeschickt).

Neben Aspekten wie der klaren Bezeichnung von Eingabefeldern, einheitlicher und sprechender Bezeichnung von Buttons und Dialogen und dem Anbieten von Tooltips oder kontextabhängiger Hilfe spielen somit auch die System-Rückmeldungen eine wichtige Rolle bei dem Thema Benutzerfreundlichkeit.

5.0.UI Patterns      5.3.Rückmeldung und Benachrichtigung      5.3.1.Validierung und Rückmeldung

5.3.1.Validierung und Rückmeldung

Validierung
Nach nicht erfolgreicher Validierung z.B. eines Pflichtfeldes ist dieses durch einen roten Rahmen und ein zusätzliches Icon zu kennzeichnen (siehe auch Abschnitt Rückmeldung)

Some Image

    Rückmeldung
    Je nach Anwendung kann es selbstverständlich zu viel des Guten sein, über jede erfolgreiche Aktion nochmals gesondert zu informieren. Als Faustregel jedoch sollte für jede der Basis-CRUD-Operationen („Create-Update-Delete“) entsprechend Rückmeldung gegeben werden: d.h. beim Erstellen von Einträgen, Aktualisieren oder Löschen.

    Some Image

      Usability-Hinweis

      • Verwenden Sie sprechende Fehlermeldungen, d.h. es muss für den Benutzer in jedem Fall ersichtlich sein, wo fehlerhafte Daten eingegeben wurden.
      • Fehlermeldungen sollten in einfacher Sprache formuliert sein, das Problem exakt beschreiben und eine konstruktive Lösung vorschlagen.
      • Sowohl bei nicht ausgefüllten Pflichtfeldern als auch bei fehlerhaften Dateneingaben ist das verursachende Eingabefeld gesondert hervorzuheben durch einen roten Rahmen und ein entsprechendes Icon.
      • Zusätzlich zur Hervorhebung des Eingabefelds ist am Seitenanfang eine Fehlerzusammenfassung anzubieten.
      • Vor der Ausführung möglicherweise problematischer Aktionen gibt die Software eine Warnung aus.
      • Keine kryptischen Fehler-Codes (z.B. „Error 13892“): Rein technische Meldungen können zu Support-Zwecken zusätzlich angeboten werden, sollten dann aber auch entsprechend kenntlich gemacht werden („Bitte geben Sie beim Kontakt mit der Service-Hotline folgenden Fehler-Code an:“), gehören aber grundsätzlich nicht in das Benutzer-Frontend.
      • Die Applikation sollte den Benutzer jederzeit angemessen darüber informieren, was passiert und in welchem Zustand sich das System derzeit befindet.

      5.0.UI Patterns      5.3.Rückmeldung und Benachrichtigung      5.3.2.Dialoge

      5.3.2.Dialoge

      Nicht nur bieten Dialog-Layer eine deutlich bessere "User Experience", da die gestalteten Dialoge sich besser und angenehmer in die Applikation einfügen; zudem sind die gängigen Browser-Dialoge oder Javascript-Alerts auch negativ konnotiert, da man diese eher nur kennenlernt, wenn ein Problem auftritt.

      Darüber hinaus bietet sich diese Form von Widget auch deshalb an, da sich über ein konsistentes Interaktionsformat alle Dialogformen abdecken lassen:

         

      • einfache zweiwertige Bestätigungs-Dialoge ("Ja, Löschen | Abbrechen")
      •  

      • dreiwertige Dialoge, die kein Browser-Standard sind, aber häufig benötigt werden ("Ja | Nein | Abbrechen")
      •  

      • frei definierbare Dialoge (z.B. "Speichern | Speichern unter...")
      •  

      • kleinere ergänzende Formularbausteine, Selektoren oder Filter lassen sich elegant im selben Format unterbringen 
      •  

      • Warnungen und Hinweise
      •  

      • Zusatzinformationen oder kürzere Hilfetexte, falls z.B. ein Tooltip nicht ausreichend ist
      Some Image
      Abbildung

      Darstellung klassischer Dialoge

        5.0.UI Patterns      5.3.Rückmeldung und Benachrichtigung      5.3.3.System-Fehler

        5.3.3.System-Fehler

        Jede Anwendung muss auch zur Benutzerseite hin ein sauberes Fehler- und Exception-Handling pflegen, d.h. keine default Server- oder Framework-Fehlerseiten sollten angezeigt werden (z.B. Java-Stack-Error Pages, gelbe .NET-Fehlerseiten oder Server-Code Fehlerseiten).

        Ebenfalls sollte ein schlichtes „Der Fehler wurde registriert und wir werden uns das anschauen“ vermieden werden. Wenn sich eine generische System-Fehlerseite nicht vermeiden lässt, sollte zumindest eine Kontaktmöglichkeit bestehen sowie ein unkritischer Link zurück auf die Applikation. Andernfalls könnte durch z.B. ein erneutes Posten von Daten, das durch Verwenden des Zurück-Buttons entstehen kann, der Fehler nochmals erzeugt werden.

        Entsprechend sind auch geplante Downtimes rechtzeitig anzukündigen und es ist nach Möglichkeit für diese Zeit eine sinnvolle und informierende Ausfallseite zu hinterlegen (statt eines evtl. Fragen hervorrufenden „Service temporarily not available“).