DESIGNSYSTEM

Design System

Wozu ein Design System

Die komponentenbasierte Entwicklung hat seit ihrer Vorstellung im Jahre 1968 für die Gestaltung interaktiver Systeme kontinuierlich an Bedeutung gewonnen. Die Unterteilung von Anwendungen in wiederverwendbare Bestandteile, steigert die Geschwindigkeit und verringert die Aufwände, indem möglichst wenig Code neu oder gar mehrfach programmiert werden muss.

Das Feld der Komponenten haben wir in den letzten 50 Jahren gelernt zu beherrschen. Es existieren inzwischen verschiedene Standards, die dazu beitragen wiederverwendbare Komponenten mit konstant hoher Qualität für unterschiedlichste Anwendungsfälle zu produzieren.

Geringe Herstellungskosten, eine kurze Produkteinführungszeit sowie ein effizienter Entwicklungsprozess sind heutzutage ständige Begleiter im Wettbewerb. Ferner gilt es trotz stetig wachsender Anwendungen und dezentral organisierten Teams ein konsistentes Benutzererlebnis zu schaffen.

 Schuldenfalle Zufallsprinzip

Die Anzahl autark agierender Teams, ungleiche Werkzeuge und eine sich ständig ändernde Funktionsdichte stellen eine Herausforderung für die Erzeugung eines homogenen Erscheinungsbildes dar.

Entscheidungen über z.B. Anordnung, Sichtbarkeit oder Verhalten wurden bisher individuell entlang der gegenwärtig vorliegenden Problemstellung getroffen. Jede Anforderung wurde isoliert betrachtet und einzig und allein für den jeweiligen Kontext gelöst. Die Fülle widersprüchlicher Design-Entscheidungen, gepaart mit unzureichenden Vorgaben führten zu unregelmäßigen Benutzeroberflächen (UI) und beliebigen Konventionen.

Hinweis

Maßgeschneidertes Design ist langsam, inkonsistent und schwierig zu warten.

Die permanente Inkonsequenz führt immer weiter in die Schuldenfalle. Die Anzahl der Design-Schulden wachsen mit jeder einzelnen maßgeschneiderten Lösung, was die Pflege der gesamten Anwendungen zusätzlich erschwert. Ein konsistentes UI-Design sowohl plattform- als auch team-übergreifend zu etablieren wird dadurch zu einer schier unlösbaren Aufgabe.

 Gemeinsames Verständnis

Wie gelingt es Design und die damit verbundenen Entscheidungen zu skalieren? Blindlings das Design-Team zu verstärken um mehr Entscheidungen noch schneller treffen zu können scheint in diesem Falle eher eine kontraproduktive Methode zu sein. Maßgeschneidertes Design lässt sich eben nur bedingt (bis gar nicht) vervielfältigen.

Wichtiger wäre es darüber nachzudenken, wie Lösungen schneller und fundierter abgeleitet werden können, die gleichermaßen für diverse Probleme funktionieren.

Um Design skalierbar zu machen, reicht es auch nicht aus, technische Aufwände ausschließlich mithilfe wiederverwendbarer Komponenten zu reduzieren. Die technische Perspektive muss von einer semantischen Ordnung (Design-Sprache) begleitet werden, um die bisher fragmentierten Designs zu einem gemeinsamen UX-Ergebnis zu vervollständigen.

Hinweis

Ohne gemeinsame Design-Sprache werden Lösungen individuell und inkonsistent bleiben.

Ein Design System bildet den Schulterschluss zwischen beschriebenen Standards und wiederverwendbarer Komponenten. Durch die Angabe von z.B. Zweck, Form, Platz, Farbe oder Bewegung erhält eine Komponente zusätzliche (wichtige) Eigenschaften, die übergreifend ein konsistentes Arbeiten ermöglichen. Für die unterschiedlichen Teams dient das System als übergreifende Referenz und begründete Grundlage für die eigenen Entscheidungen. Die einbezogenen Teams sowie die Gestaltung der jeweiligen Anwendungen können über dieses Instrument synchron gehalten werden.

FragmentiertSystematisch
Konsistentes Benutzererlebnis nicht möglichHält Teams und Anwendungen synchron
Es existieren zu viele Wahrheiten zur Lösung eines ProblemsWiederkehrende Muster sorgen für leicht verstehbare Anwendungen
Mangel an Konventionen bringt abweichende Oberflächen hervorErstellung von Prototypen wird professionalisiert und erleichtert
Design-Prozess kollabiertDesign-Schulden werden kontrollierbarer und minimiert

Die Verbindung zwischen festgelegten Konventionen und wiederkehrenden UI-Elementen erzeugt darüber hinaus für die Benutzer eine einfach zu verstehende Anwendung, was sich nicht nur positiv auf zu leistenden Supportaufwände auswirkt, sondern auch Wettbewerbsvorteile bedeuten kann und Bestandskunden bindet.

 Fortschritt durch Bewegung

Ein Design System ist wie ein Organismus und muss fortwährend gepflegt werden. Es ist kein starres Gebilde, sondern ständig in Bewegung während es regelmäßig Veränderungen in Form von Aktualisierungen und Optimierungen erfährt. Statt weitere Design-Schulden mit maßgeschneiderten Lösungen aufzubauen, können neue, kreative Ansätze in das System zurückfließen, und damit zentral zur Verfügung stehen. Von der zentralen Arbeit am System profitieren die dezentralen Teams und deren Anwendungen, bei denen mit sinkenden Aufwänden zu rechnen ist.

Mit dem systematischen Einsatz von Design-Richtlinien, begleitet von wiederverwendbaren Komponenten, werden kreative Lösungen zielgerichtet und nachhaltig für die Gestaltung interaktiver Systeme geordnet.

Bewährte Lösungen erhalten eine gesunde Art von Universalität, wobei gewährleistet bleibt, dass gleiche Problemstellungen auch immer gleich gelöst werden. Durch die kontinuierliche Resonanz der Teams wird das Design System gezielt modifiziert und optimiert, so dass verteilte Anwendungen davon profitieren können.

Ergänzung zur Anzeige eines leereren Status

 Anwendungsfall

Es kann vorkommen, dass eine Liste keine Elemente enthält, oder eine Suche keine Ergebnisse zurückliefert und somit dem Anwender ein leerer Bereich dargestellt wird.

 Erläuterungen

Besonders wenn während bestimmter Nutzungssituationen sich untypische Zustände ergeben, sollten die Hinweise oder Dialoge dazu so gestaltet sein, dass sie dem Nutzer den ungewohnten Status verdeutlichen. Dabei sollten die Hinweise mehr den Charme eines freundlichen Hinweises besitzen, anstatt über einen fehler-ähnlichen Charakter zu verfügen.

 Besonderheiten

Es gibt 4 wesentliche Elemente zur Anzeige eines leeren Status.

 Bild oder Illustration (optional)

Eine auf die Situation passende Abbildung. Hierbei sollten keine Icons verwendet werden, da diese sonst vom Anwender als Aktion wahrgenommen werden könnten.

 Titel

Eine Überschrift, die aus Sicht des Nutzers hilfreich sowie deutlich den Zweck des Bildschirms beschreibt.

 Kurzbeschreibung

Ergänzende Informationen und möglicherweise Empfehlungen zur Änderung bzw. Vermeidung des leeren Zustands.

 Aktion (optional)

Sofern sich dem Nutzer die eigentlichen Fähigkeiten der Anwendung erst in Verbindung mit entsprechenden Inhalten erschließen lassen, kann optional eine Aktion angeboten werden. Die Aktion sollte dem Anwender dabei helfen zu verstehen, was die Anwendung im Stande zu leisten ist und welche Inhalte dazu benötigt werden (z.B. Seiten hinzufügen).

Passend dazu findet man weiterführende Inhalte auf den folgenden Seiten des Design Systems.

Leere Status

Ergänzung zur erweiterbaren Suche

 Anwendungsfall

Das Konzept der erweiterbaren Suche sollte besonders dann zur Anwendung kommen, wenn die Suche nicht im Mittelpunkt der App steht. Bei der erweiterbaren Suche wird anstelle eines geöffneten Suchtextfeldes zunächst nur ein Suchsymbol (Lupe) in der Symbolleiste angezeigt.

 Erläuterungen

Der Anwender musste seine Eingaben stets mit ENTER bestätigen, bis sich die entsprechende Ergebnismenge gezeigt hat. Besonders in Verbindung mit einer einfachen Filtermöglichkeit von bereits sichtbaren Ergebnissen, war die anschließende Bestätigung der ENTER-Taste eher umständlich. Außerdem dient das Feedback während der Eingabe in diesem Fall als wertvolle Prognose auf zu erwartende Einträge.

 Besonderheiten

Entgegen der Material-Beschreibung kann individuell entlang des vorliegenden Anwendungsfall entschieden werden, ob der Suchmechanismus typischerweise bereits während der Eingabe einzelner Zeichen ausgelöst wird, oder tatsächlich erst nach Bestätigung der ENTER-Taste.

 Vorsicht

Sofern innerhalb der erweiterbare Suche Text-Vorschläge oder historische Sucheingaben zur Darstellung vorgesehen sind, sollte die Eingabe bzw. Auswahl des Nutzers abgewartet werden.

Passend dazu findet man weiterführende Inhalte auf den folgenden Seiten des Design Systems.

Erweiterbaren Suche

Navigationstypen

Erweiterte Liste mit Einträgen

 Anwendungsfall

Es soll eine Liste entstehen, auf deren Einträge unterschiedliche Aktionen durchgeführt werden können.

 Erläuterungen

Die Anatomie eines Listeneintrags lässt bis zu zwei direkte Aktionen auf dem Listenelement zu. Der primäre Aktionsbereich befindet sich vor dem eigentlichen Inhalt, während der sekundäre auf den Inhaltsbereich folgt. Der Inhalt kann ein- oder mehrzeilig (max. 3 Zeilen) gestaltet werden.

Über die Reihenfolge wird eine Hierarchie abgebildet, welche von vorne nach hinten die Relevanz abbildet. Der primäre Aktionsbereich wird sehr häufig als führendes Identifizierungsmerkmal (z.B. Piktogramm oder Bild) verwendet. Innerhalb eines mehrzeiligen Inhaltsbereich dient die Reihenfolge ebenso als Indikator für Relevanz (wichtig = oben).

 Besonderheiten

Checkboxen zur Auswahl eines Elements können sowohl vorne (primär) und hinten (sekundät) stehen. Die Position der Checkbox hängt stark vom jeweiligen Kontext ab. Sollte die Auswahlmöglichkeit die einzige Aktion für das Element darstellen, wird die Checkbox führend eingesetzt. Sollte der Platz für die primäre Aktion bereits belegt sein (z.B. Piktogramm) kann ebenso der sekundäre Bereich zur Darstellung der Checkbox gewählt werden.

Checkboxen müssen explizit angeklickt werden, um den Zustand ändern zu können. Eine Bestätigung des Eintrags per Klick wirkt sich nur dann auf den Zustand der Auswahl aus, wenn dieses die einzige Aktion für den gesamten Eintrag darstellt.

Material empfiehlt für die Auswahl von Elementen einen Hover-Effekt, um das gewünschte Element visuell zu markieren.

 Vorsicht

Es dürfen nicht zwei Aktionen gleichzeitig nebeneinander innerhalb eines Bereichs (primär oder sekundär) dargestellt werden. Im Desktop-Umfeld sind Checkboxen den Switch-Controls, wie man sie üblicher Weise vom Smartphone kennt, vorzuziehen.

Passend dazu findet man weiterführende Inhalte auf den folgenden Seiten des Design Systems.

Listen

Auswahl

Fehlende Icons und Symbole

 Anwendungsfall

Es wird ein Icon benötigt, welches sich nicht im Umfang der vom Design System zur Verfügung gestellten Symbolen befindet. Wie soll im Allgemeinen mit fehlenden Icons umgegangen werden, für die es weder in Material noch in z.B. FontAwesome eine Alternative existiert?

 Erläuterungen

Material bietet bereits eine große Anzahl unterschiedlichster Symbole zur freien Verwendung an. Obwohl regelmäßig neue Symbole hinzukommen, beschränken sich diese weitestgehend auf die übliche Symbolik der digitalen Welt (Media, Web, Content, usw.).

Symbolik ist sehr wichtig, da Menschen von Natur aus Bilder schneller wahrnehmen können als Text. Icons sollten auch immer recht nah an bereits bekannter Bildsprache anlehnen (z.B. Diskette zum Speichern), oder eine Analogie zur realen Welt herstellen (z.B. Stift zum Editieren) Durch die Wiederholung bzw. die wiederkehrenden Muster wird eine Anwendung vom Nutzer als besonders intuitiv empfunden.

Die Material Icons werden in unterschiedlichen Style-Variationen angeboten (Filled, Outlined, Rounded, Two-Tone und Sharp). Filled ist dabei die zu präferierende Variante.

 Besonderheiten

Mit d.velop Icon Font, die bereits in der DUX zum Einsatz gekommen ist, haben wir einen Weg gefunden individuelle Symbole bedarfsgerecht integrieren zu können. Diejenigen Symbole, welche im besonderen Maße im ECM-Kontext notwendig sind (z.B. Aktensymbol), können in Zukunft darüber bereitgestellt werden. Hierbei ist es zwingend erforderlich die Icons nach den Prinzipien des Design Systems entstehen zu lassen.

 Vorsicht

Sofern außerhalb der Material Icons oder der d.velop Icon Font weitere individuelle Bibliotheken verwendet werden, ist auf eine angemessene Lizenzierung zu achten.

Passend dazu findet man weiterführende Inhalte auf den folgenden Seiten des Design Systems.

Material Icons

Icon Designprinzipien

Platzierung von Aktionen

 Anwendungsfall

Die Bearbeitung von Inhalten innerhalb einer Ressource soll abgeschlossen werden. Dazu soll dem Nutzer angeboten werden die eben durchgeführten Änderungen zu speichern. An welcher Stelle soll die entsprechende Aktion untergebracht werden?

 Erläuterungen

Aktionen, die sich auf den Ressourceninhalt beziehen, sollen als s.g. Icon Buttons Teil der Top App Bar am oberen Rand der Ressource sein. Die einzelnen Aktionen werden beginnend im Startbereich von links nach rechts ergänzt. Weniger wichtige Aktionen (unter Beachtung des jeweiligen Kontext) können im Endbereich der Top App Bar platziert werden.

 Besonderheiten

Bei klassischen Web-Formularen (z.B. Registrierung oder Login), die man in der Regel von oben nach unten ausfüllt, werden die primären Aktionen nach Abschluss des Vorgangs rechtsbündig unterhalb des letzten Formular-Elements positioniert.

Sobald das Formular den sichtbaren Bereich des Anzeigegerätes überschreiten sollte, wird empfohlen die Aktionen am unteren Bildrand zu fixieren, um diese ohne zusätzliche Scrollbewegung erreichen zu können.

 Vorsicht

Selbst wenn die Darstellung von Dokument-Eigenschaften der Anmutung eines klassischen Web-Formulars sehr nahe kommen sollte, gilt es die Aktionen in der Top App Bar bereitzustellen. Schließlich vermutet ein Nutzer in solchen Fällen häufig die abschließende Aktion an der Stelle, an der die initiale Aktion stattgefunden hat (Bearbeiten -> Speichern).

Passend dazu findet man weiterführende Inhalte auf den folgenden Seiten des Design Systems.

Top App Bar

Icon Buttons

Verwendung von Buttons

 Anwendungsfall

Bei der Darstellung von Schaltflächen auf Seiten oder Dialogen soll eine Gewichtung der einzelnen Aktionen vorgenommen werden, um den Nutzer deutlich auf die unterschiedlichen Optionen hinzuweisen. Zudem soll die primäre Aktion von den restlichen Möglichkeiten visuell deutlicher abgegrenzt werden.

 Erläuterungen

Das Design System bietet im Standard vier unterschiedliche Varianten von Schaltflächen an, um die Aufmerksamkeit des Nutzers gezielt zu lenken.

Eine einzelne Schaltfläche soll in der contained-Variante mit gefüllter Fläche in der zugrundeliegenden Primärfarbe erscheinen. Existieren zwei Buttons nebeneinander, kommt neben der contained-Variante ein s. g. Text-Button ohne Rahmen oder farblicher Füllung zum Einsatz.

 Vorsicht

Der Floating Action-Button (FAB) stellt hierbei eine Ausnahme dar, und ist von dieser Ergänzung zum Design System nicht betroffen. Der Floating Action-Button (FAB) liegt schwebend über allen übrigen Bildschirminhalten und soll jederzeit erreichbar sein. Typischerweise als kreisförmige Form mit einem Symbol in der Mitte.

Hinweis

Der FAB konkurriert derzeit zu sehr mit den Konzept der Kontextaktionen, so dass dringend von der Verwendung abgeraten wird, um den Nutzer nicht unnötig zu verwirren.

Passend dazu findet man weiterführende Inhalte auf den folgenden Seiten des Design Systems.

Buttons

FAB

Verwendung von Fortschritts-Indikatoren

 Anwendungsfall

Oftmals müssen im Hintergrund für den Anwender nicht sichtbare Operationen (z.B. Server-Kommunikation) durchgeführt werden, um die Benutzeroberfläche nach Erhalt der Daten, wie erforderlich darstellen zu können. Um dem Nutzer eine im Hintergrund stattfinde Operation zu signalisieren, existieren s.g. Fortschritts-Indikatoren. Mithilfe der verschiedenen Indikatoren werden nicht spezifizierbare Wartezeiten oder die Dauer eines Prozesses ausgedrückt.

 Erläuterungen

Sobald das System im Hintergrund (nicht sichtbar) Operationen durchführt, sollte Anwender während der Nutzung rechtzeitig und durch angemessenes Feedback darüber informiert werden. Nach psychologischen Erkenntnisse erwarten Menschen innerhalb von 192 ms eine Reaktion von ihren Interaktionspartnern auf ihre Ausführungen. Die selbe Erwartungshaltung gilt für die Arbeit mit einem interaktiven System, wie z.B. die Benutzeroberfläche einer Anwendung.

Aus diesem Grund und zur Vermeidung potentieller, unbeabsichtigter Situationen (z.B. durch mehrfache Ausführung der gleichen Aktion), sollte das System die laufenden Aktivitäten dem Nutzer in einem angemessenen (Zeit-)rahmen signalisieren. Sofern davon ausgegangen werden kann, dass die tatsächliche Dauer der Wartezeit nicht näher bestimmt werden kann, wird der Indikator-Typ "Indeterminate" (engl.: unbestimmt) mit dem Formfaktor "linear" empfohlen.

Sofern möglich wird dringend empfohlen mit einer kurzen, prägnanten Beschreibung oberhalb des Indikator die aktuelle Situation zu beschreiben (z.B. "Änderungen werden gespeichert...") .

 Besonderheiten

Sofern es sich um den initialen Aufbau einer Tabelle handelt, führt der lineare Indikator entlang des unteren Randes des Tabellenkopfes. Für den Fall, dass der Tabellenkopf außerhalb des sichtbaren Bereichs befinden sollte, bewegt sich der Indikator am unteren Rand der letzten sichtbaren Tabellenzeile.

 Vorsicht

Die kreisförmige Variante der Indikatoren ist ausschließlich dann zu verwenden, wenn eine länger andauernde (Hintergrund-)Aktivität auf einem Element signalisiert werden soll, welches aufgrund seiner physikalischen Beschaffenheit (z.B. ein Button) keine andere Variante zulässt.

Passend dazu findet man weiterführende Inhalte auf den folgenden Seiten des Design Systems.

Fortschritts-Indikatoren

Verwendung der Top App Bar

 Anwendungsfall

Es existieren unterschiedliche Varianten der Top App Bar mit den Eigenschaften: u.a. Normal, Dense oder Short. Die Unterschiede der drei Varianten liegen vor Allem in der Ausprägung der Höhe des Elements. Welche Variante soll denn verwendet werden?

 Erläuterungen

Innerhalb von d.ecs shell, welches maßgeblich für die Positionierung der einzelnen App-Ressourcen sowie der Einhaltung des zugrundeliegenden Bedienkonzepts zuständig ist, werden im Zuge der Umstellung ebenfalls die Konzepte der Top App Bar zum Tragen kommen. Im Wesentlichen verwendet d.ecs shell die normale Form.

Zur Verwendung als Toolbar, um Aktionen innerhalb der eigenen Ressourcen anzubieten, soll die etwas sparsamere Form (Dense) verwendet werden. Darüber hinaus soll die Aktionsleiste nicht in der Primärfarbe, sondern in der Farbe des Hintergrundes (meist Weiß) erscheinen. Diese Änderungen können mithilfe von nachträglichen Attributierung der relevanten CSS-Klassen oder bequem über die Verwendung von SCSS-Mixins gelöst werden.

Details zu Style-Anpassungen der Top App Bar sind hier beschrieben.

 Besonderheiten

Die normale Top App Bar verringert die Höhe automatisch abhängig von dem zur Verfügung stehenden Platz. Im Gegensatz dazu bleibt die Dense-Variante jederzeit höhen-stabil.

Häufig ist es sinnvoll die Toolbar dauerhaft am oberen Rand fixieren zu können, damit die jeweiligen Aktionen jederzeit erreichbar bleiben. In diese Fall kann die Fixed-Variante mit der Dense-Variante kombiniert werden. Das Verhalten der Dense-Variante stellt sich dagegen so dar, dass die Toolbar zwar mit der Scroll-Bewegung verschwindet, bei der ersten Gegenbewegung allerdings wieder am oberen Rand erscheint.

 Vorsicht

Für die Varianten Short und Prominent haben wir bisher keinen Andwendungsfall ausmachen können. Diese sind vorerst nicht zu verwenden.

Passend dazu findet man weiterführende Inhalte auf den folgenden Seiten des Design Systems.

Top App Bar

Icon Buttons

Theming

Verwendung von Texteingabefeldern

 Anwendungsfall

Material Design bietet leicht unterschiedliche Ausprägungen von Eingabgefeldern an. Die Varianten Filled und Outlined unterschieden sich maßgeblich in der Art der Abgrenzung zueinander. Filled kennzeichnet sich durch einen vom Rest abhebenden Hintergrund, während sich die outlined-Variente durch eine geschlossene Kontur abgrenzt.

Welche der Varianten soll zugunsten einer durchgängigen User Experience verwendet werden?

 Erläuterungen

Aufgrund der visuellen Nähe zu papiergebundenen Formularfeldern und des höheren Unterscheidungsgrad gegenüber einem Button, wird empfohlen die Filled-Variante den übrigen Varianten vorzuziehen und als Default zu verwenden.

 Besonderheiten

Outlined sollte nur in Ausnahmefällen zum Einsatz kommen, und ausschließlich innerhalb eines abgeschlossenen Kontext geschehen. Die Abweichung vom Standard sollte einem bestimmten Zweck dienen, wie z.B. der besseren Unterscheidung oder der Verdeutlichung eines fremden/neuen Zusammenhangs. Ein Mischbetrieb oder Wechsel innerhalb der selben Nutzungssituation wird nicht erlaubt.

Eine Textarea zur mehrzeiligen Eingabe existiert derzeit ausschließlich als Outlined-Variante und kann bislang immer - unabhängig vom Kontext - verwendet werden.

 Vorsicht

Im Gegensatz zur Beschreibung befinden sich innerhlab der Demo weitere Varianten, wie z. B. Shaped Filled. Diese Variante mit stark abgerundeten oberen Ecken soll nicht verwendet werden.

Passend dazu findet man weiterführende Inhalte auf den folgenden Seiten des Design Systems.

Verwendung

Text Field

Frequently Asked Questions

 Was ist ein Design System

Ein Design System beschreibt eine Sammlung von wiederverwendbaren Komponenten, die sich an klaren Gestaltungsregeln orientieren. Wir wollen in Zukunft nicht nur über wiederverwendbare Komponenten Aufwände verringern und erhöhte Geschwindigkeit aufnehmen, sondern ebenso Design-Entscheidungen skalieren.

 Warum Material Design

Das Design System von Google deckt ein breites Spektrum an Gestaltungsrichtlinien ab und bietet darüber hinaus einen umfangreichen Komponenten-Katalog an. Google liefert z.B. Authoring-Richtlinien zur Implementierung und Bereitstellung eigener Komponenten.

Material Design ist an keine spezielle Javascript-Umgebung, wie z.B. Angular oder React gebunden und damit framework-neutral einsetzbar. Ein Adapter-Konzept ermöglicht den framework-nahen Einsatz des Systems bzw. dessen einzelnen Komponenten. Das Design System von Google ist durch seinen universellen Charakter vielseitig nutzbar und durch die integrierten Theming-Mechanismen besonders anpassungsfähig.

Material Design bietet des Weiteren hilfreiche Werkzeuge, wie z.B. dem Theme-Editor, Icons oder ein UI-Kit an, die sowohl Designer als auch die Entwickler-Teams bei Ihrer täglichen Arbeit unterstützen.

 Wo finde ich Details zu Material Design

Relevante Inhalte sind unter material.io zu finden. Die Seite umfasst im Wesentlichen 3 Bereiche, auf denen Details zur Semantik, den technischen Grundlagen sowie begleitenden Werkzeuge aufgeführt werden.

 Unterstützt Material Design ein barrierefreies Arbeiten

Material Design ermöglicht es neben zahlreichen technischen sowie visuellen Anpassungen (z.B. Theming) auch Voraussetzungen für barrierefreies und bidirektionales Arbeiten (Left-To-Right und thgiR-oT-tfeL) zu schaffen. Und somit die Anwendungen für Menschen mit unterschiedlichen Fähigkeiten nutzbar zu machen. Weitere Details stehen hier zur Verfügung.

 Wie ist Material Design lizenziert

Das Design System steht als Open Source unter Apache License 2.0 zur Verfügung.

 Was sind Design-Schulden

Bei wachsender Anwendung werden immer häufiger individuelle Design-Entscheidungen getroffen. Schulden entstehen aus der Fülle inkonsistenter und nicht wiederverwendbarer Konventionen. Über einen systematischen Ansatz werden Design-Schulden kontrollierbar.

 Beeinflusst der systematische Ansatz die eigene Kreativität nachteilig

Nein, statt weitere Design-Schulden anhand maßgeschneiderter Lösungen aufzubauen, können neue, kreative Ansätze sogar zurückfließen. Von Ergänzungen oder Erweiterungen des Systems profitieren dann alle gleichermaßen.

 Was ist der BEM-Syntax

Die Material Design Components (MDC) folgen innerhalb ihrer Styling-Assets dem s.g. BEM-Standard (Block, Element, Modifier), um mithilfe einer durchgehenden Kultur innerhalb ihrer Styling-Klassen und DOM-Elementen mehr Transparenz zu schaffen.

 Empfohlene Framework-Wrapper

Neben der Standard Implementierung von HTML, CSS und JS existieren für die Material Components Adpater für unterschiedliche Frameworks, wie z.B. React oder Angular.

Wir empfehlen den Einsatz folgender Adapter-Implementierungen.

 React

RMWC

Hinweis

Google selber pflegt seit Ende 2018 einen eigenen React-Zweig

 Angular

Angular MDC

 Sonstiges

 Github Repositories

 Hilfreiche Links (extern)