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 und allgemeine Prinzipien
Dieses einführende Kapitel beinhaltet allgemeine Hinweise zum Bedienkonzept. Des Weiteren werden allgemeingültige Prinzipien erläutert, die bei der Konzeption und Gestaltung von Software berücksichtigt werden sollten. Abschließend werden die Vorgaben für die zu unterstützenden Browser festgehalten.
1.1. Einführung in das Bedienkonzept
Anwendungsbereich und Abgrenzung
Da in einem Bedienkonzept generische Regeln und nicht detaillierte GUI-Spezifikationen für jeden Screen einer Applikation festgelegt werden, ist es beim Screen Design notwendig, große Sorgfalt walten zu lassen. Das vorliegende Dokument definiert einen Standard. Wann immer die Notwendigkeit zur Nichtbefolgung eines Standards auftauchen sollte, muss über Art und Umfang der Abweichung entschieden werden. Das heißt, der in diesem Dokument definierte Standard wird empfohlen, ist aber nicht in jedem Einzelfall als Restriktion zu verstehen.
Begriff der Usability
Die Benutzerfreundlichkeit (Usability) einer Anwendung gilt heute als entscheidendes Qualitätsmerkmal und trägt nachhaltig zur breiten Akzeptanz eines Systems bei. Der Begriff der Usability verweist auf ein qualitatives Konzept, welches das Ausmaß beschreibt, in dem ein Produkt von einem bestimmten Benutzer verwendet werden kann, um konkrete Arbeitsziele in einem vorgegebenen Kontext effektiv, effizient und zufriedenstellend zu erreichen. Die Usability eines Produktes kann damit nicht unabhängig von einem zuvor festgelegten Benutzer bestimmt werden, sondern bezieht ausdrücklich ein umschriebenes Benutzerprofil im Sinne von gegebenen oder fehlenden Vorkenntnissen, Ausbildungen und Fertigkeiten mit ein. Mit dem Attribut effektiv wird die Genauigkeit und Vollständigkeit angesprochen, mit der ein Benutzer sein Arbeitsziel erreicht und hierbei durch das System unterstützt wird.
Prospektive Benutzergruppen und generelle Aufgabenbeschreibung
Als Benutzerzielgruppe werden die bisherigen Anwender der bestehenden Informations-Anwendung ins Auge gefasst. Bei dieser Gruppe werden elementare Kenntnisse im Bereich von Standard-Office-Applikationen vorausgesetzt. Bei der konkreten Ausgestaltung (Spezifikation) der einzelnen Anwendungen sind die Eigenschaften der jeweiligen Benutzergruppen in Bezug auf Vorkenntnisse, Fähigkeiten, IT-Affinität usw. zu berücksichtigen.
Zielsetzung des Bedienkonzeptes und Abgrenzung zum Styleguide
Das Bedienkonzept beschreibt die Art und Weise, wie eine IsyFact-Anwendung von einem Benutzer bedient wird und konzentriert sich auf die Gestaltung der Benutzeroberfläche, die Interaktion mit dem System und die Navigation durch die Funktionen. Ein Bedienkonzept ist eine Sammlung von Designrichtlinien und Standards, die zur Wahrung einer konsistenten visuellen Identität einer Marke oder eines Unternehmens beitragen und konzentriert sich auf visuelle Elemente wie Farben, Typografie, Grafiken und Logo-Verwendung. Er kann jedoch auch Schreib- und Sprachregeln enthalten, um sicherzustellen, dass die Kommunikation mit der Zielgruppe einheitlich und klar ist.
Dieses Bedienkonzept muss von der jeweiligen Behörde ausgearbeitet werden.
Während das Bedienkonzept in erster Linie für Designer und Entwickler relevant ist, die eine Anwendung entwerfen, ist ein Bedienkonzept eher für Marken- und Kommunikationsexperten relevant, die sicherstellen möchten, dass die visuelle Identität und Markenpositionierung ihrer Behörde konsistent bleibt. Die Entwickler setzen dann die vom Bedienkonzept definierten visuelle Elemente um. Alle Teile des Bedienkonzeptes sind erweiterbar und sollten über die Zeit hinweg fortgeschrieben und ergänzt werden.
1.2. Allgemeine Prinzipien
Zur Konzeption und Gestaltung von benutzerfreundlicher Software können einige generelle Prinzipien zu Rate gezogen werden. 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 Design Prinzipien. Als tiefergehende Grundlage zu den Designprinzipien können die Gestaltgesetze aus der Gestaltpsychologie herangezogen werden.
Neben den allgemeinen Prinzipien ist besonders das Thema Barrierefreiheit für deutsche Behörden relevant und wir in diesem Abschnitt noch einmal explizit beschrieben.
1.2.1. Barrierefreiheit
Die Barrierefreiheit einer Anwendung beschreibt das Ausmaß, inwieweit die Anwendung für möglichst viele Menschen zugänglich ist, unabhängig vom Alter und von möglichen Einschränkungen durch Behinderungen. Im englischsprachigen Raum wird hierfür der Begriff „Accessibility“ (Zugänglichkeit) verwendet.
Das Ziel der barrierefreien Gestaltung liegt vor allem darin, eine verbesserte Zugänglichkeit für Menschen mit Behinderung und ältere Menschen zu erreichen. Hiervon ist ein großer Anteil der Bevölkerung betroffen, zumal es neben Menschen mit permanenter Behinderung auch viele Menschen gibt, die nur zeitweise hinsichtlich der Bedienung eingeschränkt sind. Barrierefreie Gestaltung ermöglicht nicht nur Zugänglichkeit für mehr Menschen, sondern verbessert auch deren Einbeziehung in die Anwendung. Darüber hinaus bewirkt eine erhöhte Barrierefreiheit allgemein für Benutzer auch eine Verbesserung der Usability. In vielen Ländern wird Barrierefreiheit (insbesondere für Webseiten) durch Gesetze bzw. Richtlinien geregelt, um einen allgemeinen Zugang zu öffentlichen Internetdiensten zu erreichen.
Richtlinien und Prinzipien zur Barrierefreiheit
Im Rahmen des World Wide Web Consortium (W3C) wurden die Web Content Accessibility Guidelines (WCAG) verfasst, um einen gemeinsamen Standard für die Barrierefreiheit von Webinhalten zu schaffen. Dabei handelt es sich um Richtlinien für die barrierefreie Gestaltung von Webinhalten im Hinblick auf drei Erfüllungsgrade (Conformance Levels A, AA und AAA). Diese Richtlinien basieren auf den folgenden vier Prinzipien für eine barrierefreie Anwendung:
-
Wahrnehmbar – Präsentation der Benutzerschnittstelle, so dass diese für Benutzer wahrnehmbar ist (mittels Sehkraft, Gehör oder Berührung).
-
Bedienbar – Benutzerschnittstelle muss bedienbar bzw. navigierbar sein und kompatibel mit Tastatur oder Maus.
-
Verständlich – Informationen und Bedienung müssen verständlich sein.
-
Robust – Die Benutzerschnittstelle funktioniert zuverlässig mit verschiedenen Browsern, assistiven Technologien (z.B. Screen Reader), mobilen Geräten, alten Geräten/Browsern.
In Deutschland gilt das Behindertengleichstellungsgesetz (BGG), welches eine Benachteiligung von behinderten Menschen verhindern soll. Als Teil dieses Gesetzes wurde die sogenannte Barrierefreie-Informationstechnik-Verordnung (BITV) verfasst. Für bestimmte Anwendungsgruppen gilt dies verbindlich, z.B. für Bundesbehörden im Hinblick auf deren Internetauftritte und öffentlich zugängliche Terminals. Die BITV wendet als Grundlage die Prinzipien und Richtlinien der WCAG an.
Verfassen von adäquaten Texten
Verständlicher und präziser Text ist ein ausschlaggebendes Kriterium für die Produktivität einer Software. Gleichwohl ist technischer Jargon weit verbreitet, der für Endanwender letztlich nur schwer verständlich ist. Zudem ist es sehr wichtig, applikationsübergreifend konsistente Begrifflichkeiten zu verwenden. Weiterhin ist bei der Erstellung von Texten darauf zu achten, die Benutzer nicht mit unangemessen langen Texten zu demotivieren.
-
Sprechen Sie die Sprache des Benutzers
-
Vermeiden Sie unnötig lange Texte
Angemessener Einsatz von Farben, Fonts und Icons
Große Teile des Look & Feel eines User-Interface werden mit dem Einsatz von Farben, Fonts, Grafiken und Icons definiert. Daher ist es äußerst bedeutsam, diese Elemente angemessen und konsistent zu verwenden. So sollen nicht zu viele unterschiedliche Schriftarten innerhalb einer Applikation verwendet werden. In der Regel führen bereits mehr als zwei verschiedene Schriftarten zu einem unruhigen Erscheinungsbild. Auch der Einsatz von Farben soll systematisch und behutsam erfolgen. Die im Kapitel Farben definierten Farbwerte, sollten hierbei als Vorgabe gesehen werden. Bei der semantischen Verwendung von Farben dürfen diese niemals als alleiniger Indikator genutzt werden. Es sind verschiedene Formen der Farbenfehlsichtigkeit in der Bevölkerung weit verbreitet. Es empfiehlt sich daher eine Form der redundanten Kodierung, so kann die Bedeutung einer Farbe z.B. mittels einer Form oder eines Icons unterstützend transportiert werden.
1.3. Browser-Unterstützung
Bei der Erstellung der Webseiten nach diesem Bedienkonzept muss die korrekte Darstellung und Funktionsweise der Webseiten inklusive der Browser Funktionen wie bspw. "Vor- und Zurück" geprüft werden. Dazu muss für jedes Projekt der Nutzerkreis ermittelt und geprüft werden, welche Browser und Versionen hauptsächlich eingesetzt werden. Das Bedienkonzept gibt nur ein minimales Set von zu unterstützenden Browserversionen vor, die projektspezifisch nach Bedarf erweitert werden sollten.
Die Tests der Benutzeroberfläche sollen mindestens mit folgende Browsern getestet werden, dabei sind folgende Auflösungen zu berücksichtigen: * SXGA * UXGA * 1080p * WQHD
| Browser | Neuste Version aus Channel |
|---|---|
Microsoft Edge |
Stable Channel |
Firefox |
ESR |
Chrome |
Stable Channel |
2. Fenstertypen & Layout
Im Folgenden werden die Fenstertypen und das allgemeine Layoutverhalten der Applikation beschrieben.
2.1. Layout & Resizing
2.1.1. Bildschirmauflösung & Resizing
Die Layouts sind für eine Bildschirmauflösung von 1920x1080 px (1080p) zu optimieren. Es muss jedoch sichergestellt sein, dass auch niedrigere und größere Bildschirmauflösungen unterstützt werden. Einige Bereiche des Layouts können ihre Größe, entsprechend der Auflösung, flexibel anpassen. Das genaue Verhalten der einzelnen Bereiche und Elemente wird in den entsprechenden Kapiteln näher beschrieben.
Richtlinien zur Anwendung
-
Generell sollten beim Layout innerhalb eines Screens keine horizontalen Scrollbalken verwendet werden.
-
Bei einer Seitenbreite zwischen 1280px und 1920px gelten folgende Richtlinien
-
Es sollen keine horizontalen Scrollbalken zum Scrollen der Seite angezeigt werden.
-
Die Anzahl Spalten in Formulare soll sich nicht verändern.
-
Die Anwendung soll immer die volle Seitenbreite einnehmen.
-
-
Bei Größenveränderungen von Inhalten sollte immer darauf geachtet werden, dass der Lesefluss des Benutzers nicht negativ beeinflusst wird.
-
Elemente auf der Benutzeroberfläche dürfen sich nicht überlappen.
2.2. Hauptfenster
Im Wesentlichen besteht das Hauptfenster aus zwei Bereichen: dem Header-Bereich und dem Inhaltsbereich.
Das Layout des Header-Bereichs ist immer gleichartig. Der Inhalt ändert sich nur in einem vordefinierten Rahmen (z.B. Logo der Anwendungslandschaft, Inhalte der Hauptnavigation). Der Abschnitt Header Bereich beschreibt die Möglichkeiten zur Gestaltung.
2.2.1. Header Bereich
Der Header Bereich enthält allgemeine Informationen zur Anwendungslandschaft, den in ihr verfügbaren Fachanwendungen und zum angemeldeten Anwender.
Aufbau des Header-Bereiches verdeutlicht die Teile, aus denen er besteht:
-
A Logo des Anbieters der Anwendungslandschaft
-
B Balken in Primärfarbe der Anwendungslandschaft
-
C Logo der Anwendungslandschaft
-
D Informationen zum angemeldeten Anwender
-
E + F Hauptnavigation und Subnavigation als Flyout (zur Nutzung siehe Hauptnavigation)
Der Header ist von der Gestaltung her für alle Seiten innerhalb einer Anwendungslandschaft gleich. Beim Resizing bleiben links ausgerichtete Objekte links und rechts ausgerichtete Objekte rechts und der Raum dazwischen verändert seine Größe.
Der Header kann sich vom Inhalt her allerdings geringfügig anpassen. Die Informationen zum angemeldeten Anwender zeigen mindestens den Namen oder die Kennung des Anwenders.
2.2.3. Login
Auf dem Login Screen kann der Benutzer sich mit seinem Namen und Passwort einloggen, anschließend wird er zum Dashboard (falls vorhanden) der jeweiligen Anwendung weiter geleitet.
Richtlinien zur Anwendung
-
Die generelle Aufteilung der Login Seite entspricht die des Dashboard der Applikation.
-
Header
-
3-spaltiger Inhaltsbereich
-
-
Der Header-Bereich wird ohne die Hauptnavigation dargestellt. In der Höhe bleibt der Header allerdings unverändert.
-
Inhaltsbereich
-
Die linke Spalte bleibt leer.
-
Im mittleren Bereich befindet sich das Login-Formular.
-
In der rechten Spalte findet der Benutzer Kontaktinformationen.
-
-
Während des Logins sollte eine Validierung stattfinden. Feedback wird im Meldungsbereich (zwischen Überschrift und Benutzername) und an den Eingabefeldern dargestellt. Genauere Informationen hierzu können in Kapitel Validierung nachgelesen werden.
2.2.4. Portalstartseite
Falls die Gesamtanwendung aus mehrere kleineren Anwendungen mit eigenen Benutzeroberflächen besteht, ist nach dem Login zunächst die Portalstartseite der zentrale Startpunkt nach dem Login. Sie stellt eine Sammlung mehrerer Applikationen dar. Von hier aus kann der Benutzer in die einzelnen Applikationen abspringen.
Aufbau
-
Header Bereich
-
Inhaltsbereich = dreispaltiges Layout
-
Quicklinks (wichtige Objekte) (A)
-
Widgets Applikationen (B)
-
Informationen (C)
-
Ist dies der richtige Fenstertyp?
-
Das Dashboard wird als zentraler Sammelpunkt aller Applikationen einer Anwendung genutzt.
-
Das Dashboard ist der Startpunkt für den Benutzer nach dem Login.
Richtlinien zur Anwendung
-
Das Dashboard hat eigene Layout-Regeln, die ausschließlich für das Dashboard verwendet werden.
-
Auf dem Dashboard werden für den Benutzer wichtige Funktionen und Informationen dargestellt.
-
Es sollten nur Funktionen und Objekte angezeigt werden, die
-
für den jeweiligen Benutzer von Interesse sind.
-
den Arbeitsablauf des Benutzers vereinfachen können.
-
-
Zusammengehörige Funktionen oder Objekte werden als logische Gruppen zusammengefasst, sogenannte Widgets.
-
Die Containerhöhe eines Widgets passt sich dessen Inhalt an.
-
Anordnung von Informationen/Widgets
-
Die Widgets und Informationen werden in drei Bereiche (Spalten) einsortiert.
-
Jeder Inhaltsbereich sollte nur eine Art an Informationen/Widgets enthalten. Die Beschreibung der Inhaltsbereiche erfolgt direkt im Anschluss.
-
Enthält ein Bereich keine Inhalte, was im Regelfall nicht vorkommen sollte, so bleibt der entsprechende Bereich leer.
-
-
Quicklinks (A)
-
In der ersten Spalte können Links zu häufig genutzten Funktionen oder Objekten einzelner Applikationen untergebracht werden.
-
Die Querverweise sind immer in logisch zusammenhängenden Gruppen (Widgets) angeordnet, z.B. „Wiedervorlagen", „Abgelegte Vorgänge", „Häufig benutzte Funktionen".
-
Die Anzahl der Links in einer Gruppe sollte auf 5 pro Gruppe begrenzt sein.
-
Klickt der Benutzer auf einen dieser Querverweise, so wird die zugehörige Applikation aufgerufen und die entsprechende Funktionen oder das entsprechende Objekt wird angezeigt.
-
-
Widgets Applikationen (B)
-
In der mittleren Spalte werden alle Applikationen des Portals angezeigt.
-
Der Bereich für die Widgets wird nochmals in 2 Spalten aufgeteilt.
-
Es sollte auf eine ausgewogene Befüllung der Spalten geachtet werden.
-
Die Spalten können immer von links nach rechts befüllt werden.
-
Existiert nur ein Applikations-Widget, so wird dieses in der linken Spalte platziert die rechte Spalte bleibt leer.
-
Ein Applikationsportal sollte immer über mindestens ein Applikations-Widget verfügen.
-
-
Sofern möglich und sinnvoll besteht ein Applikations-Widget aus einer Gruppe von Applikationen. Die Verlinkungen im Widget führen zu den einzelnen Applikationen.
-
Lässt sich eine Applikation keiner Gruppe zuordnen, so kann sie ein eigenes Widget erhalten. In diesem Fall würden die Links direkt zu den Funktionen (Unterkategorien) der jeweiligen Applikation führen.
-
Generell sollten die Verlinkungen im Widget mit den Verlinkungen der Navigationsebene 2 übereinstimmen.
-
Es sollten nur Applikationen und Gruppen sichtbar sein die für den Benutzer und seine entsprechende Rolle relevant sind.
-
Bei Klick auf eine Applikation oder eine Funktion wird diese im selben Fenster geöffnet.
-
Jede Applikationsgruppe bzw. alleinstehende Applikation wird durch eine farbliche Markierung (Richtlinien zur Farbwahl siehe Kapitel Applikationsfarben) und ein optionales Applikationsicon gekennzeichnet.
-
-
Informationen (C)
-
In der dritten Spalte werden für den Benutzer relevante Informationen angezeigt, die nicht in direktem Zusammenhang mit den Applikationen stehen.
-
Dies können zum Beispiel Benachrichtigungen, Details zum Benutzerkonto oder Kontaktinformationen sein.
-
Existieren weiterführende Inhalte zu einem Bereich, die nicht initial auf dem Dashboard angezeigt werden, werden diese auf eine Dashboard Unterseite ausgelagert (siehe Kapitel Dashboard Unterseite). Die Unterseiten können über einen entsprechenden Link (z.B. „Mehr anzeigen“) oder durch Klick auf ein entsprechendes Subobjekt aufgerufen werden.
-
-
Resizing
-
Wird das Browserfenster vergrößert, so wird der zusätzliche Platz gleichmäßig auf alle Spalten aufgeteilt. Ab einer bestimmten Größe werden die Mauswege zu lang und die Benutzung wird dadurch negativ beeinflusst. Deshalb skalieren die Inhalte nur bis zu einer Auflösung von 1600x1200 px, oberhalb dieser Grenze wird die Anwendung links ausgerichtet und rechts entsteht Whitespace.
-
Wird das Browserfenster über eine kritische Größe (auf der die Daten nicht mehr sinnvoll dargestellt werden können) hinaus verkleinert, so wird das Fenster horizontal und vertikal scrollbar.
-
Aufbau der Widgets
-
Typ A und C
-
Überschrift
-
Icon (optional)
-
Text Label
-
„mehr"-Link (optional)
-
-
Widget-Links
-
Icon (optional)
-
Text Label
-
Besteht ein Link der Gruppe aus Icon und Text, so sollten der Konsistenz halber alle anderen Links dieser Gruppe auch aus Icon und Text bestehen.
-
-
-
Typ B
-
Überschrift
-
Icon Applikationsgruppe/Applikation (optional) - Hat eine Applikationsgruppe/Applikation ein Icon, sollten die anderen Gruppen der Konsistenz halber auch eins erhalten.
-
Name Applikationsgruppe/Applikation
-
Farbmarkierung für die Applikationsgruppe/Applikation
-
-
Widget-Links
-
Icon
-
Text Label
-
-
2.2.5. Dashboard Unterseite
Ist dies der richtige Seitentyp?
-
Dieser Seitentyp wird ausschließlich für Unterseiten des Dashboards verwendet.
Aufbau
-
Header Bereich
-
Seiten-Toolbar
-
Inhaltsbereich
Richtlinien zur Anwendung
-
Eine Dashboard-Unterseite enthält weiterführende Informationen, die nicht vollständig auf dem Dashboard angezeigt werden wie z.B. Nachrichten, Benutzerkonto-Verwaltung.
-
Die Inhalte und deren Layout können variieren.
-
Die Inhalte sollen sich am allgemeinen Layout-Raster ausrichten.
-
Die Seite enthält eine Seiten-Toolbar, deren Funktion es ermöglicht zwischen einzelnen Detailseite einer Trefferliste und zurück zur Trefferliste zu navigieren.
2.2.6. Applikationsseite
Aufbau
-
Header Bereich
-
Linksnavigation (optional)
-
Inhaltsbereich
Ist dies der richtige Seitentyp?
-
Dieser Seitentyp wird eingesetzt, um eine Übersicht über eine Applikation zu erhalten.
Richtlinien zur Anwendung
-
Jede Applikation hat eine eigene Seite.
-
Die Inhalte können je nach Applikation variieren.
-
Die Applikationsseite kann eine optionale Linksnavigation (siehe Kapitel Linksnavigation) enthalten.
-
Entfällt die Linksnavigation, nimmt der Inhaltsbereich den gesamten Platz ein.
-
Befindet sich der Benutzer in einer Applikation, so sollte entweder in der Linksnavigation oder in der ersten Gruppierungsüberschrift im Inhaltsbereich der Name der Applikation erscheinen. Dies schafft einen Widererkennungswert für den Benutzer.
Kennzeichnung von Applikationsgruppen/Applikationen
Sofern möglich und sinnvoll werden Applikationen in Gruppen zusammengefasst. Lässt sich eine Applikation keiner Gruppe zuordnen, so kann sie auch für sich allein stehen. Applikationsgruppen oder für sich stehende Applikationen werden über Applikationsfarben und Applikationsicons gekennzeichnet. Auf dem Dashboard erhält jede Applikationsgruppe oder alleinstehende Applikation ein eigenes Widget.
Richtlinien zur Anwendung
-
Jede Applikationsgruppe bzw. alleinstehende Applikation wird durch eine farbliche Markierung und ein optionales Applikationsicon gekennzeichnet.
-
Farbcodierung (Farbdefinition siehe Kapitel Applikationsfarben)
-
Hauptnavigation – Farbbalken unterhalb des Headers
-
Submenü (Flyout) – Farbbalken am oberen Rand des Menüs
-
Applikations-Widget auf Dashboard – Farbbalken am oberen Rand
-
Titelzeile von Detailseiten – Hintergrundfarbe der Titelzeile
-
Dialoge der Applikation – Farbbalken oberhalb der Titelzeile
-
-
Applikationsicon
-
Verwendung ist optional
-
Wird ein Applikationsicon benutzt, sollte es konsistent an allen vorgesehenen Stellen eingebunden werden.
-
Einsatz des Applikationsicons
-
Dashboard Applikations-Widget (Dashboard Widget – Farbmarkierung und Applikationsicon)
-
Subnavigation (Flyout) (Applikationsicon auf Applikationsseite)
-
In Gruppenüberschriften auf Übersichten einer Applikationsseite (Applikationsicon auf Applikationsseite)
-
-
2.2.7. Applikation Detailseite
Aufbau
-
Header Bereich
-
Titelzeile
-
Seiten-Toolbar
-
Inhaltsbereich
-
Basisdaten (optional)
-
Objektdetails
-
-
Informationsbereich (optional)
Ist dies der richtige Seitentyp?
-
Dieser Seitentyp wird eingesetzt, um Details zu Objekten einer Applikation darzustellen.
Richtlinien zur Anwendung
-
Objekte einer Applikation können Detailinformationen enthalten, diese werden auf der Detailseite dargestellt.
-
Titelzeile (A)
-
Jede Detailseite hat eine Titelzeile in einer der drei Ausprägungen Titel, Headline oder Breadcrumb. Ohne Text in der Titelzeile soll eine Detailseite nicht verwendet werden.
-
Titel: Darstellung des Seitentitels
-
Headline: Darstellung von zusätzlichem Text neben einem Seitentitel
-
Breadcrumb (ähnlich einer Location Breadcrumb): In dieser werden der Objekttitel und der zum Objekt gehörige „Ort" angezeigt (siehe Applikation Detailseite – Beispiel). Dieser Ort kann je nach Anzahl der Hierarchieebenen variieren. An dieser Stelle ist es wichtig dem Benutzer eindeutig zu kommunizieren, welches Objekt er gerade betrachtet und zu welcher Applikation das Objekt gehört.
-
Hier wird nicht der vom User gegangene Weg zum angezeigten Objekt dargestellt.
-
Ein Rücksprung auf die Liste der Objekte soll nicht enthalten sein, da es dafür den Button "Zurück zu Liste" in der Seiten-Toolbar gibt.
-
Beispiel 1 Titelstruktur für 2 Hierarchieebenen
-
Label Hierarchieebne 2: Objektname / ID
-
-
Beispiel 2 Titelstruktur für 3 Hierarchieebenen
-
Label Hierarchieebne 2 – Label Hierarchieebne 3: Objektname / ID
-
-
-
-
Seiten-Toolbar (B)
-
Die Seiten-Toolbar zeigt Funktionen, welche für die gesamte Seite gelten z.B. „Zurück zur Liste", „Seite drucken", „Hilfe", mehr Informationen siehe Kapitel Toolbar.
-
-
Informationsbereich (C)
-
Der Informationsbereich ist initial ausgeblendet und kann über einen entsprechenden Button in der Toolbar eingeblendet werden.
-
Dieser Bereich sollte hilfreiche und ergänzende Informationen zum angezeigten Objekttyp und dessen Bearbeitung enthalten.
-
Der Informationsbereich und der entsprechende Button in der Seiten-Toolbar sollten nur vorhanden sein, wenn der Informationsbereich mit sinnvollen und für den Benutzer nützlichen Informationen gefüllt werden kann.
-
Ist der Informationsbereich eingeblendet, so wird der Inhaltsbereich zusammengeschoben.
-
-
Inhaltsbereich (D)
-
Im Inhaltsbereich werden die Objektdetails angezeigt.
-
Der Inhaltsbereich kann Kopfdaten enthalten.
-
Die Kopfdaten können optional eingebunden werden. Sie können dem Benutzer helfen wichtige Daten von komplexen Objekten auf einen Blick zu erkennen.
-
Es kann sinnvoll sein die Kopfdaten mit einem Expander zu kombinieren. So hat der Benutzer die Möglichkeit, diese Daten auszublenden, wenn er sie nicht benötigt.
-
-
Zur Strukturierung umfangreicher Informationen werden Gruppierungs-Container und Expander (Progressive Disclosure) eingesetzt. Hierbei werden Informationen sinnvoll gruppiert.
-
Zur weiteren Strukturierung, und um langes vertikales Scrollen auf einer Seite zu vermeiden, können Tabs zum Einsatz kommen.
-
2.3. Dialoge
Dialoge sind sekundäre Fenster die oberhalb des Hauptfensters angezeigt werden. Dialoge dienen der Auswahl und Eingabe von Daten. Sie dienen nicht dazu, komplexe Datenmengen innerhalb eines Objekts zu strukturieren. Beispiele für die Nutzung von sekundären Fenstern sind:
-
Erweiterte Funktionalitäten zur Bearbeitung von Prozessen und Aktionen (z.B. Daten editieren)
-
Komplexe Optionen, die aus Platzmangel im Arbeitsbereich nicht angezeigt werden sollten.
-
Meldungsdialoge zur Anzeige von z. B. Fehlernachrichten.
Aufbau
-
Titelzeile (A)
-
Inhaltsbereich (B)
-
Dialogbuttons (C)
Richtlinien zur Anwendung
-
Dialoge sind sekundäre Fenster, die über dem primären Fenster liegen.
-
Dialoge sind modal, d. h. das aufrufende Fenster kann nicht erreicht werden, solange der Dialog geöffnet ist.
-
Die Überlagerung mehrerer Dialogfenster sollte vermieden werden.
-
Ist die Überlagerung von Dialogen nicht zu vermeiden, müssen die Dialoge immer in der Reihenfolge geschlossen werden, in der sie geöffnet wurden.
-
Größe von Dialogen
-
Dialoge passen ihre Größe dem gezeigten Inhalt an.
-
Maximalgröße soll sich an Browser-Fenster und Anwendung im Hintergrund orientieren. Ein schmales Padding zur Abhebung von der Seite im Hintergrund reicht aus.
-
-
Die Position der Dialogbuttons sollten einheitlich über die verschiedenen modalen Dialoge der Anwendung sein. Der modale Dialog in seiner Gesamtheit darf bei Bedarf scrollbar sein. Eine permanent sichtbare Kopf- und Fußzeile ist nicht verpflichtend.
-
Bei Dialogen, in denen Formulardaten bearbeitet werden, sollte das Layout der Elemente im Dialog dem Layout im Read-Only Modus entsprechen (i.d.R. dreispaltig).
-
Titelzeile (A)
-
Der Titel des Dialogs sollte aussagekräftig sein und dem Benutzer genau zeigen, welche Interaktionen er für welche Objekte in diesem Dialog durchführt. Der Dialogtitel kann aus einem Haupttitel und einem optionalen Subtitel bestehen.
-
Der Haupttitel sollte die Art der Interaktion und den Objektnamen enthalten, z.B. „Personalie XY löschen“.
-
Der Subtitel ist optional und kann zur genaueren Spezifizierung genutzt werden, z.B. „Personalie hinzufügen - Registerdatensatz XY“ wobei „Personalie hinzufügen" ein Haupttitel wäre und „Registerdatensatz XY“ ein Subtitel.
-
Der Titel enthält die Farbmarkierung der entsprechenden Applikationsgruppe.
-
-
Im Inhaltsbereich (B) kann an oberster Stelle ein Hinweis- oder Validierungstext angezeigt werden. Der Inhalt rutscht dann um die entsprechende Höhe nach unten. Das Dialogfenster kann sich gegebenenfalls um diese Höhe vergrößern (siehe Dialog (Wizard) – Beispiel Validierung).
-
Der Bereich der Dialogbuttons (C) präsentiert je nach Kontext verschiedene Buttons.
2.3.1. Meldungsdialoge
Meldungsdialoge werden eingesetzt, wenn der Benutzer in seinem Arbeitsablauf unterbrochen werden muss. Dies ist z. B. der Fall,
-
wenn ein Vorgang ohne weitere Auswahl einer Möglichkeit nicht beendet werden kann (z. B. Nachfrage vor dem Löschen eines Objektes).
-
wenn ein Datenverlust droht (z. B. Änderungen speichern und beenden oder Änderungen verwerfen und beenden).
-
wenn der Benutzer über einen (unvorhergesehenen) nicht durchführbaren Vorgang informiert werden muss (z. B. Abbruch der Internetverbindung).
Aufbau
-
Titelzeile (A)
-
Meldungsart-Icon (B)
-
Beschreibung und zusätzliche Informationen (C)
-
Dialogbuttons (D)
-
Es sollte geprüft werden, ob der Benutzer den Dialog bei repetitiven Vorgängen ausstellen kann – dies geschieht mit Hilfe einer Check Box „Diesen Dialog in Zukunft nicht mehr anzeigen“.
Richtlinien zur Anwendung
-
Meldungsdialoge werden als Modaler Dialog aus einem primären Fenster geöffnet.
-
Ein Meldungsdialog kann nicht aus einem anderen Meldungsdialog geöffnet werden.
-
Die Titelzeile (A) des Meldungsdialogs dient in der Regel dazu, die Funktion zu identifizieren, die den Dialog getriggert hat. Versucht der Benutzer z.B. ein Objekt zu löschen, so erscheint ein Meldungsdialog mit der Überschrift „Objekt löschen“. Die Überschrift dient nicht dazu, eine Beschreibung des Problems oder konkrete Anweisungen zu liefern.
-
Das Icon (B) dient der Identifizierung der Meldungsart und muss daher der jeweiligen Meldungsart angepasst werden. Es wird links von der Beschreibung angezeigt.
-
Die Beschreibung (C) hingegen sollte in einem Satz kurz und prägnant die Kernaussage des Dialoges präsentieren. Detail-Informationen wie z. B. Pfadangaben oder URLs sollten in der Beschreibung nicht angezeigt werden.
-
Sollten zusätzliche Informationen (C) notwendig sein, so können diese unterhalb der Beschreibung eingeblendet werden. Zusätzliche Informationen können z. B. sein:
-
Schritte zur Behebung eines Problems.
-
Hinweise, wie ein Problem in Zukunft vermieden werden kann.
-
Fehlercodes.
-
Pfad- oder URL-Angaben.
-
Sollten ausführliche zusätzliche Informationen notwendig sein, wie z. B. ein Exception Text, der für Support-Anfragen benötigt wird, so können diese mit Hilfe eines Expanders (Progressive Disclosure) zunächst ausgeblendet und bei Bedarf vom Benutzer eingeblendet werden.
-
-
Der Bereich der Dialogbuttons (D) präsentiert je nach Meldungsart und Kontext verschiedene Buttons. Folgende Richtlinien für die Handhabung der Buttons sollten befolgt werden:
-
Wird vom Benutzer eine Entscheidung gefordert, so ist die Nennung der entsprechenden Aktion (z.B. Löschen, Entfernen usw.) den generischen Begriffen Ja/Nein vorzuziehen. Niemals sollte jedoch OK/Abbrechen verwendet werden. Ja/Nein fordert vom Benutzer ein Reflektieren der Entscheidung, während OK häufig geklickt wird, ohne über die Entscheidung nachzudenken.
-
-
Der Button zum Abbruch der Aktion heißt immer Abbrechen.
-
Buttons zum Quittieren von Fehlermeldungen oder Informationen sollten statt mit einem generischen OK mit Schließen bezeichnet werden. OK würde implizieren, dass der Fehler als solcher in Ordnung ist.
-
Es sollte immer einen Default-Button geben, der mit der Enter/Return-Taste betätigt werden kann. Der Abbrechen-Button sollte stets mit der Escape-Taste bedienbar sein.
-
Es muss auf eine korrekte und konsistente Beschriftung der Buttons geachtet werden.
-
Hat der Benutzer eine Entscheidung zu treffen, ist es sehr wichtig darauf zu achten, die korrekte Kombination von Buttons anzuzeigen. Folgende Kombinationen werden typischerweise verwendet:
-
Spezifische Beschreibungen: <Aktion ausführen> / <Aktion nicht ausführen><Aktion ausführen> / <Abbrechen><Aktion ausführen> / <Aktion nicht ausführen> / Abbrechen
-
Ja-Nein-Kombinationen: Ja / NeinJa / Nein / Abbrechen
-
Ein häufig auftretendes Usability-Problem ist die Anzeige einer Ja/Nein/Abbrechen-Kombination, wobei Nein und Abbrechen dieselbe Funktion haben. Die Anzeige einer solchen Kombination muss ausgeschlossen werden.
-
-
2.3.2. Wizard
Mit „Wizard“, auch Assistent genannt, wird eine geführte Abfolge von Interaktionsschritten bezeichnet. Das Konzept eignet sich für Anwendungsfälle, bei denen eine starke Führung des Benutzers erforderlich ist oder um z. B. sehr komplexe Objekte anzulegen. Die Einzelschritte stellen hier jeweils einzelne Teilaufgaben dar. Durch die Aufteilung der Interaktion auf separate Schritte und Inhaltsseiten verringert sich die Gesamtkomplexität für den Benutzer.
Aufbau
-
Titelzeile (A)
-
Schrittanzeige (B)
-
Inhaltsbereich (C)
-
Dialogbuttons (D)
Ist dies der richtige Dialog Typ?
-
Wizards werden für komplexe Aufgaben verwendet, die in Einzelschritte eingeteilt werden können.
-
Ein Wizard sollte verwendet werden, wenn zwischen einzelnen Schritten einer Aufgabe enge Abhängigkeiten bestehen, z. B. wenn ein Schritt erst bearbeitet werden kann, nachdem der vorherige beendet wurde.
-
Besteht kein Zusammenhang zwischen einzelnen Schritten oder Phasen, sollte kein Wizard verwendet werden.
Richtlinien zur Anwendung
-
Wizards werden innerhalb eines modalen Dialogs geöffnet.
-
Größe von Wizards
-
Die Dialoggröße orientiert sich an dem Schritt mit dem größten Inhalt.
-
Der Dialog sollte möglichst nicht mehr als 2/3 des Screens bedecken.
-
Die Dialoggröße sollte möglichst so gewählt werden, dass die Dialogbuttons ohne zu scrollen zu sehen sind.
-
Das Dialogfenster behält innerhalb einer Schrittfolge immer die gleiche Größe. So wird ein Positionswechsel der Dialog-Buttons verhindert.
-
-
Die Titelzeile (A) dient dazu die Funktion des Wizards zu identifizieren. Es gelten die gleichen Regeln wie für Titelzeilen von Dialogen.
-
Schrittanzeige (B) dargestellt.
-
Die einzelnen Schritte des Wizards werden unterhalb der Titelzeile in einer Schrittanzeige dargestellt.
-
Der aktuell ausgewählte Schritt ist visuell hervorgehoben.
-
Navigation über die Schrittanzeige ist möglich, wenn die Schritte aktiviert sind.
-
Navigation über die Schrittanzeige ist möglich, wenn die Schritte aktiviert sind.
-
Zurücknavigieren: Bereits durchgeführte Schritte können angeklickt werden und der Inhalt des jeweiligen Schrittes wird angezeigt.
-
Vornavigieren: Zukünftige Schritte können nur ausgewählt werden, wenn die Eingaben des aktuellen Schrittes die des zukünftigen Schrittes nicht beeinflussen.
-
-
-
Inhaltsbereich (C) werden die eigentlichen Inhalte der einzelnen Schritte angezeigt.
-
Dialogbuttons (D)
-
Per Klick auf die Dialog-Buttons kann der Benutzer vor und zurück navigieren sowie den Vorgang im Dialog abbrechen.
-
Im ersten Schritt ist der „Zurück“-Button deaktiviert.
-
Im letzten Schritt ändert sich das Text-Label des „Weiter“-Buttons (z.B. „Abschließen“).
-
Optional kann links unten ein „Ablegen“-Button angezeigt werden. Diese Funktion kann beim Neu-Anlegen von komplexen Objekten nützlich sein. Die „Ablegen“-Funktion ermöglicht es dem Benutzer den aktuellen Vorgang zu unterbrechen und zwischen zu speichern. Die abgelegten Vorgänge werden auf dem Dashboard angezeigt.
-
Beim „Abbrechen“ wird der Dialog geschlossen und die eingegebenen Daten gehen verloren.
-
Beim „Speichern“ wird der Dialog geschlossen und die eingegebenen Daten werden gespeichert.
-
2.4. Drucklayout
Wenn Daten aus der Applikation gedruckt werden sollen, muss der Inhalt für den Druck optimiert werden. Die Definitionen des Druck-Layouts können über ein CSS Druck-Stylesheet geregelt werden. Zum Beispiel sollten nicht benötigte Elemente ausgeblendet und Farben für den Druck optimiert werden.
Richtlinien zur Anwendung
-
Es werden nur relevante Inhalte gedruckt.
-
Nicht relevante Daten werden ausgeblendet.
-
Header
-
Linksnavigation
-
-
Um Tinte zu sparen, sollten die Farben für das Drucklayout auf das nötige Minimum reduziert werden.
-
Farbige Hintergründe sollten gegen weiß ausgetauscht werden. Es sei denn sie enthalten wichtige Informationen wie Farbcodierungen für bestimmte Elemente.
-
Die Schriftfarbe behält die für die Webseite definierten Standardgrauwerte bei.
-
-
Die Inhalte sollten so formatiert sein, dass sie möglichst A4 hochkant ausgedruckt werden können.
-
Auf der gedruckten Seite sollte ein Bereich für Metainformationen bereitgestellt werden.
-
Die Metainformationen werden oben auf jeder gedruckten Seite platziert.
-
Der Metabereich kann Informationen wie Datum, Seitenzahl und Benutzername enthalten.
-
-
Der Benutzer hat zwei Möglichkeiten einen Druckvorgang zu starten.
-
Nutzt der Benutzer die Druck-Funktion des Browsers (Datei > Drucken), dann werden die oben beschriebenen Regeln angewendet, es findet keine weitere Optimierung des Layouts statt (siehe Seitendruck über Druck-Funktion des Browsers).
-
Einige Inhalte der Anwendung haben eine explizite Druck-Funktion. Diese Inhalte werden noch individuell für den Druck optimiert (Beispiel siehe Detailseite – Darstellung in Druckvorschau). Richtlinien hierfür sind im Kapitel Drucken bestimmter Inhaltsbereiche beschrieben.
-
2.4.1. Drucken bestimmter Inhaltsbereiche
Neben der allgemeinen Druck-Funktion des Browsers kann der Benutzer über explizite Drucken-Buttons bestimmte Bereiche ausdrucken.
Richtlinien zur Anwendung
-
Es gelten die allgemeinen Druck-Regeln wie oben beschrieben.
-
Soll ein bestimmter Bereich der Anwendung gedruckt werden, wie z.B. eine Tabelle oder eine Detailseite, so werden hierfür erweiterte Druck-Layout-Regeln angewendet.
-
Druckvorschau
-
Die Daten werden zunächst in einer Druckvorschau aufbereitet und auf einer separaten Seite angezeigt.
-
In der Druckvorschau ist ganz oben ein Drucken-Button eingebunden. Über diesen kann der Benutzer den Druck starten.
-
-
Es werden nur relevante Daten gedruckt.
-
Navigationselemente, Buttons, Toolbars und ähnliche Bedienelemente werden ausgeblendet.
-
Werden Container gedruckt, die nicht dargestellte Informationen enthalten (Tabs, Master-Detail), so werden immer alle Inhalte untereinander wiedergegeben.
-
Dabei sollte für jeden Container eine neue Überschrift eingebunden werden (sofern nicht schon im Layout vorhanden). So kann der Benutzer genau erkennen, an welcher Stelle ein Informationsbereich aufhört und wo ein neuer beginnt.
-
-
Jede gedruckte Seite enthält Metainformationen
-
Die Metainformationen sind auf jeder gedruckten Seite ganz oben platziert.
-
Enthält folgende Informationen
-
Logo des Portalanbieters
-
Farbmarkierung des Applikationsportals
-
Logo des Applikationsportals
-
Datum
-
Aktuelle Seite
-
Gesamtseitenanzahl
-
Name des eingeloggten Benutzers
-
Drucken Button
-
-
-
Drucken von Tabellen
-
Es sollte darauf geachtet werden, dass die Inhalte der Spalten immer vollständig dargestellt werden und lesbar sind.
-
Falls eine Tabelle nicht auf eine Seite passt, wird der Inhalt auf mehrere Seiten verteilt.
-
-
Drucken von Formularen
-
Um die Lesbarkeit von Formularinhalten zu gewährleisten, werden diese einspaltig gedruckt.
-
Die Spalten der Formulare werden untereinander einspaltig dargestellt (siehe Detailseite – Darstellung in Druckvorschau).
-
3. Häufige Aufgaben
Im Folgenden werden häufig durchgeführte Aufgaben beschrieben. Der Fokus in diesem Kapitel liegt auf den Interaktionen, die während dieser Aufgaben ausgeführt werden müssen.
In den Kapiteln Bedienelemente und Design Patterns können die jeweiligen Spezifikationen der benutzen Elemente nachgelesen werden.
3.1. Objekt suchen
In den einzelnen Applikationen kann nach existierenden Objekten gesucht werden. Sofern eine Suche von der Applikation vorgesehen bzw. für die Applikation sinnvoll ist.
Suche über Suchformular
Die Suche erfolgt über ein Suchformular, welches je nach Applikation unterschiedlich komplex sein kann.
Richtlinien zur Interaktion
-
Die Suche eines Objektes erfolgt über das Ausfüllen und Abschicken eines Formulars (A) (siehe Objekt suchen).
-
Alle Suchfelder können durch Klicken auf „Suche leeren“ zurückgesetzt werden.
-
Mit Klick auf Suchen wird die Suche mit den eingegebenen Daten durchgeführt.
-
Die vom System gefundenen Objekte werden in der Ergebnistabelle (B) unterhalb des Suchformulars angezeigt.
-
Kann die Suche aufgrund von fehlerhaften Eingaben nicht durchgeführt werden, so wird im Hinweisfeld und an den entsprechenden Eingabefeldern amodales Feedback (C) angezeigt (siehe Objekt suchen).
-
Werden keine Ergebnisse gefunden, wird dem Benutzer entsprechendes Feedback (D) in der Ergebnistabelle angezeigt.
| Fenstertyp / Pattern | Bedienelemente |
|---|---|
Formulare |
Eingabefelder |
Button |
|
Tabelle |
Liste von Objekten filtern
Benutzer können auch innerhalb einer vorhandenen Liste aus Objekten (z.B. Tabelle) nach einem bestimmten Objekt suchen. In solchen Fällen wird auch von „filtern“ gesprochen.
Richtlinien zur Interaktion
-
Der Benutzer kann die angezeigten Objekte mit Hilfe von Filtern einschränken.
-
Wählt der Benutzer eine Filteroption (beispielsweise Toggle-Filter oder Filter-Zeile) so werden alle Objekte ausgeblendet, die nicht dieser Filteroption entsprechen.
-
Der Benutzer hat immer die Möglichkeit sich alle Objekte anzeigen zu lassen.
| Fenstertyp / Pattern | Bedienelemente |
|---|---|
Filter |
Tabelle |
Liste |
Positionierung der Buttons auf der Suchmaske
Die abschließenden Buttons am unteren rechten Rand sollten wie bei Dialogen durch eine horizontale Linie abgegrenzt werden. Wichtig ist dabei, dass die horizontale Linie nicht bis zum Rand gehen darf, sondern wie die Controls einen Abstand zu ihrem umgebenden Container einhält.
3.2. Objekt anzeigen
Vorschau
In Tabellen kann der Benutzer sich eine Vorschau eines Objektes anzeigen lassen.
Richtlinien zur Interaktion
-
In einer Tabelle mit Objekten kann der Benutzer die Vorschau eines Objektes einsehen.
-
Die Vorschau wird mittels Klick auf einen Vorschau Button angezeigt.
-
Zu einem Zeitpunkt ist jeweils immer nur eine Vorschau sichtbar.
| Fenstertyp / Pattern | Bedienelemente |
|---|---|
Datentabelle |
- |
Datenvorschau |
|
Expander (Progressive Disclosure) |
Detailseite
Ein Objekt kann eine Detailseite haben. Auf dieser werden dem Benutzer ausführliche Informationen zu dem Objekt angezeigt.
Schnellnavigation
Optional kann sich zur schnellen Navigation zwischen mehreren Ergebnissen ein Control zentriert in der Seiten-Toolbar befinden. Es besteht aus Zurück- und Vor-Buttons, die durch die Anzeige der aktuellen Position und der Gesamtmenge getrennt sind. Die Gesamtmenge entspricht der Anzahl der Objekte in der dahinterliegenden Übersichtsliste.
Richtlinien zur Interaktion
-
Durch Klick auf den Bezeichner des jeweiligen Objektes (Nummer, ID, Name etc.), einen Doppelklick auf das gesamte Objekt oder die Toolbar Funktion Öffnen, gelangt der Benutzer zu dessen Detailseite.
-
Auf dieser Seite werden dem Benutzer alle Informationen, die zu dem Objekt existieren, zugänglich gemacht.
-
Über einen Link in der Seiten-Toolbar kann der Benutzer jederzeit zurück zur Trefferliste springen.
-
Auch beim Navigieren zwischen Ergebnissen muss die Browser-Funktion "Vor- und Zurück" unterstützt werden.
| Fenstertyp / Pattern | Bedienelemente |
|---|---|
Applikation Detailseite |
- |
3.3. Objekt bearbeiten
Richtlinien zur Interaktion
-
Das Editieren der Objektdaten erfolgt in einem Modalen Dialog (siehe Objekt editieren).
-
Der Modale Dialog wird über eine Bearbeiten Funktion aufgerufen.
-
Die Daten werden über Eingabefelder oder andere Eingabe Patterns angepasst.
-
Beim Speichern der korrigierten Daten werden diese in das Objekt übernommen und der Dialog wird geschlossen.
-
Wird die Korrektur abgebrochen, werden die Änderungen verworfen und der Dialog wird geschlossen.
-
Besteht ein Objekt aus mehreren Teilobjekten, so lässt sich jedes Teilobjekt separat editieren.
| Fenstertyp / Pattern | Bedienelemente |
|---|---|
Dialoge |
Toolbar Button |
Toggle Button |
|
Icon Button |
3.4. Objekt löschen
Ein Objekt kann aus mehreren Teilobjekten bestehen. In diesen Fällen lässt sich jedes Teilobjekt separat löschen.
Richtlinien zur Interaktion
-
Das Löschen erfolgt über einen Löschen-Button, der z.B. in der Toolbar eines entsprechenden Objektes positioniert sein kann.
-
Bei kritischen Daten ist es sinnvoll eine Sicherheitsabfrage dazwischen zu schalten, ehe das Objekt gelöscht wird. Dies geschieht über einen Meldungsdialog.
-
Wird der Löschvorgang im Meldungsdialog bestätigt, so wird das Objekt gelöscht und somit auch aus der Detailseite entfernt. Anschließend wird der Dialog geschlossen.
-
Wird der Löschvorgang abgebrochen, bleibt das Objekt unverändert.
| Fenstertyp / Pattern | Bedienelemente |
|---|---|
Dialoge |
Toolbar Button |
Toggle Button |
|
Icon Button |
3.5. Objekt neu anlegen
Anlegen eines einfachen Objektes
Richtlinien zur Interaktion
-
Die Erstellung eines Objektes erfolgt über einen Dialog.
-
Der Dialog wird über einen Button aufgerufen.
-
Die Daten werden über Eingabefelder oder andere Eingabe Elemente erfasst.
-
Beim Speichern der neuen Daten wird das Objekt angelegt und der Dialog wird geschlossen. Dabei wird je nach Fall zur aufrufenden Seite oder zur Detailseite des Objektes gesprungen. Das angelegte Objekt sollte dabei immer im Blickfeld des Benutzers liegen – z.B. neu erstellte Objektzeile sollte selektiert und sichtbar sein.
-
Bei Abbruch des Vorgangs gehen die Daten verloren und der Dialog wird geschlossen.
| Fenstertyp / Pattern | Bedienelemente |
|---|---|
Dialoge |
- |
Anlegen eines komplexen Objektes
Richtlinien zur Interaktion
-
Komplexe Objekte werden über einen Wizard angelegt.
-
Die Anlage neuer Objekte kann über eine Funktion in der Toolbar von Tabellen oder Gruppierungs-Containern erfolgen.
-
Der Wizard führt den Benutzer Schritt für Schritt durch die Erstellung des neuen Objektes.
-
Um Objekt-Dubletten zu verhindern, sollte innerhalb des Wizards eine Dubletten-Prüfung erfolgen.
-
Über die Buttons Weiter und Zurück als auch über die Wizard Schrittanzeige kann der Benutzer zwischen den Schritten navigieren.
-
Über einen optionalen Ablage Button kann der Benutzer bestimmte Vorgänge für eine bestimmte Zeit ablegen (zwischenspeichern). Die Bearbeitung kann so zu einem späteren Zeitpunkt fortgeführt werden. Die abgelegten Objekte können an einem zentralen Punkt gesammelt werden. Beispielsweise auf dem Dashboard in der Spalte „Wichtige Objekte“.
-
Der Benutzer hat zu jedem Zeitpunkt die Möglichkeit den Wizard über einen Button abzubrechen. Der Wizard wird geschlossen und die Daten gehen verloren.
-
Schließt der Benutzer den Vorgang erfolgreich ab, wird das neue Objekt gespeichert. Der Benutzer erhält immer im letzten Schritt des Wizards eine Erfolgsmeldung und Zusammenfassung der neu angelegten Daten.
-
Nach dem Speichern kann der Benutzer zur Detailseite des neuen Objektes oder zurück zum Ausgangspunkt navigieren.
-
Springt der Benutzer zurück zum Ausgangspunkt so sollte das neue Objekt im Blickfeld des Benutzers angezeigt werden – z.B. neues Objekt sollte in einer Tabelle selektiert sein.
| Fenstertyp / Pattern | Bedienelemente |
|---|---|
Wizard |
Eingabefelder |
Formulare |
Button |
4. Bedienelemente
In diesem Kapitel werden Bedienelemente besprochen und allgemeine Eigenschaften der Bedienelemente beschrieben.
-
Testbarkeit der Bedienelemente
-
Kontextabhängige Darstellung
-
Status
-
Resizing
Testbarkeit der Bedienelemente
Um die Grundlage für automatische Tests (Einsatz von Testframeworks) von Bedienelementen einer Web-basierenden Anwendung zu schaffen, sollten allen Maskenobjekten im HTML-Sourcecode eindeutige IDs zugeordnet sein (s.a. Abschnitt: Testbarkeit von Web-basierenden Anwendungen).
Kontextabhängige Darstellung
Falls bestimmte Elemente im Kontext nicht relevant sind, muss dies im User Interface berücksichtigt werden. Nicht relevante Komponenten können deaktiviert werden, so dass der Benutzer sie zwar sehen, jedoch nicht bedienen kann. Alternativ können nicht relevante Informationen und Komponenten ausgeblendet werden, so dass der Benutzer sie nicht sehen kann.
Ausblenden nicht relevanter Elemente Elemente, die dauerhaft nicht relevant sind, sollten ausgeblendet werden, so dass sie für den Benutzer nicht sichtbar sind. Hierzu zählen insbesondere Elemente, deren Relevanz auf Benutzer-Rollen basiert. Benutzer, die aufgrund ihrer Rolle z.B. keinen Zugriff auf bestimmte Funktionen haben, sollten diese auch nicht sehen. Im Folgenden ist zu sehen wie beispielsweise ein Objekt (hier eine Gruppierung) für Benutzer mit unterschiedlichen Rechten aussehen könnte.
-
Benutzerrechte zum Löschen und Bearbeiten von Objekten vorhanden zeigt ein Objekt, für das der Benutzer die Rechte zur Bearbeitung besitzt.
-
Benutzerrechte zum Löschen und Bearbeiten von Objekten nicht vorhanden zeigt ein Objekt, für das der Benutzer keine Rechte zur Bearbeitung besitzt.
Deaktivieren nicht relevanter Elemente Elemente, die nur temporär nicht relevant sind, sollten hingegen deaktiviert werden. Hierzu zählen u. a.:
-
Tool Bar-Funktionen, die z. B. von einer entsprechenden Selektion abhängig sind.
-
Bedienelemente mit Abhängigkeiten, die zunächst von anderen Elementen wie z. B. einer Check Box freigeschaltet werden müssen.
-
Komponenten, die nur in einem bestimmten Modus bedienbar sind.
Verschiedene Bedienelemente, in der Regel Eingabeelemente, werden weiterhin zwischen den Zuständen deaktiviert und nur-lesbar unterschieden. Siehe hierzu das Kapitel Status von Bedienelementen.
Status von Bedienelementen
Je nach Kontext können manche Elemente, in der Regel Eingabeelemente, verschiedene Zustände annehmen.
Regeln zur Anwendung
-
Die drei häufigsten Zustände sind:
-
Normal
Das Element kann vom Benutzer bedient werden.
-
Deaktiviert (Disabled)
Das Element kann nicht bedient werden. Es ist z.B. aufgrund der Auswahl einer anderen Option deaktiviert. Eventuell zuvor eingegebene Werte werden nicht berücksichtigt. Das Element selbst, dessen Beschriftung sowie eventuell existierende Eingaben, werden „ausgegraut“ dargestellt.
-
Read-Only (nur lesbar)
Das Element kann nicht direkt bedient werden. Eventuell kann es jedoch mittelbar bedient werden, z.B. durch die Änderung eines anderen Wertes.
-
-
Wird die Maus über ein Eingabefeld bewegt, ändert sich die Mauszeiger-Darstellung (Maus-Pointer) zu einem Eingabe-Cursor (ähnlich einem großen I). Auch bei read-only Feldern wird der Mauszeiger beibehalten, damit Text markiert und kopiert werden kann. Bei deaktivierten Eingabe-Feldern ändert sich die Mauszeiger-Darstellung hingegen zu einem „Verbotsschild“, um unmissverständlich darzustellen, dass solche Felder in keiner Weise bedient werden können.
-
Weitere Zustände:
-
Hover (MouseOver)
Wird die Maus über ein Element bewegt so wird dieses Element mittels eines Hover-Effekts optisch hervorgehoben.
-
Pressed
In dem Moment in dem per Maus oder Tastatur ein Element ausgewählt wird, wird dieses als Pressed dargestellt.
-
Focus
Der Focus liegt auf einem Element. Der Focus kann per Mausklick oder mit Hilfe der Tabulatortasten der Tastatur geändert werden.
-
Selektiert
Ein Element ist ausgewählt und bleibt in diesem Zustand.
-
Validierung
Elemente die einer Validierung unterzogen werden (vor allem in Formularen) werden bei fehlerhaften Eingaben gesondert hervorgehoben.
-
Resizing von Bedienelementen
Bedienelemente sind in der Regel von Größenänderungen des Browsers nicht betroffen.
Es gibt einige Ausnahmen wie beispielsweise Tabellen. Diese Ausnahmen werden an den entsprechenden Stellen erläutert.
4.1. Button
Ein Button ist ein Bedienelement, welches per Klick eine direkte Aktion ausführt. Buttons enthalten entweder ein Textlabel, ein Icon oder eine Kombination aus beidem.
Zustände
-
Ein Button kann mehrere Zustände einnehmen
-
Normal
-
Hover
-
Pressed
-
Deaktiviert
-
Fokussiert
-
Ist dies das korrekte Bedienelement?
-
Buttons werden für Aktionen verwendet, die direkt ausgeführt werden.
-
Buttons dürfen nicht genutzt werden, um Selektionen aus einer Gruppe von Optionen zu treffen, stattdessen werden Radiobuttons, Checkboxen oder Toggle Buttons verwendet.
-
Wenn das Bedienelement in einem Fließtext angezeigt werden soll, wird kein Button verwendet, sondern ein Link.
Richtlinien zur Anwendung
-
Beschriftung
-
Das Label sollte kurz und selbsterklärend sein.
-
Ruft ein Button einen Dialog auf, sollte der resultierende Dialog als Fenster-Titel die Beschriftung des Buttons wiederholen.
-
Das Label sollte die auszuführende Aktion widerspiegeln (Öffnen, Löschen, Speichern, Weiter).
-
-
Größe
-
Die Breite eines Buttons soll sich generell am enthaltenen Label orientieren.
-
Es ist zulässig und gewollt, dass nebeneinanderstehende Buttons unterschiedliche Breite haben, wenn die Labels unterschiedlich groß sind.
-
Die Mindestbreite für Buttons beträgt jedoch 100 Pixel.
-
-
Ein Button sollte nach Möglichkeit so platziert werden, dass eventuelle Beziehungen zu anderen Elementen deutlich werden.
-
Falls nach einem Button-Klick die resultierende Aktion nur verzögert erkennbar ist, sollte dies durch eine System-Rückmeldung kenntlich gemacht werden (z. B. durch eine Fortschrittsanzeige).
-
Standard Button zeigt den primären Button-Stil, der eingesetzt wird, wenn keine sonstige Definition vorhanden ist.
-
Buttons sollten dann deaktiviert (disabled) sein, wenn sie durch Interaktion auf dem gleichen Screen – z.B. durch Durchführung der Suche – aktiviert werden können.
-
Wenn die durch den Button hervorgerufene Aktion für den Benutzer nicht selbsterklärend ist, sollte ein Tooltip unterstützend angezeigt werden.
4.1.1. Toolbar Button
Toolbar Buttons werden ausschließlich in Toolbars eingesetzt.
Zustände
-
Normal
-
Hover
-
Pressed
-
Focus
-
Deaktiviert
Ist dies das korrekte Bedienelement?
-
Toolbar Buttons werden in der Toolbar eingesetzt.
Richtlinien zur Anwendung
-
Toolbar Buttons bestehen aus einem Icon und Label.
-
Sie haben im Gegensatz zu Standardbuttons keinen Farbigen Hintergrund.
-
Befinden sich mehrere Buttons in einer Toolbar so können sie durch vertikale Trennlinien zu Gruppen zusammengefasst werden.
-
Mehr allgemeingültige Regeln werden im Kapitel Toolbar beschrieben.
4.1.2. Menü Button
Menü Buttons können aus Platzgründen zusammengehörige Funktionen zusammenfassen.
Zustände
-
Normal
-
Hover
-
Pressed
-
Focus
-
Deaktiviert
Ist dies das korrekte Bedienelement?
-
Menü Buttons werden hauptsächlich in Toolbars eingesetzt.
-
Menü Buttons müssen mehrere Funktionen beinhalten. Die Funktionen sollten immer in einem logischen Zusammenhang stehen. Zum Beispiel kann man unter dem Button „Exportieren“ die Funktionen „Exportieren als XLS“, „Exportieren als PDF“, „Exportieren als PNG“ zusammenfassen.
Richtlinien zur Anwendung
-
Der Menü Button besteht aus einem Icon, einem Label und einem Pfeil Icon.
-
Wird der Menü Button geklickt, werden die Funktionen wie in einem Dropdown Menü angezeigt (siehe Menü Button - Beispiel).
4.1.3. Toggle Button
Toggle Buttons kommen zum Einsatz, wenn eine bestimmte Funktion oder Eigenschaft ein- und ausgeschaltet werden muss. Die häufigsten Szenarien für den Einsatz von Toggle Buttons sind das schnelle Umschalten von Ansichten oder von Filterkriterien (siehe Kapitel Toggle-Filter).
Zustände
-
Normal
-
Hover
-
Pressed
-
Selektiert
Ist dies das korrekte Bedienelement?
-
Toggle Buttons können genutzt werden, um binäre Zustände innerhalb einer Toolbar umzuschalten.
-
Soll der Toggle Button statt in einer Toolbar in-place verwendet werden, so sollte an dessen Stelle die Nutzung von Checkboxen oder Radio Buttons in Betracht gezogen werden.
Richtlinien zur Anwendung
-
Per Default ist immer ein Wert selektiert.
-
Toggle Buttons können Textlabels oder Icons beinhalten.
4.1.4. Icon Button
Icon Buttons sind Buttons die kein sichtbares Label haben, sondern nur aus einem aussagekräftigen Icon bestehen.
Zustände
-
Normal
-
Hover
-
Pressed
-
Deaktiviert
Ist dies das korrekte Bedienelement?
-
Icon Buttons können in der Seiten-Toolbar, der Toolbar von Gruppierungsüberschriften und in der Aktionsspalte einer Tabelle benutzt werden.
Richtlinien zur Anwendung
-
Da die Buttons nur aus einem Icon bestehen, ist es essentiell, dass das Icon die dahinterstehende Funktionalität ausdrückt.
-
Icon Buttons sollten mit Bedacht eingesetzt werden.
-
Icon Buttons verfügen immer über einen Tooltip, der die entsprechende Funktionalität beschreibt.
-
Im Sinne der Barrierefreiheit sollte bei Bildern und Icons immer ein beschreibendes Label im Quellcode (z.B. Title oder alt Attribut) vorhanden sein.
4.2. Hyperlink
Hyperlinks sind verlinkte Texte (oder auch Grafiken), die im Wesentlichen als Navigations-Mechanismus dienen – so z.B. um andere Inhalte wie Fenster zu öffnen. Ebenso können Hyperlinks dazu eingesetzt werden, Funktionen aufzurufen.
Zustände
-
Normal
-
Hover
Ist dies das korrekte Bedienelement?
-
Hyperlinks werden verwendet, um zu anderen Inhalten zu navigieren.
-
Hyperlinks können aber auch genutzt werden um sekundäre Funktionen aufzurufen.
-
Hyperlinks werden jedoch nicht für das Initiieren primärer, unmittelbarer Aktionen genutzt in diesem Fall sollten Buttons verwendet werden.
-
Würde der Hyperlink eine irreversible Aktion ausführen, sollte kein Hyperlink verwendet werden, da dieses Verhalten nicht erwartungskonform wäre.
-
Hyperlinks sollten nicht in einer Toolbar verwendet werden, hier empfiehlt sich der Einsatz von Toolbar-Buttons oder Icon-Buttons.
Richtlinien zur Anwendung
-
Wird die Maus über einen Hyperlink bewegt, ändert der Mauscursor sich vom Pfeil- zum Hand-Symbol.
-
Werden Hyperlinks auf gesättigten Hintergrundfarben verwendet, sollte die Textfarbe entsprechend angepasst werden, um eine ausreichende Lesbarkeit zu gewährleisten.
-
Hyperlinks sollten einen aussagekräftigen Text zur Verfügung stellen. Generische Phrasen wie „Hier klicken“ sind nicht hilfreich und sollten vermieden werden.
-
Hyperlinks (Textlinks) innerhalb von Applikationen werden blau dargestellt und bei Hover unterstrichen, z.B. Bezeichner (Name/ID) in Tabellen.
-
Hyperlinks auf dem Dashboard
-
Verlinkungen (Textlinks) auf dem Dashboard unterscheiden sich zu Textlinks in Applikationen. Um einen optischen Overload zu vermeiden, werden sie nicht blau eingefärbt.
-
Alle Links des Dashboards sind grau und werden bei Hover blau.
-
Links, die zu Applikationen navigieren, haben vor dem Textlabel ein Pfeil-Icon.
-
4.3. Label
Ein Label besteht in der Regel aus einem Text. In manchen Fällen kann es auch eine Kombination aus einem Icon und einem Text sein (z.B. Buttons mit Icon und Text). Es gibt auch Bedienelemente deren Label ausschließlich aus einem Icon bestehen. Hier gilt es zu beachten, dass das Icon eindeutig und aussagekräftig die dahinterstehende Aktion repräsentieren muss. Solche Bedienelemente können zusätzlich durch einen Tooltip unterstützt werden. Elemente wie Eingabefelder, Radiobuttons oder Checkboxen werden typischerweise mit einem Text-Label gekennzeichnet, während auf Schaltflächen häufig auch Icons verwendet werden.
Ist dies das korrekte Bedienelement?
-
Möglichst jedes Bedienelement sollte mit einem Label versehen werden.
-
Zur besseren Strukturierung und Gliederung von formularbasierten Screens werden Labels im Inhaltsbereich in Form einer Überschrift verwendet.
Richtlinien zur Anwendung
-
Labels sind möglichst kurz und prägnant formuliert.
-
Labels für alle Bedienelemente außer Radiobuttons und Checkboxen sollen nach Möglichkeit nicht aus mehr als drei Wörtern bestehen.
-
Es ist auf eine konsistente Groß- und Kleinschreibung der Labels zu achten.
-
Labels beginnen immer mit einem Großbuchstaben, auch Verben z.B. „Drucken“, „Exportieren“.
-
Für deutschsprachige Anwendungen sollten möglichst deutsche Begriffe benutzt werden.
-
Abkürzungen müssen sparsam verwendet und immer mit einem Tooltip versehen werden, der die Abkürzung erläutert.
-
Zu lange Labels werden mit Auslassungszeichen „…“ (eng. ellipsis) abgetrennt und ein Tooltip zeigt die ausgeschriebene Variante des Labels.
-
Bei Auswahl-Elementen wie Radiobuttons oder Checkboxen setzt ein Klick auf den Wert die entsprechende Option.
4.4. Eingabefelder
Ein Eingabefeld dient der Eingabe von Daten durch den Benutzer. Dies kann ein einzeiliger oder mehrzeiliger Text sein oder auch beispielsweise ein Datum, ein numerischer Wert oder eine Betragseingabe (Währungsbetrag, Fließkommazahl).
4.4.1. Standard Eingabefeld
Das Standard Eingabefeld ist einzeilig.
Zustände
-
Normal
-
Hover
-
Deaktiviert
-
Focus
-
Read-Only
-
Validierung
Ist dies das korrekte Bedienelement?
-
Eingabefelder werden für die Eingabe von Freitext genutzt.
-
Falls die einzugebenden Daten Teil einer vordefinierten Menge sind, sollte die Verwendung eines Dropdown Menü oder einer Wertehilfe in Erwägung gezogen werden.
Richtlinien zur Anwendung
-
Die Breite eines Eingabefeldes sollte der Länge des maximal möglichen Inhalts entsprechen.
-
Viele unterschiedliche Größen sollten jedoch vermieden werden, um ein harmonisches Gesamtbild zu erhalten. Es sollten daher nicht mehr als drei verschiedene Klassen von Feldgrößen verwendet werden.
-
Es kann jedoch auch sinnvoll sein, Eingabefelder exakt auf die zu erwartende Eingabe anzupassen, so z. B. bei der Eingabe von festen Größen wie einer Postleitzahl. Dies muss von Fall zu Fall entschieden werden.
-
Werden in ein Eingabefeld oftmals gleiche oder ähnliche Daten eingegeben, sollte eine Form von Eingabehilfe wie Autovervollständigung (siehe Kapitel Autosuggestion) zur Verfügung gestellt werden.
-
Um die Bedieneffizienz zu erhöhen, sollten Eingabefelder, deren Eingaben validiert werden, nach Möglichkeit verschiedene Eingabeformate unterstützen (z. B. in Bezug auf führende Nullen bei Datumsformaten: 8.1.09 oder 08.01.09).
-
Alphanumerische Zeichenketten sollten innerhalb eines Eingabefeldes linksbündig ausgerichtet werden.
-
Numerische Eingaben sollen rechtsbündig ausgerichtet werden, wenn optisch Summen gebildet werden sollen. Numerische Werte in alleinstehenden Eingabefeldern werden nicht rechtsbündig ausgerichtet.
-
Existieren sinnvolle Vorgaben, so kann ein Eingabefeld mit diesen als Platzhalter (siehe Kapitel Platzhalter) vorbelegt sein. So kann ein Datumsfeld unter bestimmten Umständen z. B. mit dem aktuellen Datum vorbelegt werden. Falls eine Vorbelegung jedoch potentiell risikobehaftet ist, sollte das Eingabefeld nicht vorbelegt werden.
4.4.2. 4-Augen-Prinzip Eingabefelder
Teilweise besteht bei Eingabefeldern die Notwendigkeit, dass die durch einen ersten Benutzer eingegebenen Daten, zunächst noch von einem zweiten Benutzer bestätigt/freigegeben werden müssen, bevor diese von anderen Aktionen (z.B. Zahlungsläufen) berücksichtigt werden können.
Die Felder mit dieser Eigenschaft werden bei der IsyFact als "4-Augen-Prinzip Eingabefelder" bezeichnet und sind visuell durch ein Schloss-Icon zu erkennen.
Zur Umsetzung von Anwendungsfällen mit Eingabefeldern, die auf dem 4-Augen-Prinzip beruhen, sind folgende Eingabefeld-Typen verfügbar:
Ausprägungen
-
4-Augen-Prinzip Eingabefeld
-
4-Augen-Prinzip Eingabefeld-Numerischer-Wert
-
4-Augen-Prinzip Eingabefeld-Währung
-
4-Augen-Prinzip Eingabefeld-Datum
Neben diesen einzeiligen Eingabefeldtypen für das 4-Augen-Prinzip gibt es noch
-
4-Augen-Prinzip Textbox
-
4-Augen-Prinzip DropdownBox-Einzelauswahl
-
4-Augen-Prinzip Checkbox
-
4-Augen-Prinzip Aktionseingabefelder
Zustände
-
Die möglichen Grundzustände (Normal, Deaktiviert, Focus, …) entsprechen denen der jeweiligen (Eltern) Eingabefeld-Typen
-
Ergänzend hierzu wird der Zustand eines 4-Augen-Prinzip Eingabefeldes durch die Farbe des geöffneten Schloss-Icons ausgedrückt (unlocked/grau: zur Zeit kein Eingabewert | locked/rot: Eingabewertfreigabe erforderlich)
Ist dies das korrekte Bedienelement?
-
4-Augen-Prinzip Eingabefelder sind nur für die Eingabe von Daten zu verwenden, die von einem zweiten Anwendungsbenutzer entweder freizugeben oder zu verwerfen/löschen sind.
Richtlinien zur Anwendung
-
Die 4-Augen-Prinzip Eingabefelder sind durch ein Schloss-Icon zu erkennen. Es wird nur die Grafik für ein geöffnetes Schloss verwendet.
-
Das Schloss Icon als visuelle Kennzeichnung des 4-Augen-Prinzip Eingabefeldes steht rechtsseitig im Eingabefeld. Sollten aufgrund des Feldtyps noch weitere Icons im Eingabefeld angezeigt werden müssen (z.B. bei Datumsfeldern das Datumspicker-Icon), so steht das Schloss-Icon noch vor dem anderen Icon (s.a. Durch Schloss-Icon gekennzeichnete 4-Augen-Prinzip Eingabefelder)
-
Die Breite des 4-Augen-Prinzip Eingabefeldes vergrößert sich durch das Schloss-Icon nicht.
Nutzungsvorgaben
Welche Anwendungslogik mit 4-Augen-Prinzip Eingabefeldern umgesetzt wird, bleibt der expliziten Fachanwendung vorbehalten.
Ein möglicher Ablauf eines Anwendungsfalls wäre folgender:
-
Ein Benutzer A hat Daten geändert, die gemäß des 4-Augen-Prinzips bestätigt werden müssen.
-
Der Benutzer A speichert die Daten. Dadurch speichert das System die Daten unter Vorbehalt. D.h. Benutzer A sieht die Daten in der Anwendung als aktuelle Daten aber entsprechend markiert. Die ursprünglichen Werte wurden nicht überschrieben, so dass sie im Falle einer Ablehnung der Änderung wiederhergestellt werden können.
-
Das System benachrichtigt Benutzer B, um ihn zu informieren, dass Datenänderungen zur Prüfung vorliegen.
-
Das System sperrt die Daten für Veränderung durch Dritte bis die Änderungen von einem Benutzer B bestätigt oder abgelehnt wurden.
-
Der Benutzer B reagiert auf die Benachrichtigung, indem er den zu prüfenden Datensatz im System öffnet.
-
Im Falle einer Bestätigung der Änderungen durch Benutzer B übernimmt das System die Daten nun endgültig, hebt die Bearbeitungssperre auf und informiert Benutzer A.
-
Im Falle einer Ablehnung der Änderung durch Benutzer B verwirft das System die Änderungen, hebt die Bearbeitungssperre auf und informiert Benutzer A mit einem Ablehnungsgrund.
Bedienkonzept konforme Darstellungsbeispiele für 4-Augen-Prinzip Eingabefelder
Beschreibung zum folgenden Screenshots:
Beim Betreten der Maske, vor der Eingabe von Werten im oberen Abschnittsbereich, waren die Schloss-Icons der Felder Gültig ab und Stundensatz grau dargestellt.
Nach der Eingabe eines Wertes ändert sich die jeweilige Schloss-Icon Farbe auf Rot.
Nachdem Benutzer A zwei Stundensatzeinträge durch Drücken der Hinzufügen Schaltfläche der Ergebnisliste hinzugefügt hat, kann er dann die somit modifizierte Ergebnisliste final abspeichern.
Man beachte, dass auch bei Verwendung von 4-Augen-Prinzip Feldern innerhalb von Tabellenzeilen, das Schloss-Icon rechtsbündig angeordnet ist.
In der folgenden Maskenansicht für den Benutzer B, sieht man, die durch Benutzer A eingegebenen Daten, die Benutzer B nunmehr durch zwei Schaltflächen Bestätigen oder Ablehnen kann.
4.4.3. Text Box
Text Boxen sehen optisch aus wie Eingabefelder, es können jedoch mehrzeilige Daten eingegeben werden.
Zustände
-
Normal
-
Hover
-
Deaktiviert
-
Focus
-
Read-Only
-
Validierung
Ist dies das korrekte Bedienelement?
-
Text Boxen werden für die Eingabe von mehrzeiligem Freitext genutzt.
-
Für einzeilige Texte sollte ein Eingabefeld benutzt werden.
-
Falls die einzugebenden Daten Teil einer vordefinierten Menge sind, sollte die Verwendung eines Dropdown Menüs oder einer Wertehilfe in Erwägung gezogen werden.
-
Textboxen sind nicht mit einem Charpicker zum Einfügen von Sonderzeichen ausgestattet.
Richtlinien zur Anwendung
-
Für die Verwendung von Text Boxen gelten die gleichen Richtlinien wie für Eingabefelder.
-
In manchen Fällen kann die Größe der Text Box nicht der Größe des möglichen Inhaltes entsprechen. Ist die Größe der Text Box kleiner als deren Inhalt, so muss der Benutzer innerhalb der Text Box scrollen können. Vertikales Scrollen ist horizontalem Scrollen vorzuziehen.
4.4.4. 4-Augen-Prinzip Textbox
Eine 4-Augen-Prinzip Textbox kann wie eine normale Textbox einen mehrzeiligen Text aufnehmen. Ein Schloss-Icon im Eingabefeld weist auf die zusätzliche Funktionalität (4-Augen-Prinzip) hin.
"4-Augen-Prinzip Eingabefelder" erfordern, dass die durch einen ersten Benutzer eingegebenen Daten, zunächst noch von einem zweiten Benutzer bestätigt/freigegeben werden müssen.
Zustände
-
Normal
-
Hover
-
Deaktiviert
-
Focus
-
Read-Only
-
Validierung
-
4-Augen-Prinzip (locked | unlocked)
Ist dies das korrekte Bedienelement?
-
4-Augen-Prinzip Eingabefelder sind nur für die Eingabe von Daten zu verwenden, die von einem zweiten Anwendungsbenutzer entweder freizugeben oder zu verwerfen/löschen sind.
-
Textboxen sind nicht mit einem Charpicker zum Einfügen von Sonderzeichen ausgestattet.
Richtlinien zur Anwendung
-
Die 4-Augen-Prinzip Eingabefelder sind durch ein Schloss-Icon zu erkennen. Es wird nur die Grafik für ein geöffnetes Schloss verwendet.
-
Das Schloss Icon als visuelle Kennzeichnung des 4-Augen-Prinzip Eingabefeldes steht rechtsseitig, oben im Eingabefeld.
-
Die Breite der 4-Augen-Prinzip Textbox vergrößert sich durch das Schloss-Icon nicht.
Nutzungsvorgaben
Welche Anwendungslogik mit einer 4-Augen-Prinzip Textbox umgesetzt wird, bleibt der expliziten Fachanwendung vorbehalten. s.a. Ablauf eines Anwendungsfalls mit 4-Augen-Prinzip
4.4.5. Aktionseingabefeld
Zustände
-
Normal
-
Hover
-
Deaktiviert
-
Focus
-
Validierung
Ist dies das korrekte Bedienelement?
-
Falls zusätzlich zum Eingabefeld einen dazugehörigen visuellen Hinweis dargestellt werden soll.
-
Falls die Eingabe beigesteuert werden muss oder kann, z.B. in einem modalen Dialog.
4.4.6. Upload
Das Upload-Element dient dem Hochladen von Dateien für verschiedene Medientypen.
Zustände
-
Normal
-
Hover
-
Deaktiviert / Disabled
-
Focus
-
Validierung
Ist dies das korrekte Bedienelement?
-
Upload-Felder werden für das Hochladen von Dateien genutzt.
-
Wenn der zu verwendende Medientyp darstellbar ist, sollte die Datei über ein entsprechendes Darstellungselement visualisiert werden.
Richtlinien zur Anwendung
-
Dateinamen sollten innerhalb eines Eingabefeldes linksbündig ausgerichtet werden.
-
Wenn das Upload-Feld keinen Inhalt hat, kann es einen Hinweistext darstellen (z.B. Wählen Sie eine Bild-Datei zum Hochladen aus.)
-
Das Upload-Feld und die zugehörige Visualisierung der Datei sollten erkennbar sein.
4.5. Dropdown Menü
Mit einem Dropdown Menü kann der Benutzer per Mausklick oder Tastatur-Bedienung genau einen Wert aus einer Liste von Optionen auswählen.
Zustände
-
Button (selektierte Option)
-
Normal
-
Hover
-
Pressed
-
Deaktiviert
-
Focus
-
-
Menü (Auswahl Menü)
-
Normal
-
Hover
-
Pressed
-
Selektiert
-
Ist dies das korrekte Bedienelement?
-
Ein Dropdown Menü wird eingesetzt, wenn der Benutzer genau eine Option aus einer Menge sich gegenseitig ausschließender Optionen wählen kann.
-
Handelt es sich nur um eine sehr kleine Menge (typischerweise weniger als fünf) an Auswahl-Optionen, muss geprüft werden, ob die Verwendung einer Gruppe von Radiobuttons besser geeignet ist, da die möglichen Optionen eines Dropdown Menü erst nach dem Öffnen der Liste ersichtlich werden. Ist im Layout nicht ausreichend Platz vorhanden kann ein Dropdown Menü auch für kleinere Mengen genutzt werden.
-
Das Dropdown Menü eignet sich aufgrund seiner kompakten Größe dazu, die Betonung auf andere, wichtigere Aspekte eines User-Interface zu lenken. Sollte die Auswahl des entsprechenden Wertes jedoch explizit hervorgehoben werden, so wird statt eines Dropdown Menüs z.B. eine Gruppe von Radiobuttons verwendet.
-
Kann der Benutzer mehr als eine Option wählen? Falls ja, dann wird statt eines Dropdown Menüs eine Gruppe von Checkboxen verwendet.
-
Wird durch die Auswahl einer Option eine Funktion direkt ausgelöst, so ist ein Menü Button dem Dropdown Menü vorzuziehen.
Richtlinien zur Anwendung
-
Die Liste der Werte sollte nicht zu groß sein (maximal 10-12 Einträge), da der Benutzer sonst innerhalb des Auswahl-Menüs scrollen muss und es zu Usability-Problemen kommen kann.
-
Die Auswahl-Elemente sollten in einer logischen Reihenfolge angezeigt werden, z.B. sortiert nach der Wahrscheinlichkeit des Auftretens oder in zusammengehörigen Gruppen. Falls keine übergeordnete Logik angewendet wird, sollten die Elemente aufsteigend alphabetisch sortiert werden.
-
Falls es sich bei dem Dropdown Menü nicht um eine Pflichtangabe handelt, sollte eine Meta-Option wie „Keine Auswahl“ angezeigt werden, statt das Dropdown Menü im geschlossen Zustand leer anzuzeigen.
-
Meta-Optionen wie „Keine Auswahl“ oder „Alle“ sollten am Anfang der Liste platziert sein.
-
Werden mehrere Dropdown Menüs übereinander platziert oder in Kombination mit anderen Bedienelementen wie Eingabefeldern genutzt, so sollten die Breiten der Bedienelemente angeglichen werden.
-
Bei sehr langen Werten sollte eine Maximalbreite definiert werden.
-
Die Werte in einem Dropdown Menü können mit Tastatur gewählt werden, so dass der Benutzer nicht zwischen Maus und Tastatur wechseln muss.
-
Ein Dropdown Menü kann je nach Einsatzkontext unterschiedliche Funktionalitäten aufweisen.
-
Es gibt Dropdown Menüs, bei denen bei der Auswahl eines Wertes aktiv keine anderen Elemente auf dem Screen beeinflusst werden z.B. in Formularen.
-
Das Dropdown Menü kann aber auch alleinstehend verwendet werden z.B. zur lokalen Umschaltung einer Ansicht oder beispielhaft bei der Verwendung von vordefinierten Suchprofilen. Hier ändert sich die Ansicht direkt nachdem der Benutzer eine Auswahl im Dropdown Menü getroffen hat.
-
4.6. Tabs
Tabs dienen der Informationsstrukturierung und Reduktion der Anzahl gleichzeitig sichtbarer Inhaltsbereiche, wenn die Informationen schnell innerhalb des gleichen Fensters zugreifbar sein müssen. Tabreiter verhalten sich entsprechend dem analogen Vorbild eines Karteireiters, der dazu dient, verschiedene Karteikarten voneinander zu trennen. Tabs werden häufig dazu verwendet, um Eigenschaften eines Objekts in inhaltliche sinnvolle Gruppen aufzuteilen.
Zustände
-
Normal
-
Hover
-
Pressed
-
Selektiert
Ist dies das korrekte Bedienelement?
-
Tabs können eingesetzt werden, wenn der zu präsentierende Inhalt nicht ohne massives Scrolling innerhalb eines Screens dargestellt werden kann.
-
Wenn die Komplexität des User Interface reduziert werden soll und eine sinnvolle Gruppierung einzelner Bereiche vorgenommen werden kann.
-
Werden weniger als drei Tabreiter angezeigt, sollte stattdessen die Verwendung von Gruppierungs-Elementen in Betracht gezogen werden.
-
Würden die Tabreiter lediglich verschiedene Sichten auf die gleichen Daten darstellen, sollte stattdessen z. B. ein Dropdown Menü verw endet werden.
-
Falls die Tabreiter einzelne Schritte eines Prozesses abbilden, so sollte die Verwendung eines Wizards in Betracht gezogen werden.
-
Soll der Inhalt mehrerer Tabreiter gleichzeitig einsehbar sein – z. B. für Vergleichszwecke –sollten stattdessen Expander (Progressive Disclosure) Elemente verwendet werden.
Richtlinien zur Anwendung
-
Es sollte niemals ein Tabreiter-Element mit nur einem Tabreiter verwendet werden.
-
Es sollten niemals mehrere Reihen von Tabreitern übereinander angezeigt werden. Stattdessen sollte ein dediziertes Überlauf-Bedienelement (z.B. Taboverflow Menü) angeboten werden.
-
Abhängigkeiten zwischen verschiedenen Tabreitern sollten möglichst vermieden werden.
-
Eventuelle Pflicht-Eingabefelder werden wenn möglich auf dem ersten Tabreiter angezeigt.
-
Buttons, die globale Aktionen für das komplette Tabreiter-Element mit allen einzelnen Reitern anstoßen, müssen außerhalb des Tabreiter-Elements angebracht werden.
4.6.1. Taboverflow Menü
Das Taboverflow Menü dient zur Vermeidung mehrzeiliger Tabreiter-Elemente. Das Menü enthält alle Tabs, die nicht direkt auf dem Screen angezeigt werden können.
Zustände (Auswahl-Menü)
-
Normal
-
Hover
-
Pressed
Ist dies das korrekte Bedienelement?
-
Das Taboverflow Menü wird eingesetzt, wenn nicht alle Tabs auf dem Screen in einer Zeile dargestellt werden können.
Richtlinien zur Anwendung
-
Generell sollte Taboverflow vermieden werden.
-
Die Labels für die Tabreiter sollten kurz und aussagekräftig sein. Es kann auch mit sinnvollen und verständlichen Abkürzungen gearbeitet werden.
-
Die darzustellenden Inhalte sollten so gestaltet sein, dass das Taboverflow Menü nicht benötigt warden.
-
-
Das Taboverflow Menü wird über einen Button rechts neben der Tabbar aufgerufen.
-
Wählt der Benutzer einen Tab aus dem Taboverflow Menü, so wird der Inhalt dieses Tabs angezeigt. Und der Tab wird rechts neben dem letzten Tab in der Tabbar dargestellt.
-
Tabs aus dem Taboverflow Menü werden immer ganz rechts in der Tabbar angezeigt.
-
Die Reihenfolge der anderen Tabs wird nicht beeinflusst.
-
Wird das Browserfenster vergrößert, so dass alle Tabs aus dem Overflow-Menü Platz finden, werden die Tabs in das Tab-Menü integriert und das Overflow-Menü wird nicht mehr benötigt.
4.7. Liste
Listen werden benutzt, um eine überschaubare Anzahl an Daten oder Objekten eines Typus übersichtlich und vergleichbar darzustellen.
Zustände
-
Normal
-
Hover
-
Pressed
-
Selected
Ist dies das korrekte Bedienelement?
-
Eine Liste wird benutzt, um mehrere Objektdaten von einem Typ anzuzeigen.
-
Eine Liste sollte nicht verwendet werden, wenn sehr viele Objekte dargestellt werden müssen, da es keine Möglichkeit zur Sortierung bietet. In diesem Fall eignet sich eine Tabelle besser.
Richtlinien zur Anwendung
-
Listen bestehen aus einer Spalte und mehreren Zeilen.
-
Werden mehrere Listen neben- oder untereinander dargestellt, ist auf eine einheitliche Breite zu achten.
-
Listen können scrollbar sein.
-
Listen werden z.B. für das Pattern Browse & Collect genutzt.
-
Eine Liste kann optional einen Kopfbereich haben. Dieser zeigt ein gemeinsames Label für die aufgelisteten Objekte.
-
Die Breite der Liste orientiert sich an der Länge des längsten Labels. Sollte dies eine sinnvolle Länge / Breite übersteigen, so kann das Label mit Auslassungszeichen abgekürzt werden.
4.8. Tabelle
Eine Tabelle dient der übersichtlichen Anzeige von größeren Datenmengen. Die Tabelle besteht aus mehreren Informationsspalten, die zur Sortie rung verwendet werden können.
Zustände (nur für interaktive Tabellenzeilen)
-
Normal
-
Hover
-
Pressed
-
Selektiert
Ist dies das korrekte Bedienelement?
-
Tabellen werden genutzt, um große Mengen von Daten oder Objekten anzuzeigen.
-
Tabellen werden genutzt, um das Vergleichen von Daten zu ermöglichen.
-
Die Tabelle sollte nicht verwendet werden, wenn Objekte nur ein Attribut haben. In diesem Fall sollte auf eine Liste zurückgegriffen werden.
Richtlinien zur Anwendung
-
Numerische Werte werden rechts ausgerichtet, wenn die Anzahl der Nachkommastellen in allen Zeilen identisch ist.
-
Überlaufende Textlabels sollten mit "…" abgetrennt und mit einem Tooltip ergänzt werden.
-
Die initale oder fixe Breite von Spalten muss sich an der zu erwartenden Maximalwortlänge orientieren.
-
In-Place Funktionen (Aktionen) sollten immer in der rechten äußeren Spalte platziert werden (z.B. „Preview Button“ zur Vorschau von Details).
-
Die Spalten mit den größten Wortlängen sollten den maximal verfügbaren Platz einnehmen (Stretching).
-
Werteinheiten sollten im Spalten-Header angezeigt werden, wenn sie für alle Zeilen der Tabelle identisch sind.
-
Wird für die Zeilen ein Status in Form eines Icons angezeigt, so sollte das entsprechende Icon in der ersten Spalte ganz links dargestellt werden. So ist sichergestellt, dass der Benutzer schnell erkennt welchen Status ein Objekt hat. Checkboxen bilden hier eine Ausnahme. Hat eine Zeile eine Checkbox und ein Statusicon so wird die Checkbox ganz links und das Statusicon in der darauffolgenden Spalte dargestellt.
-
Werden in einer Tabelle eine Vielzahl von Einträgen dargestellt, so kann es sinnvoll sein, dem Benutzer eine Filter-Zeile zur weiteren Einschränkung zur Verfügung zu stellen.
-
Resizing von Tabellen
-
Tabellen passen ihre Größe entsprechend der Fenstergröße an.
-
-
Die Tabelle nimmt immer die ihr zur Verfügung stehende Breite ein.
-
Hierbei ist auf ein sinnvolles Resizingverhalten der einzelnen Spalten zu achten. Dies ist stark vom Inhalt der Tabelle abhängig.
-
Die Spalten einer Tabelle können eine feste oder variable Breite besitzen.
-
Für Spalten deren Inhalte eine abschätzbare Länge haben wie z.B. Datum oder Geschlecht, sollte in der Regel eine feste Spaltenbreite gewählt werden.
-
Für Inhalte, deren Länge flexibel oder unbestimmt ist wie z.B. Nachnamen, sollte eine flexible Breite gewählt werden.
4.8.1. Sortierung in einer Tabelle
Richtlinien zur Anwendung
-
Der erste Klick in einen Spaltenheader sortiert die Tabelle aufsteigend, der zweite Klick absteigend.
-
Ein Sortierungs-Indikator (Dreieck) neben dem Label zeigt die aktuell eingestellte Sortierung an.
-
Dreieck nach unten: Absteigende Sortierung
-
Dreieck nach oben: Aufsteigende Sortierung
-
Eine farbige Fläche im Tabellenkopf hebt die aktuell angewandte Sortierung hervor.
4.8.2. Selektionsverhalten in einer Tabelle
Richtlinien zur Anwendung
-
Selektion
-
Die Kennzeichnung eines Objektes (Name, Bezeichnung, ID) kann als Link zur Navigation zu weiteren Details genutzt werden.
-
Der Doppelklick auf eine Zeile öffnet ebenfalls die Details eines Objektes, sofern vorhanden.
-
Durch einfachen Klick in eine Zeile kann diese selektiert werden. Dies ist überall möglich, außer auf aktiven Bereichen wie z. B. Icons für Aktionen. Die ausgewählte Zeile wird farbig hinterlegt.
-
-
Mehrfachselektion
-
Eine Mehrfachselektion kann durch Halten der Taste STRG und das gleichzeitige Klicken auf einzelne Zeilen erfolgen. Mittels der Umschalt-Taste und Klick auf das erste und letzte Element wird der dazwischen liegende Bereich selektiert.
-
Sofern der Hauptanwendungsfall in einer Tabelle die Auswahl von einem oder mehreren Objekten ist, sollte zusätzlich eine Check Box Spalte integriert werden. Über eine Checkbox im Header können alle Zeilen gleichzeitig aus- oder abgewählt werden.
-
-
Default-Selektion
-
Bei Tabellen auf deren Objekte (Zeilen) weitere Aktionen angewendet werden können, ist eine Default Selektion sinnvoll.
-
In der Regel wird die erste Zeile per Default selektiert.
-
4.8.3. Aktionen in einer Tabelle
Richtlinien zur Anwendung
-
Aktionen, die direkt ausführbar sind und sich auf Daten in einer Zeile beziehen, werden in der rechten Spalte einer Tabelle mittels Icon-Buttons angezeigt (z.B. Vorschau für ein Objekt).
Hinweise zur Implementierung
Buttons für Aktionen können in der entsprechenden <isy:dataTableCell> angegeben werden.
Für die Detailansicht existiert auch das Tag <isy:dataTableDetailButton> welcher automatisch einen Button zum Auf- und Zuklappen der Detailansicht einfügt.
4.8.4. Große Datenmengen in einer Tabelle
Tabellen können sehr viele Daten enthalten und gegebenenfalls sehr lang werden. Um dem Benutzer den Umgang mit solchen Tabellen zu vereinfachen, werden zunächst nicht alle Daten initial in der Tabelle angezeigt. Über einen Mehr anzeigen Button oder einen Paginator kann der Benutzer sich bei Bedarf mehr Daten anzeigen lassen.
Richtlinien zur Anwendung
-
Der Paginator sollte mit Bedacht eingesetzt werden, Regeln siehe Kapitel Paginator.
-
Die Verwendung des Mehr anzeigen Button ist dem Paginator möglichst vorzuziehen.
-
Funktionalität des Mehr anzeigen Button: * Zunächst wird dem Benutzer nur eine begrenzte Anzahl (10 oder 20 Zeilen) an Daten in der Tabelle angezeigt.
-
Unterhalb der Tabelle befindet sich ein Mehr anzeigen Button. Wird dieser vom Benutzer geklickt so wird der nächste Satz an Daten angezeigt.
-
Nach Klick auf den Mehr anzeigen Button verlängert sich die Tabelle nach unten, so dass der Benutzer gegebenenfalls nach unten scrollen muss.
-
Nach Klick auf den Mehr anzeigen Button sollte die erste Zeile des neu geladenen Datensatzes an der ursprünglichen Position des Mehr anzeigen Buttons erscheinen. So kann sichergestellt werden, dass der neue Datensatz immer im Blickfeld des Benutzers erscheint. Die Selektion der Elemente bleibt unberührt.
-
Sind keine weiteren Daten mehr vorhanden, so wird der Mehr anzeigen Button ausgeblendet.
-
Wenn mehr als 100 Einträge zu erwarten sind, sollte aus technischen Gründen ein Paginator benutzt werden.
4.9. Check Box
Eine Check Box repräsentiert eine unabhängige, nicht-exklusive Auswahl. Der Benutzer kann beliebige Optionen auswählen.
Zustände
-
Normal
-
Hover (Checkbox Label)
-
Pressed (Checkbox Label)
-
Focused
-
Deaktiviert
-
Validierung (Checkbox Label)
-
Tri State
-
Required - Rotes Sternchen an Label (in
formCheckboxseit 4.0) -
Optional - Blaues Sternchen an Label (in
formCheckboxseit 4.0)
Ist dies das korrekte Bedienelement?
-
Check Boxen können für das Setzen einer oder mehrerer, sich nicht gegenseitig ausschließender Optionen oder anderer Werte genutzt werden.
-
Falls nur eine Option existiert, die einer „Ein/Aus“-Semantik folgt, kann eine Check Box zum Setzen dieser Option verwendet werden.
-
Eine Check Box darf nicht genutzt werden, um unmittelbar Funktionen auszuführen oder Aktionen auszulösen. Für diese Zwecke sollten Buttons verwendet werden.
-
Das Ein- oder Ausschalten einer Check Box kann jedoch dazu genutzt werden, um andere Elemente zu aktivieren oder zu deaktivieren.
Richtlinien zur Anwendung
-
Checkboxen werden browserspezifisch dargestellt, das heißt die Darstellung sieht in jedem Browser anders aus. Beispielgrafik für den Internetexplorer 9 siehe Check Box – Darstellungsbeispiel IE 9.
-
In der Regel besteht eine Check Box immer aus dem Check Box Button, der gleichzeitig als Indikator für den Checked-State dient und einem zugehörigen Text-Label.
-
Für eine optimierte Usability sollte sowohl der Check Box Button als auch das Text Label geklickt werden können, um den Checked-State zu verändern.
-
Eine Gruppe von Check Boxen sollte immer eine Beschriftung aufweisen, die entsprechend bei einer einzelnen Checkbox entfallen kann.
-
Das Text-Label einer Check Box steht immer hinter dem Bedienelement.
-
Für optimale Lesbarkeit sollten Check Boxes vertikal untereinander angeordnet sein.
-
In Einzelfällen kann die Check Box auch alleinstehend verwendet werden, um eine bestimmte Funktionalität an- und auszuschalten oder um bestimmte Inhaltsbereiche zu aktivieren/deaktivieren
-
Die Beschriftung einer Check Box sollte positiv formuliert sein, z. B. „Objekte einblenden“ statt „Objekte ausblenden".
-
* Neben den normalen Zuständen „Ein/Aus“ kann eine Check Box noch einen dritten Zustand „nicht definiert“ annehmen, so z. B. wenn die Check Box in einer Hierarchie zur Selektion aller untergeordneten Elemente verwendet wird. Man spricht in diesem Fall von einer sogenannten „Tri State Check Box“.
-
Solange die Werte der untergeordneten Optionen gleich sind (alle „Aus“ oder alle „An“), zeigt dies die übergeordnete Check Box mit dem entsprechenden Wert an.
-
Sind die Werte der untergeordneten Optionen jedoch nicht mehr homogen gesetzt, so schaltet die übergeordnete Check Box in den Zustand „nicht definiert“. Dieser Zustand wird häufig mit einem Quadrat innerhalb der Check Box symbolisiert.
Sollte eine Gruppe von Checkboxen aus einer großen Anzahl von Optionen bestehen, kann die Gruppe auf mehrere Spalten platzsparend und übersichtlich angezeigt werden.
4.10. Radio Button
Radio Buttons dienen der eindeutigen Auswahl von sich ausschließenden Optionen. Der Benutzer kann also nur eine der Optionen auswählen.
Zustände
-
Normal
-
Hover (Radio Button Label)
-
Pressed (Radio Button Label)
-
Focused (Radio Button Label)
-
Deaktiviert
-
Validierung (Radio Button Label)
Ist dies das korrekte Bedienelement?
-
Wenn der Benutzer genau eine Option aus einer sich gegenseitig ausschließenden Menge wählen kann, wird ein Radio Button genutzt.
-
Kann der Benutzer mehr als eine Option wählen? Falls ja, dann muss statt eines Radio Buttons eine Check Box verwendet werden.
-
Existiert nur eine Option, die einer „Ein/Aus“-Bedeutung entspricht, so muss statt eines Radio Buttons eine Check Box verwendet werden.
-
Die Verwendung von Radio Buttons 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 Dropdown Menüs in Betracht gezogen werden.
-
Ein Radio Button darf nicht genutzt werden, um unmittelbar Funktionen auszuführen oder Aktionen auszulösen. Für diese Zwecke sollten Buttons verwendet werden.
Richtlinien zur Anwendung
-
Radio Buttons werden browserspezifisch dargestellt, das heißt die Darstellung sieht in jedem Browser anders aus. Beispielgrafik für den Internetexplorer 9 siehe Radio Button – Darstellungsbeispiel IE 9.
-
Eine Gruppe von Radio Buttons sollte immer eine Beschriftung aufweisen.
-
Für optimale Lesbarkeit sollten Radio Buttons vertikal untereinander angeordnet sein.
-
Sollte es wahrscheinlich sein, dass keine (oder alle) der angebotenen Optionen zutrifft, sollte eine Meta-Option wie „Keine Option“ („Alle“) angeboten werden.
-
Das Text-Label des Radio Buttons steht immer hinter dem Bedienelement.
4.11. Status von Bedienelementen
Je nach Kontext können manche Elemente, in der Regel Eingabeelemente, verschiedene Zustände annehmen.
Regeln zur Anwendung
-
Die drei häufigsten Zustände sind:
-
Normal
Das Element kann vom Benutzer bedient werden.
-
Deaktiviert (Disabled)
Das Element kann nicht bedient werden. Es ist z.B. aufgrund der Auswahl einer anderen Option deaktiviert. Eventuell zuvor eingegebene Werte werden nicht berücksichtigt. Das Element selbst, dessen Beschriftung sowie eventuell existierende Eingaben, werden „ausgegraut“ dargestellt.
-
Read-Only (nur lesbar)
Das Element kann nicht direkt bedient werden. Eventuell kann es jedoch mittelbar bedient werden, z.B. durch die Änderung eines anderen Wertes.
-
-
Weitere Zustände:
-
Hover (MouseOver)
Wird die Maus über ein Element bewegt so wird dieses Element mittels eines Hover-Effekts optisch hervorgehoben.
-
Pressed
In dem Moment in dem per Maus oder Tastatur ein Element ausgewählt wird, wird dieses als Pressed dargestellt.
-
Focus
Der Focus liegt auf einem Element. Der Focus kann per Mausklick oder mit Hilfe der Tabulatortasten der Tastatur geändert werden.
-
Selektiert
Ein Element ist ausgewählt und bleibt in diesem Zustand.
-
Validierung
-
Elemente, die einer Validierung unterzogen werden (vor allem in Formularen), werden bei fehlerhaften Eingaben gesondert hervorgehoben.
5. Design Patterns
Ein Design Pattern ist eine Kombination aus Standardelementen, welche in dieser Kombination für verschiedene Aufgaben oder Situationen benutzt werden können.
5.1. Navigation
Die Navigation ist entscheidend für eine gute Bedienbarkeit von Fachanwendungen. Alle Anwendungsfälle einer Fachanwendung müssen, ggf. nach Anwendungskomponenten gruppiert, direkt über einen Eintrag in der Navigation ansprechbar sein.
Die IsyFact sieht drei Navigationsebenen vor:
-
Hauptnavigation (auch horizontale Navigation genannt)
-
Subnavigation (Menüs der Hauptnavigation)
-
Linksnavigation (Liste von Einträgen am linken Rand einer Applikationsseite)
Innerhalb einer Anwendungslandschaft oder einer einzelnen Fachanwendung muss die Navigation einheitlich strukturiert sein. Festlegungen auf höherer Ebene (z.B. der Anwendungslandschaft) gelten für alle Fachanwendungen.
Die IsyFact sieht grundsätzlich zwei Strukturierungen vor.
Bei der fachlichen Spezifikation einer neuen Fachanwendung oder Anwendungslandschaft muss eine der folgenden Strukturierungen für die Navigation ausgewählt und fest vorgegeben werden:
-
Anwendungsübergreifende Navigation
-
Anwendungsspezifische Navigation
Insbesondere müssen sich in einer Anwendungslandschaft alle Fachanwendungen an die getroffene Entscheidung halten. Die Entscheidung muss an geeigneter Stelle dokumentiert werden.
5.1.1. Anwendungsübergreifende Navigation
Diese Form der Navigation bietet über die gesamte Anwendungslandschaft eine einheitliche Navigation an.
- Hauptnavigation
-
Die Hauptnavigation bildet die Anwendungsgruppen ab. Diese sind meist fachlich motiviert und entsprechen oft den Anwendungsdomänen.
- Subnavigation
-
Die Subnavigation bildet einzelne Fachanwendungen innerhalb einer Anwendungsgruppe ab.
- Linksnavigation
-
Die Linksnavigation enthält eine Liste aller Anwendungsfälle der gewählten Fachanwendung.
5.1.2. Anwendungsspezifische Navigation
Diese Form der Navigation bietet die Möglichkeit, für jede Anwendung eine eigene Navigation zu definieren. Dies ist besonders bei sehr komplexen Fachanwendungen, die eine Vielzahl von Anwendungsfällen enthalten, sinnvoll.
- Hauptnavigation
-
Die Hauptnavigation bildet eine logische Gruppierung der Anwendungskomponenten ab.
- Subnavigation
-
Die Subnavigation bildet einzelne Anwendungskomponenten der Fachanwendung ab.
- Linksnavigation
-
Die Linksnavigation enthält eine Liste aller Anwendungsfälle der gewählten Anwendungskomponente.
5.1.3. Hauptnavigation
Die Hauptnavigation ist eine horizontale Navigation, die stets am unteren Rand des Header-Bereichs dargestellt wird und die gesamte Breite der Seite einnimmt.
Ist dies das korrekte Pattern?
-
Das Submenü (Flyout) kann als 2. Navigationsebene verwendet werden.
Position und Ausrichtung der horizontalen Navigation
-
Die Hauptnavigation wird von links nach rechts befüllt.
-
Ein Entfall der Linksnavigation ist möglich, hat aber keinen Einfluss auf das Layout.
Richtlinien zur Anwendung
-
In der Hauptnavigation werden Applikationsgruppen platziert. Kann eine Applikation keiner Gruppe zugeordnet werden, so kann sie einen eigenen Hauptnavigationspunkt darstellen.
-
Die Anzahl der Navigationspunkte sollte auf ein sinnvolles Minimum reduziert werden (max. 8-10). Die Hauptnavigation ist nicht scrollbar und sollte kein Taboverflow Menü haben.
-
Die aktuelle Position des Benutzers (aktueller Navigationspunkt) ist immer deutlich hervorgehoben.
-
Ist ein Dashboard vorhanden, so stellt dieses immer den ersten Punkt (ganz links) in der Hauptnavigation dar und ist per Default aktiv. Es ist immer ein Punkt in der Hauptnavigation selektiert.
-
Unterhalb der Hauptnavigation wird ein Farbbalken angezeigt. Die Farbe repräsentiert eine Applikationsgruppe/Applikation. Sie entspricht immer dem gerade aktiven Hauptnavigationspunkt (s. Navigationsleistenbeispiel auf Applikationsseite und Navigationsleistenbeispiel auf Applikation Detailseite).
-
Wird die Maus über einen Hauptnavigationspunkt bewegt (Hover), wird eine Subnavigation als Flyout angezeigt.
-
Die Subnavigation wird entsprechend der dazugehörigen Applikationsgruppe/Applikation mit einer Farbe gekennzeichnet.
-
Der erste Navigationspunkt in der Subnavigation beziehungsweise der vom Benutzer zuletzt geöffnete Navigationspunkt ist per Default vorselektiert.
-
-
Klickt der Benutzer direkt auf einen Hauptnavigationspunkt wird standardmäßig die erste beziehungsweise die zuletzt geöffnete Applikationsseite aus der Subnavigation geöffnet.
5.1.4. Linksnavigation
Die Linksnavigation ist ein optionales Element und kann zur weiteren Strukturierung einer Applikation dienen. Sie kann über ein Icon ein- und ausgeblendet werden.
Ist dies das korrekte Pattern?
-
Die Linksnavigation dient der weiteren Strukturierung einer Applikation.
-
Diese kann entweder als 2. Navigationsebene oder bei komplexeren Applikationen als 3. Navigationsebene verwendet werden.
Aufbau
-
Überschrift
-
Navigationspunkte
Richtlinien zur Anwendung
-
Wird die Linksnavigation als Navigationsebene 2 oder 3 benutzt so sollte die Überschrift das Label der übergeordneten Navigationsebene anzeigen z.B. das Label der Applikation.
-
Die Überschrift ist nicht auswählbar, alle anderen Einträge in der Linksnavigation sind mit Inhalten verlinkt.
-
Wählt der Benutzer einen Eintrag aus der Linksnavigation so wird der rechte Inhaltsbereich der Seite ausgetauscht und der gewählte Navigationspunkt als selektiert markiert.
-
Über die Linksnavigation ist kein Applikationswechsel möglich. Der Benutzer bewegt sich immer innerhalb einer Applikation.
-
Das Icon zum Einklappen der Linksnavigation befindet sich neben der Überschrift. Bei den Icons handelt es sich um angle-double-left und angle-double-right aus dem Iconset von fontawesome.
5.1.5. Quicklinks
Muss der Benutzer häufig auf bestimmte Funktionen oder Objekte in einer Anwendung zugreifen, so kann es sinnvoll sein ihm Schnellzugriffe, sogenannte Quicklinks auf diese Funktionen/Objekte zur Verfügung zu stellen.
Ist dies das korrekte Pattern?
-
Mittels Quicklinks können dem Benutzer häufig genutzte Funktionen und Objekte zur Verfügung gestellt werden, ohne dass dieser einen kompletten Prozess (z.B. Suche) durchlaufen muss um zu diesem Objekt zu gelangen.
-
Quicklinks sollten nur eingesetzt werden, wenn sie für den Benutzer einen echten Mehrwert darstellen.
-
Die Quicklinks sind eine zusätzliche Komfortfunktion für den Benutzer.
-
Sie stellen keinen Ersatz für eine Navigation dar.
Aufbau
-
Überschrift der Gruppe
-
Links
Richtlinien zur Anwendung
-
Quicklinks können auf dem Dashboard oder im linken Bereich der Inhaltsseiten platziert werden.
-
Es sollten nur Quicklinks zu Funktionen oder Objekten angezeigt werden, die
-
für den jeweiligen Benutzer von Interesse sind.
-
den Arbeitsablauf des Benutzers vereinfachen können.
-
-
Quicklinks stellen immer eine Gruppierung mehrerer Objekte dar.
-
Die Anzahl der Links in einer Gruppe sollte begrenzt sein.
-
Dashboard: 5 pro Gruppe
-
Letzte Objekte: 8-10
-
-
Klickt der Benutzer auf einen Quicklink so wird die zugehörige Anwendung aufgerufen und die entsprechende Funktionen oder das entsprechende Objekt wird angezeigt.
5.1.6. Paginator
Ein Paginator dient der Navigation durch große Mengen von Daten, die auf verschiedene Seiten verteilt sind. Der Einsatz eines Paginators ist mit wesentlichen Nachteilen verbunden und sollte daher entsprechend gegen Alternativen abgewogen werden.
Ist dies das korrekte Pattern?
-
Falls aufgrund begrenzter Ressourcen nicht der komplette Inhalt auf einer Seite geladen werden kann, kann dieser auf mehrere Seiten verteilt werden. Ein Paginator wird dann zur Navigation zwischen den einzelnen Seiten verwendet.
-
Ein Paginator ist jedoch nur ein Hilfswerkzeug und sollte nicht als Standard genutzt werden. Bestehen keine systembedingten
Restriktionen, sollte auch kein Paginator eingesetzt werden.
-
Der Einsatz eines Paginators bringt einige Nachteile mit sich (siehe unten). Daher sollte geprüft werden, ob die Objekte inhaltlich sinnvoll minimiert werden können oder ob Alternativen wie z. B. Mehr anzeigen Button oder falls erlaubt Dynamisches Scrolling genutzt werden können.
-
Der Mehr anzeigen Button erlaubt alle Inhalte auf einer einzigen Seite zu betrachten und umgeht somit die Nachteile eines Paginators. Dabei werden, ähnlich wie bei einem Paginator, nicht alle Daten auf einmal geladen, sondern bei Klick auf den Mehr anzeigen Button werden mehr Daten angezeigt. Dieses Element eignet sich für Objekte mit bis zu circa 100 Elementen.
-
* Nachteile eines Paginators
-
Eine Neu-Sortierung der Daten führt in der Regel zurück auf Seite 1, unabhängig von der Ausgangsposition. Hierdurch wird die Orientierung des Benutzers erschwert.
-
Die Daten können nicht nahtlos betrachtet werden, es gibt immer einen harten Übergang zwischen zwei Seiten eines Paginators.
-
Das Vergleichen von Informationen auf zwei verschiedenen Seiten ist mühsam.
Richtlinien zur Anwendung
-
Der Paginator wird unterhalb der entsprechenden Seiten angezeigt.
-
Die aktuell ausgewählte Seitenzahl wird hervorgehoben, während jeweils die Nachfolgeseite, die Vorgängerseite, die erste sowie die letzte Seite als Direktlinks zur Verfügung gestellt werden.
-
Falls möglich, sollten alle weiteren Seitenzahlen ebenso angezeigt werden.
-
Ist dies aus Platzgründen nicht möglich, so werden die Vorgänger- und Nachfolgeseiten der aktuell selektierten Seite angezeigt. Die dabei entstehende Lücke zu der ersten und letzten Seite wird mit Auslassungspunkten angedeutet.
-
Über die Pfeiltasten (links / rechts) kann der Benutzer jeweils eine Seite zurück oder vor navigieren.
5.2. Eingabe
Patterns zur Dateneingabe
5.2.1. Wertehilfen
Eingabefelder können durch Wertehilfen erweitert werden. Dies sind Eingabehilfen, die das manuelle Eintippen über die Tastatur ersetzen und somit zur Fehlervermeidung beitragen. Dies ist sinnvoll, wenn der Benutzer aus einer vorhandenen Menge eine Option auswählen kann, es jedoch zu viele Optionen gibt, als dass man sie in ein Dropdown Menü platzieren könnte. Die Eingabe eines Datums ist z.B. ein typischer Anwendungsfall für eine Wertehilfe.
-
A – Hover
-
B – Pressed
-
C – Selektierter Tag
-
D – Focus
Ist dies das Korrekte Pattern?
-
Wenn der einzugebende Wert Teil einer festen Wertemenge ist und diese Wertemenge zu groß für die Darstellung in einem normalen Dropdown Menü ist, so kann eine Wertehilfe zum Einsatz kommen.
-
Eine Wertehilfe kann den Benutzer in seinen Arbeitsabläufen unterstützen, indem sie alle zur Verfügung stehenden Werte auf einen Blick darstellt.
-
Wenn der Benutzer eine Mehrfachauswahl aus einer festen Wertemenge treffen muss, so kann eine Wertehilfe ihn dabei unterstützen.
-
Bietet die Wertehilfe einen wirklichen Vorteil? Wenn nein, sollte keine Wertehilfe verwendet werden.
-
Typische Anwendungen sind
-
Auswahl Datum
-
Auswahl Uhrzeit
-
Auswahl von Objekten
-
Richtlinien zur Anwendung
-
Rechts neben dem Eingabefeld wird ein Icon angezeigt, das den Typ der Wertehilfe symbolisiert.
-
Nach einem Klick auf das Icon öffnet sich die Wertehilfe.
-
Sobald der Benutzer außerhalb der Wertehilfe klickt oder innerhalb der Wertehilfe seine Auswahl trifft, wird die Wertehilfe wieder geschlossen.
-
Wurde eine Auswahl getätigt, wird diese anschließend in das Eingabefeld übertragen.
-
Für den Anwendungsfall einer Mehrfachauswahl wird auf der Wertehilfe ein Button mit der Beschriftung „Übernehmen“ angebracht. Der Benutzer kann mehrere Einträge selektieren, ohne dass sich das Fenster schließt. Sobald der Button geklickt wird, wird die Wertehilfe geschlossen und die Werte in das Eingabefeld übertragen.
-
Sollte nach einer Mehrfachauswahl nicht die komplette Selektion im Eingabefeld angezeigt werden können, so muss dennoch die Möglichkeit bestehen, mit Hilfe der Pfeil-Tasten zu den abgeschnittenen Informationen zu gelangen. Ebenso ist wichtig, dass man per Tooltip die komplette Information einsehen kann.
-
Standardmäßig sind Wertehilfen geschlossen.
-
Bei einer Datumshilfe ist es typischerweise sinnvoll, den aktuellen Tag vorauszuwählen.
-
Alternativ kann der Benutzer immer noch manuell per Tastatur einen Wert in das Eingabefeld eingeben, es ist daher hilfreich einen Hinweis zum Format anzuzeigen, solange kein Wert ausgewählt wurde.
5.2.1.1. Date Picker
Mit dem Date Picker kann der Benutzer per Klick auf das Kalender Icon ein Flyout öffnen, in dem der gewünschte Tag ausgewählt werden kann. Im oberen Bereich kann der Benutzer zwischen den Monaten und Jahren wechseln.
Richtlinien zur Anwendung
-
Beim Wechsel des Monats oder der Jahreszahl wird der Picker nicht geschlossen.
-
Weitere allgemeingültige Richtlinien siehe Kapitel Wertehilfen.
5.2.1.2. Time Picker
Mit Hilfe des Time Pickers kann der Benutzer Uhrzeiten auswählen.
Richtlinien zur Anwendung
-
Richtlinien siehe Kapitel Wertehilfen.
5.2.1.3. Buchstaben Picker
Der Buchstaben Picker kann den Benutzer bei der Auswahl bestimmter Buchstaben unterstützen z.B. zur Auswahl von Anfangsbuchstaben.
Richtlinien zur Anwendung
-
Richtlinien siehe Kapitel Wertehilfen.
5.2.1.4. List Picker (Objektauswahl)
Der List Picker kann den Benutzer bei der Auswahl bestimmter Objekte unterstützen, in dem weitere Zusatzinformationen die Identifikation von Werten vereinfachen.
Richtlinien zur Anwendung
-
Werden die Inhalte zu umfangreich (Anzahl zu groß) um sie sinnvoll innerhalb des Menüs darzustellen, so kann das List Picker Menü vertikal scrollbar werden.
-
Für lange Listen kann zudem eine Filterzeile eingefügt werden.
-
Weitere Richtlinien siehe Kapitel Wertehilfen.
5.2.2. Editable Row
Editable Rows sind flexible Zeilen deren Inhalte separat bearbeitet werden können.
Ist dies das korrekte Pattern?
-
Besitzt ein Objekt eine begrenzte Menge an Daten, die sich sinnvoll in einer Zeile darstellen lassen, so kann die Editable Row genutzt werden.
-
Die einzeilige Darstellung der Daten erlaubt den schnellen Vergleich mehrerer Datensätze / Informationen. Mittels der Editable Row können außerdem schnell neue Daten zu einem Objekt angelegt werden.
-
Bestehen die Daten aus komplexen Informationen mit vielen Attributen oder vielen darzustellenden Zeilen, so sollte eine Tabelle benutzt werden.
-
Verfügt ein Objekt über weitere Detaildaten, sollte eine Tabelle in Kombination mit Detailseiten benutzt werden.
Richtlinien zur Anwendung
-
Es dürfen keine weiteren Detaildaten (Preview oder Objektdetails) über die Editable Row aufgerufen werden.
-
Die Attribute eines Objektes werden in einer Zeile dargestellt.
-
Die Anzahl der Attribute für eine Zeile sollte auf ein sinnvolles Maß begrenzt werden. Die Attribute müssen ohne zu scrollen auf einen Blick ersichtlich sein.
-
Einzelne Zeilen können nicht selektiert werden, um weitere Informationen zu dem Objekt anzuzeigen.
-
Editierbare Zeilen treten immer in einer Gruppe auf.
-
Die Anzahl der Zeilen sollten auf ein sinnvolles Maß (10) begrenzt werden. *Editierbare Zeilen im Editieren-Dialog
-
Die Attribute können einzeln bearbeitet werden.
-
Die Attribute sind über Eingabefelder, Dropdown Menüs oder Wertehilfen bearbeitbar.
-
Es können Zeilen hinzugefügt oder gelöscht werden.
-
5.3. Selektion
Patterns zur Selektion von Daten
5.3.1. Suche
Die Suche wird benutzt um bestimmte Objekte anhand bestimmter Kriterien und Attribute in einer Applikation zu suchen. Dies erfolgt über ein Suchformular, das für jede Applikation spezifisch angepasst werden kann. Es gibt keine globale (applikationsübergreifende) Suche.
Ist dies das korrekte Pattern?
-
Dieses Pattern wird eingesetzt, wenn der Benutzer nach einem Objekt mit bestimmten Kriterien und Attributen sucht.
-
Es wird vorausgesetzt, dass der Benutzer einige dieser Attribute kennt und genau weiß, wonach er suchen muss.
Richtlinien zur Anwendung
-
Die Inhalte von Suchformularen sollten so optimiert und gestaltet sein, dass dem Benutzer möglichst nur passende Ergebnisse angezeigt werden. Um Ergebnisse schon beim Suchvorgang sinnvoll einzuschränken, können dem Benutzer Hilfsmittel wie z.B. Vorauswahl von Zeitgrenzen zur Verfügung gestellt werden.
-
Minimale Konfiguration eines Suchformulars:
-
Gruppierungsüberschrift
-
Ein Eingabefeld, Dropdown Menü oder Wertehilfe
-
Suche Button
-
Suche leeren Button
-
-
Formulare sollten nicht zu komplex und immer übersichtlich gestaltet sein.
-
Es können 2- oder 3-Spaltige Layouts benutzt werden.
-
Die Suchkriterien sollten nach ihrer Bedeutung/Wichtigkeit angeordnet werden. Das wichtigste Suchkriterium wird oben links platziert, die anderen werden von links nach rechts und oben nach unten einsortiert.
-
Generell sollten die Layout-Regeln für Formulare in Kapitel Formulare beachtet werden.
-
In speziellen Fällen kann es sinnvoll sein gewisse Eingabefelder im Suchformular voneinander abzugrenzen zwei Beispiele hierfür sind in Suchformular Beispiel 1 und Suchformular Beispiel 2 zu sehen.
-
-
Es können Eingabefelder, Dropdown Menüs, Wertehilfen, Radio Buttons, Checkboxen zur Eingabe von Attributen genutzt werden.
-
Die Suche nach Wortfragmenten (Teil-String) sollte ermöglicht werden.
-
Ein Suchformular sollte immer zusammen mit einer Ergebnistabelle (siehe Kapitel Datentabelle) genutzt werden.
-
Die Gruppierungsüberschrift sollte mit dem aktuell aktiven Submenüpunkt identisch sein. Befindet sich der Benutzer aktuell in der Navigationsebene 2 und hat Submenü A ausgewählt. So entspricht die Gruppierungsüberschrift dem Label des aktiven Submenü A.
-
Der Suchvorgang wird durch das Klicken (alternativ Aktivierung per Tastatur) des Suchen Buttons ausgeführt.
-
Mit Hilfe des „Suche leeren“ Buttons können alle Daten im Suchformular zurückgesetzt werden. Wurde bereits eine Ergebnistabelle angezeigt, so wird diese ebenfalls geleert.
-
Buttons unterhalb eines Suchformulars sind immer am rechten Inhaltsende des Formulars ausgerichtet.
-
Resizing
-
Wird die Größe Browserfenster verändert, so behalten die Bedienelemente des Formulars ihre Größe bei. Die Abstände zwischen den Spalten können sich bis zu einer gewissen Grenze vergrößern bzw. verkleinern.
-
Das genaue Verhalten von Formularen beim Resizing kann in Kapitel Formulare - Layout Verhalten nachgelesen werden.
-
5.3.2. Filter
Im Gegensatz zur Suche werden Filter immer auf bereits angezeigte Listen angewendet. Sie dienen der Strukturierung umfangreicher Listen und vereinfachen das gezielte Auffinden bestimmter Objekte in einer Liste.
Ist dies das korrekte Pattern?
-
Filter werden zur Einschränkung von Objekten in bereits vorhandenen (meistens sehr langen) Listen oder Tabellen eingesetzt.
Richtlinien zur Anwendung
-
Filter werden immer oberhalb einer Liste / Tabelle angezeigt.
-
Die Filterfunktion bezieht sich ausschließlich auf die in der dazugehörigen Liste / Tabelle angezeigten Objekte.
-
Wird ein Filter aktiviert, so werden alle anderen nicht zutreffenden Objekte ausgeblendet.
Toggle-Filter
Der Toggle-Filter ist eine Tabellen-Toolbar mit der durch einen Klick auf einen Button eine Liste von Objekten oder Formularen nach bestimmten vordefinierten Kriterien eingeschränkt werden kann. Der Toogle-Filter kann auch für die Filterung von beliebigen Inhalten im Detail-Bereich verwendet werden.
Ist dies das korrekte Pattern?
-
Der Toggle-Filter kommt zum Einsatz, wenn nach bestimmten vordefinierten Optionen gefiltert werden soll.
-
Der Toggle-Filter kann zur Filterung von langen Tabellen oder Listen genutzt werden.
-
Zur Umschaltung der verschiedenen Ansichten innerhalb des Detail-Bereichs.
Richtlinien zur Anwendung
-
Ein Toggle-Filter sollte nicht mehr als 5 Filteroptionen enthalten.
-
Er setzt sich aus einem Label und einer Toggle-Button-Group zusammen.
-
Die Filteroptionen können z.B. Objekttypen, Werte oder Attribute sein.
-
Ist eine Filteroption aktiv (ausgewählt), so werden nur die passenden Objekte angezeigt.
-
Der Benutzer sollte immer die Möglichkeit haben sich alle Objekte einer Liste anzeigen zu lassen. Hierfür wird eine Filteroption zur Verfügung gestellt z.B. „Alle“.
-
Wird eine Filteroption per Klick auf den entsprechenden Button ausgewählt, so wird die Liste sofort neu aktualisiert.
-
Filter werden in der Toolbar oder, falls es diese nicht gibt, in der Kopfzeile des entsprechenden Elementes (z.B. Liste) platziert.
-
Nicht vorhandene und damit vom Benutzer nicht auswählbare Optionen (zum Beispiel Filter A) im Detailbereich werden nicht angezeigt.
Filter-Zeile
In einer Tabelle können die Objekte auch mittels einer Filter-Zeile gefiltert werden. Die Filter-Zeile besteht aus Eingabefeldern oder Dropdown Menüs. Jedes Attribut bzw. jede Spalte kann eine Filteroption erhalten, sofern der Inhalt sinnvoll gefiltert werden kann.
Ist dies das korrekte Pattern?
-
Filter-Zeilen werden in langen Tabellen mit vielen Objekten / Einträgen eingesetzt.
-
Die Filter-Zeile ermöglicht dem Benutzer ein bestimmtes Objekt in einer langen Tabelle (oft sind Objekte hier schon über eine vorangegangene Suche eingeschränkt) schnell und einfach zu finden.
Richtlinien zur Anwendung
-
Die Filter-Zeile ist optional, nicht jede Tabelle muss zwangsläufig über eine Filter-Zeile verfügen. Der Einsatz ist vor allem bei großen Datenmengen sinnvoll.
-
Die Filter-Zeile wird zwischen Tabellenkopf und dem ersten Tabelleneintrag eingefügt.
-
Die Filter-Zeile kann über einen Toggle-Button in der Toolbar der Tabelle ein- und ausgeblendet werden.
-
Wird die Filter-Zeile ausgeblendet so werden bereits eingegebene Daten zurückgesetzt. Beim erneuten Ausklappen sind die Eingabefelder leer oder gegebenenfalls mit Platzhaltern versehen.
-
Gibt der Benutzer Text in eines der Eingabefelder ein, so wird der Inhalt dieser Spalte gefiltert. Es werden nur die Objekte angezeigt welche die entsprechende Eingabe beinhalten.
-
Beinhaltet keines der Objekte den eingegebenen Text, so wird die Tabelle leer angezeigt.
-
Die Inhalte der Eingabefelder können durch Klicken auf ein Löschen-Icon links im Eingabefeld gelöscht werden. Dieses Icon erscheint, sobald der Benutzer mit der Texteingabe im Eingabefeld beginnt.
-
Es gibt eine zusätzliche Löschen-Funktion rechts vom letzten Eingabe-Feld. Über diese Funktion können alle Eingaben in den Eingabefeldern der Filter-Zeile gemeinsam zurückgesetzt werden.
-
Werden in einer Spalte nur Icons dargestellt, wird statt eines Eingabefeldes ein Dropdown Menü zur Filterung benutzt. Das Menü enthält alle zur Auswahl stehenden Optionen als Text-Labels. Wählt der Benutzer eine dieser Optionen, so werden nur die entsprechenden Objekte angezeigt, welche dem gewählten Kriterium entsprechen.
-
Dropdown Menüs können auch zur Filterung vordefinierter Werte wie z.B. Geschlecht, Status, Währung, Sprache o.ä. benutzt werden.
-
Eingabefelder werden für undefinierte Werte wie z.B. Namen, Titel, Beschreibungen o.ä. benutzt.
-
Es können gleichzeitig mehrere Filter benutzt werden. Zum Beispiel kann es möglich sein nach Nachnamen und gleichzeitig nach Geschlecht zu filtern.
-
Die Eingabefelder der Filter-Zeile passen ihre Größe entsprechend der Spaltenbreite an.
5.3.3. Browse & Collect
Mit Browse & Collect kann der Benutzer eine Liste von Objekten erstellen. Hierbei werden Objekte von einer Quellliste in eine Zielliste übertragen.
Ist dies das korrekte Pattern?
-
Browse & Collect kann benutzt werden, um ein oder mehrere Objekte aus einer Liste auszuwählen.
-
Wenn die Liste der auszuwählenden Objekte sehr lang ist und gescrollt werden muss und die Auswahl der Werte direkt eingesehen werden sollte.
Richtlinien zur Anwendung
-
Wird eine Browse & Collect Liste außerhalb des Editieren-Dialogs angezeigt (z.B. auf einer Detailseite) so ist stets nur die Zielliste zu sehen. Die Quellliste wird nur im dazugehörigen Editier-Dialog angezeigt.
-
Die Quellliste wird immer links und die Zielliste rechts dargestellt.
-
Objekte (einzelne Zeilen) können selektiert und mittels des Hinzufügen- und Entfernen-Buttons von einer Liste in die andere verschoben werden.
-
Schritt 1: Objekte Auswählen
-
Schritt 2: Durch Klick auf Button Objekte von einer Liste in die andere verschieben.
-
-
Es ist eine Mehrfachauswahl von Objekten möglich.
-
Wenn es für den Inhalt der Liste sinnvoll erscheint, dann können die Funktionen „Alle hinzufügen“ / „Alle entfernen“ integriert werden.
-
Die Breite der Liste orientiert sich am längsten Objekt. Die Labels der Objekte sollten so kurz wie möglich gehalten werden. Zielliste und Quellliste sollten immer gleich breit sein.
-
Wenn nötig, können die Listen vertikal gescrollt werden.
-
Wenn nötig, können die Listen vertikal gescrollt werden.
-
Es sollten nur verfügbare Objekte angezeigt werden.
-
Objekte, die in die Zielliste übernommen werden, sind aus der Quellliste auszublenden.
-
Sobald sich in einer Liste ein Objekt befindet, wird immer eine Selektion angezeigt, i.d.R. das zuletzt bewegte oder selektierte Objekt.
-
Sowohl Quell- als auch Zielliste können eine Filter-Zeile enthalten, mit der die Objekte sehr langer Listen eingegrenzt werden können.
5.4. Ausgabe
Patterns zur Ausgabe von Daten.
5.4.1. Datentabelle
Die Datentabelle nutzt das Bedienelement Tabelle um Ergebnisse von Suchen darzustellen. Da Datentabellen sehr häufig in der Anwendung vorkommen, wird diese hier genauer beschrieben. Die allgemeinen Regeln zur Benutzung von Tabellen können im Kapitel Tabelle nachgelesen werden.
Ist dies das korrekte Pattern?
-
Datentabellen werden zur Anzeige von Suchergebnissen benutzt.
Regeln zur Anwendung
-
Wurde noch keine Suche durchgeführt, so ist die Tabelle leer und es wird ein Hinweistext angezeigt.
-
Die Toolbar der Tabelle ist immer sichtbar. Nicht mögliche Funktionalitäten, die durch die Durchführung der Suche freigeschalten werden, werden bei leeren Tabellen deaktiviert dargestellt.
-
Enthält eine Tabelle mehr Daten als auf den ersten Blick sinnvoll dargestellt werden können, so kann der Benutzer sich über den Mehr anzeigen Button weitere Ergebnisse anzeigen lassen (mehr Informationen siehe Kapitel Große Datenmengen in einer Tabelle).
-
Sofern sinnvoll, kann in der Ergebnistabelle eine Datenvorschau eingebunden werden. Mit deren Hilfe kann der Benutzer genauer bestimmen, ob es sich um das von ihm gesuchte Objekt handelt oder nicht.
5.4.2. Datenvorschau
Die Datenvorschau kann zur Vorschau oder Zusammenfassung von komplexen Daten dienen.
Ist dies das korrekte Pattern?
-
Innerhalb von Tabellen kann die Vorschau benutzt werden um ein Objekt näher zu beschreiben ohne auf die Detailseite wechseln zu müssen.
Richtlinien zur Anwendung
-
In der Vorschau sollten für den Benutzer interessante Daten eines Objektes dargestellt werden.
-
Die Daten in der Vorschau können auch zusammenfassende Fakten enthalten (z.B. Anzahl bestimmter Objekte).
-
Die Vorschau nutzt das Pattern Expander (Progressive Disclosure), d.h. die Daten können ein- und ausgeblendet werden.
-
Vorschau in einer Tabelle
-
Die Vorschau wird, mittels Klick auf ein Icon in einer Tabellenzeile ein und ausgeblendet.
-
Ruft der Benutzer eine Tabelle auf, so wird standardmäßig keine Vorschau angezeigt.
-
Es kann immer nur die Vorschau eines Objektes angezeigt werden. Ist die Vorschau von Objekt A geöffnet und der Benutzer lässt sich mittels Klick auf das entsprechende Icon die Vorschau von Objekt B anzeigen, dann wird die Vorschau von Objekt A geschlossen.
-
Die Daten der Vorschau sind in Spalten angeordnet, ähnlich wie bei Formularen. Das Layout sollte sich an den Regeln des Formular-Layouts orientieren (siehe Kapitel Formulare).
-
In der Vorschau können auch Bilder (z.B. Lichtbilder) angezeigt werden.
-
5.4.3. Master-Detail
Bei dem Master-Detail Konzept werden Informationen eines Master-Objekts und dessen Details auf einer Seite dargestellt. Zum Beispiel kann eine Liste von Objekten in einer Tabelle (Master) dargestellt werden. Die dazugehörigen Informationen (Detail) werden je nach Layout in einem Bereich darunter oder daneben angezeigt.
Ist dies das korrekte Pattern?
-
Das Master-Detail Konzept kann genutzt werden, wenn detaillierte Informationen zu mehreren komplexen Objekten angezeigt werden sollen, ohne dass die Seite gewechselt werden muss.
Richtlinien zur Anwendung
-
Sofern keine Ausnahmeregelung vorliegt, sollte immer initial das erste Objekt des Masters selektiert sein und die dazugehörigen Details angezeigt werden.
-
Selektiert der Benutzer ein anderes Master-Objekt so werden die entsprechenden Detaildaten angezeigt.
-
Zu einem Zeitpunkt kann immer nur ein Master-Objekt selektiert sein.
-
Das Master-Detail Konzept wird häufig mit anderen Patterns (z.B. Progressive Disclosure) oder Bedienelementen (Tabellen, Tabs) kombiniert.
-
Wird das Master-Detail Konzept auf der Detailseite benutzt, so können im Detail-Bereich weitere komplexe Objekte wie Tabellen auftreten. Hierbei gilt zu beachten, dass aus diesen Objekten nur noch Dialoge, aber keine weiteren Unterseiten aufgerufen werden können.
-
Der Titel des Details sollte das Haupidentifikationsmerkmal des Masters wiederholen (z. B.: Details von <Objektname / ID>)
-
Sollten das Master-Objekt oder dessen Details editierbar sein, erfolgt das Editieren immer über einen Dialog (siehe Kapitel Dialoge).
-
Master (Tabelle) – Detail (Gruppierungs-Container) zeigt ein Beispiel für ein Master-Detail Konzept. Hier stellt die Tabelle den Master dar und ein Gruppierungs-Container den Detail Bereich.
-
Redundante Informationen sollten vermieden werden.
-
Wichtige Informationen sollten im Master-Bereich und nicht ganz so wichtige Informationen im Detail-Bereich angezeigt werden.
-
Der Detail-Bereich kann sehr komplexe Daten enthalten z.B. Tabellen oder Formulare. Für sehr komplexe Daten kann es sinnvoll sein einen Expander (Progressive Disclosure) einzusetzen.
-
Innerhalb des Detail-Bereiches des Master-Detail Konzepts sollten keine Tabs verwendet werden.
5.5. Gruppierung
Patterns zur Gruppierung von Daten
Expander (Progressive Disclosure)
Mit einem Expander können bestimmte Inhaltsbereiche per Mausklick dynamisch ein- und ausgeblendet werden, das zugrundeliegende Prinzip wird häufig als „Progressive Disclosure“ (engl. „schrittweises Enthüllen") oder auch als Information Hiding (engl. „Ausblenden von Information“) bezeichnet. Ein Expander dient dazu die Informationskomplexität zu reduzieren. In einem Expander können sowohl Daten als auch Bedien-Elemente oder Optionen angezeigt werden.
Ist dies das korrekte Pattern?
-
Ein Expander kann genutzt werden um komplexe Inhalte zu strukturieren.
-
Komplexe Inhalte werden in logischen Gruppen zusammengefasst, die Gruppen lassen sich zur besseren Übersicht ein- (A) und ausklappen (B).
-
Wird genutzt um vertikal Platz zu sparen.
Richtlinien zur Anwendung
-
Der Expander sollte eine prägnante Beschriftung erhalten.
-
Die Beschriftung ist eine gruppierende Überschrift kombiniert mit einem Icon (Pfeil nach oben / rechts).
-
Die Beschriftung bleibt im offenen und geschlossenen Zustand gleich.
-
Über das Icon und die Beschriftung kann der Expander geöffnet und geschlossen werden.
-
Das Icon deutet an, was nach einem Klick passiert und wird entsprechend nach einem Klick gewechselt, z. B.:
-
Im geschlossenen Zustand: Pfeil nach rechts
-
In geöffnetem Zustand: Pfeil nach oben
-
-
Es können sowohl Formulare, Tabellen, andere Daten, Bedienelemente oder Optionen entsprechend der weiteren Regeln der Seitengestaltung angezeigt werden.
-
Es können mehrere Expander gleichzeitig geöffnet sein (siehe Expander geschlossen und geöffnet) (B) Personalien und Sachverhalte).
-
Expander nehmen immer die ihnen zur Verfügung stehende Breite ein. Die Inhalte des Containers passen sich nur bis zu einer gewissen Größe an, und bleiben dann gleich.
Gruppierungs-Container
Gruppierungs-Container helfen dem Benutzer bei der Strukturierung und Einordnung von Informationen.
Ist dies das korrekte Pattern?
-
Gruppierungs-Container sollten zur Strukturierung des Inhaltes eingesetzt werden, sobald umfangreiche Informationen auf einer Seite angezeigt werden müssen und diese sich zu logischen Gruppen zusammenfassen lassen.
-
Gruppierungscontainer unterstützen das schnelle Erfassen von Informationen.
Richtlinien zur Anwendung
-
Gruppierungs-Container bestehen in der Regel aus eine Gruppierungsüberschrift und einem Inhaltsbereich.
-
Die Gruppierungsüberschrift besteht aus Text und einer Trennlinie die bis zum Ende des Inhaltsbereiches führt. Optional können Gruppierungsüberschriften Icons (vor Text) oder auch eine Toolbar beinhalten.
-
Es gibt unterschiedliche Varianten von Gruppierungsüberschriften. Der Einsatz ist vom Inhalt des Gruppierungs-Containers abhängig.
-
Die einfache Gruppierungsüberschrift (Beispiele Gruppierungsüberschriften A) kann ein Icon und Text enthalten.
-
Eine Gruppierungsüberschrift in Kombination mit Expander (Progressive Disclosure) (Beispiele Gruppierungsüberschriften D + E) wird für Gruppierungs-Container eingesetzt.
-
Eine Gruppierungsüberschrift mit Toolbar (Beispiele Gruppierungsüberschriften C) kommt zum Einsatz, wenn die Objekte, die in der Gruppe enthalten sind, bearbeitet werden können (genauere Details siehe Kapitel Toolbar).
-
-
Enthält ein Gruppierungs-Container weitere Objekte (Gruppierungen) so sollte die Anzahl der Objekte (Beispiele Gruppierungsüberschriften 106 B) hinter der Überschrift angezeigt werden. Dies kann dem Benutzer den Überblick bei sehr umfangreichen Gruppierungen erleichtern.
-
Gruppierungs-Container nehmen immer die zur Verfügung stehende Breite ein. Die Inhalte des Containers passen sich nur bis zu einer gewissen Größe an, und bleiben dann gleich.
Toolbar
Allgemein
Eine Toolbar stellt ein Set von Bedienelementen wie z. B. Buttons oder Dropdown Menüs in einer Leiste zur Verfügung. Diese ist oberhalb eines
bestimmten Inhaltsbereichs angebracht. Die Funktionen werden typischerweise durch ein Icon und Text repräsentiert.
Ist dies das korrekte Pattern?
-
Die Toolbar soll das Gefühl einer schnellen und simplen Interaktion vermitteln, daher sollten keine komplexen Funktionalitäten in der Toolbar untergebracht werden.
-
Wenn eine kleine bis mittlere Anzahl häufig verwendeter Funktionen vorhanden ist und diese sich mit intuitiven Icons abbilden lassen, können diese Funktionen in einer Toolbar gruppiert werden.
-
Im Vergleich zu einem Menü sind die Funktionen in einer Toolbar immer sichtbar und direkt erreichbar.
*Richtlinien zur Anwendung *
-
Mögliche Einsatzgebiete für Toolbars
-
Seiten-Toolbar auf Detailseite (Toolbar Beispiele A)
-
Toolbar in Gruppierungs-Container (Toolbar Beispiele B)
-
Tabellen-Toolbar (Toolbar Beispiele C)
-
-
In einer Toolbar finden sich die wichtigsten oder am häufigsten genutzten Funktionen an einem zentralen Platz.
-
Bedienelemente in einer Toolbar sollten entsprechend ihrer Verfügbarkeit aktiviert oder deaktiviert werden.
-
Eine Toolbar sollte nicht mit allen zur Verfügung stehenden Bedienelementen überladen sein. Stattdessen sollten die am häufigsten benötigten Funktionen oder sehr wichtige Funktionen repräsentiert werden.
-
Mehrzeilige Toolbars sollten vermieden werden.
-
Icons sollten nach Möglichkeit mit einer Beschriftung versehen werden.
-
Icons müssen immer über einen Tooltip verfügen – auch dann, wenn sie bereits eine Beschriftung haben. Gibt es ein Tastaturkürzel für die entsprechende Funktion, so sollte dies im Tooltip angezeigt werden.
-
Sollte der Platz für eine Beschriftung aller Icons nicht vorhanden sein, so sollten zumindest die sehr häufig genutzten Funktionen eine Beschriftung erhalten. Ist eine Beschriftung aus Platzgründen nicht möglich, sollten die verwendeten Icons möglichst selbsterklärend sein.
-
Die Anordnung der Elemente innerhalb einer Toolbar sollte nach deren Priorität bzw. nach deren Nutzungsfrequenz erfolgen – häufig genutzte Funktionen links, weniger häufig genutzte Funktionen rechts.
-
Zur Strukturierung einer Toolbar können vertikale Trennlinien verwendet werden. Diese grenzen Gruppen von zusammengehörigen Elementen voneinander ab.
-
Zusammengehörige Funktionen können aus Platzgründen in Menü Buttons zusammengefasst werden.
-
Wird die Größe des Browserfensters verändert, so wächst die Toolbar (in der Breite) mit. Die Elemente in der Toolbar behalten ihre ursprüngliche Größe und Position bei.
Seiten-Toolbar
Die Seiten-Toolbar kommt auf Detailseiten von Dashboard oder Applikationen zum Einsatz.
Richtlinien zur Anwendung
-
Die Seiten-Toolbar beinhaltet Funktionen, welche für die gesamte Seite gelten z.B. „Zurück zur Liste“, „Seite drucken“ oder „Hilfe“.
-
Ganz links beinhaltet die Seiten-Toolbar immer eine Verlinkung, die zurück zur dazugehörigen Hauptseite führt. Diese Verlinkung muss in jeder Seiten-Toolbar vorhanden sein.
-
Der Navigationslink ist eine Kombination aus Icon und Text, alle anderen Buttons sind Icon-Buttons.
-
Weitere allgemeine Richtlinien zur Toolbar siehe oben.
Tabellen Toolbar
Die Toolbar oberhalb einer Tabelle beinhaltet Funktionen, welche die Tabelle oder Objekte der Tabelle beeinflussen.
Richtlinien zur Anwendung
-
In dieser Toolbar werden möglichst immer Toolbar-Buttons eingesetzt. Diese stellen eine Kombination aus Icon und Text dar (siehe Kapitel Toolbar Button).
-
Diese Toolbar kann auch einen Toggle-Filter enthalten um die Ergebnisse in der Tabelle zu filtern. Er ist immer rechts in der Toolbar ausgerichtet.
-
Alle anderen Funktionen der Toolbar werden links ausgerichtet.
-
Weitere allgemeine Richtlinien zur Toolbar siehe oben.
Gruppierungs-Container mit Toolbar
Auch im Zusammenhang mit Gruppierungs-Containern kann eine Toolbar eingesetzt werden. Diese Kombination findet sich ausschließlich auf Detailseiten wieder.
Richtlinien zur Anwendung
-
In dieser Toolbar werden ausschließlich Icon-Buttons eingesetzt.
-
Die Toolbar dient der Bearbeitung von Objekten, welche sich im Gruppierungs-Container befinden.
-
Die Funktionen der Toolbar beziehen sich immer auf alle Objekte und Untergruppen einer Gruppe.
-
Die Funktionalitäten können sich je nach Gruppentyp (siehe Kapitel Gruppierungs-Container) unterscheiden, sollten aber innerhalb eines Gruppentyps identisch sein. So kann man beispielsweise über die Toolbar einer Hauptgruppe weitere Gruppenelemente hinzufügen, die Gruppenelemente lassen sich aber ausschließlich in der Toolbar ihrer eignen Überschrift bearbeiten (Löschen, Drucken etc.). Die Buttons werden rechts neben der Überschrift positioniert und sind immer so auszurichten, dass alle Toolbarbuttons auf einer Seite linksbündig angeordnet sind.
-
Weitere allgemeine Richtlinien zur Toolbar siehe oben.
6. Formulare
Ein gleichmäßiges und konsistentes Layout von Screens und Formularen ist essentiell, um dem Benutzer die Zugänglichkeit von Informationen zu erleichtern. Klar strukturierte Inhalte erleichtern dem Benutzer schnelles Scannen und Erfassen von Informationen. Schlecht gelayoutete Screens können die Produktivität und die Zufriedenheit des Benutzers erheblich verschlechtern.
6.1. Virtuelles Raster
Inhalte von Formularen sollten sich an einem virtuellen, nicht sichtbaren Raster ausrichten. Formulare können einem 1-spaltigen, 2-spaltigen oder 3-spaltigen Layout folgen.
Richtlinien zur Anwendung
-
Bei der Eingabe oder Anzeige von Inhalten sollte ein gleichmäßiges Leseraster verwendet werden, um visuelle Sprünge zu minimieren.
-
Formulare sind aus gleichmäßig breiten Spalten aufgebaut. Es können bis zu 3 Spalten verwendet werden.
-
Labels sind immer rechtsbündig ausgerichtet und haben keinen abschließenden Doppelpunkt. Die Nähe der Label zu den Bedienelementen erleichtert somit die Zuordnung.
-
Das längste Label in einer Spalte (gruppenübergreifend) bestimmt die Breite der Label-Spalte. Bei sehr langen Labels sollten sinnvolle Abkürzungen verwendet werden, um die Spaltenbreiten so gering wie möglich zu halten.
-
Gleichmäßige Feld-Längen unterstützen den Lesefluss des Benutzers.
-
Die Feld-Längen sollten erwartungskonform gewählt werden. Soll z.B. eine Postleitzahl innerhalb Deutschlands eingegeben werden, so macht es Sinn die Feld-Länge auf 5 Stellen zu begrenzen.
6.2. Gruppierungen in Formularen
Um komplexe Formular-Inhalte auf einem Screen zu positionieren, können Gruppierungsüberschriften und bewusste Freiflächen (Whitespace) zwischen den Elementen zum Einsatz kommen. Dadurch ergibt sich eine logische Struktur, welche für den Benutzer einfacher zu erfassen ist.
Richtlinien zur Anwendung
-
Generell ist auf ein homogenes Formularlayout zu achten.
-
Logisch zusammengehörige Inhaltselemente werden über eine Gruppenüberschrift zusammengefasst.
-
Gruppierungsüberschriften
-
Innerhalb von Formularen können textuelle Überschriften zur Gruppierung von Inhalten verwendet werden.
-
Gruppierungsüberschriften können teilweise auch weitere Funktionen beinhalten, welche die Bearbeitung von Objekten ermöglichen (siehe Kapitel Gruppierungs-Container).
-
Innerhalb eines Formulars können sich Gruppierungen über 1, 2 oder 3 Spalten (Gruppierung über 3 Spalten, Gruppierungen über 1 bzw. 2 Spalten, Gruppierungen über 1 Spalte) erstrecken. Es sollte darauf geachtet werden, dass nicht zu viele verschiedene Layout-Kombinationen auf einer Seite vorkommen, da dies den Lesefluss erschweren kann.
-
Gruppierungsüberschriften sollten mit Bedacht eingesetzt werden. Viele Gruppen mit wenig Inhalt können zu einer unnötigen Komplexität beitragen. In solchen Fällen sollte geprüft werden, ob eine sinnvolle Gruppierung der Elemente auch durch die Verwendung von Whitespace erreicht werden kann.
-
-
Whitespace (Gruppierung mittels Whitespace)
-
Auch durch den Einsatz von Whitespace kann man eine Gruppierung von Elementen erreichen.
-
Dabei muss auf ausreichend Freiraum zwischen den einzelnen Gruppen geachtet werden.
-
Der Platzbedarf ist im Vergleich zum Einsatz von Gruppierungs-Elementen möglicherweise etwas höher. Ein per Whitespace strukturiertes User Interface wirkt jedoch in der Regel weniger komplex.
-
6.3. Layout Verhalten
Richtlinien zur Anwendung
-
Einige Bereiche von Formularen sollten flexibel gestaltet werden. So kann der Platz (horizontal) bei größeren Auflösungen optimal ausgenutzt werden.
-
Die Größenanpassung erfolgt innerhalb von gewissen Bereichen.
-
Wird das Browserfenster kleiner als der darzustellende Inhalt (i.d.R. 1024x768 px), so wird das gesamte Fenster scrollbar.
-
Ab einer gewissen Entfernung zwischen den Elementen werden Inhalte schlecht lesbar. Überschreitet die Größe des Browserfensters eine gewisse Grenze (i.d.R. 1600x1200 px) so wächst das Formular nicht weiter mit.
-
-
Bei einer Größenveränderung des Browserfensters, passen sich die Abstände zwischen den Spalten des Formulars bis zu einem sinnvollen Grad an.
-
Die Spaltenbreite und die eigentlichen Formularinhalte (Eingabefelder, Labels) verändern ihre Größe nicht.
-
Der Abstand zwischen Eingabefeldern und Labels bleibt ebenfalls unverändert.
-
Der vertikale Abstand zwischen Gruppen und Formularinhalten verändert sich nicht.
7. Benutzerhilfe & Unterstützung
Das System sollte für den Benutzer möglichst intuitiv und einfach zu bedienen sein. Die hier beschriebenen Möglichkeiten können den Benutzer beim Umgang mit dem System unterstützen und die Bedienung vereinfachen.
7.1. Autosuggestion
Autosuggestion ist eine Zusatzfunktion, um die normale Textfelder ergänzt werden können. 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 der Benutzer außerhalb der Eingabehilfe klickt oder innerhalb der Eingabehilfe seine Auswahl trifft.
Sobald der Benutzer mit der Eingabe beginnt, werden mögliche Werte, die mit der vom Benutzer gemachten Eingabe beginnen, in einem Menü unterhalb des Textfelds angezeigt. Der Benutzer kann nun weitertippen oder direkt einen Wert aus dem Menü auswählen und somit seine Eingabe verkürzen. Gibt es mehr als 10 mögliche passende Werte, so werden die ersten 10 Werte angezeigt, gefolgt von einer Information, dass mehr als 10 Einträge existieren.
7.2. Platzhalter
Platzhalter Texte dienen dem Benutzer als Unterstützung zur Eingabe von Daten in z.B. Eingabefeldern oder Suchfeldern.
Ist dies die korrekte Benutzerhilfe?
Platzhalter werden eingesetzt, wenn Daten in einem bestimmten Format eingegeben werden müssen (z.B. Datum, ID, Kennzeichen). Platzhalter können bei Suchfeldern eingesetzt werden, wenn unterschiedliche Attribute gesucht werden können.
Richtlinien zur Anwendung
Sobald der Benutzer in das Eingabefeld klickt, wird der Platzhalter ausgeblendet. Gibt der Benutzer keine Daten ein und klickt auf ein anderes Element (Fokuswechsel), dann wird der Platzhalter wieder angezeigt.
7.3. Tooltips
Ein Tooltip ist ein kurzer Text, der zur Beschreibung einer Funktion oder eines Objekts dient. Tooltips sind ein simples und zugleich wertvolles Werkzeug zur Benutzerführung. Tooltips erscheinen automatisch bei Hover über ein Objekt und dienen der Informations-Anreicherung ohne zusätzlichen Platzbedarf.
Ist dies die korrekte Benutzerhilfe?
-
Tooltips sind ein wichtiges Hilfsmittel und sollten daher umfangreich verwendet werden.
-
Alle Bedienelemente sollten mit einem Tooltip versehen werden.
-
Objekte wie Icons, Bilder oder Graphen sollten ebenso mit einem Tooltip ausgestattet werden.
-
Abgekürzte Texte, wie z. B. Texte in einer abgeschnittenen Tabellen-Zelle sollten in einem Tooltip vollständig angezeigt werden.
-
Menü-Einträge und andere selbsterklärende Elemente haben keine Tooltips.
Richtlinien zur Anwendung
-
Der Name des Objekts wird nur angezeigt, wenn er relevant für das Verständnis der Funktion ist, und das Objekt nicht schon benannt ist.
-
Solange ein Tooltip lediglich das Label des entsprechenden Elements wiederholt, bietet er keinen Mehrwert. Stattdessen sollte der Tooltip kurz und prägnant beschreiben, was ein Objekt bewirkt.
-
Ein Tooltip sollte möglichst spezifische Informationen geben, z.B. für den Button „Drucken“ die Erklärung „Druckt die dargestellte Liste auf dem Standarddrucker XY aus.“.
-
Wenn ein Element deaktiviert ist, sollte ein Tooltip zusätzlich erklären, warum es deaktiviert ist, z. B. „Absenden ist erst nach Ausfüllen aller Pflichteingaben möglich.“
7.4. Fortschrittsanzeige
Feedback-Konzepte für Ladezeiten sind ein sehr wichtiges Instrument zur Erreichung guter User Experience. 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.
Mit dem Toggle-Filter kann durch einen Klick auf einen Button eine Liste von Objekten oder Formularen nach bestimmten vordefinierten Kriterien eingeschränkt werden.
Ist dies die korrekte Benutzerhilfe?
-
Generell sollten Vorgänge oder Operationen, die mehr als eine Sekunde in Anspruch nehmen, eine Rückmeldung in Form einer Fortschrittsanzeige an den Benutzer 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 des Benutzers zurückführen lassen, werden keine Fortschrittsanzeigen eingesetzt.
Richtlinien zur Anwendung
-
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 dem Benutzer damit, dass sich ein Prozess im Vorgang befindet. Der Fortschritts-Spinner empfiehlt sich aufgrund seiner geringen Ausmaße insbesondere in Situationen, in denen Platzbedarf von großer Bedeutung ist.
-
7.5. Anzeige von Pflichtfeldern und optionalen Pflichtfeldern
Bedienelemente, die Pflichteingaben darstellen, werden mit einem Stern (Asterisk) gekennzeichnet, der am Ende der Beschriftung hochgesetzt und mit einem Leerzeichen als Abstand angehängt wird.
Sofern nicht alle Pflichteingaben ausgefüllt sind bzw. falls Eingaben des Benutzers nicht valide sind, kann der aktuelle Vorgang (z. B. Speichern) nicht abgeschlossen werden. Der Benutzer muss die fehlenden bzw. nicht validen Eingaben korrigieren, damit die Aktion erfolgreich durchgeführt wird.
Besonderheit: Optionale Pflichtfelder
-
Neben den Standardpflichtfeldern kann es auch „optionalen Pflichtfelder“ geben.
-
Optionale Pflichtfelder sind immer an ein Standardpflichtfeld gekoppelt.
-
Bei optionalen Pflichtfeldern muss mindestens eine Anzahl X aus mehreren Eingabefeldern ausgefüllt werden.
-
Optionale Pflichtfelder sollten, wenn möglich immer in einer separaten Gruppe zusammengefasst werden. Dies vereinfacht die Übersichtlichkeit.
-
Unterhalb der Gruppenüberschrift wird eine zusätzlich Hilfestellung/Information zum Ausfüllen der optionalen Pflichtfelder angezeigt.
7.6. Validierung
Aufgetretene Fehler sollen den Benutzer nach Möglichkeit nicht in seinem Workflow stören. Amodales Feedback gibt ihm die Möglichkeit ein Formular trotz aufgetretener Fehleingaben in beliebiger Reihenfolge und ohne Unterbrechung weiter zu bearbeiten.
Sobald durch das System ein Fehler in einem Formular erkannt wurde, wird das entsprechende Feld farblich markiert. Zusätzlich zu der farblichen Markierung kann hinter dem Feld noch ein Informations-Icon angezeigt werden.
Informations-Icon
-
Bei Hover über das Icon erscheint ein Tooltip
-
Dieser enthält weitere hilfreiche Informationen z.B. Formatierungsangaben, Zeichenbeschränkungen etc.
Neben der direkten Markierung der Felder kann zusätzlich ein zusammenfassender Hinweis angezeigt werden. Dies geschieht mithilfe von Toast-Notifications, welche immer am oberen rechten Rand des Browserfensters angezeigt werden.
Jede Toast-Notification muss eine Schließen-Aktion für den Benutzer anbieten. Um die Barrierefreiheit (nach BITV 1.4.13a) einzuhalten, muss die Toast-Notification dauerhaft eingeblendet bleiben, bis der Benutzer sie schließt.
Folgende Meldungsarten können als Toast-Notification verwendet werden:
-
Warnung
-
Hinweis
-
Fehler
-
Erfolg
7.7. Fehlerprävention
Neben der adäquaten Behandlung von Ausnahmen und Fehlern ist die Vermeidung von Fehlern ein sehr wichtiges Designprinzip. Ein gutes Design ist darauf ausgerichtet, Fehler möglichst nicht auftreten zu lassen. Folgende Richtlinien dienen als Grundlage zur Fehlerprävention.
Richtlinien
-
Verwendung von Bedienelementen, die im Kontext jeweils nur valide Werte liefern oder akzeptieren. So liefern z.B. Radiobutton, Checkboxen oder Auswahllisten vordefinierte Werte, die nicht weiter validiert werden müssen. Ein Eingabefeld ohne Eingabebeschränkung hingegen kann im Zweifelsfall Fehleingaben provozieren.
-
Falls möglich, werden verschiedene Eingabeformate akzeptiert. Beispiel: Bei der Eingabe eines Datums können sowohl Trennstriche als auch Punkte als Trennelement akzeptiert werden.
-
Falls möglich, werden sinnvolle Voreinstellungen und Default-Werte vergeben.
-
Funktionen und Bedienelemente, die temporär nicht verfügbar sind, werden deaktiviert.
8. Benutzereingaben
Tastatur
Alle Bedienelemente und Funktionen sollten auch ohne Maus bedienbar sein. Neben der Eingabe von Zeichen wird die Tastatur auch zur Navigation sowie zur Ausführung häufig genutzter Aktionen genutzt.
Richtlinien
-
Um die Richtlinien der BITV zu erfüllen, müssen alle Funktionalitäten der Applikation über eine Tastaturschnittstelle zugänglich und bedienbar sein.
-
Die Standardfunktionen und Tastaturkürzel vom Browser sollten nicht unterbunden oder anderweitig belegt werden.
-
Die Tabulator-Reihenfolge, also die Reihenfolge in welcher der Fokus mit Hilfe der Tabulator-Taste verschoben werden kann, sollte an die Bedürfnisse des Benutzers angepasst werden. In der Regel bedeutet dies, ein Ablauf von links nach rechts und von oben nach unten. Insbesondere bei webbasierten Applikationen ist die Tabulator-Reihenfolge zu überprüfen, da es hier aufgrund von Layout-Mechanismen zu ungünstigen Abfolgen kommen kann.
-
Initial sollte immer das am häufigsten genutzte Element fokussiert werden. Beispielsweise sollte der Cursor sich bei Eingabefeldern im ersten Textfeld befinden.
-
Die Standardfunktionen von Tasten sollte nicht verändert werden.
-
Das Drücken der Enter-Taste sollte beispielsweise den Standard-Bestätigungsbutton eines Screens auslösen.
Weitere Details zur Tastatursteuerung finden sich um Unterkapitel Tastatursteuerung.
Maus
Die Maus dient zur Bedienung von einzelnen Bereichen, Objekten und Formularen. Um ein Objekt (z. B. in einer Liste) auszuwählen, wird es mit der linken Maustaste einmal angeklickt. Ein Doppelklick auf ein Objekt führt eine dem Objekt zugewiesene Standardfunktion aus. In der Regel ist dies das Öffnen bzw. Bearbeiten des Objekts. Klicken mit der rechten Maustaste auf ein Objekt öffnet das Standard-Kontextmenü des Browsers.
Formate
Richtlinien
-
Für manche Eingabefelder ist es sinnvoll gewisse Formate vorzudefinieren.
-
Gibt der Benutzer ein Format oder eine Abkürzung ein, welche nicht dem Default-Format entspricht, so sollte das Eingabefeld zurück zum Default formatiert werden. Die Formatierung erfolgt, wenn das Feld verlassen oder die Enter Taste gedrückt wird.
-
Abkürzungen (z.B. „heute“ bei einem Datumsfeld) werden immer sichtbar dargestellt.
-
Der Benutzer sollte nicht gezwungen werden Separatoren einzugeben. Das System sollte das richtige Format automatisch zu erkennen.
-
Eingabe freier Werte
-
Bei der Eingabe freier Werte sollten beide Separatoren „.“ und „,“ akzeptiert werden. Allerdings sollte das dargestellte Format nur mit „.“ Angezeigt werden, wenn das Feld verlassen wird oder gespeichert wird.
-
Datumsformate werden wie folgt dargestellt: „TT.MM.JJJJ“ (z.B. 25.03.2014).
-
Alle Zeiten haben ein 24 Stunden Format: „HH:MM:SS“ (z.B. 14:10:46).
-
Wenn der Benutzer beispielsweise in einem deutschsprachigen System „1000.00“ eingibt, formatiert das System diese Eingabe in „1000,00“ um oder wenn der Benutzer „25032014“ eingibt, wird dieses Format in „25.03.2014" umgewandelt.
-
-
Unabhängig von den Systemeinstellungen, können für Datumsangaben Separatoren, Punkte, Schrägstriche „/“ und Striche „-“ eingegeben werden.
8.1. Tastatursteuerung
Diese Seite beschreibt Konzepte und Vorgaben zur Tastatursteuerung.
Allgemeine Steuerung
Tabulatorsteuerung
Für die Elemente des Inhaltsbereichs werden Tabulatorpositionen definiert. Folgende Elemente des Inhaltsbereichs können durch Tabulatorpositionen erreicht werden:
-
Eingabefeld
-
Button (alle Arten)
-
Dropdown
-
Paginierungselemente
-
Checkbox
-
Radio Button
-
Panel
-
Hyperlink
-
Text Box
-
List Picker
-
Buttons für Sortierung in der Trefferliste
-
Inner Tabs
In Formularen wird initial das erste Element aus dem Inhaltsbereich (links oben) fokussiert, das für Eingaben genutzt werden kann. Der Ablauf der Tabulatoren erfolgt von links nach rechts und oben nach unten. In der folgenden Abbildung wird beispielhaft der Ablauf der Tabulatorreihenfolge dargestellt:
Seitenbereiche
Header Bereich
Die Hauptnavigation kann über den Shortcut Alt+Shift+M erreicht werden. Initial wird das erste Hauptnavigationselement links fokussiert. Mittels Tabulator kann zwischen den Hauptnavigationselementen navigiert werden. Submenüs werden mit den Pfeiltasten (Pfeil oben und Pfeil unten) erreicht. Mit der Taste Enter kann der selektierte Menüpunkt geöffnet werden. Mit der Taste Escape wird der Header-Bereich wieder verlassen. Das zuletzt fokussierte Element des Inhaltsbereichs ist dann fokussiert.
Linksnavigation
Die Linksnavigation kann über den Shortcut Alt+Shift+L erreicht werden. Initial wird der oberste Menüpunkt fokussiert. Mittels Tabulator kann zwischen den angezeigten Elementen navigiert werden. Mit der Taste Enter wird die Aktion des fokussierten Elementes ausgelöst. Mit der Taste Escape wird die Linksnavigation wieder verlassen. Das zuletzt fokussierte Element des Inhaltsbereichs ist dann fokussiert.
Seitentoolbar
Die Seitentoolbar kann über den Shortcut Alt+Shift+S erreicht werden. Initial wird das erste Element links fokussiert. Mittels Tabulator kann zwischen den angezeigten Elementen navigiert werden. Mit der Taste Enter wird die Aktion des fokussierten Elementes ausgelöst. Mit der Taste Escape wird die Seitentoolbar wieder verlassen. Das zuletzt fokussierte Element des Inhaltsbereichs ist dann fokussiert.
Shortcuts für Aktionen
Für bestimmte Aktionen werden Shortcuts definiert, die anwendungsübergreifend verwendet werden sollen. Es handelt sich dabei nur um Aktionen, die vom Anwender in der Anwendung auch ohne Tastatursteuerung durchführbar sind.
Wenn in Seiten mehrere Datensätze angezeigt werden, dann gelten die folgenden Vorgaben zur Tastatursteuerung:
-
Anzeige des ersten Datensatzes: Dies soll über den Shortcut Alt+Shift+X erreicht werden.
-
Anzeige des nächsten Datensatzes: Dies soll über den Shortcut Alt+Shift+X erreicht werden.
-
Anzeige des vorherigen Datensatzes: Dies soll über den Shortcut Alt+Shift+X erreicht werden.
-
Anzeige des letzten Datensatzes: Dies soll über den Shortcut Alt+Shift+X erreicht werden.
-
Speichern des aktuellen Datensatzes: Dies soll über den Shortcut Alt+Shift+X erreicht werden.
-
Löschen des aktuellen Datensatzes: Dies soll über den Shortcut Alt+Shift+X erreicht werden.
-
Bearbeiten des aktuellen Datensatzes: Dies soll über den Shortcut Alt+Shift+X erreicht werden.
Weiterhin gelten die folgenden Vorgaben:
-
Öffnen der Druckansicht: Dies soll über den Shortcut Alt+Shift+X erreicht werden.
Die konkreten Shortcuts müssen noch definiert werden.
Tastatursteuerung und Fokussierung einzelner Widgets
Panel
Ein fokussiertes Panel wird über die Taste Enter aufgeklappt oder zugeklappt.
List Picker
Ein fokussierter List Picker kann per Alt+Pfeil nach unten aufgeklappt werden und per Escape-Taste wieder geschlossen werden. Dargestellte Elemente des List Pickers können mit den Pfeiltasten selektiert und mit der Enter-Taste ausgewählt werden. Nach dem Auswählen durch Enter ist das eigentliche Eingabefeld selektiert.
Dropdown
Die Liste eines fokussierten Dropdown Steuerelementes kann per Pfeil nach unten aufgeklappt werden. Die Elemente der Liste werden mit den Pfeiltasten durchlaufen und per Enter selektiert.
Das Dropdown Steuerelement nutzt ein externes Plug-In.
Inner Tabs
Ein fokussierter Inner Tab kann per Enter-Taste geöffnet werden.
Date Picker
Der Datepicker kann nicht per Tastatursteuerung bedient werden.
Der Datepicker nutzt ein externes Plug-In.
Buchstaben Picker
Ein fokussierter Buchstaben Picker kann per Alt+Pfeil nach unten geöffnet werden und per Escape-Taste wieder geschlossen werden. Dargestellte Elemente des Buchstaben Pickers können mit den Pfeiltasten selektiert und mit der Taste Enter in das zugehörige Eingabefeld an der aktuellen Cursorposition übernommen werden. Bis zum Schließen des Buchstaben Pickers erlaubt dieser die Auswahl weiterer Zeichen.
9. UI Text und Grafiken
Generelle Verwendung von Text
Die Bedeutung von Text und Bezeichnungen in Software darf nicht unterschätzt werden. Große Teile eines User-Interface beruhen auf textuellen Informationen, wie z.B. der Beschriftung von Bedienelementen. Die fehlerhafte Anwendung von Texten kann somit direkt zu einer Reduzierung der Usability des entsprechenden User-Interface führen. Häufig auftretende Probleme sind z.B.:
-
Inkonsistente Terminologie.
-
Inkonsistente Groß- und Kleinschreibung.
-
Zu lange Texte.
-
Redundante Textinformationen.
-
Technischer Jargon statt der Sprache des Benutzers.
Um benutzerfreundliche User-Interface-Texte verfassen zu können, muss man sich zunächst mit der Art und Weise vertraut machen, wie Benutzer 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 kann auf diese Tatsache jedoch nur eingeschränkt zurückgegriffen werden, denn tatsächlich lesen Benutzer die Texte auf einem Screen nicht, vielmehr wird dieser nach relevanten Informationen gescannt. Verschiedenartige Informationen rufen dabei unterschiedliche Aufmerksamkeitsstufen hervor. So werden Schaltflächen, Labels und andere interaktive Elemente gewöhnlich zuerst gescannt, während statischer Text eher selten gelesen wird.
Allgemeine Richtlinien
-
Die Sprache des Benutzers sprechen, niemals technischen Jargon verwenden.
-
Vermeiden von zu langen Textblöcken.
-
Einsatz von Überschriften und anderen Gliederungs-Elementen zur Strukturierung und besseren Übersicht.
-
Vermeiden von redundanten Informationen.
-
Fettschrift muss mit Bedacht verwendet werden, z.B. für Text, der gelesen werden muss.
-
Fließtexte dürfen nicht komplett großgeschrieben werden.
-
Unterstrichener Text darf nur für Hyperlinks benutzt werden.
-
Fachterminologie muss entsprechend konsistent verwendet werden.
-
Konsistente Verwendung von Groß- und Kleinschreibung.
Verwendung von Grafiken
Bei der Verwendung von Grafiken (schematische Darstellungen oder Photographien) und Icons ist darauf zu achten, dass diese in Größe, Stil und Farbschema mit den restlichen Inhalten harmonisieren.
Richtlinien
-
Sollten sich harmonisch in das Gesamtlayout einfügen.
-
Grafiken können zur Unterstützung bestimmter Aussagen oder Funktionen dienen.
-
Grafiken sollten sich wie die anderen Inhalte an dem optischen Raster ausrichten.
-
Um die Barrierefreiheit von Webanwendungen zu unterstützen, sollten Grafiken im Quellcode immer mit einem alternativen Text (Beschreibung) hinterlegt sein. So können die Inhalte auch für alternative Ausgabegeräte zugänglich gemacht werden.
9.1. Beschriftung von Bedienelementen
Grundsätzlich werden alle Bedienelemente mit einem Label versehen, Ausnahmen sind z.B. Schaltflächen, die nur mit einem Icon versehen sind. Das Label muss prägnant und leicht zu verstehen sein. Weitere Hinweise und Richtlinien sind im Kapitel Label bei den Bedienelementen nachzulesen.
9.2. Rechtschreibung
Zu einem klaren, professionellen Gesamterscheinungsbild trägt auch eine korrekte Rechtschreibung sowie eine konsistente Groß- und Kleinschreibung bei. Während für englischsprachige User-Interfaces zwischen verschiedenen Formen der Groß- und Kleinschreibung unterschieden wird, muss für deutschsprachige Applikationen lediglich die korrekte deutsche Rechtschreibung angewendet werden. Eine Ausnahme besteht darin, dass das erste Wort der Beschriftung eines Bedienelements immer großgeschrieben wird, unabhängig von der jeweiligen Wortart. Zudem werden keine vollständig korrekten Sätze gebildet und nicht mit einem Satzzeichen abgeschlossen. Beispiele zur Benennung von Schaltflächen
-
Kopieren
-
Speichern
-
Als Vorlage speichern
Verwendung von Auslassungspunkten
Auslassungspunkte („…“) können eingesetzt werden, um deutlich zu machen, dass mehr Text vorhanden ist, als aus Platzgründen aktuell angezeigt werden kann.
Richtlinien
-
Auslassungspunkte können an zwei Positionen eingefügt werden:
-
In der Mitte des Textes, wenn die Bedeutung von Anfang und Ende voraussichtlich wichtiger ist als der mittlere Teil des Textes.
-
Am Ende des Textes, wenn der Anfang des Textes voraussichtlich wichtiger ist als das Ende.
-
Texte mit Auslassungspunkten sollten immer einen Tooltip erhalten, der den gesamten Text anzeigt.
9.3. Vermeidung von technischem Jargon
Text muss immer in der Sprache des Benutzers verfasst werden. Im Folgenden werden einige Beispiele für technische Begriffe und ihre entsprechende Übersetzung in eine allgemein verständliche Sprache aufgezeigt.
Technischer Begriff Benutzer-Begriff
| Technischer Begriff | Benutzer Begriff |
|---|---|
|
|
9.4. System-Meldungen
Beim Verfassen von System-Benachrichtigungen – wie z.B. Fehlermeldungen – muss auf eine verständliche und konsistente Formulierung geachtet werden. Ein häufig auftretendes Problem ist dabei die Verwendung von negativ anmutenden Formulierungen, die den Benutzer demotivieren können. Die folgende Liste zeigt einige negative Bezeichnungen und ihre neutralen Äquivalente:
| Negativer Begriff | Neutraler Begriff |
|---|---|
|
|
Richtlinien
-
Vermeidung von redundanten Informationen
-
Vermeidung von mehrdeutigen Beschreibungen
-
Verwenden einer einfachen und konsistenten Satzstruktur
-
Nicht allein das Problem schildern, sondern auch eine mögliche Lösung formulieren.
-
Präzise Formulierungen
-
Inkorrekt: „Nichts selektiert"
-
Besser: „Bitte selektieren Sie ein Objekt in der Liste"
-
-
Positive Formulierungen
-
Positiver Tonfall (als würde man zu einem Freund sprechen)
-
Inkorrekt: „Illegale String-Länge aufgetreten.“
-
Besser: „Es wurden zu viele Zeichen eingegeben. Es sind maximal 20 Zeichen möglich.“
-
-
Allgemeinverständliche, positive Sprache
-
Inkorrekt: „Soll das Objekt gelöscht werden?“
-
Besser: „Wollen Sie das gewählte Objekt XY löschen?“
-
10. Visuelles Design
Im Folgenden werden Farben, Icons und Schriften definiert, die für das Visuelle Design genutzt werden sollten.
10.1. Farben
Farben sind wichtige Komponenten eines User Interface, die weit mehr darstellen als reine Ästhetik. Sie kommunizieren als Teil der visuellen Sprache des User Interface.
Allgemeine Richtlinien
-
Für das vorliegende User Interface werden hauptsächlich neutrale Weiß- und Grautöne verwendet. Generell sollten nicht zu viele verschiedene Grundfarben für die Gestaltung eines User Interface benutzt werden.
-
Werden Farben zur Codierung von Informationen genutzt, sollte eine redundante Form der Codierung angeboten werden, wie z.B. unterschiedliche Formen oder Icons oder eine zusätzliche textuelle Beschreibung.
-
Beziehungen zwischen verwandten Objekten können durch die Verwendung der gleichen Farbe verdeutlicht werden.
-
Warnfarben wie rot, orange und gelb sollten für die Anzeige von Warnungen und Fehlern reserviert bleiben.
-
Stark gesättigte Farben sollten vermieden werden.
-
Eine übermäßige Verwendung von Komplementärfarben sollte vermieden werden. Komplementärfarben der Primärfarbe eignen sich jedoch sehr gut als Aufmerksamkeits-Trigger für einen bestimmten Bereich des User Interface.
-
Ausreichend hoher Kontrast
-
Bei der Verwendung von Farben sollte immer ein ausreichend hoher Kontrast von Vorder- zu Hintergrundfarbe gewährleistet werden.
-
Die Web Accessibility Initiative (WAI), die Teil des World Wide Web Consortium (W3C) ist, hat die Web Content Accessibility Guidelines (WCAG) entwickelt, die unter anderem Referenzwerte für den Kontrast von Vorder- zu Hintergrundfarbe beinhalten. So beschreiben die WCAG verschiedene Kontrastverhältnisse, abhängig von der Schriftgröße.
-
Die folgenden Links verweisen auf weitere Informationen zur Kontrast-Analyse, die auf den Referenzwerten der WAI basieren:
-
-
Berücksichtigung von Farbenfehlsichtigkeit
-
Bei der Auswahl der Farben sollte auch eine mögliche Farbenfehlsichtigkeit der Benutzer berücksichtigt werden.
-
Etwa 8-9 % aller Männer sowie eine geringe Anzahl Frauen leiden unter einer Form von Farbenfehlsichtigkeit, häufig als Farbenblindheit bezeichnet. Folgende Formen der Farbenfehlsichtigkeit werden unterschieden:
-
Rot-Grün-Sehschwäche (Fachbegriffe: Protanopie, Deuteranopie)
-
Blau-Gelb-Sehschwäche (Fachbegriff: Tritanopie)
-
-
Die Rot-Grün-Sehschwäche ist die am weitesten verbreitete Form der Farbenfehlsichtigkeit während die Blau-Gelb-Sehschwäche eher selten auftritt. Menschen, die unter einer Sehschwäche leiden, nehmen die entsprechenden Farben nicht differenziert wahr, sondern lediglich unterschiedliche Graustufen.
-
Auf der Webseite ViCheck finden sich hilfreiche Tools und Downloads, um die verschiedenen Formen der Farbenfehlsichtigkeit zu simulieren.
10.1.1. Applikationsfarben
Pro Applikationsgruppe kann eine Farbe definiert werden, welche an verschiedenen Stellen des Applikationsportals eingesetzt wird und so einen Wiedererkennungswert schafft. Kann eine Applikation keiner Gruppe zugeordnet werden, so kann sie ihre eigene Farbe erhalten. Bei der Wahl der Farben sind die generellen Richtlinien zur Benutzung von Farben zu berücksichtigen. Die Farben sollten auch so gewählt werden, dass ein harmonisches Gesamtbild erhalten bleibt.
Richtlinien zur Anwendung
-
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.
-
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
-
10.2. Schriften
Die Standard-Schriftart für Bedienelemente und Inhalte ist Liberation 14 pt regular in Dunkelgrau. Liberation ist eine kostenfreie Schriftart und wird zur Nutzung empfohlen, wenn eine Web-Anwendung DIN SPEC 91379 unterstützt. Ausnahmen sind dem Stylesheet zu entnehmen.
Richtlinien zur Anwendung
-
Die Verwendung verschiedener Schriftarten muss vermieden werden. Mehr als zwei Schriftarten dürfen nicht verwendet 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 z.B. Expander (Progressive Disclosure).
-
Die Anzahl verschiedener Schriftgrößen muss auf ein notwendiges Minimum reduziert werden.
-
Es muss sichergestellt sein, dass der Kontrast der Schriftfarbe zur Hintergrundfarbe ausreichend groß ist.
10.3. Icons
Die Icons sollten alle einem einheitlichen Stil Folgen. Innerhalb der Anwendung wird der Icon-Font Awesome benutzt. Dieser Font muss in die Webanwendung eingebunden werden. Die Icons sollten nur an Stellen verwendet werden, an denen das Bedienkonzept den Einsatz von Icons vorsieht.
In der folgenden Tabelle sind mögliche Icons und deren Funktion dargestellt sowie die dazugehörige CSS-Klasse. Die CSS-Klasse bezieht sich auf Font Awesome Version 5.
Eine Gesamtübersicht der zur Verfügung stehenden Icons finden Sie unter: Prime Faces Icons
| 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 |
|
pi-check |
Akzeptieren, Annehmen, Erledigen, Zustimmen |
|
pi-paperclip |
Anhänge |
|
pi-reply |
Antworten |
|
pi-eye |
Anzeigen |
|
pi-file |
Archiv, aus Archiv zurück holen |
|
pi-pencil |
Bearbeiten, Bearbeitung fortsetzen, Editieren, Korrigieren |
|
pi-user |
Benutzer, User |
|
pi-image |
Bild, Bild anzeigen |
|
pi-language |
Buchstaben-Picker |
|
pi-download |
Datei laden, Download, Herunterladen, Laden von Daten |
|
pi-list |
Datensatz anzeigen, Detailauskunft |
|
pi-share-alt |
Daten senden, Daten übermitteln, Senden, Versenden |
|
|
pi-file |
Dokument erstellen, Erstmeldung |
|
|
pi-file |
Druckansicht |
|
pi-print |
|
|
pi-cog |
Einstellung, Einstellungen |
|
pi-arrow-up-right |
Eintrag auswählen |
|
pi-minus |
Entfernen |
|
pi-check-square |
Entscheiden |
|
pi-plus |
Ergänzen |
|
pi-bell |
Erinnerung |
|
pi-upload |
Exportieren |
|
pi-exclamation-triangle |
Fehler, Fehlerhaft |
|
pi-eraser |
Felder leeren |
|
pi-check-circle |
Fertig, Abgeschlossen |
|
pi-filter-fill |
Filter ausfüllen |
|
pi-history |
Historie |
|
pi-info-circle |
Info |
|
pi-arrow-circle-down |
Importieren |
|
pi-calendar |
Kalender |
|
pi-id-card |
Kontakt |
|
|
pi-list |
List Picker (Objektauswahl) |
|
pi-trash |
Löschen |
|
pi-envelope |
|
|
|
far fa-envelope |
Nachrichten |
|
pi-bookmark-fill |
Notiz |
|
pi-folder-open |
Seite öffnen |
|
pi-save |
Sichern, Speichern |
|
pi-search |
Suchen, Suche wiederholen, Neue Suche, Durchsuchen, letzte Suche |
|
|
pi-list |
Trefferliste |
|
pi-arrow-circle-left |
Vorheriger |
|
pi-arrow-circle-right |
Weiter, Nächster |
|
pi-refresh |
Wiederholen |
|
pi-star-fill |
Wiedervorlage |
|
pi-clock |
Zeit, Time Picker |
|
|
pi-arrow-circle-left |
Zurück (Navigation) |
|
|
pi-share-alt |
Zurückgeben (an Sender) |
|
|
pi-user |
Zuständigkeit |
11. Beispiel Screens
12. Do’s and Dont’s
Dieses Kapitel zeigt einige oft nicht befolgte Regeln und häufige Verstöße gegen das Bedienkonzept auf.
12.1. Do’s
-
Schreibe semantisches HTML. Verwende Elemente so, wie sie gedacht sind - ein "hauptsache optisch korrekt" genügt spätestens beim Thema Barrierefreiheit nicht mehr. Ziehe hierbei z.B. den Mozilla Developer Guide zurate. Dabei kommt es auch auf Details an, wie etwa dem Unterschied zwischen <div> und <span>.
-
Beachte unbedingt allgemeingültige Webentwicklungsvorgaben und Best Practices, insbesondere die Vorgaben zur Barrierefreiheit aus WCAG und BITV.
-
Halte Bedienelemente, z.B. Buttons, ausreichend groß für ihre Beschriftung.
-
Ist eine Abkürzung sinnvoll, erkläre sie mit einem Tooltip.
-
Ordne Labels ihren Bedienelementen im HTML zu, sodass ein Klick auf das Label auch das Bedienelement aktiviert.
-
Erwäge bei der Nutzung großer Radio-Button-Gruppen ein Dropdown und bei kleinen Dropdowns eine Radio-Button-Gruppe.
-
Sorge dafür, dass alle Elemente auch ohne Maus erreichbar und bedienbar sind.
12.2. Dont’s
-
Löse keine Aktionen durch Bedienelemente aus, wenn diese nicht dazu vorgesehen sind (z.B. Radiobuttons oder Checkboxen).
-
Vermeide schwache Kontraste, z.B. hellgrün auf grau.
-
Verzichte auf Links mit generischen Texten, wie "Hier klicken". Der Linktext sollte erklären, wohin der Nutzer gelangt.
-
Vermeide Labels mit mehr als drei Wörtern.