From UI-kit to design system

Ivy Online Cinema Experience

When at the beginning of 2017 we first thought about creating our own system for delivering design to code, many people already talked about it and someone even did it. However, little is known about the experience of building cross-platform design systems to this day, and there are no understandable and proven recipes that describe technologies and methods for such a transformation of the design implementation process into an already working product. Yes, and under the "components in the code" is often understood as very different things.

Meanwhile, the company doubled its staff from year to year - it was necessary to scale the design department and optimize the processes of creating and transferring layouts to development. We multiply all this by the “zoo” of platforms that need to be supported, and we get a semblance of a Babylonian pandemonium that simply cannot “do it right” and generate income. The development of platforms often went in parallel, and the same functionality could be released on different platforms with a lag of several months.


Separate layout sets for each platform

Traditionally, we started with problems that a design system would help solve and formulated requirements for its design. In addition to creating a single visual language, increasing the speed of prototyping and development, and improving the quality of the product as a whole, it was vital to unify the design as much as possible. This is necessary so that the development of the functionality becomes possible immediately on all our platforms simultaneously: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - without working through each of them separately . And we did it!

Design → data

When the fundamental agreements between the product and development departments were reached, we sat down to select the technology stack and work out the details of the entire process - from layout to release. To fully automate the process of transferring designs to development, we explored the option of using a component parameter parser directly from Sketch files with layouts. It turned out that finding the pieces of code we need and extracting the parameters we need is a complicated and dangerous undertaking. Firstly, designers will have to be extremely careful in naming all source layers, secondly, this only works for the simplest components, and thirdly, dependence on someone else's technology and code structure of the original Sketch layout jeopardizes the future of the entire project. We decided to abandon automation in this area. So the first person appeared in the design system team, whose input is design layouts, and the output is data that describes all the parameters of the components and is hierarchically ordered according to the atomic design methodology.

The matter remained small: where and how to store data, how to transfer it to development, and how to interpret it in development on all the platforms we support. The evening ceased to be languid... The result of regular meetings of the working group, consisting of designers and team leaders from each platform, was the agreement on the following.

We manually parse the visual into atomic elements: fonts, colors, transparency, padding, fillets, icons, pictures, and durations for animations. And we collect buttons, inputs, checkboxes, bank card widgets, etc. from this. We assign non-semantic names to styles of any of the levels, except for icons, for example, city names, names of nymphs, Pokemon, car brands ... There is only one condition - the list should not be exhausted before , than the styles end - the show must go! You should not get carried away with semantics so that you do not have to add a middle button between "small" and "medium", for example.

visual language

The developers left to think about how to store and transfer data so that it would suit all platforms, and the design had to design interface elements that could look and work equally well on the entire fleet of supported devices.

Previously, we had already managed to “run in” most of the design elements in the application for Windows 10, which at that time was a new platform for us, that is, it required rendering and development from scratch. Drawing it, we were able to prepare and test most of the components and understand which of them should be included in the future design system of Evie. Without such a sandbox, such an experience could only be obtained by a large number of iterations on already working platforms, and this would take more than a year.

Reusing the same components on different platforms reduces the number of layouts and the data array of the design system by several times, so the design had to solve another problem that was not previously described in product design and development practices - how, for example, to reuse a button for phones and tablets on TVs? And how, in principle, to be with the sizes of fonts and elements on such different platforms?

Obviously, it was necessary to design a cross-platform modular grid that would set the text and element sizes we needed for each specific platform. As a starting point for the grid, we chose the size and number of movie posters that we want to see on a particular screen and, based on this, formulated a rule for constructing grid columns, provided that the width of one column is equal to the width of the poster.

Now we need to bring all large screens to the same layout size and fit them into the overall grid. Apple TV and Roku are designed in 1920x1080, Android TV - 960x540, Smart TVs, depending on the vendor, are the same, but there are 1280x720. When the application is rendered and displayed on Full HD screens, 960 is multiplied by 2, 1280 by 1,33, and 1920 is rendered as is.

Omitting boring details, we came to the conclusion that in general, all screens, including TV screens in terms of elements and their sizes, are covered by one design layout, and all TV screens are a special case of a common cross-platform grid, and consist of five or six columns, like an average tablet or desktop. Who cares about the details, go in the comments.

Single UI for all platforms

Now, to draw a new feature, we do not need to draw layouts for each of the platforms, plus adaptability options for each of them. It is enough to show one layout and its adaptability for all platforms and devices of any width: phones - 320-599, everything else - 600-1280.

Data → development

Of course, as much as we would like to achieve a completely unified design, each platform has its own unique features. Even though both the web and Smart TV use the ReactJS + TypeScript stack, the Smart TV app runs on legacy WebKit and Presto clients and therefore cannot share styles with the web. And email newsletters are completely forced to work with a tabular layout. At the same time, none of the non-html platforms use or plan to use React Native or any of its analogues, for fear of performance degradation, since we have too many custom layouts, collections with complex update logic, images and videos. Therefore, the common scheme is not suitable for us - to supply ready-made CSS styles or React components. Therefore, we decided to pass data in JSON format, describing the values ​​in an abstract declarative way.

So property rounding: 8 Windows 10 app converts to CornerRadius="8", web border-radius: 8px, Android- android:radius="8dp", iOS- self.layer.cornerRadius = 8.0.
property offsetTop: 12 the same web client in different cases can interpret as top, margin-top, padding-top or transform

The declarative nature of the description also implies that if the platform technically cannot use a property or its value, it can ignore it. From the point of view of terminology, we made a kind of Esperanto language: we took something from Android, something from SVG, something from CSS.

In the event that on a particular platform it is necessary to display elements somehow differently, we have implemented the possibility of transferring the corresponding data generation in the form of a separate JSON file. For example, the “in focus” state for Smart TV dictates a change in the position of the text under the poster, which means that for this platform, this component in the value of the “indent” property will contain the 8 indent points it needs. Although this complicates the infrastructure of the design system, it gives an additional degree of freedom, leaving us the opportunity to manage the visual “otherness” of the platforms ourselves, and not be hostages of the architecture we have created.

Pictograms

Iconography in a digital product is always a voluminous and not the simplest subproject, often having a separate designer. There are always many glyphs, each of them has several sizes and colors, and besides, platforms need them, usually in different formats. In general, there was no reason not to bring all this into the design system.

Glyphs are loaded in vector SVG format and color values ​​are automatically replaced with variables. Client applications can receive them ready to use - in any format and color.

Preview

On top of the JSON with the data, we wrote a tool for previewing components - a JS application that passes JSON data on the fly through its markup and style generators and displays various variations of each of the components in the browser. In fact, the preview is exactly the same client as platform applications and works with the same data.

The easiest way to understand how a particular component works is by interacting with it. Therefore, we did not use tools like Storybook, but made an interactive preview - you can touch, point, click ... When a new component is added to the design system, it appears in the preview so that the platforms have something to navigate when it is implemented.

Documentation

Based on the data that is supplied to the platforms in the form of JSON, the documentation for the components is automatically generated. The list of properties and possible types of values ​​in each of them are described. After auto-generation, information can be clarified manually, and a text description can be added. The preview and documentation are cross-referenced to each other at the level of each component, and all information that falls into the documentation is available to developers in the form of additional JSON files.

Deprecator

Another need was the ability to replace and update existing components over time. The design system has learned to tell developers which properties or even entire components should not be used and remove them as soon as they are no longer used on all platforms. So far, there is still a lot of “manual” work in this process, but we are not standing still.

Client Development

Undoubtedly, the most complex stage was the interpretation of design system data in the code of all platforms we support. If, for example, modular grids on the web are nothing new, then developers of native mobile apps for iOS and Android worked hard before they figured out how to live with it.

To lay out the screens of an iOS application, we use two basic mechanisms provided by iviUIKit: free layout of elements and layout of collections of elements. We are using VIPER and all interaction with iviUIKit is in the View, and most of the interaction with Apple UIKit is in iviUIKit. Elements are sized and positioned in terms of columns and syntactical constructs that work on top of native iOS SDK constraints to make them more usable. This especially made life easier for us when working with UICollectionView. We have written several custom wrappers for layouts, including quite complex ones. There was a minimum of client code and it became declarative.

To generate styles in the Android project, we use Gradle to turn design system data into XML format styles. At the same time, we have several generators of various levels:

• Basic. Parse primitive data for higher level generators.
• Resource. Download pictures, icons, and other graphics.
• Component. They are written for each component, which describes which properties and how to translate them into styles.

Application releases

After the designers have drawn a new component or redesigned an existing one, these changes get into the design system. The developers of each of the platforms are finalizing their code generation, providing support for changes. After that, it can be used in the implementation of new functionality, where this component is needed. Thus, interaction with the design system does not occur in real time, but only at the time of the assembly of new releases. This approach also allows for better control over the data transfer process and ensures that the code works in client development projects.

Results

It's been a year since the design system became part of the infrastructure serving the development of the Ivy online cinema, and we can already draw some conclusions:

• This is a large and complex project that requires constant dedicated resources.
• This allowed us to create our own unique cross-platform visual language that meets the objectives of the online video service.
• We no longer have visually and functionally lagging platforms.

Preview of the components of the Evie design system - design.ivi.ru

Source: habr.com