...
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 werdenFür normale bzw. neutrale Zustände sollten möglichst unauffällige Farben (leichtes grau, leichtes blau) verwendet werden, damit im Ausnahmefall die vorgenannten Signalfarben besser herausstechen
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.
...