Vom UI-Kit zum Design-System

Ivy Online-Filmerfahrung

Als wir Anfang 2017 zum ersten Mal darüber nachdachten, ein eigenes System für die Bereitstellung von Design für Code zu erstellen, sprachen viele darüber und jemand tat es sogar. Über die Erfahrung mit dem Aufbau plattformübergreifender Entwurfssysteme ist bis heute wenig bekannt, und es gibt keine klaren und bewährten Rezepte, die Technologien und Methoden für eine solche Umwandlung des Entwurfsimplementierungsprozesses in ein bereits funktionierendes Produkt beschreiben. Und „Komponenten im Code“ bedeuten oft sehr unterschiedliche Dinge.


In der Zwischenzeit verdoppelte das Unternehmen seine Mitarbeiterzahl von Jahr zu Jahr - es war notwendig, die Designabteilung zu skalieren und die Prozesse zum Erstellen und Übertragen von Layouts in die Entwicklung zu optimieren. Wir multiplizieren dies alles mit einem „Zoo“ von Plattformen, die unterstützt werden müssen, und wir bekommen den Anschein einer Babel-Menge, die einfach nicht in der Lage ist, „normal“ zu arbeiten und Einkommen zu generieren. Die Plattformentwicklung verlief häufig parallel, und dieselbe Funktionalität konnte auf verschiedenen Plattformen mit einer Verzögerung von mehreren Monaten ausgeführt werden.


Separate Layout-Sets für jede Plattform

Traditionell haben wir mit Problemen begonnen, bei denen das Entwurfssystem helfen würde, Anforderungen für seinen Entwurf zu lösen und zu formulieren. Neben der Schaffung einer einzigen visuellen Sprache, der Beschleunigung des Prototyping und der Entwicklung sowie der Verbesserung der Qualität des gesamten Produkts war es von entscheidender Bedeutung, das Design so weit wie möglich zu vereinheitlichen. Dies ist notwendig, damit die Entwicklung von Funktionen sofort auf allen unseren Plattformen gleichzeitig möglich ist: Web, iOS, Android, Smart-TV, tvOS, Android-TV, Windows 10, xBox One, PS4, Roku - ohne jeweils einzeln zu arbeiten . Und wir haben es geschafft!

Design → Daten

Als die wichtigsten Vereinbarungen der Produkt- und Entwicklungsabteilungen getroffen wurden, setzten wir uns zusammen, um den technologischen Stack auszuwählen und die Details des gesamten Prozesses zu untersuchen - vom Layout bis zur Veröffentlichung. Um den Prozess der Übertragung des Designs in die Entwicklung vollständig zu automatisieren, haben wir die Option mit einem Parser von Komponentenparametern direkt aus Skizzendateien mit Layouts untersucht. Es stellte sich heraus, dass es ein kompliziertes 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 der Codestruktur des ursprünglichen Sketch-Layouts anderer Personen die Zukunft des gesamten Projekts. Wir haben beschlossen, die Automatisierung in diesem Bereich aufzugeben. So erschien die erste Person im Design-System-Team, an dessen Eingang Design-Layouts eingereicht werden, und am Ausgang Daten, die alle Parameter der Komponenten beschreiben und hierarchisch nach der atomaren Design-Methodik geordnet sind.

Die Angelegenheit blieb klein: Wo und wie werden Daten gespeichert, wie werden sie in die Entwicklung übertragen und wie werden sie in der Entwicklung auf allen von uns unterstützten Plattformen interpretiert? Der Abend hörte auf, träge zu sein ... Das Ergebnis regelmäßiger Treffen der Arbeitsgruppe, bestehend aus Designern und Teamleitern von jeder Plattform, war die Vereinbarung über Folgendes.

Wir analysieren das Visuelle manuell in atomare Elemente: Schriftarten, Farben, Transparenz, Einrückungen, Verrundungen, Symbole, Bilder und Dauer für Animationen. Über diese Schaltfläche erfassen wir Eingaben, Kontrollkästchen, Widgets für Bankkarten usw. Wir weisen Stilen aller Ebenen nicht-semantische Namen zu, mit Ausnahme von Symbolen, z. B. Städtenamen, Namen von Nymphen, Pokémon, Automarken ... Es gibt nur eine Bedingung - die Liste sollte nicht früher erschöpft werden , mit welchen Styles wird es enden - show mast go he! Sie sollten sich nicht von der Semantik mitreißen lassen, damit Sie beispielsweise keine mittlere Schaltfläche zwischen "klein" und "mittel" hinzufügen müssen.

Visuelle Sprache

Die Entwickler überlegten, wie Daten so gespeichert und übertragen werden sollten, dass sie auf alle Plattformen passen, und das Design musste Schnittstellenelemente entwerfen, die gleich gut aussehen und für die gesamte Flotte unterstützter Geräte effektiv funktionieren konnten.

Zuvor war es uns gelungen, die meisten Designelemente in einer Anwendung für Windows 10 zu „durchlaufen“, die zu diesem Zeitpunkt eine neue Plattform für uns war, dh das Rendern und Entwickeln von Grund auf war erforderlich. Durch das Zeichnen konnten wir die meisten Komponenten vorbereiten und testen und verstehen, welche davon in das zukünftige Ivy-Design-System aufgenommen werden sollten. Ohne eine solche Sandbox könnte eine solche Erfahrung nur durch eine große Anzahl von Iterationen auf bereits funktionierenden Plattformen gewonnen werden, und dies hätte mehr als ein Jahr gedauert.

Die Wiederverwendung derselben Komponenten auf verschiedenen Plattformen reduziert zeitweise die Anzahl der Layouts und das Datenfeld des Designsystems. Daher musste das Design ein anderes Problem lösen, das zuvor in der Praxis des Produktdesigns und der Produktentwicklung nicht beschrieben wurde - wie kann beispielsweise die Taste für Telefone und Tablets auf Fernsehgeräten wiederverwendet werden? Und was sollte im Prinzip mit der Größe von Schriftarten und Elementen auf so unterschiedlichen Plattformen sein?

Offensichtlich war es notwendig, ein plattformübergreifendes modulares Raster zu entwerfen, das die Text- und Elementgrößen festlegt, die wir für jede bestimmte Plattform benötigen. Als Referenzpunkt für das Raster haben wir die Größe und Anzahl der Filmplakate ausgewählt, die auf einem bestimmten Bildschirm angezeigt werden sollen, und darauf basierend die Regel für die Erstellung von Rasterspalten formuliert, sofern die Breite einer Spalte der Breite des Posters entspricht.


Jetzt müssen Sie alle großen Bildschirme auf die gleiche Größe des Layouts bringen und sie in das allgemeine Raster einfügen. Apple TV und Roku werden in den Größen 1920 x 1080, Android TV - 960 x 540, Smart TV entwickelt, je nach Hersteller sind sie gleich, und es gibt 1280 x 720. Wenn die Anwendung gerendert und auf Full HD-Bildschirmen angezeigt wird, wird 960 mit 2, 1280 mit 1,33 multipliziert und 1920 wird unverändert angezeigt.

Ohne langweilige Details kamen wir zu dem Schluss, dass im Allgemeinen alle Bildschirme, einschließlich der Fernsehbildschirme in Bezug auf Elemente und deren Größe, von einem Designlayout abgedeckt werden und alle Fernsehbildschirme ein Sonderfall eines gemeinsamen plattformübergreifenden Rasters sind und wie ein durchschnittliches Tablet aus fünf oder sechs Spalten bestehen oder Desktop. Wer sich um die Details kümmert, geht zu den Kommentaren.


Einheitliche Benutzeroberfläche für alle Plattformen

Um eine neue Funktion zu zeichnen, müssen wir nicht für jede Plattform Layouts sowie Anpassungsoptionen für jede Plattform zeichnen. Es reicht aus, ein Layout und seine Anpassungsfähigkeit für alle Plattformen und Geräte jeder Breite zu zeigen: Telefone - 320–599, alles andere - 600–1280.

Daten → Entwicklung

Unabhängig davon, wie wir zu einem völlig einheitlichen Design kommen möchten, hat jede Plattform ihre eigenen einzigartigen Funktionen. Trotz der Tatsache, dass sowohl das Web als auch Smart TV den ReactJS + TypeScript-Stack verwenden, wird die Smart TV-Anwendung auf älteren WebKit- und Presto-Clients ausgeführt und kann daher keine gemeinsamen Stile mit dem Web verwenden. Und E-Mail-Newsletter sind völlig gezwungen, mit dem Tabellenlayout zu arbeiten. Gleichzeitig verwendet oder plant keine der Nicht-HTML-Plattformen aus Angst vor Leistungseinbußen die Verwendung von React Native oder eines seiner Analoga, da wir zu viele benutzerdefinierte Layouts, Sammlungen mit komplexer Aktualisierungslogik, Bilder und Videos haben. Daher ist ein gemeinsames Schema für uns nicht geeignet - um vorgefertigte CSS-Stile oder React-Komponenten bereitzustellen. Aus diesem Grund haben wir uns entschlossen, Daten im JSON-Format zu übertragen und die Werte in einer abstrakten deklarativen Form zu beschreiben.

Die Eigenschaft von rounding: 8 , konvertiert die Windows 10-Anwendung in CornerRadius="8" , das Web - border-radius: 8px , Android - android:radius="8dp" , iOS - self.layer.cornerRadius = 8.0 .
OffsetTop- offsetTop: 12 Der gleiche Webclient kann in verschiedenen Fällen als top , margin-top , padding-top oder transform interpretiert transform

Der deklarative Charakter der Beschreibung legt auch nahe, dass die Plattform, wenn sie technisch nicht in der Lage ist, eine Eigenschaft oder ihren Wert zu verwenden, diese ignorieren kann. In Bezug auf die Terminologie haben wir eine Art Esperanto-Sprache erstellt: Wir haben etwas von Android übernommen, einige von SVG, einige von CSS.

Wenn Elemente auf einer bestimmten Plattform anders angezeigt werden müssen, haben wir die Möglichkeit implementiert, die entsprechende Datengenerierung als separate JSON-Datei zu übertragen. Beispielsweise ist der Status für Smart TV "im Fokus". Er schreibt eine Änderung der Position des Textes unter dem Poster vor. Für diese Plattform enthält diese Komponente im Wert der Eigenschaft "Einzug" die 8 benötigten Einrückungspunkte. Dies verkompliziert zwar die Infrastruktur des Designsystems, bietet jedoch einen zusätzlichen Freiheitsgrad und gibt uns die Möglichkeit, die visuelle „Unähnlichkeit“ der Plattformen selbst zu verwalten und nicht als Geiseln der von uns erstellten Architektur zu fungieren.

Piktogramme

Die Ikonographie in einem digitalen Produkt ist immer ein umfangreiches und nicht das einfachste Teilprojekt, häufig mit einem separaten Designer. Es gibt immer viele Glyphen, jede hat verschiedene Größen und Farben, außerdem benötigen Plattformen diese in der Regel in verschiedenen Formaten. Im Allgemeinen gab es keinen Grund, all dies nicht in das Entwurfssystem einzubeziehen.


Glyphen werden im Vektor-SVG-Format geladen und Farbwerte werden automatisch durch Variablen ersetzt. Client-Anwendungen können sie einsatzbereit machen - in jedem Format und in jeder Farbe.

Vorschau

Zusätzlich zu JSON mit Daten haben wir ein Tool für die Vorschau von Komponenten geschrieben - eine JS-Anwendung, die JSON-Daten im laufenden Betrieb über ihre Markup- und Stilgeneratoren weiterleitet und verschiedene Variationen jeder Komponente im Browser anzeigt. Tatsächlich ist die Vorschau genau derselbe Client wie die Plattformanwendungen und arbeitet mit denselben Daten.

Zu verstehen, wie eine bestimmte Komponente funktioniert, ist am einfachsten, wenn Sie mit ihr interagieren. Aus diesem Grund haben wir keine Tools wie das Storybook verwendet, sondern eine interaktive Vorschau erstellt. Sie können berühren, den Mauszeiger bewegen, klicken ... Wenn Sie dem Designsystem eine neue Komponente hinzufügen, wird diese in der Vorschau angezeigt, sodass sich die Plattformen bei der Einführung auf etwas konzentrieren können.

Die Dokumentation

Basierend auf den Daten, die in Form von JSON an die Plattformen geliefert werden, wird automatisch eine Komponentendokumentation generiert. Die Liste der Eigenschaften und möglichen Wertetypen in jedem von ihnen wird beschrieben. Nach der automatischen Generierung können die Informationen manuell geklärt werden. Fügen Sie eine Textbeschreibung hinzu. Vorschau und Dokumentation werden auf der Ebene jeder Komponente mit Querverweisen versehen, und alle Informationen, die in die Dokumentation fallen, stehen Entwicklern in Form zusätzlicher JSON-Dateien zur Verfügung.

Abschreiber

Ein weiterer Bedarf war die Möglichkeit, vorhandene Komponenten im Laufe der Zeit zu ersetzen und zu aktualisieren. Das Design-System hat gelernt, Entwicklern mitzuteilen, welche Eigenschaften oder sogar ganze Komponenten nicht verwendet werden können, und sie zu entfernen, sobald sie nicht mehr auf allen Plattformen verwendet werden. Es gibt immer noch viel „Handarbeit“ in diesem Prozess, aber wir stehen nicht still.

Kundenentwicklung

Zweifellos wurde die Interpretation der Entwurfssystemdaten im Code aller von uns unterstützten Plattformen zur umfangreichsten Stufe der Komplexität. Wenn zum Beispiel modulare Grids im Web nicht neu sind, haben Entwickler nativer mobiler Anwendungen für iOS und Android ziemlich stark geschwitzt, bevor sie herausgefunden haben, wie sie damit leben sollen.

Für das Layout der iOS-Anwendungsbildschirme verwenden wir zwei grundlegende Mechanismen, die iviUIKit bietet: das kostenlose Layout von Elementen und das Layout von Sammlungen von Elementen. Wir verwenden VIPER und alle Interaktionen mit iviUIKit konzentrieren sich auf View, und der Großteil der Interaktionen mit Apple UIKit konzentriert sich auf iviUIKit. Die Größe und Anordnung der Elemente wird in Form von Spalten und syntaktischen Konstruktionen angegeben, die auf nativen iOS SDK-Konstanten basieren, wodurch sie besser angewendet werden können. Dies hat unser Leben bei der Arbeit mit UICollectionView besonders vereinfacht. Wir haben einige anpassbare Layouts für Layouts geschrieben, darunter auch recht komplexe. Der Client-Code stellte sich als Minimum heraus und wurde deklarativ.

Um Stile im Android-Projekt zu generieren, verwenden wir Gradle und wandeln die Entwurfssystemdaten in Stile im XML-Format um. Gleichzeitig haben wir mehrere Generatoren auf verschiedenen Ebenen:

• Grundlegend . Analysieren von Daten von Grundelementen für übergeordnete Generatoren.
• Ressource . Laden Sie Bilder, Symbole und andere Grafiken herunter.
• Komponente Sie werden für jede Komponente geschrieben, die beschreibt, welche Eigenschaften und wie sie in Stile übersetzt werden.

Anwendungsversionen

Nachdem die Designer eine neue Komponente gezeichnet oder eine vorhandene überarbeitet haben, fallen diese Änderungen in das Designsystem. Die Entwickler jeder Plattform schließen ihre Codegenerierung ab und unterstützen Änderungen. Danach kann es bei der Implementierung neuer Funktionen verwendet werden, wenn diese Komponente erforderlich ist. Die Interaktion mit dem Design-System erfolgt daher nicht in Echtzeit, sondern nur zum Zeitpunkt der Zusammenstellung neuer Releases. Dieser Ansatz ermöglicht es Ihnen auch, den Prozess der Datenübertragung besser zu steuern und die Leistung des Codes in Cliententwicklungsprojekten zu gewährleisten.

Zusammenfassung

Als Designsystem wurde bald ein Jahr Teil der Infrastruktur für die Entwicklung des Ivy-Online-Kinos, und einige Schlussfolgerungen können bereits gezogen werden:

• Dies ist ein großes und schwieriges Projekt, für das ständig zugewiesene Ressourcen erforderlich sind.
• Auf diese Weise konnten wir unsere eigene plattformübergreifende visuelle Sprache erstellen, die die Ziele des Online-Videodienstes erfüllt.
• Wir haben keine visuell und funktionell verzögerten Plattformen mehr.

Vorschau der Komponenten des Ivy- Designsystems - design.ivi.ru