Del kit de interfaz de usuario al sistema de diseño

Experiencia de cine en línea Ivy

Cuando a principios de 2017 pensamos por primera vez en crear nuestro propio sistema de entrega de diseño a código, muchos ya hablaban de ello y algunos incluso lo estaban haciendo. Sin embargo, hasta el día de hoy se sabe poco sobre la experiencia de construir sistemas de diseño multiplataforma y no existen recetas claras y probadas que describan tecnologías y métodos para dicha transformación del proceso de implementación del diseño en un producto que ya funciona. Y por "componentes del código" a menudo se refieren a cosas muy diferentes.

Mientras tanto, la empresa duplicó su personal año tras año: era necesario ampliar el departamento de diseño y optimizar los procesos de creación y transferencia de diseños para el desarrollo. Multiplicamos todo esto por el "zoológico" de plataformas que necesitan apoyo, y obtenemos una apariencia de caos babilónico, que simplemente no es capaz de "hacerlo normalmente" y generar ingresos. El desarrollo de las plataformas a menudo se desarrollaba en paralelo y la misma funcionalidad podía lanzarse en diferentes plataformas con un retraso de varios meses.


Conjuntos de diseño separados para cada plataforma

Tradicionalmente, comenzamos con problemas que un sistema de diseño ayudaría a resolver y formulamos requisitos para su diseño. Además de crear un lenguaje visual unificado, aumentar la velocidad de diseño y desarrollo y mejorar la calidad del producto en general, era vital unificar el diseño tanto como fuera posible. Esto es necesario para que el desarrollo de funcionalidades sea posible en todas nuestras plataformas simultáneamente: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku, sin trabajar en cada una de ellas por separado. ¡Y lo logramos!

Diseño → datos

Cuando se alcanzaron los acuerdos fundamentales entre los departamentos de producto y desarrollo, nos sentamos a seleccionar una pila de tecnología y trabajar en los detalles de todo el proceso, desde el diseño hasta el lanzamiento. Para automatizar completamente el proceso de transferencia del diseño al desarrollo, exploramos la opción de analizar los parámetros de los componentes directamente desde archivos de Sketch con diseños. Resultó que encontrar las piezas de código que necesitábamos y extraer los parámetros que necesitábamos era una tarea compleja y peligrosa. En primer lugar, los diseñadores tendrán que tener mucho cuidado al nombrar todas las capas del código fuente; en segundo lugar, esto solo funciona para los componentes más simples y, en tercer lugar, la dependencia de la tecnología y la estructura del código de otra persona del diseño original de Sketch pone en peligro el futuro de todo el proyecto. proyecto. Decidimos abandonar la automatización en esta área. Así apareció la primera persona en el equipo de diseño del sistema, cuya entrada son los diseños de diseño y la salida son datos que describen todos los parámetros de los componentes y están ordenados jerárquicamente según la metodología de diseño atómico.

Lo único que quedaba por hacer era dónde y cómo almacenar los datos, cómo transferirlos al desarrollo y cómo interpretarlos en el desarrollo en todas las plataformas que admitimos. La velada dejó de ser lánguida... El resultado de las reuniones periódicas del grupo de trabajo formado por diseñadores y jefes de equipo de cada plataforma fue el acuerdo sobre lo siguiente.

Analizamos manualmente lo visual en elementos atómicos: fuentes, colores, transparencia, sangrías, redondeos, íconos, imágenes y duraciones de animaciones. Y de esto recopilamos botones, entradas, casillas de verificación, widgets de tarjetas bancarias, etc. Asignamos nombres no semánticos a los estilos de cualquiera de los niveles, excepto íconos, por ejemplo, nombres de ciudades, nombres de ninfas, Pokémon, automóviles. marcas... Solo hay una condición: la lista no debe agotarse antes, cómo terminan los estilos: ¡el espectáculo debe desaparecer! No debes dejarte llevar por la semántica, para no tener que añadir un botón central entre “pequeño” y “mediano”, por ejemplo.

lenguaje visual

Los desarrolladores tuvieron que pensar en cómo almacenar y transferir datos de una manera que se adaptara a todas las plataformas, y el diseño tenía que diseñar elementos de interfaz que pudieran verse bien y funcionar de manera efectiva en toda la flota de dispositivos compatibles.

Anteriormente ya habíamos logrado “probar” la mayoría de los elementos de diseño en una aplicación para Windows 10, que en ese momento era una plataforma nueva para nosotros, es decir, requería renderizado y desarrollo “desde cero”. Al dibujarlo, pudimos preparar y probar la mayoría de los componentes y comprender cuáles de ellos se suponía que se incluirían en el futuro sistema de diseño de Eevee. Sin un entorno de pruebas de este tipo, esa experiencia sólo podría obtenerse mediante un gran número de iteraciones en plataformas que ya funcionan, y esto llevaría más de un año.

Reutilizar los mismos componentes en diferentes plataformas reduce significativamente la cantidad de diseños y la variedad de datos del sistema de diseño, por lo que el diseño tuvo que resolver un problema más, que anteriormente no se había descrito en las prácticas de diseño y desarrollo de productos: cómo, por ejemplo, ¿Se puede reutilizar en los televisores un botón de teléfonos y tablets? ¿Y qué deberíamos hacer con los tamaños de fuentes y elementos en plataformas tan diferentes?

Obviamente, era necesario diseñar una grilla modular multiplataforma que estableciera los tamaños de texto y elementos que necesitábamos para cada plataforma específica. Como punto de partida para la cuadrícula, elegimos el tamaño y la cantidad de carteles de películas que queremos ver en una pantalla en particular y, en base a esto, formulamos una regla para construir columnas de la cuadrícula, siempre que el ancho de una columna sea igual al ancho del cartel.

Ahora necesitamos llevar todas las pantallas grandes al mismo tamaño de diseño y encajarlas en una cuadrícula común. Apple TV y Roku están diseñados en un tamaño de 1920x1080, Android TV: 960x540, los Smart TV, según el proveedor, son iguales, pero a veces 1280x720. Cuando la aplicación se procesa y se muestra en pantallas Full HD, 960 se multiplica por 2, 1280 se multiplica por 1,33 y 1920 se genera tal cual.

Saltándonos detalles aburridos, llegamos a la conclusión de que, en general, todas las pantallas, incluidas las de televisión, en términos de elementos y tamaños, están cubiertas por un diseño de diseño, y todas las pantallas de televisión son un caso especial de la cuadrícula general multiplataforma. y consta de cinco o seis columnas, como una tableta o computadora de escritorio promedio. Quien esté interesado en los detalles, vaya a los comentarios.

UI única para todas las plataformas

Ahora, para dibujar una nueva característica, no necesitamos dibujar diseños para cada plataforma, además de opciones de adaptabilidad para cada una de ellas. Basta mostrar un diseño y su adaptabilidad a todas las plataformas y dispositivos de cualquier ancho: teléfonos - 320-599, todo lo demás - 600-1280.

Datos → desarrollo

Por supuesto, por mucho que nos gustaría lograr un diseño completamente unificado, cada plataforma tiene sus propias características únicas. Aunque tanto la web como Smart TV utilizan la pila ReactJS + TypeScript, la aplicación Smart TV se ejecuta en clientes WebKit y Presto heredados y, por lo tanto, no puede compartir estilos con la web. Y los boletines informativos por correo electrónico están completamente obligados a funcionar con un diseño tabular. Al mismo tiempo, ninguna de las plataformas que no son HTML usa ni planea usar React Native o cualquiera de sus análogos, por temor a la degradación del rendimiento, ya que tenemos demasiados diseños personalizados, colecciones con lógica de actualización compleja, imágenes y videos. Por lo tanto, el esquema común de entregar estilos CSS listos para usar o componentes React no es adecuado para nosotros. Por lo tanto, decidimos transmitir datos en formato JSON, describiendo los valores en forma declarativa abstracta.

entonces propiedad rounding: 8 La aplicación de Windows 10 se convierte a CornerRadius="8", web - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Propiedad offsetTop: 12 el mismo cliente web en diferentes casos puede interpretar como top, margin-top, padding-top o transform

La declaratividad de la descripción también implica que si la plataforma técnicamente no puede utilizar una propiedad o su valor, puede ignorarla. En términos de terminología, creamos una especie de idioma esperanto: algunos fueron tomados de Android, otros de SVG, otros de CSS.

Si en una plataforma en particular necesita mostrar elementos de manera diferente, hemos implementado la capacidad de transferir la generación de datos correspondiente en forma de un archivo JSON separado. Por ejemplo, el estado "en foco" para Smart TV dicta un cambio en la posición del texto debajo del cartel, lo que significa que para esta plataforma este componente en el valor de la propiedad "sangría" contendrá los 8 puntos de sangría que necesita. Aunque esto complica la infraestructura del sistema de diseño, brinda un grado adicional de libertad, dejándonos la oportunidad de gestionar nosotros mismos la "diferencia" visual de las plataformas y no ser rehenes de la arquitectura que creamos.

Pictogramas

La iconografía en un producto digital es siempre un subproyecto voluminoso y no el más simple, que a menudo requiere un diseñador independiente. Siempre hay muchos glifos, cada uno de ellos tiene varios tamaños y colores, y las plataformas suelen necesitarlos en diferentes formatos. En general, no había ninguna razón para no incluir todo esto en el sistema de diseño.

Los glifos se cargan en formato vectorial SVG y los valores de color se reemplazan automáticamente con variables. Las aplicaciones cliente pueden recibirlos listos para usar, en cualquier formato y color.

avance

Además de los datos JSON, escribimos una herramienta para obtener una vista previa de los componentes: una aplicación JS que pasa datos JSON sobre la marcha a través de sus generadores de marcado y estilo, y muestra varias variaciones de cada componente en el navegador. Básicamente, la vista previa es exactamente el mismo cliente que las aplicaciones de la plataforma y funciona con los mismos datos.

La forma más sencilla de comprender cómo funciona un componente en particular es interactuando con él. Por lo tanto, no utilizamos herramientas como Storybook, sino que hicimos una vista previa interactiva: puedes tocar, señalar, hacer clic... Al agregar un nuevo componente al sistema de diseño, aparece en la vista previa para que las plataformas tengan algo en qué centrarse cuando implementarlo.

Документация

A partir de los datos suministrados a las plataformas en formato JSON, se genera automáticamente la documentación de los componentes. Se describe una lista de propiedades y posibles tipos de valores en cada una de ellas. Después de la generación automática, la información se puede aclarar manualmente y se puede agregar una descripción de texto. La vista previa y la documentación tienen referencias cruzadas entre sí a nivel de cada componente, y toda la información incluida en la documentación está disponible para los desarrolladores en forma de archivos JSON adicionales.

Deprecator

Otra necesidad era la capacidad de reemplazar y actualizar los componentes existentes con el tiempo. El sistema de diseño ha aprendido a indicar a los desarrolladores qué propiedades o incluso componentes completos no se pueden utilizar y eliminarlos en cuanto dejan de utilizarse en todas las plataformas. Todavía queda mucho trabajo “manual” en este proceso, pero no nos quedamos quietos.

Desarrollo de clientes

Sin duda, la etapa más compleja fue la interpretación de los datos del sistema de diseño en el código de todas las plataformas que soportamos. Si, por ejemplo, las redes modulares en la web no son algo nuevo, entonces los desarrolladores de aplicaciones móviles nativas para iOS y Android trabajaron duro antes de descubrir cómo vivir con ellas.

Para diseñar las pantallas de las aplicaciones iOS, utilizamos dos mecanismos básicos proporcionados por iviUIKit: diseño libre de elementos y diseño de colecciones de elementos. Usamos VIPER y toda la interacción con iviUIKit se concentra en View, y la mayor parte de la interacción con Apple UIKit se concentra en iviUIKit. Los tamaños y la disposición de los elementos se especifican en términos de columnas y estructuras sintácticas que funcionan por encima de las restricciones nativas del SDK de iOS, lo que los hace más prácticos. Esto simplificó especialmente nuestra vida cuando trabajamos con UICollectionView. Hemos escrito varios envoltorios personalizados para diseños, incluidos algunos bastante complejos. Había un mínimo de código de cliente y se volvió declarativo.

Para generar estilos en el proyecto de Android, utilizamos Gradle, convirtiendo los datos del sistema de diseño en estilos en formato XML. Al mismo tiempo, disponemos de varios generadores de varios niveles:

• Básico. Se analizan los datos de las primitivas para generadores de nivel superior.
• Recurso. Descargue imágenes, íconos y otros gráficos.
• Componente. Están escritos para cada componente, que describe qué propiedades y cómo traducirlas en estilos.

Lanzamientos de aplicaciones

Una vez que los diseñadores han dibujado un nuevo componente o rediseñado uno existente, estos cambios se introducen en el sistema de diseño. Los desarrolladores de cada plataforma están afinando su generación de código para soportar los cambios. Después de esto, se puede utilizar en la implementación de nuevas funciones donde se necesita este componente. Así, la interacción con el sistema de diseño no se produce en tiempo real, sino sólo en el momento de montar nuevos lanzamientos. Este enfoque también permite un mejor control sobre el proceso de transferencia de datos y garantiza la funcionalidad del código en los proyectos de desarrollo de clientes.

resultados

Ha pasado un año desde que el sistema de diseño pasó a formar parte de la infraestructura que sustenta el desarrollo del cine online Ivy y ya podemos sacar algunas conclusiones:

• Este es un proyecto grande y complejo que requiere recursos dedicados constantes.
• Esto nos permitió crear nuestro propio lenguaje visual multiplataforma único que cumple con los objetivos del servicio de video en línea.
• Ya no tenemos plataformas visual y funcionalmente retrasadas.

Vista previa de los componentes del sistema de diseño Ivy - diseño.ivi.ru

Fuente: habr.com