Baustein Bedienkonzept
Diese Seite ist ein Teil der IsyFact-Standards.
Alle Inhalte der Seite, insbesondere Texte und Grafiken, sind urheberrechtlich geschützt.
Alle urheberrechtlichen Nutzungs- und Verwertungsrechte liegen beim Bundesverwaltungsamt.
Die Nutzung ist unter den Lizenzbedingungen der Creative Commons Namensnennung 4.0 International gestattet.
1. Einführung
Das vorliegende Bedienkonzept ist nicht nur ein Dokument mit Gestaltungsrichtlinien für Frontends, sondern ein umfassendes Werkzeug, das die Grundlage für die Entwicklung einer konsistenten und benutzerfreundlichen Benutzeroberfläche schafft. Indem es einheitliche Standards und Best Practices festlegt, trägt es maßgeblich zur Erreichung von Zielen wie der Steigerung der Benutzerzufriedenheit, der Verbesserung der Effizienz oder der Stärkung der Markenidentität bei.
Das Hauptziel ist dabei, die Benutzererfahrung zu verbessern und die Zufriedenheit und Produktivität der Nutzenden zu maximieren. So soll sichergestellt werden, dass Nutzende das Frontend ohne Schwierigkeiten verwenden können und dabei ihre Ziele effizient erreichen.
In den folgenden Kapiteln werden die benötigten Elemente von "klein nach groß" beschrieben. Der allgemeine Rahmen und die übergreifenden Prinzipien werden in den ersten Kapiteln beschrieben. Darauf folgen die Basiselemente (wie zum Beispiel Text und Farben), die den Grundstein für die nachfolgenden Kapitel legen und von essenzieller Bedeutung sind. Danach kommen die Bedienelemente, die einfachste Ausprägung eines Interaktionselements. Design Pattern stellen eine Bündelung von Bedienelementen und Basiselementen dar und können letztendlich in beliebiger Kombination als vollständige Use Cases beschrieben werden.
Eine Live-Demo zu den Richtlinien dieses Bedienkonzepts finden Sie unter: https://isyfact.github.io/isy-angular-widgets/
1.1. Einführung in das Bedienkonzept
Gültigkeit und Anwendung
Dieses Konzept ist für jedes Frontend relevant, unabhängig von dessen Komplexität oder Zielgruppe. Es ist gültig für alle Neuentwicklungen und für Überarbeitungen von Frontends, die einem Major Change oder Technologiewechsel unterliegen. Ausgeschlossen sind minimale Bugfixes und die grundsätzliche Wartung von Altanwendungen.
Das Bedienkonzept ist gültig ab Q4 – 2024. Für Altanwendungen gilt, dass das Bedienkonzept (beziehungsweise ehemals Styleguide) zum Zeitpunkt der Entwicklung der Altanwendung mit den damals geltenden Inhalten gültig bleibt.
Rolle von Designenden, Entwickelnden und Fachlichkeit
Designende und Entwickelnde spielen eine entscheidende Rolle bei der Umsetzung des Bedienkonzepts. Während Designende für die Gestaltung der Benutzeroberfläche verantwortlich sind und sicherstellen, dass sie den festgelegten Standards entspricht, liegt es in der Verantwortung der Entwickelnden, diese Gestaltung in einem funktionierenden Frontend umzusetzen. Eine enge Zusammenarbeit zwischen Design- und Entwicklungsteams ist unerlässlich, um sicherzustellen, dass das Endprodukt den gestalterischen und funktionalen Anforderungen entspricht. Insbesondere bei komplexen Frontends ist es ratsam so früh wie möglich die Fachlichkeit hinzuzuziehen und den erarbeiteten Stand der Konzeption zu evaluieren.
Einhaltung von Standards und Best Practices
Das Bedienkonzept legt Standards und Best Practices fest, die von Designenden und Entwickelnden eingehalten werden müssen. Diese Standards können sich auf verschiedene Aspekte der Gestaltung und Interaktion beziehen, wie Typografie, Farbgebung, Bedienelemente und Barrierefreiheit. Durch die Einhaltung dieser Standards gewährleisten Designende und Entwickelnde nicht nur eine konsistente Benutzeroberfläche, sondern auch die Kompatibilität dieser Oberfläche mit verschiedenen Geräten und Plattformen.
Genau wie jedes digitale Frontend wird auch dieses Bedienkonzept ständig weiterentwickelt. Die Entwicklungen und Änderungen werden entsprechend dem Stand der Technik und der rechtlichen Gegebenheiten aktualisiert und gekennzeichnet.
Technische Kompatibilität
Wenn Frontends anhand dieses Bedienkonzepts erstellt werden, müssen die korrekte Darstellung und Funktionsweisen des Frontends inklusive ihrer Browser-Funktionen, wie beispielsweise "Vor" und "Zurück", geprüft werden. Dafür muss für jedes Projekt der primäre Browser und dessen Versionen ermittelt und geprüft werden.
In der Regel soll sichergestellt sein, dass folgende Browser unterstützt werden:
| Browser | Neuste Version aus Channel |
|---|---|
Microsoft Edge |
Stable Channel |
Firefox |
ESR |
Chrome |
Stable Channel |
Soweit notwendig wird auf browserspezifische Eigenheiten eingegangen. Dabei sind folgende Auflösungen zu berücksichtigen:
-
2K: 2560 x 1440
-
Full HD: 1920 x 1080
-
Tablet: 1536 x 864
-
Smartphone: 390 x 873
Kontinuierliche Weiterentwicklung und Pflege
Ein Bedienkonzept ist kein statisches Dokument, sondern sollte kontinuierlich weiterentwickelt und gepflegt werden. Mit dem Fortschreiten der Technologie und den sich ändernden Anforderungen der Nutzenden ist es wichtig, das Bedienkonzept regelmäßig zu überprüfen und anzupassen. Dadurch wird sichergestellt, dass das Bedienkonzept stets den aktuellen Standards und Best Practices entspricht. Diese kontinuierliche Weiterentwicklung erfordert eine enge Zusammenarbeit zwischen allen Beteiligten und eine offene Kommunikation über Änderungen und Aktualisierungen – insbesondere zwischen Umsetzungsprojekten, Stakeholdern und den Designenden, die mit diesem Dokument arbeiten.
1.2. Usability (UI) und Benutzerfreundlichkeit (UX)
Obwohl die Begriffe oft synonym verwendet werden, gibt es wichtige Unterschiede und Zusammenhänge, die sie voneinander unterscheiden und gleichzeitig miteinander verbinden.
Begriff der Usability (User Interface - UI)
Usability oder Gebrauchstauglichkeit bezieht sich auf die Benutzerfreundlichkeit einer Oberfläche (UI). Dabei geht es darum, wie leicht Nutzende ein Frontend verstehen und die Bedienung erlernen können. Zu den Hauptkomponenten der Usability gehören:
-
Effektivität: Die Fähigkeit eines Frontends, den Nutzenden die Möglichkeit zu geben, ihre Ziele zu erreichen.
-
Effizienz: Die Fähigkeit eines Frontends den Nutzenden zu ermöglichen, ihre Ziele mit möglichst geringem Zeit- und Arbeitsaufwand zu erreichen.
-
Zufriedenheit: Das Maß an Komfort und positiver Erfahrung der Benutzenden bei der Nutzung des Frontends.
Usability ist eng mit dem Design der Benutzeroberfläche verknüpft. Eine gut gestaltete UI ermöglicht es den Benutzenden, intuitiv zu navigieren, schnell zu verstehen, wie sie Aufgaben ausführen können und bietet klare, konsistente visuelle Hinweise. Besonders bei komplexen Fachanwendungen ist es wichtig, dass eine gute UI sich nahtlos in die fachlich notwendigen Geschäftsprozesse integrieren lässt.
Begriff der Benutzerfreundlichkeit (User Experience - UX)
Benutzerfreundlichkeit oder User Experience (UX) geht über die reine Usability hinaus und bezieht sich auf das gesamte Erlebnis der Nutzenden mit einem Produkt oder einer Dienstleistung. UX umfasst alle Aspekte der Interaktion, einschließlich der emotionalen, psychologischen und praktischen Reaktionen auf das Produkt.
Hauptkomponenten der UX sind:
-
Nützlichkeit: Ob das Produkt den Bedürfnissen und Anforderungen der Benutzenden entspricht.
-
Verfügbarkeit: Die Zugänglichkeit und Erreichbarkeit des Produkts für verschiedene Gruppen.
-
Glaubwürdigkeit: Das Vertrauen der Benutzenden in das Produkt und die Marke.
-
Wert: Die Wahrnehmung des Nutzens und der Wertschöpfung durch das Produkt.
UX berücksichtigt nicht nur die Interaktion mit der Benutzeroberfläche, sondern auch die gesamte Benutzerreise von der ersten Wahrnehmung des Produkts bis zur fortlaufenden Nutzung und Unterstützung.
Zusammenhänge zwischen Usability (UI) und Benutzerfreundlichkeit (UX)
Usability ist ein integraler Bestandteil der Benutzerfreundlichkeit. Ein benutzerfreundliches Frontend muss eine hohe Usability aufweisen, da die Benutzeroberfläche der primäre Kontaktpunkt zwischen den Benutzenden und dem Frontend ist. Gute Usability sorgt für:
-
Reibungslose und intuitive Interaktion: Benutzende können problemlos navigieren und ihre Ziele erreichen, was zu einer positiven UX beiträgt.
-
Effizienz: Benutzende brauchen weniger Zeit und Mühe, um Aufgaben zu erledigen, was ihre Zufriedenheit erhöht und die Gesamt-UX verbessert.
Unterschiede zwischen Usability (UI) und Benutzerfreundlichkeit (UX)
Trotz ihrer engen Verbindung gibt es klare Unterschiede zwischen UI und UX:
-
Fokusbereich: Usability konzentriert sich auf die Effizienz und Effektivität der Benutzeroberfläche, während UX das gesamte Erlebnis der Nutzenden mit dem Produkt betrachtet.
-
Umfang: Usability befasst sich hauptsächlich mit den funktionalen Aspekten der Interaktion wie Navigation und Bedienbarkeit, während UX auch emotionale und psychologische Faktoren einbezieht wie Freude und Zufriedenheit.
-
Messbarkeit: Usability kann durch spezifische Metriken wie Fehlerquote, Zeitaufwand und Benutzerzufriedenheit gemessen werden. UX erfordert jedoch eine umfassendere Bewertung, die qualitative und quantitative Methoden kombiniert, um das gesamte Benutzererlebnis zu verstehen.
Grundlegende Dos, die die Benutzerfreundlichkeit einer Benutzeroberfläche in Frontends erhöhen:
-
Klare Anweisungen und Fehlermeldungen: Nutzende sollten stets verstehen, was von ihnen erwartet wird. Klare Anweisungen und verständliche Fehlermeldungen helfen dabei, Frustration zu vermeiden und den Nutzenden durch den Prozess zu führen.
-
Validierung von Eingaben: Eingabefelder sollten in Echtzeit validiert werden, um Nutzende vor Fehlern zu warnen, bevor sie das Formular absenden. Dadurch wird vermieden, dass Nutzende nach dem Absenden des Formulars feststellen, dass sie fehlerhafte oder unvollständige Informationen eingegeben haben.
-
Progressive Offenbarung von Informationen: Die Benutzeroberfläche sollte nicht mit zu vielen Informationen auf einmal überladen werden. Informationen sollten kontextbezogen und schrittweise offenbart werden, um Nutzende nicht zu überfordern.
-
Testen mit verschiedenen Nutzungsgruppen: Um sicherzustellen, dass die Oberfläche für eine breite Palette von Nutzenden zugänglich ist, ist es wichtig, Tests mit verschiedenen Personengruppen durchzuführen. Dabei sollten Nutzende mit unterschiedlichen Fähigkeiten, Geräten und technischen Kenntnissen berücksichtigt werden.
Weitere Informationen zu einer besseren Benutzerfreundlichkeit sind in den Abschnitten zu den Basiselementen, Bedienelementen, Design Pattern, Use Cases oder Eingabehilfen und Fehlermeldungen zu finden (siehe jeweils bei den Unterkapiteln "Dos" und "Don’ts").
1.3. Allgemeine Prinzipien
Das Bedienkonzept basiert auf einer Reihe von allgemeinen Prinzipien, die als Leitfaden für die Gestaltung von Benutzeroberflächen dienen. Diese Prinzipien umfassen Klarheit, Konsistenz, Feedback, Effizienz und Zugänglichkeit und bilden das Fundament für eine benutzerzentrierte Gestaltung. Viele dieser Prinzipien werden beispielsweise in der ISO 9241 und in Nielsen’s Web Usability Criteria beschrieben. Zusätzlich liefert lawsofux eine anschauliche Sammlung von Designprinzipien.
Klarheit
In Bezug auf das Design bezieht sich das Prinzip der "Klarheit" darauf, wie verständlich und einfach der Aufbau und die Navigation des Frontends gestaltet sind. Klarheit bedeutet, dass Informationen klar präsentiert werden, sodass Besuchende sofort verstehen, was das Frontend bietet und wie sie es nutzen können. Dies umfasst eine klare Strukturierung von Inhalten, eine leicht lesbare Typografie, gut platzierte Navigationselemente und eine konsistente visuelle Gestaltung. Durch die Priorisierung von Klarheit im Design können Designende sicherstellen, dass Nutzende sich leicht auf dem Frontend zurechtfinden und ihre Ziele effizient erreichen können.
Konsistenz
Das Prinzip der "Konsistenz" bezieht sich auf die Notwendigkeit, ein einheitliches Erscheinungsbild und Verhalten über alle Seiten eines Frontends hinweg zu gewährleisten. Konsistenz bedeutet, dass Designelemente wie Farben, Schriftarten, Symbole und Layouts einheitlich angewendet werden, um eine nahtlose Benutzererfahrung zu schaffen. Durch die Aufrechterhaltung einer konsistenten Gestaltung können Nutzende das Frontend leichter verstehen und navigieren, da sie sich auf bereits bekannte Muster und Interaktionen verlassen können. Darüber hinaus trägt die Konsistenz dazu bei, das Markenimage zu stärken und das Vertrauen der Nutzenden in das Frontend zu fördern.
Feedback
Das Designprinzip des "Feedbacks" bezieht sich auf die kontinuierliche Kommunikation zwischen dem Frontend und den Nutzenden. Feedback ist entscheidend, um den Nutzenden Rückmeldungen darüber zu geben, ob ihre Aktionen erfolgreich waren oder nicht. Dies kann in Form von visuellem Feedback, zum Beispiel einer Farbänderung eines Buttons nach einem Klick oder durch informative Nachrichten wie Bestätigungsmeldungen nach dem Absenden eines Formulars, erfolgen. Durch effektives Feedback fühlen sich Nutzende unterstützt und informiert, was zu einer verbesserten Benutzererfahrung und einer höheren Zufriedenheit führt. Dies gilt insbesondere auch für Aspekte der Barrierefreiheit. Technische Standardmöglichkeiten sollen genutzt und gegebenenfalls mit entsprechenden Hilfsmitteln (wie ARIA-Elementen) angereichert werden.
Effizienz
Das Designprinzip der "Effizienz" bezieht sich darauf, wie gut ein Frontend die Bedürfnisse und Ziele der Nutzenden mit minimalen Aufwänden erfüllt. Effizientes Design strebt danach, unnötige Komplexität zu vermeiden und die Interaktionen der Nutzenden so reibungslos wie möglich zu gestalten. Dies umfasst Aspekte wie schnelle Ladezeiten, intuitive Navigation, gut platzierte Call-to-Actions und eine klare Informationsarchitektur. Ein effizientes Design stellt sicher, dass Nutzende ihre Ziele schnell erreichen können, ohne dabei Zeit oder Mühe zu verschwenden – sei es beim Finden von Informationen, beim Abschließen eines Kaufs oder beim Ausführen einer bestimmten Aktion.
Zugänglichkeit
Das Designprinzip der "Zugänglichkeit" soll sicherstellen, dass ein Frontend für alle Nutzenden, unabhängig von ihren individuellen Fähigkeiten oder Einschränkungen, leicht zugänglich ist. Dies beinhaltet die Gestaltung und Entwicklung des Frontends unter Berücksichtigung verschiedener Bedürfnisse, zum Beispiel Sehbehinderungen, Hörbehinderungen oder motorische Einschränkungen. Zugängliches Design beinhaltet die Verwendung von verständlichen Texten, von ausreichendem Kontrast zwischen Text und Hintergrund, von Tastaturzugänglichkeit und von alternativen Texten für Bilder, sowie die Vermeidung von Technologien (zum Beispiel Gestensteuerung), die für einige Personengruppen hinderlich sein könnten. Ein zugängliches Design gewährleistet, dass alle Nutzenden die Informationen und Funktionen des Frontends nutzen können, was zu einer inklusiven und positiven Benutzererfahrung führt. Dieses Prinzip wird im Kapitel Barrierefreiheit und unter den einzelnen Bedienelementen detaillierter beschrieben.
2. Barrierefreiheit
Barrierefreiheit setzt das Prinzip der Zugänglichkeit um. Das heißt durch Barrierefreiheit soll sichergestellt werden, dass alle, unabhängig von ihren Fähigkeiten, ein Frontend nutzen können. Im Folgenden werden die Richtlinien zur Barrierefreiheit gemäß Standards wie WCAG und Methoden zur Verbesserung der Zugänglichkeit erläutert.
Für dieses Bedienkonzept gilt, dass die Zugänglichkeitsstandards WCAG 2.1 und EN 305419 berücksichtigt werden müssen:
-
Alle Seiten sollten mindestens das Level AA oder höher erreichen.
-
Für Haupt- & Einstiegsseiten und Seiten mit rechtlicher Relevanz sollte das Level AAA berücksichtigt werden.
Die detaillierten Anforderungen sind zu finden unter:
Vor der Auflistung der einzelnen Kriterien sind im Kontext der IsyFact einige Kriterien der Barrierefreiheit besonders herauszustellen und bereits bei der fachlichen Konzeption zu berücksichtigen. In der Regel sind die genannten Anforderungen durch die Nutzung der Standardelemente der IsyFact erfüllt oder es wird die Möglichkeit geboten, zum Beispiel durch das Theme, diese in einem Frontend umzusetzen. Alle hier genannten Maßnahmen sind besonders hervorzuheben und unabdinglich für ein barrierefreies Frontend.
Dos
-
Eingabefelder müssen nach der Aktivierung eines Hochkontrastmodus/Farbfilters zu 50 % bestehen bleiben – eine einzelne Linie als Bestandteil ist nicht ausreichend als Identifizierung eines Eingabefeldes.
-
Die Textgröße soll zum Erreichen der AA-Kriterien mindestens 14pt für Labels und 12pt für Fließtexte betragen.
-
Der Textkontrast muss immer mindestens 4,5:1 und bei großer Schrift mindestens 3:1 betragen. Für Haupt- und Einstiegsseiten sowie Seiten mit rechtlicher Relevanz muss der Kontrast 7:1 betragen.
-
Alle Bilder benötigen ein inhaltlich sinnvolles, beschreibendes Alt-Attribut.
-
Bilder, die ausschließlich der Gestaltung dienen (zum Beispiel Trennlinien), müssen als solche (Schmuckgrafik) gekennzeichnet werden.
-
Tastatur-Navigation: Nicht alle Nutzenden können eine Maus verwenden. Daher ist es wichtig, dass alle Interaktionen auf dem Frontend auch über die Tastatur möglich sind. Dies bedeutet, dass alle Navigationselemente, Links und interaktiven Elemente leicht per Tastatur zugänglich sein müssen.
Don’ts
-
Es sollten keine Schriftgrafiken genutzt werden.
-
Schwache Kontraste, zum Beispiel Hellblau auf Grau, sollen vermieden werden.
-
Vermeidung von reinen Farbunterscheidungen: Informationen sollten nicht allein durch Farbe vermittelt werden, da einige Nutzende Farben nicht unterscheiden können. Daher sollten auch andere visuelle Elemente, wie Symbole oder Muster genutzt werden, um wichtige Informationen zu vermitteln.
-
Aktionen sollen nicht durch Bedienelemente ausgelöst werden, wenn diese nicht dazu vorgesehen sind (zum Beispiel Radiobutton und Checkboxen).
2.1. Barrierefreier Einsatz von Farben
Farben sind ein Hauptbestandteil, um Frontends zu gestalten und um die Nutzenden zu unterstützen. Um eine gute Erkennbarkeit der Elemente sicherzustellen, muss bei großer Schrift ein Kontrast von mindestens 3:1 gewährleistet sein.
Nachfolgend sind die Kontrastverhältnisse aller zur Verfügung stehenden Farben abgebildet. Farbkombinationen, die rot gelabelt sind und keinen ausreichenden Kontrast aufweisen, dürfen nicht verwendet werden. Andere Farbkombinationen sind entsprechend ihrer Textart oder Elementgröße frei zu wählen - Fließtext & Label 4,5:1, Überschrift 3:1, Haupt-/Einstiegsseiten & Seiten mit rechtlicher Relevanz 7:1. Dabei soll der Kontrast so hoch wie möglich gewählt werden.
Eine interaktive und erweiterbare Tabelle ist unter Farbmatrix zu finden.
Die folgenden Links verweisen auf weitere Informationen zur Kontrast-Analyse:
2.2. Alt-Attribute für Bilder
Alt-Attribute (alternative Texte) sind textuelle Beschreibungen, die in den HTML-Code von Bildern eingebettet werden. Sie dienen mehreren wichtigen Zwecken:
-
Zugänglichkeit: Screenreader verwenden Alt-Attribute, um sehbehinderten oder blinden Nutzenden den Inhalt und Zweck eines Bildes zu vermitteln.
-
Fehlertoleranz: Wenn ein Bild aus irgendeinem Grund nicht geladen werden kann, zeigt der Browser den Alt-Text anstelle des Bildes an.
Best Practices für das Schreiben von Alt-Attributen
Beim Erstellen von Alt-Texten sollten folgende Richtlinien beachtet werden:
-
Beschreibend und prägnant: Der Alt-Text sollte den Inhalt und Zweck des Bildes kurz und genau beschreiben. Beispiel:
<img src="blume.jpg" alt="Gelbe Tulpe im Frühlingsgarten">. -
Kontextbezogen: Der Alt-Text sollte den Kontext berücksichtigen, in dem das Bild verwendet wird. Beispiel: Bei einem Bild eines Einkaufswagens auf einer E-Commerce-Seite könnte der Alt-Text lauten:
<img src="cart.png" alt="Warenkorb">. -
Keine redundante Information: Informationen, die bereits im umgebenden Text enthalten sind, müssen nicht im Alt-Text wiederholt werden. Beispiel: Wenn ein Bild neben einer Überschrift „Teamfoto 2024“ steht, sollte der Alt-Text nicht einfach „Teamfoto 2024“ wiederholen.
-
Vermeidung von Keyword-Stuffing: Der Alt-Text sollte nicht mit Schlüsselwörtern überladen werden, da dies die Zugänglichkeit beeinträchtigt.
-
Verwendung von leeren Alt-Attributen für dekorative Bilder: Wenn ein Bild rein dekorativ ist und keinen informativen Wert hat, sollte das Alt-Attribut leer sein (alt=""), um Screenreadern zu signalisieren, dass sie das Bild ignorieren können.
2.3. ARIA-Labels für andere Bedienelemente
Bedeutung von ARIA-Labels:
ARIA-Labels (Accessible Rich Internet Applications) sind ein Set von Attributen, die entwickelt wurden, um die Zugänglichkeit von dynamischen Inhalten und Benutzeroberflächen zu verbessern. Sie bieten zusätzliche Informationen für Screenreader, insbesondere für Elemente, die keine standardisierten HTML-Attribute zur Beschreibung ihres Zwecks haben.
Implementierung von ARIA-Labels:
ARIA-Labels kommen zum Einsatz, wenn ein Bedienelement keinen eindeutigen für Screenreader zugänglichen Text enthält. Hier sind die wichtigsten ARIA-Attribute und ihre Anwendungen:
-
aria-label: Wird verwendet, um ein Element zu beschreiben. Es ist besonders nützlich für Bedienelemente ohne sichtbaren Text. Beispiel:
<button aria-label="Schließen">X</button>. -
aria-labelledby: Verweist auf ein anderes Element, dessen Text als Beschriftung dient. Beispiel:
<button aria-labelledby="closeButtonText">X</button> <span id="closeButtonText" hidden>Schließen</span>. -
aria-describedby: Gibt ein anderes Element an, das eine ausführlichere Beschreibung des aktuellen Elements enthält. Beispiel:
<input type="text" aria-describedby="nameDesc"> <span id="nameDesc">Bitte geben Sie Ihren vollständigen Namen ein.</span>.
Best Practices für die Verwendung von ARIA-Labels
Um sicherzustellen, dass ARIA-Labels effektiv eingesetzt werden, sollten folgende Richtlinien beachtet werden:
-
Klarheit und Präzision: ARIA-Labels sollten klar und präzise sein, um den Zweck des Elements genau zu vermitteln.
-
Vermeidung von Redundanz: ARIA-Labels sollten nicht redundant zu bereits vorhandenen textuellen Beschreibungen sein.
-
Konsistenz: Die Verwendung von ARIA-Labels sollte konsistent über das gesamte Frontend hinweg erfolgen, um eine einheitliche Benutzererfahrung zu gewährleisten.
-
Testen: Die implementierten ARIA-Labels sollten regelmäßig mit verschiedenen Screenreadern getestet werden, um sicherzustellen, dass sie korrekt interpretiert werden.
Zusammenfassung:
Alt-Attribute und ARIA-Labels sind unverzichtbare Werkzeuge, um die Zugänglichkeit und Benutzerfreundlichkeit von Frontends zu gewährleisten. Durch sorgfältige Planung und Implementierung dieser Attribute können Designende und Entwickelnde sicherstellen, dass ihre Inhalte für alle Nutzenden zugänglich sind. Das Beachten der Best Practices beim Schreiben von Alt-Attributen und der Implementierung von ARIA-Labels trägt wesentlich dazu bei, eine inklusive und effiziente Benutzererfahrung zu schaffen.
2.4. Language Tag
Das lang-Attribut informiert Browser und Unterstützungstechnologien über die Sprache des Inhalts. Dies hat mehrere Vorteile:
-
Zugänglichkeit: Screenreader verwenden das lang-Attribut, um die richtige Aussprache und die korrekten Sprachregeln anzuwenden, was für Nutzende mit Sehbehinderungen von entscheidender Bedeutung ist.
-
Mehrsprachige Frontends: Das lang-Attribut ermöglicht es, verschiedene Sprachversionen eines Frontends korrekt zu kennzeichnen und so die Benutzererfahrung zu verbessern.
Um die Sprache zu definieren, können die standardisierten ISO 639-1 Sprachcodes (zwei Buchstaben) genutzt werden (zum Beispiel: de = deutsch). Dabei gilt es folgende Grundregeln zu beachten:
Festlegen der Hauptsprache eines Dokuments
Das lang-Attribut sollte im <html>-Tag des Dokuments festgelegt werden, um die Hauptsprache der gesamten Seite anzugeben. Dies stellt sicher, dass alle Inhalte auf der Seite als in dieser Sprache verfasst erkannt werden.
Festlegen der Sprache für spezifische Elemente
Wenn einzelne Abschnitte oder Elemente in einer anderen Sprache verfasst sind, sollte das lang-Attribut entsprechend auf diese Elemente angewendet werden. Dies ist besonders wichtig für mehrsprachige Frontends, Dokumente und die korrekte Aussprache durch Screenreader. Wenn nötig, können auch spezifische Sprachvarianten oder Dialekte mithilfe von Codes für Regionen oder Länder angegeben werden (zum Beispiel: en-US für amerikanisches Englisch, en-GB für britisches Englisch).
Das lang-Attribut wird nur verwendet, wenn der Text tatsächlich in einer anderen Sprache verfasst ist. Es wird nicht aus ästhetischen oder stilistischen Gründen gesetzt.
Beispiel:
<html lang="de">
<head>
<meta charset="UTF-8">
<title>Mehrsprachige Frontends</title>
</head>
<body>
<h1>Willkommen auf unserem Frontend</h1>
<p>Dies ist ein Beispieltext in deutscher Sprache.</p>
<p lang="en">This is a sample text in English.</p>
</body>
</html>3. Technische Rahmenbedingungen
Die technischen Rahmenbedingungen legen fest, welche Technologien und Plattformen für die Umsetzung des Bedienkonzepts verwendet werden sollen.
-
Für die Entwicklung von Frontends kommt primär die auf Angular basierte Widget Bibliothek PrimeNG zum Einsatz.
-
Ergänzend zu PrimeNG stellt die IsyFact einen Angular-Baustein zur Verfügung. Dieser beinhaltet behördenspezifische Widgets wie den Anwendungsrahmen oder Eingabefelder für Sonderzeichen.
-
Der Baustein liefert ein eigenes Theme, welches die im Bedienkonzept beschriebenen allgemeinen Prinzipien weitestgehend umsetzt. Dieses Theme kann bei Bedarf auch durch ein projektspezifisches Theme ersetzt werden.
-
Primär ist der Baustein für die Nutzung auf Desktopgeräten konzipiert, kann aber durch die grundlegende Responsivität auch auf mobilen Geräten genutzt werden.
4. Basiselemente
4.1. Farben
Farben tragen maßgeblich zur visuellen Identität eines Frontends bei und beeinflussen die Stimmung und Wahrnehmung der Nutzenden. Im Rahmen dieses Bedienkonzeptes ist die folgende Farbpalette vorgegeben (Stand 03.07.2024):
Die Standardpalette wird mit dem IsyFact-Theme ausgeliefert und entsprechend der aktuellen gesetzlichen Lage aktualisiert. Deshalb kann die ausgelieferte Palette von dem hier dokumentierten Stand abweichen. Die dazugehörige Kontrasttabelle der Standardpalette ist im Kapitel Barrierefreiheit zu finden. Die Farbpalette legt ebenfalls fest, zu welchem Zweck bestimmte Farben eingesetzt werden sollen, zum Beispiel Rot (#A4252C) zur Markierung von Alerts.
Dos
-
Grün = Erfolg, Bestätigung, Korrekt, etc.
-
Rot = Fehler, Abbruch, Stopp, etc.
Don’ts
-
Grün = Abbruch, Fehler, Stopp, etc.
-
Lila = Weiter, Sekundärbutton, Löschen, etc.
| Sollte die Standardfarbpalette aufgrund der fachlichen Anforderungen nicht ausreichen oder dem Zweck entsprechen, so kann in Einzelfällen von der Standardfarbpalette abgeleitet werden. |
Die Ableitung der Standardfarbe für Flächen und Hintergründe liegt bei 30% Opacity. Die Ableitung der Standardfarbe für Schriften, Border und Akzente liegt bei +30% black Opacity, damit ein ausreichend hoher Kontrast gewährleistet werden kann. Der daraus resultierende Kontrast erfüllt die Bedingungen bis zum Level AAA - große Schrift.
| Die leichten Farben sind auf hellen Hintergrund nicht mehr barrierefrei! |
Die Anwendungsfarbe des Frontends ist frei wählbar, aber muss vom Projekt auf Barrierefreiheit geprüft werden.
4.2. Applikationsfarben
Sofern es möglich und sinnvoll ist, werden Applikationen aufgrund ihrer Fachlichkeit in Gruppen zusammengefasst. Pro Applikationsgruppe kann eine Farbe definiert werden, welche an verschiedenen Stellen des Applikationsportals eingesetzt wird und so einen Wiedererkennungswert schafft. Wenn eine Applikation keiner Gruppe zugeordnet werden kann, kann sie für sich alleine stehen und ihre eigene Farbe erhalten. Bei der Wahl der Farben sind die generellen Richtlinien zur Nutzung von Farben zu berücksichtigen. Die Farben sollten so gewählt werden, dass ein harmonisches Gesamtbild erhalten bleibt.
Die Applikationsfarbe kommt an folgenden Stellen zum Einsatz:
-
Hauptnavigation – Farbbalken unterhalb des Headers
-
Submenü (Flyout) – Farbbalken am oberen Rand des Menüs
-
Widget auf Dashboard – Farbbalken am oberen Rand
-
Titelzeile von Detailseiten – Hintergrundfarbe der Titelzeile
-
Dialoge der Applikation – Farbbalken oberhalb der Titelzeile
Dos
-
Die Applikationsfarbe repräsentiert eine Gruppe von Applikationen oder eine einzelne Applikation, sofern sie keiner Gruppe zugeordnet werden kann.
-
Eine Applikationsgruppe kann immer nur eine Farbe annehmen. Die Applikationen innerhalb einer Gruppe erhalten keine unterschiedlichen Farben.
-
Die Farben sollten so gewählt werden, dass ein harmonisches Gesamtbild erhalten bleibt.
4.3. Icons
Icons können als zusätzliche Elemente genutzt werden, um Funktionen und Inhalte auch visuell kenntlich zu machen. Dabei sollten Icons primär mit Text genutzt werden und so wenig wie möglich alleine stehen. Wenn Icons alleine als Icon-Buttons oder Aktionselemente genutzt werden, sollte sich auf eine kleinstmögliche Menge beschränkt werden. Es wird empfohlen alleinstehende Icons mit einer weit verbreiteten und allgemein bekannten Bedeutung zu nutzen.
In der folgenden Tabelle sind mögliche Icons, deren Funktionen sowie die dazugehörige CSS-Klasse aufgeführt. Eine Gesamtübersicht der zur Verfügung stehenden Icons ist unter PrimeFaces Icons zu finden.
| Icon | CSS-Klasse | Funktionen |
|---|---|---|
|
pi-times |
Abbrechen, Ablehnen, Filterzelle leeren, Stornieren |
|
pi-car |
Abholen |
|
pi-sign-out |
Abmelden |
|
pi-sign-in |
Anmelden |
|
pi-unlock |
Aktivieren, Freischalten |
|
pi-sync |
Aktualisieren, Synchronisieren |
|
pi-check |
Akzeptieren, Annehmen, Erledigen, Zustimmen |
|
pi-paperclip |
Anhänge |
|
pi-reply |
Antworten |
|
pi-eye |
Anzeigen |
|
pi-file |
Archiv, aus Archiv zurückholen, Dokument erstellen, Erstmeldung |
|
pi-pencil |
Bearbeiten, Bearbeitung fortsetzen, Editieren, Korrigieren |
|
pi-user |
Benutzende, Anwendende, Nutzende, Person |
|
pi-image |
Bild, Bild anzeigen |
|
pi-language |
Buchstaben-Picker |
|
pi-download |
Datei laden, Download, Herunterladen, Laden von Daten |
|
pi-list |
Datensatz anzeigen, Detailauskunft, List-Picker (Objektauswahl), Trefferliste |
|
pi-share-alt |
Daten senden, Daten übermitteln, Senden, Versenden, Teilen |
|
pi-print |
|
|
pi-cog |
Einstellung, Einstellungen |
|
pi-arrow-up-right |
Eintrag auswählen |
|
pi-minus |
Entfernen, Löschen |
|
pi-plus |
Ergänzen, Hinzufügen |
|
pi-bell |
Erinnerung |
|
pi-upload |
Hochladen, Upload |
|
pi-exclamation-triangle |
Fehler, Fehlerhaft, Warnung |
|
pi-eraser |
Felder leeren |
|
pi-check-circle |
Fertig, Abgeschlossen |
|
pi-history |
Historie |
|
pi-info-circle |
Info |
|
pi-arrow-circle-down |
Importieren |
|
pi-calendar |
Kalender |
|
pi-id-card |
Kontakt |
|
pi-trash |
Löschen |
|
pi-envelope |
Mail, Nachrichten |
|
pi-folder-open |
Seite öffnen |
|
pi-save |
Sichern, Speichern |
|
pi-search |
Suchen, Suche wiederholen. Neue Suche, Durchsuchen, letzte Suche |
|
pi-arrow-circle-left |
Vorheriger, Zurück (Navigation) |
|
pi-arrow-circle-right |
Weiter, Nächster |
|
pi-refresh |
Wiederholen |
|
pi-clock |
Zeit, Time-Picker |
|
pi-star-fill |
Wiedervorlage |
4.4. Text
Textelemente spielen eine entscheidende Rolle bei der Kommunikation mit den Nutzenden. Um benutzerfreundliche Texte verfassen zu können, ist es wichtig, die Art und Weise zu verstehen, wie Nutzende Texte auffassen und verarbeiten. In westlichen Kulturen wird in der Regel von links nach rechts und von oben nach unten gelesen. In Bezug auf Software und User-Interface-Design gilt diese Tatsache jedoch nur eingeschränkt, denn Nutzende lesen die Texte auf einem Bildschirm meistens nicht vollständig, sondern überfliegen sie nur kurz, um die für sie relevanten Informationen zu finden.
Die beim Design eines Frontends eingesetzten Elemente unterscheiden sich auch dadurch, wie stark sie die Aufmerksamkeit der Nutzenden auf sich ziehen. So werden Schaltflächen, Labels und andere interaktive Elemente gewöhnlich zuerst wahrgenommen, während statischer Text eher selten gelesen wird. Dieser Abschnitt definiert die typografischen Standards, sprachlichen Richtlinien und Längenbeschränkungen, die dazu beitragen, dass Texte klar, verständlich und ansprechend sind.
Frontends des Bundes sollen über die IT-Landschaft hinweg ein einheitliches Look-and-Feel bieten. Dies wird über den Einsatz der IsyFact und deren Komponenten gewährleistet. Dafür ist es notwendig auch bei der Schrift (im weiteren Font) einheitlich vorzugehen. Zur Anwendung kommt primär BundesSans.
BundesSans
Diese Schriftart wurde extra für Inhalte des Bundes entwickelt und zur Verfügung gestellt. Die BundesSans ist eine humanistische serifenlose Schrift. Rationalität und äußerste Klarheit kennzeichnen ihre Formensprache. Die BundesSans gehört zu den sogenannten humanistischen Serifenlosen und entspricht den Empfehlungen des DBSV hinsichtlich der Leserlichkeit von Schrift. Auch in der DIN 1450 – Leserlichkeit – werden Humanistische Antiqua (mit Serifen) und Groteskschriften (ohne Serifen) als besonders gut leserlich bezeichnet.
Sprachumfang
Folgende Sprachen werden von den Schriften BundesSerif, BundesSans und BundesSans Condensed unterstützt (nur lateinische Schriftzeichen):
Afrikaans, Albanisch, Aserbaidschanisch, Asu, Baskisch, Bemba, Bena, Bosnisch, Bretonisch, Cebuano, Chiga, Deutsch, Dänisch, Embu, Englisch, Esperanto, Estnisch, Filipino, Finnisch, Französisch, Friaulisch, Färöisch, Galizisch, Ganda, Grönländisch, Gusii, Hawaiianisch, Ido, Inari-Samisch, Indonesisch, Interlingua, Irisch, Isländisch, Italienisch, Javanisch, Jju, Jola-Fonyi, Kabuverdianu, Kalenjin, Kamba, Katalanisch, Kikuyu, Kinyarwanda, Kornisch, Korsisch, Kroatisch, Kurdisch, Kölnisch, Lettisch, Ligurisch, Litauisch, Lojban, Lombardisch, Luhya, Luo, Luxemburgisch, Machame, Makhuwa, Makhuwa-Meetto, Makonde, Malagasy, Malaiisch, Maltesisch, Manx, Meru, Mohawk, Morisyen, Māori, Niederdeutsch, Niederländisch. Niedersorbisch, Nord-Ndebele, Nord-Sami, Nord-Sotho, Norwegisch (Bokmål), Norwegisch (Nynorsk), Nyanja, Nyankole, Obersorbisch, Okzitanisch, Oromo, Polnisch, Portugiesisch, Quechua, Rejang, Rombo, Rukiga, Rumänisch, Rundi, Rwa, Rätoromanisch, Samburu, Samoanisch, Sango, Sangu, Sardisch, Schlesisch, Schottisches Gälisch, Schwedisch, Schweizerdeutsch, Sena, Shambala, Shona, Siswati, Slowakisch, Slowenisch, Soga, Somali, Spanisch, Sundanesisch, Swahili, Süd-Ndebele, Süd-Sotho, Taita, Taroko, Teso, Tongaisch, Tschechisch, Tsong, Tswana, Turkmenisch, Türkisch, Ungarisch, Usbekisch, Vunjo, Walisisch, Walliserdeutsch, Wallonisch, Westfriesisch, Wolastoqey, Wolof, Xhosa, Zhuang, Zulu
Die Liste entspricht der Sprachenzeichennorm ISO 639-1-3.
Nicht-lateinische Fließtextschriften
Nicht-lateinische Schriften umfassen Schriftsysteme, die anstelle lateinischer Schriftzeichen zum Beispiel arabische, kyrillische oder chinesische Zeichen beinhalten. Mit einem Schriftsystem lassen sich meist mehrere Sprachen schreiben (zum Beispiel mit dem arabischen Schriftsystem Sprachen wie Arabisch, Urdu, Paschtu, Persisch (Dari/Farsi)).
Die Notwendigkeit der Darstellung nicht-lateinischer Schriften ergibt sich durch die DIN 91379 „Zeichen und definierte Zeichensequenzen in Unicode für die elektronische Verarbeitung von Namen und den Datenaustausch in Europa“ mit Ausgabedatum 2022-08. Basierend auf UNICODE wurde für jedes nicht-lateinische Zeichen, das in EU-Mitgliedsstaaten verwendet wird, beispielsweise griechische oder kyrillische Zeichen, eine eindeutige Zuordnung zu einem lateinischen Zeichen vorgenommen. Die DIN 91379 wendet sich vorrangig an Behörden und Organisationen, die IT-Verfahren betreiben, welche dem behördenübergreifenden Datenaustausch oder dem Datenaustausch mit Bürgerinnen, Bürgern sowie der Wirtschaft dienen und deckt in ihrer Gesamtheit die EU-Amtssprachen und die Amtssprachen Islands, Liechtensteins, Norwegens und der Schweiz ab sowie die deutschen Minderheitensprachen. Um fehlende UNICODE-Zeichen in der BundesSans zu ergänzen, kommt sekundär die Schriftart Liberation zum Einsatz.
Liberation
Die Schriftart Liberation soll ausschließlich für fehlende UNICODE-Zeichen in der BundesSans verwendet werden. Denn beim Einsatz von Liberation muss beachtet werden, dass bei dieser Schriftart das große I und das kleine l leicht verwechselt werden können. Da dies einen Verstoß gegen die BITV (Barrierefreie-Informationstechnik-Verordnung) bedeuten würde, muss bei der Darstellung von I und l in jedem Fall auf BundesSans zurückgegriffen werden.
Barrierefreiheit von Text
Zusätzlich zu einem klar leserlichen Schriftschnitt sind auch die Gestaltungsmerkmale von Text, Farbe und Größe entsprechend zu berücksichtigen. Die fehlerhafte Anwendung von Texten kann somit direkt zu einer Reduzierung der Benutzerfreundlichkeit des entsprechenden Frontends führen.
Die Standard-Schriftart für Bedienelemente und Inhalte ist BundesSans (14pt, regular, dunkelgrau #212529). Grundsätzlich gilt, ausreichende Schriftgrößen sind abhängig vom Betrachtungsabstand, von der Art des Textes und von der Sehschärfe der Lesenden. Individuelle Schriftgrößen können mit dem Schriftgrößenrechner auf leserlich.info ermittelt und entsprechend an den Nutzungskreis angepasst werden.
Rechtschreibung
Zu einem klaren, professionellen Gesamterscheinungsbild trägt auch eine korrekte Rechtschreibung sowie eine konsistente Groß- und Kleinschreibung bei. Während bei englischsprachigen Frontends zwischen verschiedenen Formen der Groß- und Kleinschreibung unterschieden wird, reicht es bei deutschsprachigen Frontends aus, die korrekte deutsche Rechtschreibung anzuwenden. Eine Ausnahme besteht darin, dass das erste Wort der Beschriftung eines Bedienelements immer großgeschrieben wird, unabhängig von der jeweiligen Wortart.
Vermeidung von technischem Jargon
Text muss immer in der Sprache der Nutzenden verfasst werden. Im Folgenden werden einige Beispiele für technische Begriffe und deren Übersetzung in allgemein verständliche Sprache aufgezeigt.
| Technischer Begriff | Allgemeiner Begriff |
|---|---|
Dirty State |
Nicht gespeicherte Änderungen |
Mouse-Up-Event |
Maus-Klick |
Reboot |
Neustart |
String-Länge |
Anzahl der Zeichen |
Data Grid |
Tabelle |
Dos
-
Die Verwendung verschiedener Schriftarten (über die im Bedienkonzept hinaus vorgegebenen Schriftarten) muss vermieden werden.
-
Die Schriftgröße muss immer ausreichend groß sein. Ein Unterschreiten von Mindestgrößen zugunsten des Platzgewinns muss vermieden werden. Stattdessen werden andere, platzsparende Mechanismen angewandt wie Expander (Progressive Disclosure).
-
Die Anzahl verschiedener Schriftgrößen muss auf ein notwendiges Minimum reduziert werden.
-
Als Standard-Schrift wird BundesSans 14pt Regular in Dunkelgrau (#212529) empfohlen.
-
Es muss sichergestellt sein, dass der Kontrast der Schriftfarbe zur Hintergrundfarbe ausreichend groß ist. Hier ist der Kontrast größtmöglich zu wählen (zum Beispiel dunkelgraue Schrift auf weißem Hintergrund). Ist dies aus technischer oder fachlicher Notwendigkeit nicht möglich, so muss der Kontrast bei kleiner Schrift mindestens 4,5:1 entsprechen.
-
Überschriften und großer/dicker Text müssen einen Mindestkontrast von 3:1 aufweisen.
-
Die Nutzung von Fachterminologie muss entsprechend konsistent verwendet werden.
Don’ts
-
Inkonsistente Terminologie.
-
Inkonsistente und falsche Groß- und Kleinschreibung.
-
Die Verwendung von zu langen Texten und Textblöcken.
-
Nutzung von unterstrichenem Text in Textpassagen, außer für Hyperlinks.
-
Die Verwendung von redundanten Textinformationen.
-
Nutzung von technischem Jargon statt der Sprache der Nutzenden.
4.5. Grafiken
Bilder und Grafiken ergänzen den Text und vermitteln Informationen auf visuelle Weise. Sie unterliegen in erster Linie der Fachlichkeit beziehungsweise dem inhaltlichen Kontext und sollten nicht allzu oft als Schmuckgrafiken in Frontends integriert werden. Hier werden die Leitlinien für die Verwendung von Grafiken festgelegt, einschließlich Stilrichtlinien, Bildgrößen und im Ansatz deren Barrierefreiheit.
Jedes Bild benötigt eine Bildunterschrift und ein aussagekräftiges Alt-Attribut, um die Barrierefreiheit von Frontends zu unterstützen. So können die Inhalte für alternative Ausgabegeräte oder beim fehlerhaften Laden zugänglich gemacht werden. Des Weiteren soll die Bildgröße an den Inhalt angepasst werden, um sicherzustellen, dass die Informationen den Nutzenden übermittelt werden und kein horizontales Scrolling erforderlich ist.
Schriftgrafiken
Schriftgrafiken können nicht oder nur eingeschränkt an Benutzeranforderungen angepasst werden, weshalb sie nicht genutzt werden dürfen. Logos sind hiervon ausgenommen. Gründe dafür sind, dass ihre Farben und Schriftgrößen nicht individuell eingestellt werden können und die Schriftkanten bei einer Zoomvergrößerung meist unscharf werden.
Schmuckgrafiken
Schmuckgrafiken können zwar genutzt werden, sollten jedoch so wenig wie möglich eingesetzt werden. Solche Grafiken müssen entsprechend als Schmuckgrafik gekennzeichnet sein und benötigen deshalb auch keine Alt-Attribute.
Dos
-
Bilder benötigen eine Bildunterschrift.
-
Grafiken müssen ein aussagekräftiges Alt-Attribut besitzen.
-
Das Bildmaterial muss ausreichend hoch aufgelöst sein, sodass keine Fragmente erkennbar sind.
-
Schmuckgrafiken sind erlaubt, müssen jedoch entsprechend gekennzeichnet werden.
Don’ts
-
Bilder dürfen nicht gegen deutsches Recht verstoßen, politisch, sexuell oder angreifend sein.
-
Bilder dürfen keine Schriftgrafiken enthalten, ausgenommen Logos. In Ausnahmefällen muss die Schriftgrafik beispielsweise durch Alt-Attribute ausreichend beschrieben sein.
4.6. Überschriften
Überschriften ermöglichen es Nutzenden, schnell die Hauptthemen einer Seite zu erfassen und sich zu orientieren. Sie helfen, Inhalte in logische Abschnitte zu gliedern, wodurch Nutzende die Informationen leichter aufnehmen und navigieren können.
Best Practices für die Verwendung von Überschriften
-
Hierarchische Ordnung: Überschriften sollten in einer klaren hierarchischen Struktur verwendet werden. Die Hauptüberschrift (<h1>) sollte nur einmal pro Seite verwendet werden, gefolgt von Unterüberschriften (<h2>, <h3>, etc.) in absteigender Reihenfolge.
-
Einheitliches Design: Überschriften sollten über das gesamte Frontend hinweg einheitlich gestaltet sein, um ein kohärentes Erscheinungsbild zu gewährleisten. Dies umfasst Schriftart, -größe, -farbe und -stil.
-
Abstände und Margins: Angemessene Abstände vor und nach den Überschriften verbessern die Lesbarkeit und visuelle Struktur der Seite.
Zugänglichkeit
-
Beschreibende Texte: Überschriften sollten aussagekräftig und beschreibend sein, um den Inhalt des folgenden Abschnitts klar zu kommunizieren. Dies hilft sowohl Nutzenden als auch Suchmaschinen, die Relevanz des Inhalts zu erkennen.
-
Verwendung von ARIA-Rollen: In Fällen, in denen Überschriften nicht aus Standard-HTML-Überschriften-Tags bestehen, können ARIA-Rollen verwendet werden, um die Struktur zu erhalten. Beispiel:
<div role="heading" aria-level="2">Unterüberschrift</div>
Typografie und Design
-
Klarheit und Lesbarkeit: Die zu verwendende Schriftart ist BundesSans und sollte mindestens 14pt groß sein. Die Hauptüberschrift sollte deutlich größer und auffälliger als der normale Text sein.
-
Kontrast: Der Kontrast sollte mindestens 4,5:1 sein, um die Lesbarkeit zu maximieren.
Stile und Akzente
-
Fettdruck und Kursivschrift: Fettdruck oder Kursivschrift können verwendet werden, um wichtige Überschriften hervorzuheben, jedoch sollte dies sparsam geschehen, um eine Überladung zu vermeiden.
-
Farben: Farben können verwendet werden, um Hierarchieebenen zu betonen, sollten jedoch mit Bedacht gewählt werden, um ein harmonisches Gesamtbild zu bewahren. Es wird empfohlen die Standardfarben zu nutzen.
4.7. Label
Labels dienen dazu, Eingabefelder und andere Bedienelemente klar zu kennzeichnen, sodass Nutzende genau verstehen, welche Informationen erforderlich sind und welche Aktionen durchgeführt werden können. Ein konsistentes und gut durchdachtes Design von Labels trägt wesentlich zur Verbesserung der Benutzererfahrung bei.
Labels sind nicht nur visuelle Hinweise, sondern auch wesentliche Bestandteile der Barrierefreiheit. Sie ermöglichen es Screenreadern, die Beziehung zwischen einem Eingabefeld und seiner Beschreibung zu verstehen, was besonders für sehbehinderte Nutzende von großer Bedeutung ist. Ein korrekt implementiertes Label sorgt dafür, dass alle Nutzenden, unabhängig von ihren Fähigkeiten, Formulare und andere interaktive Elemente problemlos nutzen können.
Best Practices für die Verwendung von Labels
-
Eindeutige Beschreibung: Labels sollten klar und eindeutig beschreiben, was von den Nutzenden erwartet wird. Beispielsweise sollte ein Label für ein Namensfeld "Vollständiger Name" und nicht nur "Name" lauten.
-
Eindeutige Kennzeichnung von Pflichtfeldern: Labels, die ein Pflichtfeld kennzeichnen, werden immer am Ende mit einem Asterisk (*) gekennzeichnet. Es wird empfohlen das Asterisk farblich nicht vom Label abzuheben.
-
Kurze Formulierungen: Labels sollten kurz und prägnant sein, um die Benutzerfreundlichkeit zu maximieren. Labels mit mehr als drei Wörtern sollten vermieden werden.
-
Nähe zum Eingabefeld: Labels sollten in unmittelbarer Nähe des zugehörigen Eingabefelds platziert werden – entweder darüber oder links davon, um eine klare Zuordnung zu gewährleisten.
-
Ausrichtung: Labels können linksbündig oder rechtsbündig zum Eingabefeld ausgerichtet sein, wobei linksbündige Labels tendenziell besser lesbar und benutzerfreundlicher sind.
Zugänglichkeit
-
HTML-For-Attribut: Jedes Label sollte das for-Attribut verwenden, das mit der ID des entsprechenden Eingabefelds übereinstimmt. Dies stellt sicher, dass Screenreader die Verbindung zwischen Label und Eingabefeld korrekt interpretieren können. Beispiel:
<label for="email">E-Mail-Adresse</label> <input type="email" id="email"> -
Vermeidung von Platzhaltern als Labels: Platzhaltertexte (Placeholder) sollten nicht als Ersatz für Labels verwendet werden, da sie verschwinden, sobald der Nutzende mit der Eingabe beginnt. Dies kann die Benutzerfreundlichkeit und Zugänglichkeit beeinträchtigen.
Stil und Design
-
Lesbarkeit: Labels sollten in einer gut lesbaren Schriftart und -größe dargestellt werden - mindestens 14pt. Der Kontrast muss mindestens 4,5:1 betragen, um auch bei schlechten Lichtverhältnissen gut lesbar zu sein.
-
Konsistenz: Die Gestaltung von Labels sollte über das gesamte Frontend hinweg konsistent sein. Einheitliche Schriftarten, Größen und Abstände tragen zur Benutzerfreundlichkeit und einem professionellen Erscheinungsbild bei.
Interaktive Elemente
Schaltflächen und Links: Labels können auch für interaktive Elemente wie Schaltflächen und Links verwendet werden. Hier sollten ARIA-Labels (aria-label) oder ARIA-Beschreibungen (aria-labelledby) eingesetzt werden, um die Zugänglichkeit zu verbessern. Beispiel:
<button aria-label="Schließen">X</button>5. Bedienelemente
Einleitung und Allgemeines:
Bedienelemente sind die Bausteine der Benutzeroberfläche, die es den Nutzenden ermöglichen, mit dem Frontend zu interagieren. Dieser Abschnitt definiert die verschiedenen Bedienelemente und legt fest, wie sie gestaltet und angeordnet werden sollen, um eine intuitive Benutzererfahrung zu gewährleisten.
5.1. Button
Ein Button dient dazu, Aktionen auszulösen, wie das Einreichen von Formularen, das Navigieren zu anderen Seiten oder das Ausführen spezifischer Funktionen innerhalb der Anwendung. Bei der Gestaltung von Buttons ist es wichtig, auf klare Beschriftungen, ansprechende visuelle Gestaltung und intuitive Platzierung zu achten, um die Benutzerfreundlichkeit zu maximieren. Nachfolgend werden die verschiedenen Arten von Buttons und ihre Anwendung in der IsyFact beschrieben.
5.1.1. Kolorierte Button
Kolorierte Buttons oder auch farbig gefüllte Buttons sind die am häufigsten verwendete Button-Variante. Grundsätzlich handelt es sich um minimal abgerundete Rechtecke, die ein Textlabel, ein Icon oder eine Kombination aus beidem enthalten und farblich gefüllt sind. Aufgrund ihrer kräftigen Farbe werden sie auch CTA-Buttons (Call-To-Action Buttons) genannt.
Je nach Zustand des Buttons unterscheiden sich die eingesetzten Farben und Fokus-Border voneinander. Dies ist in der folgenden Abbildung Zustände von beschrifteten Buttons in Primärfarbe dargestellt.
In diesem Beispiel wurde die Primärfarbe Blau (mit weißer Schrift) verwendet, um die unterschiedlichen Zustände eines Buttons zu veranschaulichen. In den Zuständen "Hover" und "Pressed" wird die Button-Farbe dunkler als im Normalzustand. Entsprechend wird die Button-Farbe im Zustand "Disabled" heller. Im "aktiven" beziehungsweise "fokussierten" Zustand bekommt der Button einen Fokus-Rahmen, der einen helleren Ton hat als der Button selbst. Die Button-Farbe bleibt jedoch die gleiche wie im Normalzustand. Dies lässt sich beim Einsatz der anderen Farben, wie in Abbildung Farben von kolorierten Buttons exemplarisch zu sehen, ebenso anwenden.
Farbwahl bei Buttons
Die folgende Grafik zeigt die zulässigen Farben, die im Frontend für Button-Elemente verwendet werden dürfen:
Hauptsächlich kommen die Primärfarbe Blau und die Sekundärfarbe Orange zum Einsatz, um die Wichtigkeit der einzelnen Aktionselemente innerhalb eines Frontends voneinander zu unterscheiden. Wenn mehrere Buttons in einem Frontend eingesetzt werden, wird der Button mit dem wichtigsten Ziel beziehungsweise mit der am häufigsten genutzten Aktion innerhalb einer inhaltlichen Gruppe in der Primärfarbe dargestellt. Ein Beispiel dafür sind Log-In-Seiten von Social-Media-Plattformen. Die Hauptaufgabe dieser Seite ist es, neue Mitgliedschaften zu generieren, weshalb der Registrieren-Button die Primärfarbe erhält und nicht der Log-In-Button.
In der Regel wird nur ein Button innerhalb der sichtbaren Bedienoberfläche in der Primärfarbe eingefärbt. Dies hilft den Nutzenden sich auf die Hauptaktion zu fokussieren.
Für manche Aktionen sollten spezielle Farben verwendet werden, die eine bestimmte Bedeutung haben, zum Beispiel Grün für Erfolg oder Rot für Alarm. Vor allem bei Aktionen, die nicht wieder rückgängig gemacht werden können, wie Löschen oder Entfernen, kann ein roter "Alarm"-Button sehr hilfreich sein. Diese Signalfarbe veranlasst den Nutzenden noch einmal über seine Aktion nachzudenken, da diese nach der Bestätigung endgültig ist. Alle anderen Buttons werden in der Sekundärfarbe oder als invertierte Buttons dargestellt. Insgesamt sollte die Anzahl der genutzten Farben innerhalb einer Benutzeroberfläche nicht zu hoch sein, um das Frontend nicht zu überladen.
Platzierung der Buttons
Bei der Platzierung der Buttons innerhalb eines Frontends wird zwischen zwei Use Cases unterschieden. Bei kleinen Dialogfenstern, in denen lediglich zwischen Akzeptieren und Abbrechen einer Aktion unterschieden wird, wird der Primär-Button rechts unten platziert.
Auf Formularseiten oder auch Full-Page-Designs ist die Häufigkeit der Verwendung der Buttons ausschlaggebend. Buttons für primäre, einleitende und abschließende Aktionen können sehr präsent in der Mitte des Frontends angeordnet werden. Buttons für navigierende und häufiger verwendete Aktionen werden bevorzugt rechts angeordnet, da die Aufmerksamkeit der Nutzenden während des Lesens oder Hinzufügens von Informationen dorthin gerichtet ist. Es ist darauf zu achten, dass die Anordnung der Buttons mit identischem Zweck über das gesamte Frontend hinweg konsistent bleibt.
Abgrenzung zu anderen Bedienelementen
Da Buttons als Aktionselemente eingesetzt werden, dürfen diese nicht genutzt werden, um Selektionen aus einer Gruppe von Optionen zu treffen. Stattdessen werden Radiobuttons, Checkboxen oder Input Switches verwendet. Wenn nur das Textlabel ohne farbliche und räumliche Abgrenzung zum Hintergrund verwendet wird, kommt kein Button, sondern ein Hyperlink zum Einsatz (beispielsweise bei Fließtexten oder Seitenleisten).
Dos
-
Beim Aktivieren eines Buttons wird immer eine Funktion ausgelöst oder eine (Fehler-)Meldung sichtbar.
-
Buttons mit dem wichtigsten Ziel beziehungsweise mit der am häufigsten genutzten Aktion werden in der Primärfarbe dargestellt. Falls es unklar ist, welche Aktion wichtiger ist, wird die Standardaktion als primäre Aktion angesehen und entsprechend gefärbt.
-
Das Label sollte kurz und selbsterklärend sein.
-
Das Label sollte die auszuführende Aktion beschreiben (zum Beispiel Öffnen, Löschen, Speichern, Weiter).
-
Wenn ein Button einen Dialog aufruft, sollte der resultierende Dialog die Beschriftung des Buttons als Titel wiederholen.
-
Die Schaltfläche für Buttons beträgt mindestens 44px x 44px.
-
Die Breite eines Buttons soll sich am enthaltenen Label orientieren.
-
Nebeneinanderstehende Buttons können unterschiedlich breit sein, wenn die jeweiligen Labels unterschiedlich groß sind.
-
Ein Button soll nach Möglichkeit so platziert werden, dass mögliche Beziehungen zu anderen Elementen deutlich werden.
-
Wenn nach einem Klick auf einen Button die Ergebnisaktion nicht sofort ersichtlich ist, soll dies durch ein System-Feedback (zum Beispiel durch eine Fortschrittsanzeige) veranschaulicht werden.
Don’ts
-
Buttons werden nicht zum Selektieren oder Auswählen von Inhalten verwendet. Hier werden die Bedienelemente Radiobutton und Checkbox eingesetzt.
-
Zum Ein- oder Ausschalten von Inhalten werden keine Buttons verwendet, sondern spezielle Input Switches.
-
Innerhalb von Fließtexten oder zum Verweisen auf externe Inhalte kommen keine Buttons zum Einsatz. Stattdessen werden Links genutzt.
-
Um ein Frontend farblich nicht zu überladen, sollten nicht zu viele Button-Farben für spezielle Aktionen eingesetzt werden.
5.1.2. Invertierte Button
Falls die farblich gefüllten Buttons das Frontend zu bunt werden lassen, weil es zu viele Funktionen auf einer Seite gibt, können für sekundäre Funktionen die invertierten Varianten der Buttons genutzt werden. Jedoch braucht es innerhalb einer Frontend-Seite immer einen farblich kolorierten Button in der Primärfarbe, der die Hauptaktion darstellt. Dieser Button kann nicht durch seine invertierte Variante ersetzt werden.
Bei der invertierten Button-Variante ist die Button-Farbe für jeden Aktionsbutton weiß und nur die Schrift und die Button-Border farblich eingefärbt. Die unterschiedlichen Button-Zustände lassen sich wie bei den farblich gefüllten Buttons voneinander abgrenzen. Das heißt, bei den Zuständen "Hover" und "Pressed" wird die Button-Farbe, die nicht mehr weiß, sondern mit der Button-Schriftfarbe vermischt ist, dunkler und beim Zustand "Disabled" heller. Im "aktiven" beziehungsweise "fokussierten" Zustand erhält der Button einen Fokus-Rahmen, der einen helleren Ton als die Button-Rahmenfarbe aufweist.
| Invertierte Buttons werden häufig genutzt, wenn es mehr als zwei Aktionen auf einer Seite gibt oder wenn einer Aktion ein besonderer Fokus eingeräumt werden soll, wie zum Beispiel beim "Registieren". Das heißt nach der Nutzung eines kolorierten Buttons in der Primärfarbe kann auf die invertierten Buttons umgestiegen werden. Eine Kombination aus farblich kolorierten (ausgenommen der Primärfarbe) und invertierten Buttons ist jedoch nicht zulässig. Es sollte eine der beiden Varianten konsistent im gesamten Frontend benutzt werden. |
5.1.3. Icon-Button
Icon-Buttons sind Buttons die kein sichtbares Label haben, sondern nur aus einem aussagekräftigen Icon bestehen. Sie sind rund und haben einen farbigen Rand, um sich vom Hintergrund oder anderen Basis- und Bedienelementen abzugrenzen. Dabei ist es essenziell, dass das Icon die dahinterstehende Funktionalität ausdrückt. Bei der Entwicklung muss darauf geachtet werden, dass Icon-Buttons durch ein ARIA-Label für Screenreader zugänglich sind.
Generell sollten Icon-Buttons mit Bedacht eingesetzt werden und können somit nicht jeden beliebigen beschrifteten Button ersetzen. Am häufigsten wird diese Button-Art in Kombination mit einer Aktion eines Bedienelements oder Design Patterns genutzt, wie zum Beispiel in der Aktionsspalte einer Tabelle oder zum Hinzufügen oder Löschen von Elementen.
Der Farbeinsatz und die verschiedenen Zustände der Icon-Buttons sind genauso wie bei den Button-Varianten zuvor. Für positive Aktionen wird das grüne Styling, für negative Aktionen das rote Styling und für informierende Aktionen das blaue Styling genutzt. Sie unterscheiden sich lediglich in der Form und Größe.
Beim Hovern über einen Icon-Button kann ein Tooltip angezeigt werden, der die entsprechende Funktionalität beschreibt. Ist diese Beschreibung jedoch zu lang (mehr als drei Wörter), ist das Icon nicht dazu geeignet, einen beschrifteten Button zu ersetzen.
Sonderfall:
In speziellen Fällen werden Icon-Buttons auch ohne ihre Border dargestellt. Hierbei ist es besonders wichtig, dass die Icon-Buttons passend zum Design Pattern gewählt werden. Diese werden beispielsweise innerhalb von Tabellenheadern zum Sortieren und Filtern der Tabelleninhalte verwendet und sehen wie folgt aus:
Dos
-
Die Schaltfläche für Icon-Buttons beträgt mindestens 44px x 44px.
-
Ein Icon-Button ohne Border muss so platziert werden, dass die Beziehungen zu anderen Elementen deutlich werden.
5.2. Hyperlink
Hyperlinks sind verlinkte Texte (oder auch Grafiken), die im Wesentlichen als Navigationsmechanismus dienen, zum Beispiel um neue Fenster mit anderen Inhalten zu öffnen. Wird die Maus über einen Hyperlink bewegt, ändert sich der Cursor vom Pfeil zum Handsymbol. Hyperlinks folgen per Default einem einheitlichen Styling und sind in der Regel unterstrichen. Da Nutzende daran gewöhnt sind, weiterführende Informationen/Links in einem Fließtext oder auf einer Seite anhand des unterstrichenen Textes zu erkennen, ist es nicht ratsam, daran etwas zu ändern.
Hyperlinks können den Status (State) "normal", "hovered/focus" und "clicked" haben.
Hyperlinks benötigen zwingend ein farbunabhängiges Element zum Identifizieren und Erkennen des States.
| Hyperlinks sollten aussagekräftig beschriftet sein. Generische Phrasen wie „Hier klicken“ sind nicht hilfreich und sollten vermieden werden. |
5.3. Eingabefeld
Eingabefelder sind grundlegende Interaktionselemente in einer Benutzeroberfläche, die es den Nutzenden ermöglichen, Daten einzugeben, zu bearbeiten oder auszuwählen. Sie spielen eine zentrale Rolle bei der Interaktion zwischen Nutzenden und System. Sie kommen in verschiedensten Formen und Kontexten vor, sei es in Form von Textfeldern, Dropdown-Menüs, Auswahllisten oder Datumsauswahlkalendern. Die Gestaltung und Platzierung von Eingabefeldern hat direkten Einfluss auf die Benutzererfahrung und die Effizienz der Dateneingabe.
Die nachfolgenden Angaben beziehen sich immer auf Neuentwicklungen und Aktualisierungen. Altanwendungen, die nicht angepasst werden müssen, können weiterhin dem zum Umsetzungszeitpunkt gültigen Bedienkonzept entsprechen.
Eingabefelder sind dynamisch. Sie bestehen aus dem Eingabefeld selbst, einem vorbelegten Platzhalter (Placeholder) und optional aus einer daraus entstehenden Vorschau (Mask) zur Anzeige des erwarteten Formats. Bei der Gestaltung des Labels gibt es zwei Möglichkeiten. Das Label ist "regular" oder "bold".
Normal:
oder
Im Normalzustand ist das Eingabefeld mit einem bündigen, statischen Label in Dunkelgrau versehen. Der Platzhalter ist in einem helleren Grau gehalten. Platzhalter müssen sinnvolle Eingabeunterstützungen (im einfachsten Fall das Label selbst) enthalten.
Aktiv:
oder
Aktive Eingabefelder werden mit einer 1px dickeren Umrandung in der Highlightfarbe Blau dargestellt. Sie verlieren ihren Platzhalter und können entweder geleert werden (siehe Abbildung Eingabefeld aktiv) oder eine Mask enthalten (siehe Abbildung Eingabefeld und Mask).
Befülltes Eingabefeld:
oder
Wenn eine Eingabe in einem Eingabefeld getätigt wurde und das Feld wieder verlassen wird, wechselt das Eingabefeld wieder in den Normalzustand mit dem Unterschied, dass der Platzhalter verschwunden ist und die Eingabe angezeigt wird.
Disabled:
oder
Deaktivierte Eingabefelder (disabled) sind grau hinterlegt und geben zusätzlich über einen Mouse-Cursor-Wechsel beim Hovern den Disabled State wieder. Disabled Felder werden nur eingesetzt, wenn der Inhalt zum aktuellen Zeitpunkt nicht relevant ist. Disabled-Elemente müssen nicht für den Screenreader oder andere Unterstützungstechnologien zugänglich sein.
Readonly:
oder
Im Gegensatz zu einem deaktivierten Eingabefeld sind Readonly-Eingabefelder für Screenreader und andere Unterstützungstechnologien zugänglich und ihr Inhalt für die Nutzenden zum Zeitpunkt der Interaktion relevant. Deaktivierte Felder haben einen Standardhintergrund und sehr hellen Rand. Die enthaltene Information lässt sich aus dem Eingabefeld auslesen (auch durch Screenreader oder andere Unterstützungstechnologien) zum Beispiel durch die Tastenkombination "Strg + C". Die Information ist zum aktuellen Zeitpunkt relevant, kann aber nicht verändert werden.
Eingabefeld als Pflichtfeld:
oder
Ein Eingabefeld als Pflichtfeld ist im Grunde ein normales Eingabefeld mit der Besonderheit, dass es befüllt werden muss. Die "Pflicht"-Kennzeichnung erfolgt dabei durch das Label und wird durch einen Asterisk (*) dargestellt. Der Asterisk wird immer ans Ende eines Labels gestellt. Pflichtfelder haben immer eine Validierung und eine entsprechende Fehlermeldung, die bei einer fehlerhaften Eingabe unterhalb des Eingabefeldes sichtbar wird (siehe zum Beispiel Abbildung Eingabefeld und Fehlermeldung).
| Ein Pflichtfeld kann zusätzlich durch die Deklaration des Platzhalters mit "Pflichtfeld" oder "required" gekennzeichnet werden. |
Eingabefeld mit Fehlermeldung und Hinweis:
oder
Bei einer Fehlermeldung färbt sich das Eingabefeld rot und es wird ein inhaltlich logischer Hinweistext (auch in Rot) angegeben, damit die Eingabe korrigiert werden kann. Das Label des Eingabefeldes wird bei einem Fehler nicht verändert.
Eingabefelder, die eine Erläuterung benötigen, sollen diese immer so kurz wie möglich und so lang wie nötig gestalten. Erläuterungen können dabei unterschiedlich realisiert werden, sortiert von kurz nach lang:
-
als Platzhalter im Eingabefeld selbst.
-
als Klammeranhang am Label, um das Label zu erläutern, zum Beispiel: Name (gemeint ist der eingetragene Familienname).
-
als maximal zweizeiliger Hinweistext unter oder über dem Label (bitte nach Entscheidung konsistent im gesamten Frontend damit fortfahren).
Alle Erläuterungstexte, die mehr als zwei Zeilen einer Eingabefeldlänge benötigen, sind zu komplex gestaltet und bedürfen einer fachlichen Neugestaltung. Sollte dies nicht möglich sein, so ist ein vorangehendes Textelement über dem Eingabefeld notwendig. Erklärungshilfen, sollen nicht dynamisch versteckt werden – entweder ist die Erläuterung notwendig, dann sollte sie sichtbar sein oder sie ist nicht notwendig, sodass sie entfernt werden kann.
Allgemeine Hinweise zu Eingabefeldern:
Ein Eingabefeld hat keine fixe Länge. Ein Eingabefeld ist so lang, wie es der fachliche Kontext notwendig macht. Wenn beispielsweise 95% der erwarteten Eingaben deutlich kürzer sind als Einzelfälle, sollte die Länge so gewählt werden, dass 95% der Eingaben ohne Interaktion vollständig gelesen werden können. Die Mindesthöhe eines Eingabefelds von 44px darf nicht unterschritten werden, um die Barrierefreiheit von Input-Optionen zu gewährleisten.
Die Schriftgröße von Labeln, Platzhaltern und Hinweistexten sollte 14pt nicht unterschreiten. Der Abstand eines Eingabefelds zum darunter liegenden Label eines weiteren Eingabefelds soll ca. dem doppelten Abstand zwischen einem Label-Eingabefeld-Paar entsprechen, um eine eindeutige Zuordnung zu gewährleisten.
Dos:
-
Die unmittelbare Nähe der Labels zu den dazugehörigen Bedienelementen verbessert die visuelle Verbindung und ermöglicht es den Nutzenden, Formulare schneller und effizienter auszufüllen.
-
Gleichmäßige Feldlängen unterstützen den Lesefluss der Nutzenden.
-
Die Feldlängen sollten erwartungskonform gewählt werden. Soll zum Beispiel eine Postleitzahl innerhalb Deutschlands eingegeben werden, so ist es sinnvoll, die Feldlänge auf fünf Stellen zu begrenzen. Optisch kann das Eingabefeld der Konsistenz entsprechend länger sein.
-
Pflichtfelder werden mit einem Asterisk (*) gekennzeichnet.
Don’ts:
-
Labels enden nicht mit einem Doppelpunkt.
-
Bei sehr langen Labels sollten sinnvolle Abkürzungen verwendet werden.
5.3.1. Eingabefeld mit Mask-Option
Um das erwartete Eingabeformat von Eingabefeldern anzuzeigen und als Bedienhilfe die Fehlerwahrscheinlichkeit zu minimieren, werden Masks verwendet.
oder
Eine Mask kann nur im aktiven State angezeigt werden und entspricht der regulären Schriftfarbe. Die Mask ist dem erwarteten Inhalt entsprechend fachlich logisch und nachvollziehbar gewählt. Zum Beispiel entspricht „mobile number“ dem Pattern: +0012 345 / 678 999 oder Ländervorwahl, Vorwahl, Rufnummer. Masks können dabei auch frei gestaltet und den fachlichen Bedürfnissen entsprechend angepasst werden, beispielsweise für Aktenzeichen. Eine Mask kann in Einzelfällen auch dem Platzhalter entsprechen.
5.3.2. Eingabefeld mit Input-Option
Für häufig verwendete Eingaben gibt es die Möglichkeit Input-Optionen für das Eingabefeld anzeigen zu lassen. Dies erleichtert den Nutzenden die Eingabe von festgelegten Formaten, beispielsweise die Eingabe eines Datums bei einem Date-Picker oder die Sicherstellung besonderer Zeichen beim "Sonderzeichenpicker".
oder
Ein Eingabefeld mit Input-Option ist von der Basis identisch zu einem normalen Eingabefeld. Allerdings gibt es am rechten, äußeren Ende des Eingabefelds eine Schaltfläche, um eine Eingabeoption zu aktivieren, zum Beispiel einen Sonderzeichen-Picker (zu sehen in der Abbildung Eingabefeld und Input-Option Sonderzeichen im "Outline"-Style) oder eine Datumseingabe. Die Schaltfläche der Input-Option ist mindestens 44px x 44px.
Date-Picker WiP
Time-Picker WiP
Sonderzeichen-Picker
Der Sonderzeichen-Picker ist eine Input-Option, um nicht übliche Zeichen ohne weitere Hilfsmittel eingeben zu können. Die Input-Option des Sonderzeichen-Picker ist immer am Ende eines Eingabefelds und entweder vollständig ausgefüllt mit der Primärfarbe oder alternativ im "Outline"-Styling (siehe folgende Abbildungen).
oder
Alternativ:
oder
Beim Klick auf die Input-Option öffnet sich in der Mitte des Frontends der Sonderzeichenpicker als Overlay.
Mit dem Sonderzeichenpicker lässt sich nun ein Sonderzeichen wählen und einfügen.
5.3.3. Textbox
Eingabefelder können auch eine unbestimmte Menge an Zeichen erwarten. Dann wird von einer Textbox gesprochen. Diese unterscheiden sich in der Größe und Form von gewöhnlichen Eingabefeldern.
Bei der Eingabe von Text können Textboxen manuell in ihrer Größe verändert werden, sodass der gesamte Inhalt angezeigt werden kann. Textboxen sollten mindestens so groß gestaltet werden, dass der am häufigsten zu erwartende Inhalt hineinpasst, ohne manuell die Box anzupassen.
| Textboxen haben die gleichen States und Styles wie Eingabefelder. |
5.4. Liste
Listen sind zentrale Bestandteile in Frontends und insbesondere von Fachanwendungen. Sie dienen dazu, Inhalte zu strukturieren und erfassbar zu machen. Listen ermöglichen es Nutzenden, zulässige Werte auszuwählen. Dadurch werden Fehleingaben und unerwartete Ergebnisse reduziert.
Listen bestehen optisch aus einem geschlossenen Rahmen und bestenfalls aus logisch sortierten Elementen.
Listen können in den verschiedensten Ausprägungen eingesetzt werden:
-
Eingabefeld + Liste
-
Eingabefeld + Suchbox + Liste
-
Menüitem + Liste
-
etc.
Die einfachste Form einer Liste ist die rein textuelle Liste.
Eine Liste kann theoretisch beliebig viele Einträge enthalten, was aber die Usability verschlechtert. Im optimalen Fall haben Listen eine überschaubare Anzahl an logisch relevanten Einträgen. Die Einträge sind eindeutig und prägnant. Bei langen Einträgen können auch sinnvolle Abkürzungen genutzt werden.
Die Listenelemente sind mindestens 44px hoch und entsprechend dem dazugehörigen Element breit (hier exemplarisch das Eingabefeld). Aktive Elemente sind in der Highlightfarbe und hinterlegt dargestellt.
Dos
-
Listen sollen inhaltlich so einfach wie möglich gestaltet werden.
-
Listeneinträge sollten so kurz wie möglich formuliert sein.
-
Listeneinträge sind eindeutig unterscheidbar.
-
Wenn Listen viele Einträge haben, so sollten andere Elemente die Durchsuchbarkeit, Filterung oder Kategorisierung ermöglichen.
-
Listen können mit unterschiedlichen interaktiven Elementen kombiniert werden, um den Nutzenden eine Hilfestellung zu bieten.
-
Bei einer kleinen Liste kann auch eine Radio-Button-Gruppe genutzt werden.
Don’ts
-
Listeneinträge sollten nie mehrzeilig sein.
-
Listeneinträge sollten nicht doppelt vorhanden sein.
-
Listen sollten nicht unsortiert und sehr lang sein.
-
Listeneinträge mit ganzen Sätzen sollten, wenn möglich, vermieden werden.
5.5. Checkbox
Checkboxen ermöglichen es Nutzenden, mehrere Optionen aus einer (offenen) Liste auszuwählen und spielen eine wichtige Rolle bei der Interaktivität und Benutzerführung. Der gezielte Einsatz von Checkboxen bei kurzen Listen gibt den Nutzenden die Möglichkeit, die Optionen schnell zu erkennen und auszufüllen.
Checkboxen können auch alleinstehend als boolean-Wert genutzt werden (zum Beispiel, um das Lesen der AGB zu bestätigen).
Checkboxen sind 24px x 24px groß und weisen für mobile Geräte mindestens einen 44px x 44px großen Klickbereich (Click-Target-Area) auf. Checkboxen haben immer ein rechtsstehendes Label mit einer Schriftgröße von mindestens 14pt (hier exemplarisch 16pt).
Eine Checkbox repräsentiert eine unabhängige, nicht-exklusive Auswahl, bei der die Nutzenden beliebig viele Optionen auswählen können. Dabei können Checkboxen vertikal oder auch horizontal angeordnet werden.
Wichtig ist, dass jede Checkbox einem Label zugeordnet ist. Für eine homogene Darstellung sind folgende Abstände einzuhalten:
Dos
-
Das Ein- oder Ausschalten einer Checkbox kann dazu genutzt werden, andere Elemente dynamisch zu aktivieren/anzuzeigen oder zu deaktivieren/unsichtbar zu machen. Zum Beispiel können Eingabefelder eingeblendet werden, wenn per Checkbox "Abweichende Lieferadresse" ausgewählt wird.
-
Nicht nur die Box und Target-Area, sondern auch das Label sollten anklickbar sein.
-
Eine Gruppe von Checkboxen sollte immer eine Beschriftung aufweisen. Bei einer einzelnen Checkbox kann diese entfallen.
-
Für optimale Lesbarkeit sollten Checkboxen untereinander angeordnet sein.
-
Bei Checkboxen mit mehreren Ebenen gilt:
-
Solange die Werte der untergeordneten Optionen gleich sind (alle „Aus“ oder alle „An“), zeigt dies die übergeordnete Checkbox mit dem entsprechenden Wert an.
-
Sind die Werte der untergeordneten Optionen jedoch nicht mehr homogen gesetzt, so schaltet die übergeordnete Checkbox in den Zustand „nicht definiert“. Dieser Zustand wird häufig mit einem Quadrat innerhalb der Checkbox symbolisiert.
-
Don’ts
-
Checkboxen sind kein alleinstehender Ein- und Ausschalter, dafür gibt es die Komponente Input Switch.
-
Eine Checkbox soll keine Funktionen (drucken, speichern, etc.) auslösen oder Seiten öffnen/verlinken.
5.6. Radiobutton
Radiobuttons ermöglichen es Nutzenden, eine Option aus einer (offenen) Liste auszuwählen und spielen eine wichtige Rolle bei der Interaktivität und Benutzerführung. Beim Einsatz von Radiobuttons wird den Nutzenden sehr schnell gezeigt, dass sie sich zwischen allen Optionen für eine entscheiden müssen.
Radiobuttons können nicht alleine verwendet werden, da sie nicht wieder abwählbar sind.
Radiobuttons sind 24px groß und weisen für mobile Geräte mindestens einen 44px x 44px großen Klickbereich (Click-Target-Area) auf. Radiobuttons haben immer ein rechtsstehendes Label mit einer Schriftgröße von mindestens 14pt (hier exemplarisch 16pt).
Ein Radiobutton repräsentiert eine exklusive Auswahl. Es kann innerhalb der Gruppe genau eine Option ausgewählt werden. Dabei können Radiobuttons vertikal oder horizontal angeordnet werden.
Wichtig ist, dass jeder Radiobutton einem Label zugeordnet ist. Für eine homogene Darstellung sind folgende Abstände einzuhalten:
Dos
-
Die Verwendung von Radiobuttons empfiehlt sich für eine kleinere Anzahl an Optionen. Ist die Menge der zur Verfügung stehenden Optionen sehr groß oder hat der Platzbedarf eine große Bedeutung, so kann der Einsatz eines Dropdowns in Betracht gezogen werden.
-
Eine Gruppe von Radiobuttons sollte immer eine Beschriftung aufweisen.
-
Für optimale Lesbarkeit sollten Radiobuttons untereinander angeordnet sein.
-
Falls alle oder keine der angebotenen Optionen zutreffen können, sollte eine zusätzliche allgemeine Meta-Option, zum Beispiel "Keine Option" oder "Alle", hinzugefügt werden.
Don’t
Ein Radiobutton darf nicht genutzt werden, um unmittelbar Funktionen auszuführen oder Aktionen auszulösen. Für diese Zwecke sollten Buttons verwendet werden.
5.7. Input Switch
Ein Input Switch, auch Eingabeschalter genannt, kommt zum Einsatz, wenn eine bestimmte Funktion oder Eigenschaft ein- und ausgeschaltet werden muss. Per Default ist immer ein Wert gesetzt: inaktiv (ausgeschaltet) oder aktiv (eingeschaltet).
Um den Nutzenden zu vermitteln welche Funktion oder Eigenschaft ein- beziehungsweise ausgeschaltet werden kann, sollte ein Label links oder rechts neben dem Input Switch platziert werden. Das verwendete Label sollte aussagekräftig und eindeutig sein.
Dos
-
Ein Input Switch wird zum Ein- und Ausschalten von Funktionen oder Eigenschaften benutzt.
-
Die Funktion sollte eindeutig benannt werden (zum Beispiel: Zeige ausgeblendete Felder).
Don’ts
-
Input Switches sollten nicht bei mehr als einer Option gewählt werden.
-
Input Switches sollten nicht in Sätze eingebaut werden.
-
Checkboxen und Input Switches sollen nicht zusammen genutzt werden. Eine Kombination aus beiden Bedienelementen zum Ein- und Ausschalten von Funktionalitäten ist nicht intuitiv für Nutzende.
5.8. Tabview
Ein Tabview ist ein wesentliches Element im modernen Design, das die Benutzererfahrung erheblich verbessert. Es bietet eine intuitive Möglichkeit, verschiedene Inhalte oder Abschnitte eines Frontends übersichtlich und platzsparend darzustellen. Durch die Verwendung von Tabs können Nutzende schnell und einfach zwischen verschiedenen Bereichen navigieren, ohne die Seite ständig neu laden zu müssen. Dies fördert nicht nur die Benutzerfreundlichkeit, sondern auch die Effizienz bei der Informationssuche. Tabviews ermöglichen Entwickelnden, Inhalte logisch zu organisieren und sorgen für eine klare Struktur, die die Benutzerbindung und Zufriedenheit steigert.
Ein Tabview hat initial einen aktivierten, aber nicht markierten/fokussierten State (siehe Tabview). Sobald ein Tab aktiv ausgewählt wird, wird auch die Markierung im Reiter visuell deutlich. Der aktive Tab erhält eine 3px dicke Markierungslinie und ein gefärbtes Label in der Highlightfarbe (hier exemplarisch Blau).
Tabviews können ihre Reiter auch mit visuellen Icons unterstützen. Diese verhalten sich analog zum Tab-Label.
Es ist ratsam ein Tabview zu nutzen, wenn der Inhalt nicht ohne starkes Scrolling innerhalb des Screens dargestellt werden kann. Dabei ist eine fachlich logische Aufgliederung vorauszusetzen.
Sollte es fachlich zwingend notwendig sein, mehr Tabs anzubieten, so kann technisch ein „TabOverflow“ via Scrolling eingesetzt werden. Dieses Element ist ein „Überlängen-Tabview“.
Das Tabview nutzt dabei die volle, ihm zur Verfügung stehende Breite und graut (faded) den letzten sichtbaren Menüpunkt aus. Darüber liegt ein Pfeil, der es ermöglicht, zu den nächsten Tabs zu gelangen. Wurde dieser angeklickt, so springt das Tabview entsprechend viele Einträge weiter.
Die Schriftgröße eines Labels im Tabview sollte 14pt nicht unterschreiten. Ist die Standardschriftgröße gewählt, so erhöht sich diese bei aktiven Elementen um 2pt (hier exemplarisch auf 16pt). Die Höhe eines Tabreiters ist mindestens 44px. Die Breite ist abhängig vom Label. Icons sind mindestens 17px x 17px groß.
Dos:
-
Tabs werden eingesetzt, wenn die Komplexität der UI reduziert werden soll und eine sinnvolle Gruppierung einzelner Bereiche vorgenommen werden kann.
-
Die optimale Anzahl an Tabs ist 4 – 7.
-
Labels für die Tabreiter sollten kurz und aussagekräftig sein. Es kann auch mit sinnvollen und verständlichen Abkürzungen gearbeitet werden.
-
Überlängen-Tabview sollten nur genutzt werden, wenn es keine andere Möglichkeit zur Gestaltung gibt.
Don’ts:
-
Seiten sollten nicht mit nur einem Tabreiter gestaltet werden. Bei weniger als drei Tabreitern, ist eventuell ein dynamisches Panel das passendere Element.
-
Muss der Inhalt verschiedener Tabreiter verglichen/abgestimmt werden, sollte anstelle eines Tabreiters lieber ein dynamisches Panel verwendet werden.
-
Tabreiter stellen nicht verschiedene Sichten zu gleichen Daten dar.
-
Tabreiter sind keine Prozessschritte. Für diesen Zweck wird ein Wizard genutzt.
-
Tabreiter sollen keine Abhängigkeiten untereinander haben.
-
Labels, die länger als 26 Zeichen sind, sollten nicht genutzt werden.
5.9. Tabelle
Eine Tabelle dient der übersichtlichen Anzeige von größeren Datenmengen und besteht aus mehreren Spalten, die zur Sortierung verwendet werden können.
Tabellenzeilen sind standardmäßig nicht anwählbar, was aber durch eine fachliche Notwendigkeit umgesetzt werden kann. So steht es der Anwendung frei:
-
Keine Zeile auswählbar zu machen.
-
Eine Zeile mit Klick auswählbar zu machen.
-
Eine Zeile mit Doppelklick, zum Beispiel direkt in der Detailansicht, zu öffnen.
-
Eine Zeile mit einer Spalte und Checkbox auswählbar zu machen.
| Es ist wichtig, das Verhalten von Tabellen innerhalb der Anwendung konsistent zu halten. Unterschiedliches Verhalten von Tabellen ist NICHT zulässig! |
Wenn mehrere Aktionen für eine Tabellenzeile erfolgen können, dann werden Folgeaktionen über Aktionselemente in der letzten Spalte "Aktionen" bereitgestellt. Falls eine Doppelklick-Aktion in einer Zeile implementiert wird, sollte dies die primäre Funktion der möglichen Tabellenzeilen-Aktionen sein.
-
Doppelklick = Detailansicht öffnen; folglich ist die erste/primäre Aktion = "Detailansicht öffnen".
-
Die aktive/fokussierte Zeile hat die Primärfarbe und der Hover entspricht dem PrimeNG Standard.
Dos:
-
Tabellen werden genutzt, um große Mengen von Daten oder Objekten anzuzeigen.
-
Tabellen sollten übersichtlich bleiben. Weniger wichtige Spalten können ausgeblendet werden. Es ist nicht zielführend alle Daten anzuzeigen. Die Fachlichkeit sollte sich auf eine Teilmenge von wichtigen Informationen beschränken.
-
Überlaufende Textlabels werden abgetrennt und mit einem Tooltip ergänzt.
-
Spaltentitel sollten so kurz wie möglich und prägnant gewählt werden. Abkürzungen sind zulässig.
-
Die initiale oder maximale Breite von Spalten muss sich an den zu erwartenden Inhalten orientieren, auch wenn der Spaltentitel dadurch abgeschnitten wird (es gibt keine feste maximale Buchstabenanzahl).
-
Tabellenspalten können unterschiedlich breit sein.
-
Vertikales Scrolling ist zu vermeiden.
-
Die Spalten sollten ihrer Wichtigkeit nach angeordnet werden.
-
Tabellen sollten nach Möglichkeit maximal 20 Zeilen anzeigen und dann eine Paginierung nutzen. Sollte es fachlich notwendig sein, kann auch endless-scrolling eingesetzt werden.
-
Symbole und Bilder können zur schnelleren visuellen Unterscheidung von Listeneinträgen genutzt werden.
Don’ts:
-
Es sollten keine Tabellen mit nur 1-2 Spalten erzeugt werden.
-
Bei Tabellen sollte nicht vertikal gescrollt werden.
-
Wenn nur ein einziger Eintrag länger ist als der Durchschnitt, sollte sich die Breite der Spalten nicht nach diesem Eintrag richten.
-
Wenn sich Symbole oder Bilder nur wiederholen, sollte auf sie verzichtet werden.
5.9.1. Sortierung in einer Tabelle
Tabellen sollten aufgrund ihrer großen Datenmengen pro Spalte sortierbar sein und eine auf- und absteigende Sortierung anbieten (zwei Pfeile im Tabellenheader). Der Klickbereich des Icons ist dabei 44px x 44px groß (s. Beispiel Tabelle).
-
Der erste Klick auf die Sortiericons sortiert die Tabelle nach den Werten in der gewählten Spalte aufsteigend.
-
Ein zweiter Klick auf die Sortiericons sortiert die Tabelle entsprechend absteigend.
-
Das wechselnde Icon zeigt die aktuelle Sortierung an.
5.9.2. Filterung in einer Tabelle
Es bietet sich an, dass Tabellen auch filterbar gestaltet werden. Dafür können verschiedene fachliche Filter definiert werden. Die Filter lassen sich in beliebiger Weise kombinieren. Über den übergeordneten Icon-Button "Löschen" werden alle Filter gelöscht und die Tabelle aktualisiert.
-
Eine Spalte kann mehrere Filter anwenden.
-
Filter sind nur pro Spalte gültig.
-
Es können gleichzeitig mehrere Filter auf unterschiedliche Spalten angewendet werden.
-
Filter werden sofort nach Auswahl angewandt (Aktualisierung der Tabelle).
-
Aktive Filter sollten deutlich erkennbar sein.
5.9.3. Selektionsverhalten in einer Tabelle
Es gibt verschiedene Möglichkeiten, ein Element in einer Tabelle zu selektieren. Dabei ist die notwendige Fachlichkeit maßgeblich für das Verhalten verantwortlich.
Es kann vorkommen, dass es in einer Anwendung sinnvoll ist, große Datenmengen auszuwählen und dass es in einer anderen Anwendung wiederum besser ist, gar keine Auswahl zuzulassen. Grundsätzlich gilt, dass ausgewählte Zeilen farbig hinterlegt werden müssen. Alle nachfolgenden Punkte sind Möglichkeiten, die eingesetzt werden können. Sollte ein entsprechendes Verhalten angewendet werden, so ist darauf zu achten, dass sich alle Tabellen in der Anwendung konsistent verhalten.
-
Die Kennzeichnung eines Objektes (Name, ID, etc.) kann als Link zur Navigation genutzt werden, um weitere Details anzuzeigen.
-
Der Doppelklick auf eine Zeile kann zum Beispiel die Details eines Elements öffnen.
-
Die erste Zeile kann per Default selektiert werden.
5.9.4. Große Datenmengen in einer Tabelle
Tabellen können sehr viele Daten enthalten und gegebenenfalls sehr lang werden. Um den Umgang mit solchen Tabellen zu vereinfachen, sollten nicht alle Daten initial in der Tabelle angezeigt werden. Über einen Paginator, Endless Scrolling oder einen "Mehr anzeigen"-Button können Nutzende sich bei Bedarf mehr Daten anzeigen lassen.
Paginator
-
Der Paginator wird nach 5, 10 oder 20 Zeilen am Ende der Tabelle angezeigt.
-
Der Paginator erlaubt es, die nächste Seite aber auch weiter entfernte Seiten auszuwählen.
-
Der Paginator zeigt immer den Stand der angezeigten Menge an (zum Beispiel: "1-10").
-
Der Paginator bietet die Möglichkeit ganz ans Ende oder ganz an den Anfang zu springen.
Endless Scrolling
-
Die Tabelle wird initial mit den ersten 10 oder 20 Zeilen angezeigt.
-
Standardmäßig erscheint eine Scrollbar und beim Scrollen werden nach und nach weitere Zeilen eingeblendet, während die oberen Zeilen aus dem View verschwinden.
| Es kann Lazy Loading verwendet werden. |
"Mehr anzeigen"-Button
-
Die Tabelle wird initial mit den ersten 10 oder 20 Zeilen angezeigt.
-
Nach einem Klick auf den "Mehr anzeigen"-Button werden die nächsten 9 oder 19 Items nachgeladen. Dadurch soll erkenntlich sein, dass es genau am Ende des letzten Eintrags weitergeht.
6. Design Pattern
Design Patterns sind wiederkehrende Lösungen für Designprobleme, die sich über verschiedene Teile des Frontends erstrecken können.
6.1. Navigation
Alle Use Cases einer Fachanwendung müssen, gegebenenfalls nach Anwendungskomponenten oder Anwendungen gruppiert, direkt über einen Eintrag in der Navigation ansprechbar sein.
Die IsyFact sieht drei Navigationsebenen vor:
-
Die Hauptnavigation (auch horizontale Navigation genannt)
-
Die darin enthaltene Subnavigation (Menüitems der Hauptnavigation)
-
Die Linksnavigation (Liste von Einträgen am linken Rand der Applikation)
Innerhalb einer Anwendungslandschaft oder einer einzelnen Fachanwendung muss die Navigation einheitlich strukturiert sein.
Je nach Komplexität der Anwendung oder Anwendungslandschaft gibt es verschiedene Möglichkeiten eine Navigation zu gestalten. Alle Navigationen haben gemeinsam, dass sie ihren Use Case auf letzter Ebene in der Linksnavigation haben. Die Subnavigation kann dabei die übergeordnete Anwendungskomponente oder Anwendung enthalten. Die Hauptnavigation bildet entsprechend der Subnavigation die Anwendung (oder eine logische Gruppe der Anwendungskomponenten) oder sogar eine Anwendungsgruppe ab.
Dies sieht in einfachen Fällen wie folgt aus:
-
Anwendung (Hauptnavigation) enthält
-
Anwendungskomponente (Subnavigation) enthält
-
Use Case (Linksnavigation)
In komplexeren übergreifenden Szenarien kann eine Navigation wie folgt aussehen:
-
Anwendungsgruppen (Hauptnavigation) enthält
-
Anwendungen (Subnavigation) enthält
-
Use Case (Linksnavigation, nach Möglichkeit gruppiert)
| Dies sind nur exemplarische Möglichkeiten eine Hierarchie innerhalb der zur Verfügung stehenden Elemente aufzubauen. |
6.1.1. Hauptnavigation
Die Hauptnavigation ist eine horizontale Navigation, die stets am unteren Rand des Header-Bereichs dargestellt wird. Sie wird mit Menüpunkten von links nach rechts befüllt. Im optimalen Fall sind die Menüpunkte ihrer Priorität nach angeordnet. Im optimalen Fall hat die Hauptnavigation nicht mehr als 4-7 Menüpunkte. Die Hauptnavigation ist nicht scrollbar und enthält kein TabOverflow.
Unterhalb der Hauptnavigation wird ein Farbbalken angezeigt. Die Farbe repräsentiert eine Anwendung oder eine Anwendungsgruppe und kann entsprechend ihrer aktiven Auswahl die Farbe ändern. Die Subnavigation öffnet sich per Mausklick.
6.1.2. Subnavigation
Die Subnavigation ist eine vertikale Navigation, die immer an einem Menüpunkt der Hauptnavigation beginnt. Sie wird mit Menüpunkten von oben nach unten befüllt. Im optimalen Fall sind die Menüpunkte ihrer Priorität nach angeordnet. Nach Möglichkeit sind die Menüpunkte logisch gruppiert. Die Subnavigation ist nicht scrollbar.
Die Subnavigation wird zum Öffnen von Anwendungskomponenten oder Anwendungen, deren Navigation sich in der Linksnavigation fortsetzt, genutzt.
6.1.3. Linksnavigation
Die Linksnavigation ist eine vertikale Navigation am linken Bildschirmrand. Sie lässt sich ein und ausblenden. Die Linksnavigation wird mit Menüpunkten von oben nach unten befüllt. Im optimalen Fall sind die Menüpunkte ihrer Priorität nach angeordnet. Nach Möglichkeit sind die Menüpunkte logisch gruppiert.
Per Mausklick lassen sich in der Linksnavigation die Gruppierungen öffnen.
Diese bleiben auch beim weiteren Öffnen von anderen Gruppen weiterhin offen und verhalten sich an dieser Stelle wie ein Panel. Die Linksnavigation enthält optional übergeordnet den Anwendungs- oder Anwendungskomponentennamen. Über die Linksnavigation ist kein Anwendungswechsel möglich.
| Müssen Anwendende häufig auf bestimmte Funktionen oder Objekte zugreifen, so kann es sinnvoll sein, Schnellzugriffe einzurichten. Diese können statisch implementiert sein (zum Beispiel über "häufige Aufgaben") oder sich dynamisch ändern, je nach Nutzung (zum Beispiel über "häufig benutzt"). |
6.2. Eingabefeldliste (Dropdown)
Ein Eingabefeld mit hinterlegten Werten ist in seiner einfachsten Form ein Eingabefeld mit Liste. Die Liste ist die bekannteste Art eines interaktiven Eingabefelds, besser bekannt als Dropdown.
Eingabefeldlisten setzen Standards für interaktive Eingabefelder, Dropdown-Menüs, enthaltene Kontrollkästchen und andere interaktive Elemente. Dadurch wird sichergestellt, dass alle Eingabefelder auf dem Frontend einheitlich gestaltet sind und den besten Praktiken hinsichtlich Benutzerfreundlichkeit und Barrierefreiheit entsprechen. Ein konsistentes Design fördert die Orientierung und das Vertrauen der Nutzenden, was letztendlich zu einer höheren Zufriedenheit und Effizienz führt.
Beim Klick auf das gesamte Element klappt die Liste aus und ein Element kann angewählt werden.
Die Listenelemente sind mindestens 44px hoch und so breit wie das dazugehörige Element (hier exemplarisch das Eingabefeld). Aktive Listenelemente sind in der Highlightfarbe und hinterlegt dargestellt.
6.3. Menü-Button
Ein Menü-Button, technisch Split-Button, ist eine Kombination aus einem Button und einem Dropdown. Die linke Hälfte des Buttons löst beim Betätigen eine Standardaktion aus (zum Beispiel Speichern) und die rechte Hälfte öffnet eine Auswahl an Funktionen (zum Beispiel Speichern als PDF oder Speichern als XLS).
Diese Button-Art wird hauptsächlich in Toolbars eingesetzt und muss immer mehrere Funktionen, die in einen logischen Zusammenhang zueinander stehen, beinhalten. Eine mögliche Verwendung ist das Zusammenfassen von mehreren Exportmöglichkeiten.
Menü-Buttons bestehen aus zwei Bestandteilen:
| Das Icon sollte inhaltlich eindeutig zur Funktion passen. Es sollten bereits bekannte Symbole (zum Beispiel Diskette = Speichern) genutzt werden. Bei der Gestaltung sollte darauf geachtet werden, dass die Icon-Sprache über die gesamte Anwendung konsistent bleibt. |
6.4. Eingabefeldgruppen
In fast jedem Frontend beziehungsweise in den häufigsten Anwendungsfällen lassen sich Eingabefelder inhaltlich zu (homogenen) Gruppen zusammenfassen. Häufig verwendete Gruppen sind beispielsweise „Angaben zur Person“ (mit den Eingabefeldern Vorname, Familienname, Nationalität, Geschlecht etc.), Adressdaten (Straße, Hausnummer, Postleitzahl, Ort) oder Bezahldaten (Art der Bezahlung, Kartennummer etc.). Eingabefeldgruppen sind eine Möglichkeit solche Gruppierungen darzustellen.
Eingabefeldgruppen bestehen immer aus mindestens einer Gruppenüberschrift beziehungsweise einem Gruppenlabel, mehreren Eingabefeldern und gegebenenfalls weiteren Bedienelementen. Die nachfolgenden Angaben beziehen sich immer auf Neuentwicklungen und Aktualisierungen. Altanwendungen, die nicht angepasst werden müssen, können weiterhin dem zum Umsetzungszeitpunkt gültigen Bedienkonzept entsprechen.
Beispiel einer Eingabefeldgruppe "Persönliche Angaben":
Es wird ein einspaltiges Layout verwendet. Jedes Eingabefeld ist ein Pflichtfeld, gekennzeichnet durch einen Asterisk (*). Eingabefeldgruppen bedürfen keiner zusätzlichen optischen Gruppierung. Sie können durch ihre inhaltlich logische Struktur dem zu empfehlenden dreispaltigen Layout des Frontends (siehe Drei-Spalten Layout mit unterschiedlich breiten inhaltlichen Gruppen) folgen.
Beispiel einer Eingabefeldgruppe mit bedingten Pflichtfeldern (ehemals Optionale Pflichtfelder):
Bei einer bedingten Pflichtfeldgruppe ist das Ausfüllen mindestens eines Feldes in einer Eingabefeldgruppe Voraussetzung, um den Prozess abzuschließen.
Im konkreten Beispiel: Identitätsnachweisdokument
Der Prozess sieht vor, dass ein Nachweis über die Identität erbracht wird. Dies kann jedoch über verschiedene Dokumente erfolgen. Somit wird unter der Gruppe „Identitätsnachweisdokument“ in verschiedenen Eingabefeldern die Möglichkeit gegeben sich für eine Nachweisart zu entscheiden und entsprechend ihrer Art entweder eine Auswahl zu treffen oder eine entsprechende Nummer anzugeben.
Dabei ist nicht das einzelne Eingabefeld ein Pflichtfeld, sondern das Ausfüllen mindestens einer Option innerhalb einer Eingabefeldgruppe verpflichtend. Sobald eine Möglichkeit innerhalb der Gruppe ausgewählt/befüllt wurde, wird die bedingte Pflichtfeldgruppe für den Identitätsnachweis als positiv bestätigt.
Dies ist technisch ein sogenanntes „Fieldset“.
Für komplexere fachliche Konstellationen kann eine textuelle Hilfestellung mit Signalwörtern verwendet werden. Der Einsatz solcher komplexen bedingten Pflichtfelder ist aus Sicht der Benutzerfreundlichkeit nur im absoluten Ausnahmefall zu wählen. Vielmehr sollte überlegt werden, ob es einen verständlicheren fachlichen Lösungsansatz gibt.
Beispielhafte Verwendung von Gruppen und inhaltlich logische Gruppierung:
-
Personendaten (rosa Overlay, vertikal gruppiert)
-
Identitätsnachweis (oranger Overlay, vertikal gruppiert)
Hier wird deutlich, dass in einem mehrspaltigen Layout verschiedene Kombinationen an Eingabefeldern in zweispaltiger (horizontaler) Anordnung einer Hauptgruppe (in Lila) unterliegen. Die blockartige Anordnung erleichtert das Erfassen und ermöglicht eine thematische Untergruppen-Clusterung.
7. Use Cases
Use Cases stellen typische Szenarien oder Seiten dar, die bestimmte Funktionalitäten oder Aktionen erfordern. Dieser Abschnitt kombiniert Design Patterns, um benutzerfreundliche Lösungen für spezifische Anwendungsfälle zu präsentieren und ihre Umsetzung anhand von Beispiel-Screens zu veranschaulichen.
7.1. Formulare
Inhalte von Formularen sollten sich an einem virtuellen, nicht visuell dargestellten Raster ausrichten. Formulare sollen einem einspaltigen, zweispaltigen oder dreispaltigen Layout folgen. Dabei sind alle Spalten innerhalb eines Formulars gleich breit aufgebaut.
Die nachfolgenden Angaben beziehen sich immer auf Neuentwicklungen und Aktualisierungen. Altanwendungen, die nicht angepasst werden müssen, können weiterhin dem zum Umsetzungszeitpunkt gültigen Bedienkonzept entsprechen.
Beispielhaftes Formular dreispaltig:
-
Drei-Spalten Layout image::24_UC_3_spalten.png[align="center"]
Formulare bestehen mindestens aus einer Eingabefeldgruppe und einer beliebigen Anzahl weiterer Elemente. Alle Regeln für Eingabefelder und Label haben hier auch ihre Gültigkeit.
Die inhaltliche Gruppierung folgt dabei keinem starren Muster, sondern kann fachlich entsprechend angepasst werden. Diese Gruppierung der Inhalte kann dabei sowohl horizontal als auch vertikal gestaltet werden. Hierbei ist wichtig, dass die Inhaltselemente über eine Gruppenüberschrift logisch zusammengefasst werden.
Exemplarische inhaltliche Nutzung der Spalten:
Durch die saubere Anwendung der Gruppenüberschriften, Titel und Eingabefeldgruppen ist auch ein Wechsel der vertikalen Gruppierungsgröße nicht negativ auffällig. Jede inhaltliche Gruppe (dreispaltig in der ersten Gruppe (rosa, orange, gelb) und einspaltig in der nächsten Gruppe (grün)) wird ganzheitlich als logisches Element wahrgenommen.
Wahrnehmung der inhaltlichen Gruppen:
Gleichmäßige Feldlängen unterstützen den Lesefluss der Nutzenden. Die letzten Eingabefelder können bei Bedarf ihrem Inhalt entsprechend gekürzt werden. Dies unterstützt die inhaltlich logische Gruppierung und signalisiert den Nutzenden auch visuell ein Ende der inhaltlichen Gruppe.
Bei geringeren Auflösungen sollten Eingabefelder untereinander angeordnet werden, um sich der begrenzten Breite anzupassen.
Die Größenanpassung erfolgt innerhalb von gewissen Bereichen:
-
Wird das Browserfenster kleiner als der darzustellende Inhalt (in der Regel bei Tablets und Smartphones), so wird das gesamte Fenster vertikal scrollbar.
-
Der vertikale Abstand zwischen Gruppen und Eingabefeldern bleibt unabhängig von der Bildschirmgröße konstant.
-
Der Abstand zwischen Eingabefeldern und Labeln bleibt ebenfalls unverändert.
-
Bei einer Veränderung der Browserfenster-Größe sollte sich die Breite der Spalten dynamisch an den verfügbaren Platz anpassen, ohne dabei die Lesbarkeit zu beeinträchtigen.
Beispielhafte Gesamtumsetzung eines Formulars im Anwendungsrahmen:
8. Eingabehilfen und Fehlermeldungen
Eingabehilfen und Fehlermeldungen sind essenziell wichtig, um die Benutzerfreundlichkeit eines Frontends zu erhöhen. Im folgenden Kapitel werden die Grundlagen zur erfolgreichen Gestaltung von Eingabehilfen und Fehlermeldungen erläutert.
8.1. Eingabehilfen
8.1.1. Korrekte Labels
Auch Labels gelten als Eingabehilfen. Klare und präzise Beschriftungen (Labels) sind für die Benutzerführung entscheidend, insbesondere für Formulare und Eingabefelder. Jedes Eingabefeld muss ein entsprechendes Label haben, das den Nutzenden genau sagt, welche Art von Information erwartet wird. Beispielsweise sollte ein Anmeldeformular separate Felder für "Anmeldename" und "Passwort" haben, jeweils mit deutlich sichtbaren Labels.
8.1.2. Gute Platzhaltertexte
Platzhaltertexte sind nützlich, um Nutzenden zusätzliche Hinweise oder Beispiele für die erwarteten Eingaben zu geben. Sie sollten jedoch nicht als Ersatz für Labels dienen. Idealerweise sollten Platzhaltertexte kurz und prägnant sein, um den Nutzenden zu helfen, die Anforderungen des jeweiligen Eingabefelds besser zu verstehen, ohne den Platz zu überladen oder den Fokus zu stören.
Beispiel 1: Es wird ein Nachname im Eingabefeld erwartet
Do: Nachname
Don’t: Dein Nachname
Beispiel 2: Es wird eine Telefonnummer erwartet
Do: +49 123 1234567
Don’t: Deine Telefon- oder Handynummer
Sobald die Nutzenden in das Eingabefeld klicken, wird der Platzhalter ausgeblendet und es besteht die Möglichkeit, eine Mask anzeigen zu lassen (siehe Kapitel Eingabefelder). Sie geben das gewünschte Eingabepattern vor und lassen sich fast vollständig frei gestalten.
Gute Hinweistexte zur Erläuterung bei Eingabefeldern und Fehlermeldungen:
Bei komplexeren Formularen oder spezifischen Eingabeanforderungen können Hinweistexte hilfreich sein, um den Nutzenden zusätzliche Anleitungen oder Kontext zu bieten. Diese Texte sollten in der Nähe des entsprechenden Eingabefelds platziert werden und sollten klar und präzise sein. Sie können beispielsweise erklären, welche Art von Informationen erwartet wird oder auf spezielle Formatierungsanforderungen hinweisen.
8.1.3. Autosuggestion
Autosuggestion ist eine Zusatzfunktion, die in Eingabefeldern ergänzt werden kann. Sie dient dazu, Eingaben durch Vorschläge zu vervollständigen und somit zu beschleunigen. Diese Eingabehilfe erscheint direkt unter dem Textfeld. Sie schließt sich, wenn Nutzende neben die Eingabehilfe klicken oder innerhalb der Eingabehilfe ihre Auswahl treffen.
Sobald die Nutzenden mit der Eingabe beginnen, werden mögliche Werte, die mit der getätigten Eingabe beginnen, in einem Menü unterhalb des Textfelds angezeigt. Nutzende können nun weiter tippen oder direkt einen Wert aus dem Menü auswählen und somit ihre Eingabe verkürzen. Gibt es mehr als zehn mögliche passende Werte, so werden die ersten zehn Werte angezeigt, gefolgt von einer Information, dass mehr als zehn Einträge existieren.
8.1.5. Fortschrittsanzeige
Feedback-Konzepte für Ladezeiten sind ein sehr wichtiges Instrument, um eine gute User Experience zu erreichen. Für längere Operationen kann ein Fortschritts-Balken (Progress Bar) genutzt werden, der sich entsprechend dem Fortschritt des Vorgangs füllt. Für kürzere Vorgänge kann ein Fortschritts-Spinner (kreisrunde Fortschrittsanzeige) verwendet werden.
Grundlegende Anwendungshinweise:
-
Generell sollten Vorgänge oder Operationen, die mehr als eine Sekunde in Anspruch nehmen, eine Rückmeldung in Form einer Fortschrittsanzeige an Nutzende geben.
-
Die Form der Fortschrittsanzeige richtet sich dabei nach der Länge des Vorgangs und dem Anwendungskontext.
-
Fortschrittsanzeigen werden in der Regel nur für Wartezeiten verwendet, die sich aus System-Operationen ergeben. Für Wartezeiten, die sich auf die Bedienung der Nutzenden zurückführen lassen, werden keine Fortschrittsanzeigen eingesetzt.
Fortschritts-Balken (Progress Bar):
-
Fortschritts-Balken werden in der Regel für Ladevorgänge mit bestimmbarer Gesamtlänge verwendet.
-
Ein Balken zeigt den Grad der Zielerreichung an. Dabei füllt sich der Balken von links (0%) nach rechts (100%).
Fortschritts-Spinner (kreisrunde Fortschrittsanzeige):
-
Fortschritts-Spinner werden für Ladevorgänge verwendet, deren Gesamtlänge unbekannt ist.
-
Für die Dauer der Operation dreht sich der Fortschritts-Spinner und signalisiert Nutzenden damit, dass sich ein Prozess in Gang befindet. Der Fortschritts-Spinner empfiehlt sich aufgrund seiner geringen Maße insbesondere in Situationen, in denen Platzbedarf von großer Bedeutung ist.
8.1.6. System-Meldungen
Beim Verfassen von System-Benachrichtigungen – wie beispielsweise Fehlermeldungen – muss auf eine verständliche und konsistente Formulierung geachtet werden. Neben Fehlermeldungen, die am Eingabeobjekt auftreten, kann zusätzlich ein zusammenfassender Hinweis angezeigt werden (Achtung: dynamisch nachgeladene Elemente müssen auch einem Screenreader mitgeteilt werden, sodass auch Personen mit Einschränkungen diese Hinweise mitbekommen). Dies geschieht mithilfe von Toast-Notifications, welche immer am unteren rechten Rand des Browserfensters angezeigt werden.
Jede Toast-Notification muss eine Schließen-Aktion für den Nutzenden anbieten. Um die Barrierefreiheit einzuhalten, muss die Notification dauerhaft eingeblendet bleiben, bis sie von den Nutzenden geschlossen wird, siehe WCAG 2.1 Kriterium 1.4.13a.
Folgende Meldungsarten können als Toast-Notification verwendet werden:
-
Warnung
-
Hinweis
-
Fehler
-
Erfolg
Hinweisdialoge und -popups WiP
Dos
-
Allgemeinverständliche und positive Sprache
-
Inkorrekt: „Soll das Objekt gelöscht werden?“
-
Besser: „Wollen Sie das gewählte Objekt XY löschen?“
-
-
Verwenden einer einfachen und konsistenten Satzstruktur
-
Präzise Formulierungen:
-
Inkorrekt: „Nichts selektiert“
-
Besser: „Bitte selektieren Sie ein Objekt in der Liste“
-
-
Positive Formulierungen:
-
Inkorrekt: „Illegale String-Länge aufgetreten.“
-
Besser: „Es wurden zu viele Zeichen eingegeben. Es sind maximal 20 Zeichen möglich.“
-
-
Es soll nicht nur das Problem geschildert, sondern auch eine mögliche Lösung mitgeliefert werden.
Don’ts
-
Vermeidung von redundanten Informationen
-
Vermeidung von mehrdeutigen Beschreibungen
8.2. Fehlermeldungen
Fehlermeldungen sind unvermeidlich, aber wie sie präsentiert werden, kann einen großen Unterschied für die Benutzererfahrung bedeuten. Fehlermeldungen sollten gut sichtbar und in verständlicher Sprache verfasst sein sowie klare Anweisungen zur Behebung des Fehlers enthalten. Idealerweise sollten Fehlermeldungen in unmittelbarer Nähe von betroffenen Objekten platziert werden (siehe als Beispiel: Eingabefelder - Fehlermeldung), um Nutzenden sofortiges Feedback zu geben und sie bei der Fehlerbehebung zu unterstützen. Neben Fehlermeldungen, die am Eingabeobjekt auftreten, kann zusätzlich ein zusammenfassender Hinweis, wie im Kapitel System-Meldungen beschrieben, angezeigt werden.
Ein häufig gemachter Fehler ist dabei die Verwendung von negativ anmutenden Formulierungen, die Benutzende demotivieren können. Die folgende Liste zeigt einige negative Bezeichnungen und ihre neutralen Äquivalente:
| Negativer Begriff | Neutraler Begriff |
|---|---|
Illegal |
Nicht korrekt |
Fehler |
Problem |
Fehlschlagen („Speichern ist fehlgeschlagen“) |
Nicht können („Es konnte nicht gespeichert werden“) |
9. Designrichtlinien
WiP
9.1. Strukturierung von Frontend-Seiten
WiP (Wann setze ich Panels, Akkordeons und/oder Überschriften ein?)
9.1.1. Screenbereiche (Screenareas)
WiP (beinhaltet die Grundstruktur einer Frontend-Seite anhand der isy-angular-widgets Komponente isy-hauptfenster)
9.3. Readonly vs. Disabled
9.3.1. "Readonly" State
Ein "Readonly"-Feld erlaubt es, die darin enthaltenen Daten zu sehen, jedoch nicht zu ändern. Dies ist besonders dann nützlich, wenn Informationen relevant sind, jedoch nicht modifiziert werden sollen.
Merkmale:
-
Sichtbarkeit: Der Inhalt des Feldes kann von Nutzenden vollständig gesehen und von Screenreadern erfasst werden.
-
Interaktivität: Die Daten können nicht bearbeitet werden, jedoch bleiben Funktionen wie das Markieren und Kopieren erhalten.
-
Design: Optisch wird das Eingabefeld leicht modifiziert mit leichteren Farben oder Formen dargestellt.
Anwendungsfälle:
-
Bestätigungsseiten: Nach der Eingabe eines Formulars kann ein "Readonly"-Zustand verwendet werden, um die eingegebenen Daten zur Überprüfung anzuzeigen.
-
Informationsanzeige: Felder, die wichtige Daten enthalten, die jedoch von bestimmten Nutzergruppen nicht verändert werden sollen (zum Beispiel automatisch generierte ID-Nummern, erfasste Zeitstempel).
Handlungsempfehlungen:
"Readonly" sollte für Felder verwendet werden, deren Inhalte für Nutzende relevant sind, aber nicht verändert werden dürfen. Gestalte das Design so, dass die visuelle Unterscheidung klar, aber nicht störend ist – zum Beispiel durch subtile Farbveränderungen. Erlaube Nutzenden weiterhin Inhalte aus dem "Readonly"-Feld zu kopieren.
9.3.2. "Disabled" State
Ein "Disabled"-Feld hingegen ist vollständig inaktiv. Nutzende können den Inhalt nicht oder schlecht sehen, nicht bearbeiten und auch keine Interaktion (wie Kopieren) durchführen. Diese Option wird verwendet, um Nutzenden zu signalisieren, dass bestimmte Funktionen oder Eingaben derzeit nicht zur Verfügung stehen.
Merkmale:
-
Sichtbarkeit: Oft wird der Inhalt des Feldes ausgegraut oder gar nicht sichtbar gemacht.
-
Interaktivität: Keine Interaktion möglich – weder das Bearbeiten, noch das Kopieren von Inhalten.
-
Design: Meist visuell hervorgehoben durch ausgegraute Felder oder abweichende Farbschemata, um den Zustand klar zu kommunizieren.
Anwendungsfälle:
-
Zugriffssteuerung: Felder, die nur von Nutzergruppen mit bestimmten Rechten bearbeitet werden dürfen, können für andere "disabled" sein.
-
Bedingte Formularfelder: Wenn bestimmte Eingaben erst aktiviert werden sollen, nachdem vorherige Felder korrekt ausgefüllt wurden, können diese initial "disabled" sein.
Handlungsempfehlungen:
"Disabled" sollte für Felder verwendet werden, die Nutzenden derzeit nicht zugänglich sein sollen, um Fehlinteraktionen zu verhindern. Vermeide "Disabled" für wichtige Informationen, die Nutzende sehen müssen – in solchen Fällen ist "Readonly" besser geeignet. Mache den "Disabled"-Status klar ersichtlich, indem eine deutliche visuelle Abgrenzung durch Ausgrauen oder andere farbliche Mittel verwendet wird.
Vergleich und Fazit
Der wesentliche Unterschied zwischen "Readonly" und "Disabled" liegt in der Sichtbarkeit und der Interaktivität der Felder. Während "Readonly"-Felder Nutzenden Informationen präsentieren, die sie nicht bearbeiten dürfen, aber weiterhin sehen und kopieren können, sind "Disabled"-Felder vollständig gesperrt und weder sichtbar noch interaktiv. Für die Anwendung in Formularen sollten folgende Grundsätze beachtet werden:
-
"Readonly" ist ideal, wenn die Informationen wichtig sind und für Nutzende sichtbar bleiben müssen, aber nicht verändert werden sollen.
-
"Disabled" eignet sich, wenn Nutzende keine Informationen im Feld sehen oder bearbeiten sollen – zum Beispiel bei unzugänglichen Funktionen oder Bedingungen, die erst später erfüllt werden müssen.