Gutes Error Handling beginnt idealerweise damit, Fehler gar nicht erst entstehen zu lassen. Klare UI Strukturen, verständliche Beschriftungen und sinnvolle Defaults helfen dabei, Fehlbedienungen zu vermeiden. Da sich Fehler jedoch nie vollständig verhindern lassen, ist ein solides Error Handling entscheidend.
Best Practices
- Fehlervermeidung: Gestalte Oberflächen so, dass Fehler möglichst gar nicht erst entstehen.
- Einfach formulieren: Verwende klare, alltagstaugliche Sprache ohne Fachbegriffe (siehe Fehlermeldung).
- Handlung ermöglichen: Zeige dem User, wie er den Fehler beheben oder weitermachen kann.
Fehler beim Laden von Inhalten
Beim Laden von Inhalten können Fehler auftreten, zum Beispiel wenn ein Service nicht erreichbar ist, ein Timeout entsteht oder ein technischer Fehler vorliegt. In diesen Fällen sollte der Ladezustand beendet werden, damit User sehen, dass ein Fehler eingetreten ist und sie nicht weiter warten müssen.
Die Fehlermeldung sollte immer dort erscheinen, wo der erwartete Inhalt wäre. Für größere Bereiche wie LayoutCards oder Sections eignet sich eine IllustratedMessage mit dem Status Danger. Sie signalisiert deutlich, dass der Inhalt aktuell nicht verfügbar ist, und bietet idealerweise eine Handlung an, zum Beispiel einen Button mit der Beschriftung "Erneut laden".
Mein Projekt
Für kleinere, abgegrenzte UI Elemente wie Tabellen- oder Listenzeilen sollte ein AlertText verwendet werden. So bleibt der Kontext erhalten und der Fehler wirkt sich nicht auf die ganze Table oder List aus.
Domains
Um Errors auf kleine Bereiche zu begrenzen, nutzen wir im mStudio Loading und Error Boundaries. Diese kapseln technische Fehler ab und sorgen für konsistentes Feedback. Details dazu sind in der Guideline zu Boundaries (Internal) beschrieben.
Fehler beim Durchführen von Aktionen
Fehler durch ungültige Eingaben
Ungültige Eingaben treten häufig in Forms auf, zum Beispiel bei fehlenden Pflichtfeldern oder falsch formatierten Werten. In diesen Fällen sollte das Feedback direkt am Form Control erfolgen. User müssen sofort erkennen können, was angepasst werden muss, ohne die Seite oder den Kontext zu verlassen. Weitere Details dazu sind unter Forms (Validation) beschrieben.
Fehler bei serverseitigen Aktionen
Aktionen, die einen Request an das Backend senden, können aus unterschiedlichen Gründen fehlschlagen. Dazu zählen technische Fehler im System, Probleme bei der Kommunikation mit dem Backend oder fehlende Berechtigungen.
Wenn eine Aktion fehlschlägt, sollte dies deutlich kommuniziert werden. Dafür eignet sich ein Modal mit einer IllustratedMessage im Status Danger. Diese informiert darüber, dass die Aktion nicht durchgeführt werden konnte, und erklärt kurz den Grund, sofern dieser für den User relevant ist. Zusätzlich sollte immer ein Ausweg angeboten werden, zum Beispiel die Aktion erneut auszuführen.
Projekte
Für Aktionen, die über einen längeren Zeitraum laufen und zunächst erfolgreich an das Backend übermittelt werden, aber erst später fehlschlagen, eignen sich besser Notifications. Ein typisches Beispiel ist das Registrieren einer Domain. Weitere Details dazu sind im Informationskonzept beschrieben.