Nachfolgend sind allgemeine Empfehlungen zum Aufbau der unterschiedlichen Ansichtstypen aufgelistet.
Grundsätze
Folgende Grundsätze gelten in allen Fällen:
Ansichten in logische/thematische Gruppen aufteilen, die der Zielgruppe im Standard-Anwendungsfall eine optimale Aufgabenerledigung ermöglichen
Bei sehr umfangreichen Datenobjekten lohnt es sich allenfalls, Aufgaben-optimierte Ansichten zu erstellen, z.B. "Fallbearbeitung" vs. "Rechnungsstellung"
Ansichten sollen immer nach Wichtigkeit der Informationen strukturiert werden; links/oben = wichtigste Information
Es sollen nur wirklich benötigte Ansichten erstellt werden; keine Ansichten "auf Vorrat"
Liste
Spalten:
Empfohlen sind max. 5-7 Spalten
Nur Spalten in die Liste nehmen, die…
zur eindeutigen Identifikation eines Objekts relevant sind
zum Vergleich von Objekten benötigt werden
wichtige Status-Informationen zum Objekt enthalten
für Kontext-Aktionen relevant sind
wichtige Navigationsmöglichkeiten bieten
Weitere Spalten können auf "invisible” gesetzt werden, um bei Bedarf im Column Chooser zur Verfügung zu stehen
Drilldown:
Erste Spalte soll (n) sollen immer eine Drilldown-Spalte(n) sein (Ausnahme: Icon-Spalte)
Eine Drilldown-Spalte sollte wenn möglich immer auf ein eindeutig "identifizierendes" Feld gelegt werden (Titel, Name, Id, ...)
Optimal ist eine Drilldown-Spalte, mehr als zwei sind nicht empfohlen
Relationen bzw. ValueLists sollten nicht zum Drilldown verwendet werden (Ausnahme: Relation auf Zwischentabelle)
Sortierung:
Default Sortier-Spalten im Layout möglichst weit vorne platzieren (in der Sortierreihenfolge)
Sortierung nicht als Gruppierungsersatz missbrauchen; wenn eine Gruppierung sinnvoll ist, sollte die Liste auch explizit gruppiert werden
Gruppierung:
Gruppierung nur dann per Default anwenden, wenn:
Die verwendeten Gruppen im Kontext eine hohe Relevanz haben (z.B. Event-Gruppierung nach Monaten, Angestellten-Gruppierung nach Abteilung)
Die zu erwartende Gruppengrösse im Durchschnitt nicht mehr als 50-70 Elemente umfasst (wenn grösser, übersteigt der "Scrollaufwand" den "Filteraufwand" um die gleiche Information zu erhalten)
Nur in Ausnahmefällen mehr als eine Default-Gruppierung verwenden
Wiederverwendung:
Bei mehreren ähnlichen Listen mit unterschiedlicher Filterung (z.B. aktive/inaktive) jeweils die gleichen Columns verwenden, damit User sich einfach orientieren können
Detail
Object Summary
Object Summaries grundsätzlich nur auf zentralen bzw. häufig verwendeten Entitäten einsetzen (z.B. Person, Vertrag, Firma)
Im Object Summary nur Infos platzieren, die:
Ergänzend zum Title-Layout wichtig für die Identifikation des betreffenden Objekts sind
Während der Navigation auf dem Objekt so relevant sind, dass sie immer sichtbar/zugreifbar sein müssen
Empfohlen sind max. 4-5 Felder
Tabs
Tabs sollen thematische Einheiten bilden und sinnvoll/eindeutig benannt werden
Gut: "Personendaten", "Aktivitäten", "Dokumente"
Schlecht: "Allgemein", "Erweitert"
Falls trotzdem ein “allgemeiner” Tab benötigt wird, wird "Grunddaten" als Bezeichnung empfohlen
Tab-Contents sollen überschaubar sein (max. 2 "Scroll-Seiten" auf Desktop); bei mehr Content besser ein weiteres Tab erstellen (besser lern- und navigierbar)
Bei umfangreichen Objekten kann es sinnvoll sein, ein "Übersicht"-Tab zu verwenden, auf welchem die wichtigsten Daten im Sinne eines kleinen Dashboards zusammengefasst sind
Gruppen
Die Infos innerhalb einer Seite/Tab in logische Gruppen unterteilen
Faustregel: Nicht mehr als 5-7 Zeilen innerhalb einer Gruppe
Aufklappbare Gruppen
Nur für sekundäre Informationen verwenden, nicht als Notlösung für Platzmangel (in diesem Fall werden weitere Tabs empfohlen)
Per default zugeklappt anzeigen
Pro Seite max. 1-2 aufklappbare Gruppen verwenden
Spalten
Innerhalb einer Ansicht überall das gleiche “Spalten-Grid” verwenden, so dass Elemente miteinander aliniert sind
Empfehlung für "normale" Desktop-Anwendung: 2-4 Spalten
Verwendung von Invisible vs. Disabled vs. Read-Only
Grundsatz: Die Ansicht sollte während der Bearbeitung möglichst wenig "springen"
Invisible: Felder, die im gegebenen Fall grundsätzlich nicht verfügbar/relevant sind (z.B. aus Berechtigungs- oder Kontextgründen)
Disabled: Felder, die aufgrund des aktuellen Zustands des Objekts nicht relevant sind , bei einer Zustandsänderung aber aktiv werden können (z.B. "Ehepartner", wenn Status "ledig" ist)
Read-Only: Felder, die zwar relevant sind, aber (im aktuellen Kontext) nicht bearbeitet werden können (z.B. MWSt-Anteil eines Preises)
Selektions-Controls für Einzelselektion
Checkbox: Bei eindeutigen ja/nein bzw. ein/aus Fällen. Label muss so gewählt werden, dass Zustand eindeutig ist
Radio-Group: Bei einer begrenzten Auswahlmöglichkeit (max. 3-5 Optionen), wenn eine explizite Auflistung der Möglichkeiten und eine direkte Auswahl sinnvoll sind
Combobox: Bei grösseren Optionen-Sets, wo eine Auswahl mittels Option-Bezeichnung gut möglich ist
SearchEdit: Bei grösseren Optionen-Sets, wo eine komplexe Suche aufgrund mehrerer Parameter benötigt wird. Aufgrund der etwas komplexeren Bedienung nur dann zu verwenden, wenn die Combobox nicht ausreicht.
Titel
Sollte nur Felder enthalten, die aus menschlicher Sicht eine eindeutige Identifikation erlauben
Stati gehören grundsätzlich nicht in ein Title Layout
"TextExpression" benutzen, wenn der Title formatiert werden soll und dadurch besser lesbar wird
Max. 3 Felder, eindeutigstes zuerst
Gut: John Doe - Encodo
Schlecht: 885794949 - Encodo - John Doe - Aktiv
Dashboard
System Dashboad soll zur Übersicht bzw. als Schnelleinstieg beim Login dienen
Wenn möglich keine Redundanz zur Hauptnavigation, sondern Fokus auf Systemzustand und Todos
Empfehlung: Content auf max. 5-6 komplexe Tiles begrenzen (verteilt auf nicht mehr als 3 "Zeilen")