Do UI-kit ao sistema de design

Experiência de cinema online Ivy

Quando no início de 2017 pensamos pela primeira vez em criar nosso próprio sistema de entrega design-to-code, muitos já falavam sobre isso e alguns até o faziam. No entanto, até hoje pouco se sabe sobre a experiência de construção de sistemas de design multiplataforma, e não existem receitas claras e comprovadas que descrevam tecnologias e métodos para tal transformação do processo de implementação de design em um produto já funcional. E por “componentes no código” eles geralmente significam coisas muito diferentes.

Enquanto isso, a empresa dobrava seu quadro de funcionários ano após ano – era preciso dimensionar o departamento de design e otimizar os processos de criação e transferência de layouts para desenvolvimento. Multiplicamos tudo isso pelo “zoológico” de plataformas que precisam ser apoiadas, e temos uma aparência de pandemônio babilônico, que simplesmente não consegue “fazer normalmente” e gerar renda. O desenvolvimento de plataformas muitas vezes ocorria em paralelo, e a mesma funcionalidade poderia ser lançada em plataformas diferentes com um atraso de vários meses.


Conjuntos de layout separados para cada plataforma

Tradicionalmente, começamos com problemas que um sistema de design ajudaria a resolver e formulamos requisitos para seu design. Além de criar uma linguagem visual unificada, aumentar a velocidade de layout e desenvolvimento e melhorar a qualidade geral do produto, era vital unificar ao máximo o design. Isso é necessário para que o desenvolvimento de funcionalidades seja possível em todas as nossas plataformas simultaneamente: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - sem trabalhar em cada uma delas separadamente. E nós conseguimos!

Projeto → dados

Quando os acordos fundamentais entre os departamentos de produto e desenvolvimento foram alcançados, sentamos para selecionar uma pilha de tecnologia e elaborar os detalhes de todo o processo – do layout ao lançamento. Para automatizar totalmente o processo de transferência do design para o desenvolvimento, exploramos a opção de analisar os parâmetros dos componentes diretamente dos arquivos Sketch com layouts. Descobrimos que encontrar os trechos de código de que precisávamos e extrair os parâmetros de que precisávamos era uma tarefa complexa e perigosa. Em primeiro lugar, os designers terão que ser extremamente cuidadosos ao nomear todas as camadas do código-fonte, em segundo lugar, isso só funciona para os componentes mais simples e, em terceiro lugar, a dependência da tecnologia e estrutura de código de outra pessoa do layout original do Sketch compromete o futuro de todo o projeto. Decidimos abandonar a automação nesta área. Foi assim que apareceu a primeira pessoa na equipe do sistema de design, cuja entrada são os layouts de design, e a saída são dados que descrevem todos os parâmetros dos componentes e ordenados hierarquicamente de acordo com a metodologia de design atômico.

A única coisa que faltava fazer era onde e como armazenar os dados, como transferi-los para o desenvolvimento e como interpretá-los no desenvolvimento em todas as plataformas que apoiamos. A noite deixou de ser lânguida... O resultado de reuniões regulares do grupo de trabalho composto por designers e líderes de equipe de cada plataforma foi o acordo sobre o seguinte.

Analisamos manualmente o visual em elementos atômicos: fontes, cores, transparência, recuos, arredondamentos, ícones, imagens e durações de animações. E coletamos a partir disso botões, entradas, caixas de seleção, widgets de cartão bancário, etc. Atribuímos nomes não semânticos aos estilos de qualquer um dos níveis, exceto para ícones, por exemplo, nomes de cidades, nomes de ninfas, Pokémon, carro marcas... Só há uma condição - a lista não deve se esgotar antes de como terminam os estilos - o show deve acabar! Você não deve se deixar levar pela semântica, para não precisar adicionar um botão do meio entre “pequeno” e “médio”, por exemplo.

Linguagem visual

Os desenvolvedores tiveram que pensar em como armazenar e transferir dados de uma forma que se adaptasse a todas as plataformas, e o design teve que projetar elementos de interface que pudessem ter boa aparência e funcionar de maneira eficaz em toda a frota de dispositivos suportados.

Anteriormente, já havíamos conseguido “testar” grande parte dos elementos de design de um aplicativo para Windows 10, que na época era uma plataforma nova para nós, ou seja, exigia renderização e desenvolvimento “do zero”. Ao desenhá-lo, pudemos preparar e testar a maioria dos componentes e entender quais deles deveriam ser incluídos no futuro sistema de design Eevee. Sem essa sandbox, essa experiência só poderia ser obtida através de um grande número de iterações em plataformas já em funcionamento, e isso levaria mais de um ano.

A reutilização dos mesmos componentes em plataformas diferentes reduz significativamente o número de layouts e a matriz de dados do sistema de design, de modo que o design teve que resolver mais um problema, antes não descrito nas práticas de design e desenvolvimento de produtos - como, por exemplo, um botão para telefones e tablets pode ser reutilizado em TVs? E o que devemos fazer com os tamanhos das fontes e dos elementos em plataformas tão diferentes?

Obviamente, foi necessário projetar uma grade modular multiplataforma que definisse os tamanhos de texto e elementos que precisávamos para cada plataforma específica. Como ponto de partida para a grade, escolhemos o tamanho e a quantidade de pôsteres de filmes que queremos ver em uma determinada tela e, com base nisso, formulamos uma regra para construção de colunas da grade, desde que a largura de uma coluna seja igual à largura do pôster.

Agora precisamos trazer todas as telas grandes para o mesmo tamanho de layout e encaixá-las em uma grade comum. Apple TV e Roku são projetados no tamanho 1920x1080, Android TV - 960x540, Smart TVs, dependendo do fornecedor, são iguais, mas às vezes 1280x720. Quando o aplicativo é renderizado e exibido em telas Full HD, 960 é multiplicado por 2, 1280 é multiplicado por 1,33 e 1920 é gerado como está.

Ignorando detalhes enfadonhos, chegamos à conclusão de que em geral todas as telas, incluindo telas de televisão, em termos de elementos e seus tamanhos, são cobertas por um layout de design, e todas as telas de televisão são um caso especial da grade geral de plataforma cruzada, e consistem em cinco ou seis colunas, como um tablet ou desktop comum. Quem tiver interesse em detalhes, vai nos comentários.

UI única para todas as plataformas

Agora, para desenhar um novo recurso, não precisamos desenhar layouts para cada plataforma, além de opções de adaptabilidade para cada uma delas. Basta mostrar um layout e sua adaptabilidade para todas as plataformas e dispositivos de qualquer largura: telefones - 320-599, todo o resto - 600-1280.

Dados → desenvolvimento

É claro que, por mais que desejemos obter um design completamente unificado, cada plataforma tem seus próprios recursos exclusivos. Embora a web e a Smart TV usem a pilha ReactJS + TypeScript, o aplicativo Smart TV é executado em clientes WebKit e Presto legados e, portanto, não pode compartilhar estilos com a web. E os boletins informativos por e-mail são totalmente forçados a funcionar com layout tabular. Ao mesmo tempo, nenhuma das plataformas não-html utiliza ou planeja utilizar React Native ou qualquer um de seus análogos, temendo degradação de desempenho, já que temos muitos layouts customizados, coleções com lógica de atualização complexa, imagens e vídeos. Portanto, o esquema comum de entrega de estilos CSS prontos ou componentes React não é adequado para nós. Portanto, decidimos transmitir os dados no formato JSON, descrevendo os valores de forma declarativa abstrata.

Então propriedade rounding: 8 O aplicativo do Windows 10 é convertido para CornerRadius="8", rede - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Propriedade offsetTop: 12 o mesmo cliente web em casos diferentes pode ser interpretado como top, margin-top, padding-top ou transform

A declaratividade da descrição também implica que, se a plataforma não puder usar tecnicamente uma propriedade ou seu valor, ela poderá ignorá-la. Em termos de terminologia, fizemos uma espécie de linguagem Esperanto: algumas foram tiradas do Android, outras do SVG, outras do CSS.

Se em uma plataforma específica você precisar exibir elementos de maneira diferente, implementamos a capacidade de transferir a geração de dados correspondente na forma de um arquivo JSON separado. Por exemplo, o estado “em foco” para Smart TV determina uma mudança na posição do texto sob o pôster, o que significa que para esta plataforma este componente no valor da propriedade “recuo” conterá os 8 pontos de recuo necessários. Embora isto complique a infra-estrutura do sistema de design, dá um grau adicional de liberdade, deixando-nos a oportunidade de gerir nós próprios a “dissimilaridade” visual das plataformas, e não ficarmos reféns da arquitectura que criamos.

Pictogramas

A iconografia em um produto digital é sempre um subprojeto volumoso e não o mais simples, muitas vezes exigindo um designer separado. Sempre há muitos glifos, cada um deles tem vários tamanhos e cores, e as plataformas geralmente precisam deles em formatos diferentes. Em geral, não havia razão para não incluir tudo isso no sistema de design.

Os glifos são carregados no formato vetorial SVG e os valores das cores são automaticamente substituídos por variáveis. Os aplicativos clientes podem recebê-los prontos para uso - em qualquer formato e cor.

visualização

Além dos dados JSON, escrevemos uma ferramenta para visualizar componentes - um aplicativo JS que transmite dados JSON dinamicamente por meio de seus geradores de marcação e estilo e exibe diversas variações de cada componente no navegador. Essencialmente, a visualização é exatamente o mesmo cliente dos aplicativos da plataforma e funciona com os mesmos dados.

A maneira mais fácil de entender como funciona um determinado componente é interagindo com ele. Portanto, não utilizamos ferramentas como o Storybook, mas fizemos uma visualização interativa - você pode tocar, apontar, clicar... Ao adicionar um novo componente ao design system, ele aparece na visualização para que as plataformas tenham algo em que focar quando implementá-lo.

Documentação

Com base nos dados fornecidos às plataformas em formato JSON, a documentação dos componentes é gerada automaticamente. É descrita uma lista de propriedades e possíveis tipos de valores em cada uma delas. Após a geração automática, as informações podem ser esclarecidas manualmente e uma descrição de texto pode ser adicionada. A visualização e a documentação têm referências cruzadas no nível de cada componente, e todas as informações incluídas na documentação estão disponíveis para os desenvolvedores na forma de arquivos JSON adicionais.

Descontinuador

Outra necessidade era a capacidade de substituir e atualizar componentes existentes ao longo do tempo. O sistema de design aprendeu a informar aos desenvolvedores quais propriedades ou mesmo componentes inteiros não podem ser usados ​​e removê-los assim que não forem mais usados ​​em todas as plataformas. Ainda há muito trabalho “manual” nesse processo, mas não estamos parados.

Desenvolvimento de cliente

Sem dúvida, a etapa mais complexa foi a interpretação dos dados do design system no código de todas as plataformas que suportamos. Se, por exemplo, grades modulares na web não são algo novo, então os desenvolvedores de aplicativos móveis nativos para iOS e Android trabalharam duro antes de descobrirem como conviver com isso.

Para fazer o layout das telas de aplicativos iOS, usamos dois mecanismos básicos fornecidos pelo iviUIKit: layout livre de elementos e layout de coleções de elementos. Usamos VIPER, e toda a interação com o iviUIKit está concentrada no View, e a maior parte da interação com o Apple UIKit está concentrada no iviUIKit. Os tamanhos e a disposição dos elementos são especificados em termos de colunas e estruturas sintáticas que funcionam sobre as restrições nativas do SDK do iOS, tornando-os mais práticos. Isso simplificou especialmente nossa vida ao trabalhar com UICollectionView. Escrevemos vários wrappers personalizados para layouts, incluindo alguns bastante complexos. Havia um mínimo de código do cliente e ele se tornou declarativo.

Para gerar estilos no projeto Android, utilizamos Gradle, transformando os dados do sistema de design em estilos no formato XML. Ao mesmo tempo, temos vários geradores de vários níveis:

• Básico. Os dados das primitivas para geradores de nível superior são analisados.
• Recurso. Baixe fotos, ícones e outros gráficos.
• Componente. Eles são escritos para cada componente, que descreve quais propriedades e como traduzi-las em estilos.

Lançamentos de aplicativos

Depois que os projetistas desenham um novo componente ou redesenham um existente, essas alterações são inseridas no sistema de design. Os desenvolvedores de cada plataforma estão ajustando sua geração de código para suportar as mudanças. Depois disso, ele poderá ser utilizado na implementação de novas funcionalidades onde este componente for necessário. Assim, a interação com o design system não ocorre em tempo real, mas apenas no momento da montagem de novos lançamentos. Essa abordagem também permite um melhor controle sobre o processo de transferência de dados e garante a funcionalidade do código em projetos de desenvolvimento de clientes.

Resultados de

Já faz um ano que o design system passou a fazer parte da infraestrutura de apoio ao desenvolvimento do cinema online Ivy, e já podemos tirar algumas conclusões:

• Este é um projeto grande e complexo que requer recursos dedicados constantes.
• Isso nos permitiu criar nossa própria linguagem visual multiplataforma que atende aos objetivos do serviço de vídeo online.
• Não temos mais plataformas com atraso visual e funcional.

Visualização dos componentes do sistema de design Ivy - design.ivi.ru

Fonte: habr.com