Spezifikation
Für den Aufbau einer effizienten und nutzbaren Bibliothek ist die sinnvolle Strukturierung und Organisation der Komponenten entscheidend. Gut definierte und konsistente Namenskonventionen ermöglichen es dem Benutzer nicht nur die relevanten Komponenten schneller zu finden, sondern machen die Bibliothek auch für zukünftige Erweiterungen skalierbar. Verwende folgende Regeln und Konventionen für die Erweiterung sowie Erstellung einer DB UX-Komponentenbibliothek. Verwende sie für Symbole, Textstile oder Ebenenstile.
Dokument
Sprache
Wir unterscheiden bei der Anwendung von Sprache zwischen Bezeichnungen und Inhalten.
Bezeichnungen
Für Bezeichnungen von Ebenen, Symbolen, Textstilen, Ebenenstilen, Overrides etc. verwenden wir US-Englisch.
Inhalte
Für Inhalte verwenden wir als Standard die Ziel-Sprache in der die App oder der Service angeboten wird. Für Standard Librarys verwenden wir Deutsch.
Schreibweise
Wir verwenden für Bezeichnungen Symbole, Textstile, Ebenenstile, Overrides etc die Title Case Schreibweise. Wende sie wie folgt an:
Was schreiben wir groß
Adjektive (schön, groß, hoffnungsvoll)Adverbien (kraftvoll, leise, hastig)Substantive (Computer, Tabelle, Manuskript)Pronomen (sie, sie, er)Untergeordnete Konjunktionen (wie so) | Was schreiben wir klein
|
|---|
Dateibezeichnung
Verwende für Sketch-Librarys, Templates und Stickersheets folgendes Schema für die Formatierung, Bezeichnungen und Dateinamen.
| Type | Prefix | Dateiname | Library Name |
|---|---|---|---|
DB Standard | DB-Standard | DB-Standard_Icon.sketch | DB Standard:Icon 2.0.2 |
DB Service | DB-Service | DB-Service_Maps.sketch | DB Service: Maps 2.1.2 |
DB Produkt | DB-Product | DB-Product_Navigator.sketch | DB Product:Navigator 3.4.2 |
DB Template | DB-Design-Template | DB-Design-Template_Bahn-de.sketch | DB Design Template Bahn.de 2.0.0 |
Vorschaubild
Wir erstellen für jede Bibliothek ein eigenes Vorschaubild. Dazu legen wir in der Sketch-Datei ein Artboard mit dem Namen "Library Preview" an. Bei Standard- und Service-Bibliotheken folgen wir den unten genannten Vorgaben und Beispielen. Für Produkt-Bibliotheken verwenden wir das jeweilige Produkt-Icon.
Template für Vorschaubilder
Ein Template für das Erstellen von Sketch-Vorschaubildern.
Layerstruktur
Positionierung Vorschaubild
Farben, Texte und Layer Styles
Die DB Brand Colors und Text Styles lassen sich einfach von einer bestehenden Library kopieren. Du findest die installierten Libraries auf deinem Mac unter Library/Application Support/com.behomiancoding.sketch3/Libraries
Symbole (Komponenten)
Thematisch haben wir in diesem Beispiel die generellen Komponenten und Spezialkomponenten für eine bessere Übersicht getrennt. Das hat keine Auswirkung auf die Struktur bei der Installation und Anwendung.
Versionierung der Library
Symbol
Benennung
Verwende für die Benennung der Symbole einen Präfix und für Schreibweise die Title Case Regel.
Regel
BeispielDiese sind:
Namen können immer beliebig geändert werden! Jedes Symbol hat eine UNIQE ID durch die die Verlinkung innerhalb desselben Sketch-Dokuments oder zu anderen Sketch-Dokumenten hergestellt wird.
Präfix
Der Präfix ist immer abhängig von der Hierarchie. Wir beginnen mit der Zahl, dann Großbuchstaben und zuletzt Kleinbuchstaben.
Zusätzliche Ebenen
Wenn es zusätzliche Ebenen gibt, dann wiederholen wir die Regel. Das heißt: Zahl, Großbuchstaben und dann Kleinbuchstaben.
Variationen
Verfügt eine Komponente über mehrere Varianten, dann fassen wir diese in einer Gruppe zusammen. So können wir alle Varianten, im Sketch-Inspektor bequem über das Dropdown-Menü auswählen. Verwende dabei die Namenskonvention aus den nachfolgenden Grafiken.
Symbolstruktur
Wir halten die Struktur einfach und unterscheiden nur in Komponenten und Basiselemente.
Basiselemente
Basiselemente sind die Grundbausteine, aus denen wir Komponenten bauen. Je nach Einsatz werden sie global unter "Basic Elements" oder lokal unter "x" in einer Komponente abgelegt.
Globale BasiselementeGlobal verwendete Basiselemente legen wir unter "17. Basic Elements" ab.
Lokale BasiselementeFür lokale Basiselemente verwenden wir die Gruppe "x". Diese platzieren wir auf derselben Ebene wie die Komponente.
Präfix für Basiskomponenten
Innerhalb der Basiskomponenten beginnen wir Präfixe mit der Zahl, dann Großbuchstaben und zuletzt Kleinbuchstaben.
Symbolzeichenfläche
Wir verwenden nachfolgende Regeln zum Anordnen und Benennen von Ebenen innerhalb einer Zeichenfläche.
Hierarchie
Die Anordnung der Ebenen in der Zeichenfläche (Symbol) bestimmt die Reihenfolge der Overrides im Inspektor. Die Ebenen haben wir in Leserichtung angeordnet.
Ebenenbezeichnungen
Wir verwenden gut verständliche und intuitive Ebenenbezeichnungen. Emojis im Namen helfen uns dabei die Funktionen visuell einfach zu unterscheiden.
Overrides
Mit Overrides können wir einfach zwischen den verfügbaren Text- und Layerstilen wechseln. Wir können sie aktivieren oder deaktivieren. Dabei versuchen wir immer die Komplexität zu minimieren, um das Fehlerpotential zu reduzieren.
Komplexität vermeiden
Vermeide unnötige Komplexität und aktiviere nur Overrides deren Einsatz benötigt wird.
Don't: Alles ungeprüft aktiviert lassen
Keine gute Übersicht und keine sichere Verwendung garantiert
Do: Reduzierung der erlaubten Überschreibungen
Einfache Übersicht mit wenig Fehlerpotential
Globale Stile
Textstile
Wir verwenden einheitliche Textstile, um ein gleichmäßiges Bild in unseren Produkten zu gewährleisten. Dabei unterteilen wir die Textstile in zwei Kategorien. Primär: Basic Mobile Text und sekundär: Mobile Component Text Overrides
Primär: Basic Mobile TextDiese Kategorie hat neun Textstile und umfasst verschiedene Ausrichtungen und Farben. Wir versuchen bei der Erstellung neuer Komponenten immer einen dieser Stile zu verwenden.
HINWEIS: Diese sollten niemals aktualisiert werden.
Sekundär: Mobile Component Text OverridesDie zweite Kategorie beinhaltet textbasierte Overrides für Komponenten.
Zum Beispiel kann in der Komponente "Titel" der "Titeltext" sowohl fett als auch regular sein. Dieser kann dann im Inspektor einfach umgeschaltet werden. Um diese Overrides zu ermöglichen, wurden zwei Textstile definiert und in einer Gruppe zusammengefasst.
Definieren von Textstilen
Textstile folgen der gleichen Namenskonvention wie Komponenten.
Redundanz vermeiden
Um zu verhindern, dass wir für jeden Schriftschnitt eine neue Komponente (Symbol) erstellen, fassen wir diese in Gruppen zusammen. So können wir die Anzahl der Komponenten reduzieren und über den Inspektor ganz einfach einen neuen Schriftschnitt zuweisen.
Don't: Für jeden Schriftschnitt eine neue Komponente
Do: Wir reduzieren die Anzahl der Komponenten auf ein Minimum und nutzen Textstile für die Varianten
Textstile können einfach ausgewählt werden ohne die Komponente auszutauschen
Ebenenstile
Über die Ebenenstile definieren wir Hintergründe, Höhe, Deckkraft (100% vs. 70%) usw. Ähnlich wie bei den Textstilen bietet die DBUX-Komponentenbibliothek zwei primäre Kategorien von Ebenenstilen.
DB-MarkenfarbenDie erste Kategorie umfasst alle DB-Markenfarben und hat diese in drei Unterkategorien unterteilt: Primärfarben, Sekundärfarben und Transportfarben.
Weitere Informationen zu den Markenfarben findest Du hier im Ux Guide.
DB Mobile Component ColorsDie zweite Kategorie umfasst komponenten-spezifische Ebenenstile wie Hintergrundfarbe, Höhe, Linien usw.
1. Text Color2. Fill3. Background4. Background Blur5. Elevation6. Divider Line7. Disabled State / Opacity8. <any other additional layer style>
Definieren von Ebenenstilen
Auch bei den Ebenenstilen reduzieren wir die Anzahl der Komponenten sinnvoll. Wenn sich Eigenschaften oft wiederholen, wie z.B. bei Hintergrundfarben, Rändern und Schatten, legen wir Ebenenstile an, um einfach darauf zugreifen zu können. So erreichen wir eine hohe Konsistenz und vermeiden unnötige Abweichungen.
Redundanz vermeiden
Um zu verhindern, dass wir für jede Designänderung eine neue Komponente (Symbol) erstellen, fassen wie diese in Gruppen zusammen. So können wir die Anzahl der Komponenten reduzieren und über den Inspektor der Komponenten ganz einfach die Ebenenstile auswählen und anwenden.
Don't: Für jede Style-Änderung eine neue Komponente
Do: Wir reduzieren die Anzahl der Komponenten auf ein Minimum und nutzen Ebenenstile für die Varianten
Ebenenstile zur Auswahl im Inspektor
Overrides definieren
Erstellen von Unterkomponenten
Wie auch schon bei den oberen Beispielen, versuchen wir für sich wiederholende Muster Overrides anzulegen, um die Komplexität zu reduzieren.
Redundanz vermeiden
In dem unteren Beispiel sind die Buttons nahezu identisch. Der einzige Unterschied ist, dass die Reihenfolge Text und Icon umgekehrt ist. Es entsteht eine unnötig hohe Anzahl an Optionen in der Dropdown-Liste.
Don't: Für leichte Abweichungen neue Zeichenflächen verwendet
Jede Variante ist aufgeführt. Das führt zu langen Listen und macht es unübersichtlich.
Do: Erstellung von Unterkomponenten, um diese für alle Buttons einfach zu verwenden
Übersichtliche Auswahl
Leichte Anwendung
Weiter