Vom UI-Kit zum Designsystem

Ivy Online-Kinoerlebnis

Als wir Anfang 2017 zum ersten Mal darüber nachdachten, ein eigenes Design-to-Code-Liefersystem zu entwickeln, sprachen viele bereits darüber und einige taten es sogar. Über die Erfahrungen beim Aufbau plattformübergreifender Designsysteme ist jedoch bis heute wenig bekannt, und es gibt keine klaren und bewährten Rezepte, die Technologien und Methoden für eine solche Transformation des Prozesses der Designimplementierung in ein bereits funktionierendes Produkt beschreiben. Und mit „Komponenten im Code“ meinen sie oft sehr unterschiedliche Dinge.

Inzwischen verdoppelte das Unternehmen seine Belegschaft Jahr für Jahr – es war notwendig, die Designabteilung zu skalieren und die Prozesse zur Erstellung und Übertragung von Layouts für die Entwicklung zu optimieren. Wenn wir das alles mit dem „Zoo“ der Plattformen multiplizieren, die unterstützt werden müssen, erhalten wir den Anschein eines babylonischen Chaos, das einfach nicht in der Lage ist, „es normal zu machen“ und Einnahmen zu generieren. Die Entwicklung von Plattformen verlief oft parallel und die gleiche Funktionalität konnte mit einer Verzögerung von mehreren Monaten auf verschiedenen Plattformen veröffentlicht werden.


Separate Layout-Sets für jede Plattform

Traditionell begannen wir mit Problemen, bei deren Lösung ein Designsystem helfen würde, und formulierten Anforderungen für sein Design. Neben der Schaffung einer einheitlichen visuellen Sprache, der Beschleunigung von Layout und Entwicklung und der Verbesserung der Qualität des Produkts insgesamt war es von entscheidender Bedeutung, das Design so weit wie möglich zu vereinheitlichen. Dies ist notwendig, damit die Entwicklung von Funktionalität auf allen unseren Plattformen gleichzeitig möglich wird: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku – ohne an jeder davon einzeln zu arbeiten. Und wir haben es geschafft!

Design → Daten

Als die grundlegenden Vereinbarungen zwischen Produkt- und Entwicklungsabteilung getroffen waren, setzten wir uns zusammen, um einen Technologie-Stack auszuwählen und die Details des gesamten Prozesses auszuarbeiten – vom Layout bis zur Veröffentlichung. Um den Prozess der Übertragung des Entwurfs in die Entwicklung vollständig zu automatisieren, haben wir die Möglichkeit untersucht, Komponentenparameter direkt aus Skizzendateien mit Layouts zu analysieren. Es stellte sich heraus, dass es ein komplexes und gefährliches Unterfangen war, die benötigten Codeteile zu finden und die benötigten Parameter zu extrahieren. Erstens müssen Designer bei der Benennung aller Ebenen des Quellcodes äußerst vorsichtig sein, zweitens funktioniert dies nur für die einfachsten Komponenten und drittens gefährdet die Abhängigkeit von der Technologie und Codestruktur des ursprünglichen Sketch-Layouts anderer Personen die Zukunft des gesamten Projekt. Wir haben uns entschieden, in diesem Bereich auf die Automatisierung zu verzichten. So erschien die erste Person im Design-System-Team, deren Input Design-Layouts sind und deren Output Daten sind, die alle Parameter der Komponenten beschreiben und gemäß der atomaren Design-Methodik hierarchisch geordnet sind.

Es blieb nur noch zu tun, wo und wie die Daten gespeichert werden, wie sie in die Entwicklung übertragen werden und wie sie in der Entwicklung auf allen von uns unterstützten Plattformen interpretiert werden. Der Abend hörte auf, träge zu sein ... Das Ergebnis regelmäßiger Treffen der Arbeitsgruppe, bestehend aus Designern und Teamleitern jeder Plattform, war die Einigung über Folgendes.

Wir zerlegen das Bildmaterial manuell in atomare Elemente: Schriftarten, Farben, Transparenz, Einrückungen, Rundungen, Symbole, Bilder und Dauer für Animationen. Und daraus sammeln wir Schaltflächen, Eingaben, Kontrollkästchen, Bankkarten-Widgets usw. Wir weisen den Stilen aller Ebenen, mit Ausnahme von Symbolen, nicht-semantische Namen zu, zum Beispiel Namen von Städten, Namen von Nymphen, Pokémon, Autos Marken... Es gibt nur eine Bedingung – die Liste darf nicht erschöpft sein, bevor die Styles enden – Show muss raus! Sie sollten sich nicht auf die Semantik einlassen, damit Sie beispielsweise keinen Mittelknopf zwischen „klein“ und „mittel“ einfügen müssen.

Bildsprache

Den Entwicklern blieb die Aufgabe überlassen, darüber nachzudenken, wie sie Daten auf eine Weise speichern und übertragen können, die für alle Plattformen geeignet ist, und das Design musste Schnittstellenelemente entwerfen, die gut aussehen und auf der gesamten Flotte unterstützter Geräte effektiv funktionieren.

Zuvor war es uns bereits gelungen, die meisten Designelemente einer Anwendung für Windows 10 zu „testen“, was damals eine neue Plattform für uns war, das heißt, es erforderte ein Rendering und eine Entwicklung „von Grund auf“. Durch die Zeichnung konnten wir die meisten Komponenten vorbereiten und testen und verstehen, welche davon in das zukünftige Eevee-Designsystem aufgenommen werden sollten. Ohne eine solche Sandbox könnten solche Erfahrungen nur durch eine große Anzahl von Iterationen auf bereits funktionierenden Plattformen gesammelt werden, und dies würde mehr als ein Jahr dauern.

Die Wiederverwendung derselben Komponenten auf verschiedenen Plattformen reduziert die Anzahl der Layouts und die Datenmenge des Designsystems erheblich, sodass das Design ein weiteres Problem lösen musste, das bisher in den Praktiken des Produktdesigns und der Produktentwicklung nicht beschrieben wurde – wie zum Beispiel Kann eine Taste für Telefone und Tablets auf Fernsehgeräten wiederverwendet werden? Und was sollen wir mit den Größen von Schriftarten und Elementen auf so unterschiedlichen Plattformen machen?

Offensichtlich war es notwendig, ein plattformübergreifendes modulares Raster zu entwerfen, das die Text- und Elementgrößen festlegt, die wir für jede spezifische Plattform benötigen. Als Ausgangspunkt für das Raster wählten wir die Größe und Anzahl der Filmplakate, die wir auf einem bestimmten Bildschirm sehen möchten, und formulierten darauf basierend eine Regel für den Aufbau von Rasterspalten, vorausgesetzt, dass die Breite einer Spalte gleich ist auf die Breite des Posters.

Jetzt müssen wir alle großen Bildschirme auf die gleiche Layoutgröße bringen und sie in ein gemeinsames Raster einpassen. Apple TV und Roku sind in einer Größe von 1920 x 1080 konzipiert, Android TV – 960 x 540, Smart TVs sind je nach Anbieter gleich, manchmal jedoch 1280 x 720. Wenn die App gerendert und auf Full-HD-Bildschirmen angezeigt wird, wird 960 mit 2 multipliziert, 1280 mit 1,33 multipliziert und 1920 unverändert ausgegeben.

Wir ließen die langweiligen Details außer Acht und kamen zu dem Schluss, dass im Allgemeinen alle Bildschirme, einschließlich Fernsehbildschirme, hinsichtlich ihrer Elemente und ihrer Größe von einem Designlayout abgedeckt werden und alle Fernsehbildschirme ein Sonderfall des allgemeinen plattformübergreifenden Rasters sind und bestehen aus fünf oder sechs Spalten, wie ein durchschnittliches Tablet oder ein durchschnittlicher Desktop. Wer sich für die Details interessiert, geht in die Kommentare.

Eine einzige Benutzeroberfläche für alle Plattformen

Um nun ein neues Feature zu zeichnen, müssen wir nicht für jede Plattform Layouts und Anpassungsoptionen für jede von ihnen zeichnen. Es reicht aus, ein Layout und seine Anpassungsfähigkeit für alle Plattformen und Geräte beliebiger Breite zu zeigen: Telefone – 320–599, alles andere – 600–1280.

Daten → Entwicklung

So sehr wir uns auch ein völlig einheitliches Design wünschen, hat natürlich jede Plattform ihre eigenen einzigartigen Funktionen. Obwohl sowohl das Web als auch Smart TV den ReactJS + TypeScript-Stack verwenden, läuft die Smart TV-App auf älteren WebKit- und Presto-Clients und kann daher keine Stile mit dem Web teilen. Und E-Mail-Newsletter sind völlig gezwungen, mit tabellarischem Layout zu arbeiten. Gleichzeitig verwendet keine der Nicht-HTML-Plattformen React Native oder eines seiner Analoga oder plant die Verwendung, aus Angst vor Leistungseinbußen, da wir zu viele benutzerdefinierte Layouts, Sammlungen mit komplexer Aktualisierungslogik, Bilder und Videos haben. Daher ist das übliche Schema der Bereitstellung vorgefertigter CSS-Stile oder React-Komponenten für uns nicht geeignet. Aus diesem Grund haben wir uns entschieden, Daten im JSON-Format zu übertragen und die Werte in einer abstrakten deklarativen Form zu beschreiben.

Also Eigentum rounding: 8 Windows 10-App konvertiert in CornerRadius="8", Netz - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Eigentum offsetTop: 12 Derselbe Webclient kann in verschiedenen Fällen als interpretieren top, margin-top, padding-top oder transform

Die Aussagekraft der Beschreibung impliziert auch, dass die Plattform eine Eigenschaft oder ihren Wert ignorieren kann, wenn sie technisch gesehen nicht nutzbar ist. Was die Terminologie betrifft, haben wir eine Art Esperanto-Sprache erstellt: Einige wurden von Android übernommen, einige von SVG, einige von CSS.

Wenn Sie auf einer bestimmten Plattform Elemente unterschiedlich anzeigen müssen, haben wir die Möglichkeit implementiert, die entsprechende Datengenerierung in Form einer separaten JSON-Datei zu übertragen. Beispielsweise erfordert der Status „Im Fokus“ für Smart TV eine Änderung der Position des Textes unter dem Poster, was bedeutet, dass diese Komponente im Wert der Eigenschaft „indent“ für diese Plattform die 8 benötigten Einrückungspunkte enthält. Obwohl dies die Infrastruktur des Designsystems verkompliziert, bietet es einen zusätzlichen Freiheitsgrad und gibt uns die Möglichkeit, die visuelle „Unähnlichkeit“ der Plattformen selbst zu verwalten und nicht Geisel der von uns erstellten Architektur zu sein.

Piktogramme

Die Ikonographie in einem digitalen Produkt ist immer ein umfangreiches und nicht das einfachste Teilprojekt, das oft einen separaten Designer erfordert. Es gibt immer viele Glyphen, jedes davon hat mehrere Größen und Farben und Plattformen benötigen sie normalerweise in unterschiedlichen Formaten. Generell gab es keinen Grund, dies alles nicht in das Designsystem aufzunehmen.

Glyphen werden im SVG-Vektorformat geladen und Farbwerte werden automatisch durch Variablen ersetzt. Kundenanwendungen können sie gebrauchsfertig erhalten – in jedem Format und jeder Farbe.

Vorschau

Zusätzlich zu den JSON-Daten haben wir ein Tool zur Vorschau von Komponenten geschrieben – eine JS-Anwendung, die JSON-Daten im Handumdrehen durch ihre Markup- und Stilgeneratoren leitet und verschiedene Variationen jeder Komponente im Browser anzeigt. Im Wesentlichen ist die Vorschau genau derselbe Client wie Plattformanwendungen und arbeitet mit denselben Daten.

Der einfachste Weg, die Funktionsweise einer bestimmten Komponente zu verstehen, besteht darin, mit ihr zu interagieren. Aus diesem Grund haben wir keine Tools wie Storybook verwendet, sondern eine interaktive Vorschau erstellt – Sie können berühren, zeigen, klicken ... Wenn Sie dem Designsystem eine neue Komponente hinzufügen, wird diese in der Vorschau angezeigt, sodass Plattformen wann etwas haben, auf das sie sich konzentrieren können es umzusetzen.

Dokumentation

Basierend auf den in Form von JSON an die Plattformen gelieferten Daten wird automatisch eine Dokumentation für die Komponenten generiert. Eine Liste der Eigenschaften und mögliche Wertetypen in jedem von ihnen werden beschrieben. Nach der automatischen Generierung können die Informationen manuell präzisiert und eine Textbeschreibung hinzugefügt werden. Vorschau und Dokumentation sind auf der Ebene jeder Komponente miteinander verknüpft und alle in der Dokumentation enthaltenen Informationen stehen Entwicklern in Form zusätzlicher JSON-Dateien zur Verfügung.

Abwertender

Eine weitere Notwendigkeit war die Möglichkeit, vorhandene Komponenten im Laufe der Zeit auszutauschen und zu aktualisieren. Das Designsystem hat gelernt, Entwicklern mitzuteilen, welche Eigenschaften oder sogar ganze Komponenten nicht verwendet werden können, und diese zu entfernen, sobald sie nicht mehr auf allen Plattformen verwendet werden. In diesem Prozess steckt immer noch viel „manuelle“ Arbeit, aber wir stehen nicht still.

Kundenentwicklung

Die komplexeste Phase war zweifellos die Interpretation der Designsystemdaten im Code aller von uns unterstützten Plattformen. Wenn beispielsweise modulare Grids im Web nichts Neues sind, dann haben die Entwickler nativer mobiler Anwendungen für iOS und Android hart gearbeitet, bevor sie herausgefunden haben, wie sie damit leben können.

Zum Layouten von iOS-Anwendungsbildschirmen verwenden wir zwei grundlegende Mechanismen, die von iviUIKit bereitgestellt werden: freies Layout von Elementen und Layout von Elementsammlungen. Wir verwenden VIPER und die gesamte Interaktion mit iviUIKit ist in View konzentriert, und die meiste Interaktion mit Apple UIKit ist in iviUIKit konzentriert. Die Größen und Anordnung der Elemente werden in Form von Spalten und syntaktischen Strukturen angegeben, die über die nativen iOS SDK-Einschränkungen hinausgehen und sie dadurch praktischer machen. Dies hat unser Leben insbesondere bei der Arbeit mit UICollectionView vereinfacht. Wir haben mehrere benutzerdefinierte Wrapper für Layouts geschrieben, darunter auch recht komplexe. Es gab ein Minimum an Client-Code und er wurde deklarativ.

Um Stile im Android-Projekt zu generieren, verwenden wir Gradle und wandeln die Designsystemdaten in Stile im XML-Format um. Gleichzeitig verfügen wir über mehrere Generatoren unterschiedlicher Leistungsstufen:

• Basic. Die Daten von Grundelementen für Generatoren höherer Ebenen werden analysiert.
• Ressource. Laden Sie Bilder, Symbole und andere Grafiken herunter.
• Komponente. Sie werden für jede Komponente geschrieben und beschreiben, welche Eigenschaften sie hat und wie diese in Stile übersetzt werden.

Anwendungsfreigaben

Nachdem Designer eine neue Komponente gezeichnet oder eine bestehende neu entworfen haben, werden diese Änderungen in das Designsystem eingespeist. Die Entwickler jeder Plattform optimieren ihre Codegenerierung, um die Änderungen zu unterstützen. Danach kann es bei der Implementierung neuer Funktionen verwendet werden, wenn diese Komponente benötigt wird. Somit erfolgt die Interaktion mit dem Designsystem nicht in Echtzeit, sondern erst zum Zeitpunkt der Zusammenstellung neuer Releases. Dieser Ansatz ermöglicht außerdem eine bessere Kontrolle über den Datenübertragungsprozess und stellt die Codefunktionalität in Kundenentwicklungsprojekten sicher.

Ergebnisse

Es ist ein Jahr her, seit das Designsystem Teil der Infrastruktur wurde, die die Entwicklung des Ivy-Online-Kinos unterstützt, und wir können bereits einige Schlussfolgerungen ziehen:

• Dies ist ein großes und komplexes Projekt, das ständige dedizierte Ressourcen erfordert.
• Dadurch konnten wir unsere eigene einzigartige plattformübergreifende visuelle Sprache erstellen, die den Zielen des Online-Videodienstes entspricht.
• Wir haben keine optisch und funktional zurückgebliebenen Plattformen mehr.

Vorschau auf die Komponenten des Ivy-Designsystems - design.ivi.ru

Source: habr.com