Leitfaden Ansichten-Aufbau

Owned by Sebastian Greulach
Last updated: Apr 17, 2024 by Dominic Wettstein
4 min read

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 in den Column-Chooser ausgelagert werden um bei Bedarf zur Verfügung zu stehen. Diese Spalten werden auf IsHidden() gesetzt.

  • Drilldown:

    • Erste Spalte(n) sollen immer 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

    • Empfohlene Anzahl Felder: max. 4-5

      • Um die Anzahl Felder zu reduzieren, können Daten auch zusammengefasst werden. Statt z.B. für “Rechnungen total: 20” und “Rechnungen offen: 3” zwei Felder zu verwenden, kann dies in einem Feld “Rechnungen (offen/total): 3 / 20” zusammengefasst werden

    • Das Ein-/Ausblenden von Feldern (z.B. aufgrund von Stati) ist nicht empfohlen, da dies dazu führt, dass User sehr jedesmal genau hinschauen müssen, um welches Feld es sich an einer gegebenen Position handelt. Es wird deshalb stattdessen empfohlen, mit Stati (z.B. aktiv/inaktiv oder normal-warnung-error) zu arbeiten, damit Elemente immer an derselben Position zu finden sind.

    • Bei Object Summaries auf “ähnlichen” Klassen (z.B. Personen und Firmen) wird empfohlen, immer eine ähnliche Reihenfolge der Informationen im Object Header zu verwenden (also z.B. immer aktiv/inaktiv als erstes, Anzahl offene Tasks als zweites, etc.). Dies hilft Usern, sich in der Applikation schneller zurechtzufinden.

    • Einsatz von Farben:

      • Ganz grundsätzlich wird empfohlen, auffällige Farben nur einzusetzen, um auf einen Handlungsbedarf aufmerksam zu machen. Werden im Normalzustand schon zu viele Farben verwendet, werden ausserordentliche Zustände schlechter erkannt.

      • Für den Normalzustand sollten deshalb möglichst unauffällige Farben (leichtes grau, leichtes blau) verwendet werden

      • Die gängigen Signalfarben (rot/gelb/grün) sollten ihrer Bedeutung entsprechend für ausserordentliche Fehler-/Warnungs-/Erfolgs-Zustände verwendet werden

      • Neben den Signalfarben und dem neutralen Zustand wird maximal eine zusätzliche Farbe für spezifische Fälle empfohlen. Diese sollte sich genügend gut von den anderen Farben abheben, so dass sie nicht verwechselt wird. Zudem sollte diese zusätzliche Farbe so gewählt werden, dass deren Bedeutung mit den üblichen Farb-Assoziazionen (rot/gelb = Fehler, grün = Erfolg, blau = info/neutral) vereinbar ist.

  • 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")