Ivy Online Movie ExperienceCuando a principios de 2017, primero pensamos en crear nuestro propio sistema para entregar diseño al código, muchos hablaron sobre esto y alguien incluso lo hizo. Sin embargo, se sabe poco sobre la experiencia de construir sistemas de diseño multiplataforma hasta el día de hoy, y no hay recetas claras y probadas que describan tecnologías y métodos para tal transformación del proceso de implementación del diseño en un producto que ya funcione. Y "componentes en código" a menudo significa cosas muy diferentes.

Mientras tanto, la compañía duplicó su personal de año en año: era necesario escalar el departamento de diseño y optimizar los procesos de creación y transferencia de diseños al desarrollo. Multiplicamos todo esto por un "zoológico" de plataformas que necesitan ser soportadas, y tenemos una apariencia de una multitud de Babel, que simplemente no es capaz de "hacer normalmente" y generar ingresos. El desarrollo de la plataforma a menudo procedía en paralelo, y la misma funcionalidad podría salir en diferentes plataformas con un retraso de varios meses.
Conjuntos de diseño separados para cada plataformaTradicionalmente, comenzamos con problemas que el sistema de diseño ayudaría a resolver y formuló requisitos para su diseño. Además de crear un solo lenguaje visual, aumentar la velocidad de creación de prototipos y desarrollo, mejorar la calidad del producto en su conjunto, era vitalmente necesario unificar el diseño tanto como sea posible. Esto es necesario para que el desarrollo de la funcionalidad sea posible de forma inmediata 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 individualmente . Y lo hicimos!
Diseño → Datos
Cuando se alcanzaron los principales acuerdos de los departamentos de productos y desarrollo, nos sentamos a seleccionar la pila tecnológica y estudiar los detalles de todo el proceso, desde el diseño hasta el lanzamiento. Para automatizar completamente el proceso de transferir el diseño al desarrollo, investigamos la opción con un analizador de parámetros de componentes directamente desde los 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 complicada y peligrosa. En primer lugar, los diseñadores tendrán que ser extremadamente cuidadosos al nombrar todas las capas del código fuente, en segundo lugar, funciona solo para los componentes más simples y, en tercer lugar, la dependencia de la tecnología y la estructura del código de otras personas del diseño de Sketch original pone en peligro el futuro de todo el proyecto. Decidimos abandonar la automatización en esta área. Entonces, la primera persona apareció en el equipo del sistema de diseño, a la entrada de la cual se alimentan los diseños de diseño, y en la salida: datos que describen todos los parámetros de los componentes y ordenados jerárquicamente de acuerdo con la metodología de diseño atómico.
El asunto seguía siendo pequeño: dónde y cómo almacenar datos, cómo transferirlos al desarrollo y cómo interpretarlos en el desarrollo en todas las plataformas compatibles con nosotros. La tarde dejó de ser lánguida ... El resultado de las reuniones periódicas del grupo de trabajo, compuesto por diseñadores y líderes de equipo de cada plataforma, fue el acuerdo sobre lo siguiente.
Analizamos manualmente lo visual en elementos atómicos: fuentes, colores, transparencias, sangrías, filetes, iconos, imágenes y duraciones para animaciones. Y recogemos de este botón, entradas, casillas de verificación, widgets de tarjetas bancarias, etc. Asignamos nombres no semánticos a estilos de cualquiera de los niveles, excepto iconos, por ejemplo, nombres de ciudades, nombres de ninfas, Pokémon, marcas de automóviles ... Solo hay una condición: la lista no debe agotarse antes , ¿con qué estilos terminarán? No debe dejarse llevar por la semántica para no tener que agregar un botón central entre "pequeño" y "medio", por ejemplo.
Lenguaje visual
Los desarrolladores dejaron de pensar en cómo almacenar y transferir datos para que se adapten a todas las plataformas, y el diseño tuvo que diseñar elementos de interfaz que pudieran verse igual de bien y funcionar de manera efectiva en toda la flota de dispositivos compatibles.
Anteriormente, logramos "ejecutar" la mayoría de los elementos de diseño en una aplicación para Windows 10, que en ese momento era una nueva plataforma para nosotros, es decir, se requería renderización y desarrollo desde cero. Al dibujarlo, pudimos preparar y probar la mayoría de los componentes y comprender cuáles de ellos se incluirían en el futuro sistema de diseño de Ivy. Sin una caja de arena de este tipo, dicha experiencia solo se podría obtener mediante un gran número de iteraciones en plataformas que ya funcionan, y esto habría llevado más de un año.
La reutilización de los mismos componentes en diferentes plataformas reduce el número de diseños y la matriz de datos del sistema de diseño a veces, por lo que el diseño tuvo que resolver otro problema que no se describió previamente en la práctica del diseño y desarrollo de productos: ¿cómo, por ejemplo, reutilizar el botón para teléfonos y tabletas en televisores? ¿Y qué debería ser, en principio, con los tamaños de fuentes y elementos en plataformas tan diferentes?
Obviamente, era necesario diseñar una cuadrícula modular multiplataforma que estableciera el texto y los tamaños de elementos que necesitábamos para cada plataforma en particular. Para el punto de referencia de la cuadrícula, seleccionamos 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 la regla para construir columnas de cuadrícula, siempre que el ancho de una columna sea igual al ancho del cartel.
Ahora debe llevar todas las pantallas grandes al mismo tamaño del diseño y ajustarlas a la cuadrícula general. Apple TV y Roku se están desarrollando en el tamaño de 1920x1080, Android TV - 960x540, Smart TV, dependiendo del proveedor, son los mismos, y hay 1280x720. Cuando la aplicación se procesa y se muestra en pantallas Full HD, 960 se multiplica por 2, 1280 por 1.33 y 1920 se muestra como está.
Omitiendo detalles aburridos, llegamos a la conclusión de que, en general, todas las pantallas, incluidas las pantallas de TV en términos de elementos y sus tamaños, están cubiertas por un diseño, y todas las pantallas de TV son un caso especial de una cuadrícula común multiplataforma, y consisten en cinco o seis columnas, como una tableta promedio o escritorio A quién le importan los detalles, vaya a los comentarios.
IU unificada para todas las plataformasAhora, para dibujar una nueva característica, no necesitamos dibujar diseños para cada plataforma, más opciones de adaptabilidad para cada una de ellas. Es suficiente mostrar un diseño y su adaptabilidad para todas las plataformas y dispositivos de cualquier ancho: teléfonos - 320–599, todo lo demás - 600–1280.
Datos → Desarrollo
Por supuesto, no importa cómo nos gustaría llegar a un diseño completamente unificado, cada plataforma tiene sus propias características únicas. A pesar de que tanto la web como Smart TV usan la pila ReactJS + TypeScript, la aplicación Smart TV se ejecuta en clientes WebKit y Presto heredados, y por lo tanto no puede usar estilos comunes con la web. Y los boletines por correo electrónico están completamente obligados a trabajar con el diseño de la tabla. Al mismo tiempo, ninguna de las plataformas no html usa o 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, un esquema común no es adecuado para nosotros: suministrar estilos CSS listos para usar o componentes React. Por lo tanto, decidimos transferir datos en formato JSON, describiendo los valores en una forma declarativa abstracta.
Entonces, la propiedad de rounding: 8
, la aplicación de Windows 10 se convierte en CornerRadius="8"
, la web - border-radius: 8px
, Android - android:radius="8dp"
, iOS - self.layer.cornerRadius = 8.0
.
offsetTop: 12
OffsetTop offsetTop: 12
el mismo cliente web puede interpretarse en diferentes casos como top
, margin-top
, padding-top
o transform
La naturaleza declarativa de la descripción también sugiere que si la plataforma es técnicamente incapaz de usar alguna propiedad o su valor, puede ignorarla. En términos de terminología, creamos una especie de lenguaje esperanto: tomamos algo de Android, algunos de SVG, algunos de CSS.
Si es necesario mostrar elementos de una manera diferente en una plataforma en particular, hemos implementado la capacidad de transferir la generación de datos correspondiente como un archivo JSON separado. Por ejemplo, el estado está "enfocado" para Smart TV, dicta un cambio en la posición del texto debajo del póster, por lo 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 la "disparidad" visual de las plataformas nosotros mismos, 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 fácil, a menudo tiene un diseñador separado. Siempre hay muchos glifos, cada uno de ellos tiene varios tamaños y colores, además, las plataformas los necesitan, por regla general, en diferentes formatos. En general, no había 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 prepararlos para usar, en cualquier formato y color.
Vista previa
Además de JSON con datos, escribimos una herramienta para previsualizar componentes: una aplicación JS que pasa datos JSON a través de sus generadores de marcado y estilo sobre la marcha y muestra varias variaciones de cada componente en el navegador. De hecho, la vista previa es exactamente el mismo cliente que las aplicaciones de la plataforma y funciona con los mismos datos.
Comprender cómo funciona un componente en particular es más fácil al interactuar con él. Por lo tanto, no utilizamos herramientas como Storybook, sino que hicimos una vista previa interactiva: puede tocar, desplazar, hacer clic ... Cuando agrega un nuevo componente al sistema de diseño, aparece en la vista previa para que las plataformas tengan algo en qué enfocarse al introducirlo.
La documentación
Según los datos que se entregan en forma de JSON a las plataformas, la documentación de los componentes se genera automáticamente. Se describe la lista de propiedades y los posibles tipos de valores en cada uno de ellos. Después de la generación automática, la información se puede aclarar manualmente, agregue una descripción de texto. La vista previa y la documentación se proporcionan con referencias cruzadas entre sí en el 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 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 usar y eliminarlos tan pronto como ya no se usen en todas las plataformas. Todavía hay mucho trabajo "manual" en este proceso, pero no nos quedamos quietos.
Desarrollo del cliente
Sin lugar a dudas, la interpretación de los datos del sistema de diseño en el código de todas las plataformas soportadas por nosotros se convirtió en la etapa más extensa en complejidad. Si, por ejemplo, las redes modulares en la web no son nuevas, entonces los desarrolladores de aplicaciones móviles nativas para iOS y Android sudaron bastante antes de descubrir cómo vivir con ellas.
Para el diseño de las pantallas de la aplicación iOS, utilizamos dos mecanismos básicos que proporciona iviUIKit: diseño gratuito 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ía 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 construcciones sintácticas que funcionan sobre las constantes nativas del SDK de iOS, lo que las hace más aplicadas. Esto simplificó especialmente nuestra vida cuando trabajamos con UICollectionView. Escribimos algunos diseños personalizables para diseños, incluidos los bastante complejos. El código del cliente resultó mínimo y se volvió declarativo.
Para generar estilos en el proyecto de Android, utilizamos Gradle, convirtiendo los datos del sistema de diseño en estilos de formato XML. Al mismo tiempo, tenemos varios generadores de varios niveles:
- Básico Análisis de datos de primitivas para generadores de nivel superior.
- Recurso Descargue imágenes, iconos y otros gráficos.
- Componente Están escritos para cada componente, que describe qué propiedades y cómo traducir a estilos.
Lanzamientos de aplicaciones
Después de que los diseñadores hayan dibujado un nuevo componente o reelaborado uno existente, estos cambios caen en el sistema de diseño. Los desarrolladores de cada plataforma están finalizando su generación de código, brindando soporte para los cambios. Después de eso, se puede usar en la implementación de una nueva funcionalidad, donde este componente es necesario. Por lo tanto, la interacción con el sistema de diseño no ocurre en tiempo real, sino solo al momento de ensamblar nuevos lanzamientos. Este enfoque también le permite controlar mejor el proceso de transferencia de datos y garantiza el rendimiento del código en proyectos de desarrollo de clientes.
Resumen
Pronto, como sistema de diseño, un año se convirtió en parte de la infraestructura al servicio del desarrollo del cine en línea Ivy, y ya se pueden sacar algunas conclusiones:
- Este es un proyecto grande y difícil de implementar, que requiere recursos asignados constantemente.
- 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 con retraso visual y funcional.
Vista previa de los componentes del sistema de diseño Ivy -
design.ivi.ru