Meldungen erscheinen in GeFa entweder direkt anschließend auf eine Nutzeraktion (synchrone Meldung) oder unabhängig einer Nutzerinteraktion zu einem beliebigen Zeitpunkt (asynchrone Meldungen).

Zwischen folgenden synchronen Meldungen wird unterschieden:

• Seitenfüllende Fehlermeldungen: werden angezeigt, wenn die Inhalte einer ganzen Seite in GeFa nicht angezeigt werden können.
• Erfolgsmeldung “Bestätigungsbanner”: informiert Nutzende nach Rückkehr in eine Datenübersicht (Tabelle/Liste/Baumstruktur/Kalender) über den erfolgreichen Abschluss einer Aktion mit einem Hauptobjekt.
• Formular-Validierungsfehler (inkl. Fehlermeldungsbanner): informiert Nutzende über Fehler, die innerhalb von Formularen anfallen und sich auf genau ein Element beziehen (Validierungsfehler an Formularfeldern) oder durch eine Kombination aus getätigten oder fehlenden Eingaben (formularfeldunabhängige Validierungsfehler) entstehen.
• Sicherheitsabfragen (Modaldialog): erscheinen direkt anschließend auf eine Nutzeraktion, bei welcher besondere Vorsicht geboten ist. Solange eine Sicherheitsabfrage nicht bearbeitet ist, ist eine Bearbeitung der im Hintergrund liegenden Seite nicht möglich.
• Fehlermeldungen (Modaldialog): erscheinen entweder direkt anschließend auf eine Nutzeraktion, die z. B. auf Grund eines Fehlers nicht ordnungsgemäß ausgeführt werden kann oder auch unabhängig von einer Nutzeraktion, wenn es wichtig ist, dass der Nutzer die Meldung sofort wahrnimmt. Solange die Fehlermeldung nicht bearbeitet ist, ist eine Bearbeitung der im Hintergrund liegenden Seite nicht möglich.

Asynchrone Meldungen werden ausschließlich als Meldungskachel im Meldungscenter (Benachrichtigung über das Meldungscenter) dargestellt und beinhalten Erinnerungen und allgemeine Informationen rund um GeFa.

In der folgenden Grafik sind die Ebenen der Meldungstypen dargestellt. Eine Meldung unterer Ebene kann dabei nie eine Meldung höherer Ebene überdecken bzw. darüber angezeigt werden.

• Ebene 0 (Unterste Ebene)
• • Seitenfüllende Fehlermeldungen
• Ebene 1
• • Alle GeFa-Seiten

  • Zusätzlich in Formularen: Formular-Validierungsfehler (feldabhängig und -unabhängig) inkl. Fehlermeldungsbanner; Bestätigungsbanner
• Ebene 2
• • Benachrichtigungen über das Meldungscenter
• Ebene 3
• • Modaldialoge: Sicherheitsabfragen
• Ebene 4 (Oberste Ebene)
• • Modaldialoge: Fehlermeldungen

Da das Nicht-auftreten einer seitenfüllenden Fehlermeldung die Grundvoraussetzung ist, dass eine andere Seite in GeFa inkl. Meldungen angezeigt werden kann, bildet diese Meldung die unterste Meldungsebene. Die oberste Ebene stellt der Modaldialog Fehlermeldung dar. Wenn dieser Meldungstyp angezeigt wird, kann keine weitere Meldung darüber angezeigt werden bzw. diesen überdecken.

Seitenfüllende Fehlermeldungen werden dann angezeigt, wenn die Inhalte einer ganzen Seite in GeFa aus einem der folgenden Gründe nicht angezeigt werden können:

• Fehlende Autorisierung: Anwendungsbeispiel: Nutzende haben einen GeFa-Direktlink im Browser aufgerufen und haben keine Berechtigung zum Aufruf dieser Seite. Dies gilt sowohl für fehlende Tätigkeitsberechtigungen im Backend oder Frontend (werden verwaltet in der BK Benutzerrechteverwaltung) als auch für fehlende Zugriffsberechtigungen (werden über die Zuordnung von Personen zu OE-Besetzungslisten in der GRVW gesetzt).
• Seite existiert nicht. Anwendungsbeispiel: Nutzende haben einen GeFa-Link eingegeben, der nicht bzw. nicht mehr existiert.
• Für den Fall, wenn Anwendende nicht eingeloggt sind, wird keine Seitenfüllende GeFa-Fehlermeldung angezeigt sondern sie werden direkt zur Login-Maske weitergeleitet.
Nach erfolgreichem Anmelden, werden Anwendende direkt auf die initial aufgerufene Seite zurückgeleitet.

Je nach Art des Fehlers können Handlungsanweisungen oder Aktionen angeboten werden (Beispielsweise “Zurück zur Startseite”, wenn Nutzende nicht authorisiert sind oder “Seite neu laden”, wenn ein Serverproblem vorliegt). Bei Meldungstexten sowie Handlungsanweisungen ist zu beachten

• Aus Sicht der Ergonomie & Barrierefreiheit sollte so genau wie möglich der Fehler beschrieben und konkrete Handlungsanweisung zu seiner Behebung gegeben werden.
• Aus Sicht der IT-Sicherheit, sollten keine sicherheitsrelevanten Informationen preisgegeben werden, bspw. keine Anleitung zur Umgehung von Authentifizierungen.

Seitenfüllende Fehlermeldungen enthalten jeweils:

• Diese ist als Layoutgrafik zu deklarieren, da der Inhalt durch den daneben stehenden Text vermittelt wird.

• Kurze Fehlerbeschreibung als Überschrift (H1), z. B. “Sie sind nicht autorisiert”

• Eine mehrzeilige Detailbeschreibung des Fehlers. Diese beschreibt in Fließtext den festgestellten Fehler (Ursache) und was der Nutzer tun kann, um den Fehler zu beheben (soweit mit Datenschutzvorgaben vereinbar)
• Eine Request ID. Diese wird in folgendem Format an den Fehlertext angehängt:„[Detailbeschreibung Fehler] [Umbruch] (Request ID: [ID])“

• Aktionsbutton: Beschreibt in max. 2-3 Wörtern die Aktion, die bevorzugt von Nutzenden auszuführen ist. Auf seitenfüllenden Fehlermeldungen wird maximal nur ein Aktionsbutton angezeigt.
  
  Details zu Verhalten und Bedienung, siehe Komponente seitenfüllende Fehlermeldung.

Wird ein Umsystem, bei dem es sich um eine Desktopanwendung handelt, aus GeFa heraus aufgerufen (z. B. über einen entsprechenden Button im GeFa Hauptmenü oder im Verfahrensheader), dann öffnet sich in einem neuen Browsertab eine seitenfüllende Meldung, welche den Nutzer darüber informiert, dass das entsprechende Umsystem gerade aufgerufen wird. Ein Hinweis informiert außerdem darüber, was Nutzer tun können, falls nichts passiert.

Ein Button ermöglicht den erneuten Aufruf des Umsystems. Nach Ausführen dieses Buttons öffnet sich erneut ein neuer Browsertab mit identischem Inhalt und gleichem Verhalten.

Nachdem sich die Desktopanwendung geöffnet hat, kann der Browsertab von Nutzenden manuell wieder geschlossen werden.

Falls es sich beim aufgerufenen Umsystem um eine Browserapplikation handelt, so erscheint diese Seite nicht und statt dessen wird direkt die URL des jeweiligen Systems aufgerufen.

Grundaufbau der Seite, Formulierungsregeln und Inhalte siehe oben bei Seitenfüllende Fehlermeldungen

Die Erfolgsmeldung in Form eines Bestätigungsbanners informiert Nutzende nach Rückkehr in eine Datenübersicht (Tabelle/Liste/Baumstruktur/Kalender) über den erfolgreichen Abschluss einer Aktion mit einem Hauptobjekt.

Die Meldung beinhaltet:

• Link:
• • Dieser besteht aus: Häkchen-Symbol (Layoutgrafik)
  • Text: “Erfolgreich [Verb, wie z. B. angelegt/zugeordnet/...]: [Bezeichnung des Objekts]” Dabei sollte das Verb die Aktion im abschließenden Button des vorher geöffneten Formulars/Wizards wieder aufgreifen.
• Schließen-Button: Dieser trägt den Alternativtext “Erfolgsmeldung ausblenden”.

Details zur Komponente “Bestätigungsbanner” befinden sich in der Komponentenbeschreibung (siehe Bestätigungsbanner).

Dieser Meldungstyp behandelt Validierungsfehler, die innerhalb von Formularen anfallen. Es gibt zwei Typen:

1. Validierungsfehler an Formularfeldern: Es handelt sich hier um Fehler, die sich auf exakt ein Element im Formular (Eingabe-, Auswahlfeld, Checkboxen, Radiobuttongruppe etc.) beziehen und durch die Korrektur dieses einen Elements behoben werden können. (Beispiel: Pflichtfeld nicht befüllt).
2. Formularfeldunabhängige Validierungsfehler: Es handelt sich hier um Fehler, die nicht an exakt einem Element, sondern aus einer Kombination aus getätigten oder fehlenden Eingaben im Formular entstehen. (Beispiel: Gültigkeitszeitraum eines Unterobjekts liegt nicht im Gültigkeitszeitraum des Elternobjekts).

Für beide Meldungstypen erscheint nach Klick auf die Primäraktion in der Fußzeile des Formulars, wenn Fehler in diesem Formular vorhanden sind, die ensprechende Fehlermeldung (formularfeldabhängig bzw. -unabhängig) im Formular sowie alle Fehler des Formulars als Liste im Fehlermeldungsbanner.

Bei Fehlern direkt am Formularfeld wird des Weiteren unterschieden, wann validiert werden kann:

• Komponente / Feld (Frontend): Wert wird direkt durch die Komponente validiert; Fehler wird direkt bei Wertübernahme unterhalb der Komponente angezeigt. Pflichtfeldvalidierungen ohne Wertänderung werden immer erst nach Ausführen der Primäraktion in der Fußzeile des Formulars durchgeführt.
• Backend: Es werden immer erst alle Frontend-Validierungen durchgeführt. Erst wenn diese Fehler behoben wurden und auf die Primäraktion in der Fußzeile des Formulars geklickt wird, werden alle Backend-Validierungen durchgeführt.
• Details zum Ablauf der Frontend- und Backendvalidierung sowie zum Fehlermeldungsbanner sind im Abschnitt Ablauf Front- und Backendvalidierung (siehe Formular: Verhalten - Ablauf Front-/Backend-Validierung) hinterlegt

Die formularfeldunabhängige Validierung erfolgt als Fronted-Cross- oder Backendvalidierung. Details dazu sind in den Arten der Validierung (siehe Formular: Verhalten - Arten der Validierung) aufgeführt.

Wenn der Fehler nicht durch die in den unten genannten Standard-Meldungen definierten Fehlermeldungen abgedeckt ist, sind die folgenden Formulierungsregeln zu nutzen. Die Formulierungsregeln beziehen sich nur auf die Meldungen an den Formularfeldern bzw. die eigentliche Fehlermeldung für formularfeldunabhängige Fehler. Details zu den Formulierungsregeln des Fehlermeldungsbanners sind in den Formularelementen erläutert (siehe Formular: Verhalten - Fehlerbanner Schema Benennung).

• So kurz & präzise wie möglich (max. 1-2 Sätze)
• Zeichenzahl so gering wie möglich halten (Richtwert sind ca. 60 Zeichen, die bei schmalen Feldern bereits zweizeilig angezeigt werden)
• Genaue Fehlerursache bzw. Schritt zu dessen Behebung müssen deutlich hervorgehen
• Keine Punkte, außer bei mehreren Sätzen; Keine Ausrufezeichen
• Objekt- und Attributsbezeichnungen werden immer in doppelte Anführungszeichen gesetzt: „...”. Ausnahme: Keine Anführungszeichen bei Aufzählungen, wenn bei einem Anstrich nur eine Objekt- oder Attributsbezeichnung genannt ist; Objekttyp, Feldlabel, Gruppenbeschriftungen, Anzahl und Datum, werden ohne „...” genutzt
• Bei Validierungsfehlern an Formularfeldern wird die Feldbezeichnung nicht wiederholt, da sich diese aus dem Kontext erschließt.
• • Do ✅ "Nur numerische Werte erlaubt"
  • Do not ❌ "Telefonnummer darf nur numerische Werte enthalten"
• Kurzform statt ganzer Sätze verwenden. Einleitende Artikel (und ggf. Verb) können weggelassen werde.
• • Do ✅ [Feldbezeichnung] bereits [an Stelle] vorhanden
  • Do not ❌ Die Bezeichnung ist bereits vorhanden
• Keine unnötigen Aufforderungen zur Behebung über den eigentlichen Fehler hinaus verwenden.
• • Do ✅ Falsches Eingabeformat
  • Do not ❌ Falsches Eingabeformat. Bitte korrigieren und erneut speichern.
• Fehlermeldungen, die auf einen bestimmten Wert Bezug nehmen (z. B. “Datum darf nicht vor Erfassungsdatum liegen”), müssen den Bezugswert in der Meldung enthalten, wenn der Bezugswert auf der Seite nicht direkt erkennbar ist, also z. B. “Datum darf nicht vor Erfassungsdatum 22.07.2024 liegen”.
• Bei Formularfeldunabhängigen Validierungsfehlern muss möglichst genau daraus hervorgehen, an welchen Feldern bzw. Gruppen Änderungen vorgenommen werden müssen.
• Der Text im Fehlerbanner "[Aktion (z.B. “Speichern”, “Anlegen”, “Übernehmen” o.ä.] nicht möglich" ist nicht Teil des Meldungstextes (Standardverhalten, welches die Komponente Fehlerbanner mitbringt).

Die folgende Tabelle bietet einen schnellen Überblick über Standardfehlermeldungen für die in GeFa genutzten Feldtypen. Da es sich hier nur um eine Übersicht handelt, sind die Details zum Verhalten in den jeweiligen Konponentenbeschreibungen unbedingt zu beachten.

Dialoge vom Typ Sicherheitsabfrage erscheinen direkt anschließend auf eine Nutzeraktion, bei welcher besondere Vorsicht geboten ist. Nutzende müssen direkt eine Entscheidung für die primäre oder sekundäre Aktion treffen, um fortfahren zu können. Eine gleichzeitige Bearbeitung der im Hintergrund liegenden Seite ist nicht möglich.

Standardsicherheitsabfragen sind zu nutzen, wenn ein Formular (Neuanlage oder Bearbeitungsformular) mit ungespeicherten Eingaben verlassen wird, Hauptobjekte gelöscht, Unterobjekte entfernt werden, beim Verlassen eines Formulars im Wizard mit Frontend-/Crossvalidierungsfehlern über Zurück bzw. Klick auf einen vorherigen Schritt in der Schrittübersicht (falls zu diesem Zeitpunkt bereits Folgeschritte besucht wurden und aktiv sind) und beim Ausloggen aus GeFa. In diesen Fällen sind die hinterlegten Formulierungen für Standardsicherheitsabfragen zu nutzen.

Weitere Fälle könenen fachlich definiert werden. Für diese anderen Fälle gelten die unten gennanten Formulierungsregeln.

Sicherheitsabfragen erscheinen auch dann, wenn z. B.:

durch Änderungen an einem Formularfeld andere bereits befüllte Daten im Formular zurückgesetzt bzw. fehlerhaft werden.

Diese Sicherheitsabfragen sind gemäß den folgenden Regeln zu formulieren.

• Objekt- und Attributsbezeichnungen werden immer in doppelte Anführungszeichen gesetzt: „...”. Ausnahme: Keine Anführungszeichen bei Aufzählungen, wenn bei einem Anstrich nur eine Objekt- oder Attributsbezeichnung genannt ist; Objekttyp, Feldlabel, Gruppenbeschriftungen, Anzahl und Datum, werden ohne „...” genutzt

• Als Frage formulieren, die das Verb aus dem Primäraktionsbutton und das betroffene Objekt bzw. den Kontext beinhaltet z. B.: “„[Objektbezeichnung]” löschen?"
• Die „Objektbezeichnung" soll so kurz wie möglich und eindeutig wie nötig sein. Wenn die tatsächliche Objektbezeichnung nicht eindeutig oder zu lang ist, kann auch der Objekttyp mit einem aussagekräftigen Attribut verwendet werden, z. B.: “„Termin vom 15.05.2024” löschen?” oder “Kommunikationsart „Sonstiges” löschen?””.
• Zu vermeiden:
• • Fragen ohne Kontext, wie z. B. „Sind Sie sicher?”, „Wirklich löschen?”
  • Generische Titel ohne Informationsgehalt, z. B. „Warnung”, „Hinweis”
    Verneinung, wie z. B. „Nicht löschen?”

• Erklärt den Grund des Modals und mögliche Konsequenzen (z. B.: Konsequenzen, die eine Löschung haben wird).
• im Idealfall max. 2-3 Sätze, falls nötig auch Aufzählung möglich,
• Aufzählungen muss ein einleitender Text vorangestellt werden, der den Grund des Modals erläutert.
• Weiterführende Links können optional ergänzt werden. Der Link sollte immer nach dem dazugehörigen Beschreibungstext platziert sein. Wenn eine Meldung also zwei Links enthält, sollte das Muster “Text 1, Link 1, Text 2, Link 2” gelten. Links ohne Beschreibungstext sind nicht zulässig.
• Die Primäraktion wird hinter der Erklärung wiederholt, einleitend mit „Möchten Sie ...”.

• Ergebnis der Aktion („Löschen” oder „Ändern” statt „Weiter”) als Antwort auf die Frage im Titel.
• Verneinungen oder Widersprüche zum Titel „Jetzt abbrechen? > Nein”; „Abbrechen rückgängig > Weiter” vermeiden.
• Wenn möglich als EIN Wort („Löschen”, statt „Einträge löschen”, letzteres stattdessen im Meldungstext I unterbringen).

• Immer „Abbrechen"
• Kein „nicht Löschen", „Nein" etc. verwenden

Dialoge vom Typ Fehler erscheinen entweder direkt anschließend auf eine Nutzeraktion, die z. B. auf Grund eines Fehlers nicht ordnungsgemäß ausgeführt werden kann oder auch unabhängig von einer Nutzeraktion, wenn es wichtig ist, dass der Nutzer die Meldung sofort wahrnimmt.

Dabei kann es sich um technische Fehler (z. B. Server nicht erreichbar) oder fachliche Fehler (z. B. Weglegen eines Verfahrens aufgrund noch nicht erledigter Unterobjekte nicht möglich) handeln.

Falls technisch möglich, muss der Meldungstext bei technischen Fehlern eine Request ID (muss nicht von Fachteams definiert werden) enthalten (Ausnahme kann z. B. reine Frontend-Kommunikation zwischen GeFa und Umsystem in der Rahmenanwendung und Kontexthandler sein), um eine eindeutige Identifizierung des Fehlers zu gewährleisten.

Fehlermeldungen könenn aus unterschiedlichen Gründen ausgelöst werden, die entweder mit den Anwendern oder dem System zusammenhängen. Für die folgenden Fälle sind die Meldungsinhalte (s. Standard-Fehlermeldungen unten) definiert:

• Optimistic Locking: Bearbeiten zwei Personen dasselbe Formular, so werden die Änderungen der Person übernommen, die zuerst speichert.
• Ein Objekt wird von einem anderen Anwender, oder demselben Anwender in einem neuen Tab gelöscht, bevor Änderungen übernommen wurden.
• Versuch des Öffnens eines bereits gelöschten Datensatzes.
• Der Server reagiert nicht.
• Das Umsystem ist nicht erreichbar.

Weitere Fälle können fachlich definiert werden. Für diese anderen Fälle gelten die unten genannten Formulierungsregeln.

• Objekt- und Attributsbezeichnungen werden immer in doppelte Anführungszeichen gesetzt: „...”. Ausnahme: Keine Anführungszeichen bei Aufzählungen, wenn bei einem Anstrich nur eine Objekt- oder Attributsbezeichnung genannt ist; Objekttyp, Feldlabel, Gruppenbeschriftungen, Anzahl und Datum, werden ohne „...” genutzt.
• Die „Objektbezeichnung" soll so kurz wie möglich und eindeutig wie nötig sein. Wenn die tatsächliche Objektbezeichnung nicht eindeutig oder zu lang ist, kann auch der Objekttyp mit einem aussagekräftigen Attribut verwendet werden, z. B.: „Termin vom 15.05.2024” oder “Kommunikationsart „Sonstiges””.

• 2-3 Wörter
• Beschreibt, welche Aktion/Funktionalität vom Fehler betroffen ist
• Keine Satzzeichen

• Erklärt den Grund des Modals und mögliche Schritte zur Behebung des Fehlers.
• Im Idealfall max. 1-2 Sätze, falls nötig auch Aufzählung möglich.
• Aufzählungen muss ein einleitender Text vorangestellt werden, der den Grund des Modals erläutert.
• Weiterführende Links können optional ergänzt werden, wenn beispielsweise zum Beheben des Fehlers das Bearbeiten anderer Objekte (z. B. Verfahren) in GeFa erforderlich ist. Der Link sollte immer nach dem dazugehörigen Beschreibungstext platziert sein. Wenn eine Meldung also zwei Links enthält, sollte das Muster “Text 1, Link 1, Text 2, Link 2” gelten. Links ohne Beschreibungstext sind nicht zulässig.
• Bei technischen Fehlern, wenn möglich, eine Request ID im Format: „[Detailbeschreibung Fehler] [Umbruch] (Request ID: [ID]“) angehängt.

• Beschreibt in max. 2-3 Wörtern die Aktion, die bevorzugt von Nutzenden auszuführen ist.
• „Okay" ist auch möglich, falls nur das Lesen der Meldung bestätigt werden muss.

• Kann z. B. „Abbrechen" sein.
• Kein „Ja", „Nein” etc. verwenden.

Über das Meldungscenter werden Nutzende über Hintergrundaktionen informiert, die, anders als beispielsweise Fehlermeldungen, nicht direkt auf eine Nutzeraktion folgen und somit nicht unbedingt mit Elementen auf der gerade geöffneten Seite zusammenhängen.

Diese Meldungen sind zeitlich nicht kritisch, müssen also nicht sofort gelesen und/oder bearbeitet werden. Beispiele (Beispiele nur exemplarisch: genauer Inhalt ist vom jeweiligen Fachteam zu definieren):

• Monatsstatistik ist am [Datum] fällig.
• Aktueller GVP läuft am [Datum] aus.
• Am [Datum] zwischen 22:00 Uhr und 23:00 Uhr ist ein GeFa-Login wegen Serverarbeiten nicht möglich.

Meldungscenter-Inhalte können von globaler Art sein oder einen Modulkontext besitzen.

Abhängig von der Kategorie der Meldung ist die Hintergrundfläche von Meldungskachel gefärbt:

• Hinweis/Erinnerung = Nachtblau
• Warnung/Fehler = Rot

Details siehe Meldungskachel

Meldungekacheln enthalten immer:

• Ein Wort
• Beschreibt Meldungstyp:
• • Hinweis/Erinnerung = blaue Meldung
  • Warnung/Fehler = rote Meldung 

• Erklärt den Grund der Meldung und eine möglichst konkrete Handlungsanweisung.
• Im Idealfall max. 1-2 Sätze.

• Je nach Art der Meldung - Button: öffnet entweder ein Modal oder eine Modulseite, auf dem die Details des Meldungsgrundes angesehen oder bearbeitet werden können.