INTERACTION

Hinweis- und Rückmeldungen dienen dazu den Nutzer auf laufende, erfolgreich abgeschlossenen oder fehlerhafte Vorgänge hinzuweisen.

Overview

Generelle Richtlinien

Hinweis- und Rückmeldungen dienen dazu den Nutzer auf laufende, erfolgreich abgeschlossenen oder fehlerhafte Vorgänge hinzuweisen. Hinweise- und Rückmeldungen können in verschiedenen Formen erfolgen und sollten an den Anwendungsfall angepasst sein. Im Folgenden wird auf die grundlegenden Prinzipien und Kategorien eingegangen. Einer Übersicht aller zur Verfügung stehenden Komponenten und relevanten Zuständen folgen Entscheidungshilfen zur richtigen Verwendung der Komponente für die unterschiedlichen Anwendungsfälle sowie ein Beispiel, wie man zur "richtigen" Lösung kommt.

Prinzipien

Bei der Anwendung von Hinweis- und Rückmeldungen sollte grundsätzlich auf folgende Prinzipien geachtet werden.

Zeitnah

Hinweise sind nur effektiv, wenn sie zum richtigen Zeitpunkt angezeigt werden. Mit einem verspäteten Hinweis kann der Nutzer nichts anfangen.

Nicht störend

Nicht jede Interaktion benötigt einen Hinweis. Wenn der Nutzer zu oft durch Hinweise unterbrochen wird, führt dies dazu, dass diese störend wirken und der Nutzer beginnt Hinweise zu ignorieren.

Informativ & Prägnant

Hinweise sollten genügend Informationen bereitstellen, damit der Nutzer weiß, was zu tun ist. Jedoch sollten die Hinweise möglichst kurz und prägnant formuliert werden. Ein Hinweis sollte dem Nutzer klare Anweisungen geben um eine schnelle Bearbeitung des Problems bzw. der Aufforderung zu ermöglichen.

Umsetzbar

Um dem Nutzer die Bearbeitung des Hinweises effizient zu ermöglichen, sollte der Hinweis benötigte Funktionen oder relevante Navigations-Abkürzungen zur Verfügung stellen.

Geräteübergreifend

Hinweise sollten dem Nutzer, wenn sinnvoll, auf allen Geräten zur Verfügung stehen. Nach dem Lesen bzw. Bearbeiten der Hinweise müssen diese jedoch auf allen Geräten als solche markiert werden, sodass die Konsistenz gewahrt wird. Wenn der Nutzer beispielsweise über den Laptop und über das Handy auf die Benachrichtigungen zugreift, muss eine Benachrichtigung, nachdem sie vom Nutzer auf dem Handy gelesen wurde, auch am Laptop als gelesen markiert erscheinen. Das System muss die Zustände der Meldungen also synchronisiert halten.

Kategorien

Hinweis und Rückmeldungen lassen sich in vier verschiedene Kategorien aufteilen.

System

Meldungen, die vom System kommen, sind meist kritische Benachrichtigungen, die gut sichtbar dargestellt werden sollten. Der Nutzer hat keinen Einfluss auf das Auftreten einer Systembenachrichtigung.

Beispiel für eine Systembenachrichtigung: "Die Anbindung an die Datenbank wurde unterbrochen".

Engagement

Engagement-Meldungen sind Benachrichtigungen, die vom System oder von einem anderen Nutzer ausgelöst werden und den Nutzer zur Interaktion auffordern. Diese Meldungen sind meist unkritisch und sollten den Nutzer deshalb nicht zu sehr bei der Arbeit unterbrechen.

Beispiel für eine Engagement-Benachrichtigung: "Es wurde seit 50 Tagen kein Backup erstellt. Starten sie jetzt ein neues Backup."

Zugriff

Eine Zugriffsbenachrichtigung kann auftreten, wenn der Nutzer versucht auf ein Element zuzugreifen, für das er keine Rechte besitzt oder wenn ein Element gelöscht wurde. Diese Meldung sollte gut sichtbar dargestellt werden.

Beispiel für eine Zugriffsbenachrichtigung: "Sie haben nicht die nötige Berechtigung um diese Datei zu öffnen."

Feedback

Feedback-Meldungen dienen als Rückmeldung auf eine Interaktion des Nutzers. Sie werden also immer durch den Nutzer ausgelöst. Eine Feedback-Meldung kann nach einer Vielzahl von Interaktionen ausgelöst werden, wie beispielsweise erstellen, lesen, aktualisieren, löschen von Daten, usw.

Beispiel für eine Feedback-Meldung: "Der Datensatz wurde erfolgreich gespeichert."

Komponenten

Es stehen verschiedene UI Komponenten für Hinweis und Rückmeldungen zur Verfügung. Diese unterscheiden sich in ihrem Sichtbarkeitslevel, der Dauer wie lange diese angezeigt werden sowie ob diese statisch oder dynamisch sind. Diese Unterschiede ermöglichen einen gezielten Einsatz für jeden Anwendungsfall.

Beispiele

Modal Dialog

Der  Modal Dialog  unterbricht den Arbeitsablauf des Nutzers und sollte daher nur spärlich verwendet werden. Ausführliche Empfehlungen zur Verwendung des Modal Dialogs sind im Kapitel Modale Dialoge (Modal Dialog) aufgeführt.

Toasts

Die sogenannten Toasts sind Hinweise, die für eine bestimmte Zeit erscheinen und danach wieder verschwinden. Sie werden eingesetzt, nachdem eine Aktion durch den Nutzer ausgelöst wurde (z.B. wenn etwas erfolgreich gespeichert wurde).

Notification Bar (Alert)

Bei sehr wichtigen System Hinweis- oder Rückmeldungen, wird die Notification bar verwendet. Solche Meldungen beziehen sich auf das ganze System und nicht auf einzelne Seiten und sollten daher immer sichtbar sein.

Notificatons

Benachrichtigungen können für eine Vielzahl von Rückmeldungen eingesetzt werden. Sie können Shortcuts oder Links zu weiterführenden Informationen enthalten. Ein Vorteil der Benachrichtigungen ist, dass der Nutzer sie wiederfinden kann, auch wenn sie bereits gelesen wurden und dass sie asynchron erfolgen, das heißt der Nutzer muss eine Benachrichtigung nicht sofort lesen, wenn sie auftritt.

Zustände

Rückmeldungen können verschiedene Zustände haben. Die Darstellung der Rückmeldung sollte den Zustand widerspiegeln, indem z.B. die Farben und Formulierung der Rückmeldung entsprechend gewählt werden.

Fehler (Error)

Fehlerhafte Zustände können in unterschiedlichen Szenarien auftreten:

• Ein Nutzer schickt ein Formular ab das Fehler in einem oder mehreren Feldern beinhaltet.
• Ein Nutzer schließt eine Aktion wie z.B. einen Verbindungstest, Dokumente signiert oder das Speichern eines Objekts ab, aber diese ist durch systembedingte Probleme unvollständig oder nicht wirklich erfolgreich.
• Ein systembedingter Fehler betrifft die gesamte Session vom aktuellen Nutzer.
• Ein systembedingter Fehler tritt zufällig auf.
• Eine Seite ist nicht erreichbar, weil diese nicht mehr gefunden werden kann oder die Berechtigungen vom angemeldeten Nutzer nicht ausreichen.
• Ein Nutzer hat einen langwierigeren Prozess wie z.B. einen Daten Import ausgelöst und dieser weißt Fehler auf.

Jedes oben genannte Szenario stellt fehlerhafte Rückmeldungen etwas unterschiedlich dar. Es folgen einige weitere Leitlinien wofür welche Komponente zu verwenden ist:

Formular Fehler

Wenn ein Nutzer ein Formular abschickt das einen oder mehrere Fehler beinhaltet, dann verwende Inline Text unter dem jeweiligen Feld oder in Form vom Errors-On-Top Muster.

Unvollständige Aktion Fehler

Wenn ein Nutzer eine Aktion abschließt, diese aber systembedingt nicht wirklich abgeschlossen wurde, dann verwende ein Toast im Fehler Zustand.

Diese Art von Fehlern sollte im System nur sehr selten auftreten und nicht zum typischen Nutzungserlebnis gehören.

System Fehler (Aktuelle Session)

Wenn ein systembedingter Fehler der die gesamte Session vom Nutzer betrifft auftritt, dann verwenden ein Alert solange der Nutzer das System nutzt.

System Fehler (Zufällig)

Wenn ein systembedingter Fehler zufällig auftritt, dann verwende ein Modal Dialog.

Seite nicht verfügbar

Wenn der Nutzer eine Seite aufrufen will, die nicht erreichbar ist, dann verwende eine Seite mit Inline Text.

Prozess Fehler

Wenn der Nutzer einen länger laufenden Prozess startet und dieser hinterher Fehler aufweist, dann verwende eine Benachrichtigung.

Warnung (Warning)

Warnungen sind nicht so schwerwiegend wie Fehler und erfordern keine sofortige Aufmerksamkeit des Nutzers. Der Nutzer kann entweder normal oder eingeschränkt weiterarbeiten, wenn eine Warnung auftritt.

Beispiel: Der Drucker ist nicht angeschlossen. Der Nutzer benötigt für seine aktuelle Arbeit keinen Drucker. Es wird jedoch eine Warnung angezeigt, um den Nutzer davor zu warnen, dass kein Drucken möglich ist.

Information

Informationshinweise dienen lediglich zur Information des Nutzers. Sie dienen hauptsächlich als Hilfestellung.

Beispiel: Hinweis darauf, in welchem Format das Datum eingegeben werden muss.

Erfolg (Success)

Eine Erfolgsmeldung gibt dem Nutzer Sicherheit, indem sie auf einen erfolgreich abgeschlossenen Vorgang hinweist. Eine solche Meldung ist vor allem dann notwendig, wenn der Nutzer einen für seine Arbeit wichtigen Vorgang abschließt. Erfolgsmeldungen müssen nicht dauerhaft sichtbar sein. Sie können für einen bestimmten Zeitraum eingeblendet werden und dann wieder verschwinden.

Beispiel: Nach dem Anlegen eines neuen Datensatzes, bei dem der Nutzer viele Daten in ein Formular eingegeben hat, wird eine Meldung angezeigt, dass der Datensatz erfolgreich gespeichert wurde.

Leer (Emtpy)

Ein leerer Zustand dient als Platzhalter für Elemente, die gerade nicht sichtbar sind.

Beispiel: Die Seite braucht einige Zeit um Inhalte zu laden. Anstelle der echten Inhalte werden leere Platzhalter angezeigt, die dem Nutzer zeigen, wo sich Elemente befinden werden.

Offline Indikator

Der Offline Indikator informiert den Nutzer klar und sichtbar darüber, dass aktuell keine Verbindung zum Internet oder Intranet besteht. Die Meldung sollte sofort und dauerhaft sichtbar sein, sobald keine Netzverbindung erkannt wird – idealerweise als Banner im oberen Bereich der Anwendung. Vaadin Flow und Hilla bieten integrierte Mechanismen zur Anzeige des Verbindungsstatus. Die Umsetzung unterscheidet sich leicht je nach Framework in Verhalten und Styling – orientiere dich daher an den jeweiligen Komponentenrichtlinien.

Vorübergehend (Transient)

Vorübergehende Zustandsanzeigen, verdeutlichen dem Nutzer, dass im Hintergrund ein Vorgang durchgeführt wird. Diese Zustandsanzeigen geben dem Nutzer Sicherheit, dass ein Vorgang läuft und informieren ihn optional darüber, wie lange der Vorgang noch dauern wird.

Beispiel: Beim Kopieren von Dateien wird eine vorübergehende Fortschrittsanzeige eingeblendet, die zeigt, wie viele Dateien bereits kopiert wurden und wie viele noch zu kopieren sind.

Verwendung

Entscheidungstabelle

Folgende Tabelle dient als Entscheidungshilfe bei der Auswahl der richtigen Komponente für die jeweiligen Kategorie.

Kategorie	Inline Text	Benachrichtigungen	Toast	Notification bar	Inline Text & Grafik	Modaler Dialog
System	✅	✅		✅	✅	✅
Engagement	✅	✅			✅
Zugriff	✅				✅
Feedback	✅		✅			✅

Beispiel zur Verwendung

Angenommen eine Sachbearbeiterin hat ein Dokument vom Finanzamt bekommen und muss daraufhin die Gewerbesteuern für ein Unternehmen anpassen. Sie öffnet eine AKDB Anwendung und passt die Daten an, damit ein neuer Bescheid erstellt werden kann.

Welche Hinweis- oder Rückmeldung sollte die Anwendung nach dem erfolgreichen speichern der Sachbearbeiterin anzeigen?

1. Bestimme die Hinweis- und Rückmeldungskategorie anhand der folgenden Darstellung:
   

• Nachdem die Situation vom Nutzer initiiert wird, kommen die Kategorien Access oder Feedback in Frage.
• Der Zugriff auf die Daten ist möglich, somit bleibt nur noch eine Option übrig:
• Hinweis- und Rückmeldekategorie: Feedback

2. Bestimme die möglichen Komponenten mit Hilfe der Entscheidungstabelle

• Inline Text: Wird verwendet um leere oder unzugängliche Zustände in Komponenten, Feldbezogene Validierungsmeldungen in Formularen oder vorübergehende Zustände wie Laden..., Speichern... anzuzeigen. Wir brauchen hier etwas deutlicheres um die Erfolgsmeldung zu kommunizieren.
• Toast: Dienen als Rückmeldungsmechanismus für Aktionen die vom Nutzer ausgehen, insbesondere im Zusammenhang mit Aktionen zum Erstellen/Bearbeiten/Löschen.
• Modal Dialog: Werden verwendet um weitreichende Aktionen ein weiteres mal vom Nutzer bestätigen zu lassen, damit diese nicht versehentlich ausgelöst werden. In unserem Bespiel ist die Aktion natürlich bewusst durch den Nutzer initiiert worden.
• Komponente: Toast

3. Zustand der Meldung bestimmen

• In unserem Beispiel wurden die Daten erfolgreich gespeichert
• Zustand: Erfolg

Somit stellt das  Toast im Erfolgszustand die richtige Komponente in unserem Beispiel dar.

Changelog

v2.0.0

• Release der Grundlagen zu Hinweis- und Rückmeldungen.