Ivy Online Movie ExperienceQuando, no início de 2017, primeiro pensamos em criar nosso próprio sistema para fornecer design ao código, muitos falaram sobre isso e até alguém o fez. No entanto, pouco se sabe sobre a experiência de criar sistemas de design de plataforma cruzada até hoje, e não há receitas claras e comprovadas que descrevam tecnologias e métodos para essa transformação do processo de implementação de design em um produto já em funcionamento. E “componentes no código” geralmente significam coisas muito diferentes.
Enquanto isso, a empresa dobrava sua equipe de ano para ano - era necessário escalar o departamento de design e otimizar os processos de criação e transferência de layouts para o desenvolvimento. Multiplicamos tudo isso por um "zoológico" de plataformas que precisam ser suportadas, e temos uma aparência de uma multidão de Babel, que simplesmente não é capaz de "normalmente fazer" e gerar renda. O desenvolvimento da plataforma geralmente prosseguia em paralelo, e a mesma funcionalidade poderia sair em plataformas diferentes com um atraso de vários meses.
Conjuntos de layout separados para cada plataformaTradicionalmente, começamos com problemas em que o sistema de design ajudaria a resolver e formular requisitos para seu design. Além de criar uma linguagem visual única, aumentando a velocidade da criação de protótipos e desenvolvimento, melhorando a qualidade do produto como um todo, era de vital importância a unificação do design, tanto quanto possível. Isso é necessário para que o desenvolvimento da funcionalidade seja possível imediatamente 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 individualmente . E nós conseguimos!
Design → Dados
Quando os principais acordos dos departamentos de produto e desenvolvimento foram alcançados, nos sentamos para selecionar a pilha tecnológica e estudar os detalhes de todo o processo - desde o layout até o lançamento. Para automatizar completamente o processo de transferência do design para o desenvolvimento, investigamos a opção com um analisador de parâmetros do componente diretamente dos arquivos de esboço com layouts. Aconteceu que encontrar os trechos de código que precisávamos e extrair os parâmetros que precisávamos era uma tarefa complicada 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, ele funciona apenas para os componentes mais simples e, em terceiro lugar, a dependência da tecnologia de outras pessoas e da estrutura de código do layout original do Sketch coloca em risco o futuro de todo o projeto. Decidimos abandonar a automação nesta área. Assim, a primeira pessoa apareceu na equipe do sistema de design, na entrada de quais layouts de design são enviados e na saída - dados descrevendo todos os parâmetros dos componentes e ordenados hierarquicamente de acordo com a metodologia de design atômico.
O assunto permaneceu pequeno: onde e como armazenar dados, como transferi-los para o desenvolvimento e como interpretá-los no desenvolvimento em todas as plataformas suportadas por nós. 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 a seguir.
Analisamos manualmente o visual em elementos atômicos: fontes, cores, transparência, recuos, filetes, ícones, imagens e durações para animações. Coletamos a partir desse botão, entradas, caixas de seleção, widgets de cartões bancários, etc. Atribuímos nomes não-semânticos a estilos de qualquer um dos níveis, exceto ícones, por exemplo, nomes de cidades, nomes de ninfas, Pokemon, marcas de carros ... Há apenas uma condição - a lista não deve ser esgotada anteriormente com que estilos terminará - mostre o mastro! 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 saíram para pensar em como armazenar e transferir dados para que se ajustassem a todas as plataformas, e o design teve que criar elementos de interface que parecessem igualmente bons e funcionassem efetivamente em toda a frota de dispositivos suportados.
Anteriormente, conseguimos "executar" a maioria dos elementos de design em um aplicativo para Windows 10, que na época era uma nova plataforma para nós, ou seja, era necessário renderizar e desenvolver 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 Ivy. Sem esse sandbox, essa experiência poderia ser adquirida apenas por 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 o número de layouts e a matriz de dados do sistema de design às vezes; portanto, o design precisava resolver outro problema que não era descrito anteriormente na prática de design e desenvolvimento de produtos - como, por exemplo, reutilizar o botão para telefones e tablets em TVs? E o que, em princípio, deveria ser com os tamanhos de fontes e elementos em plataformas tão diferentes?
Obviamente, era necessário projetar uma grade modular de plataforma cruzada que definisse os tamanhos de texto e elemento necessários para cada plataforma específica. Para o ponto de referência da grade, selecionamos o tamanho e o número de pôsteres de filmes que queremos ver em uma tela específica e, com base nisso, formulamos a regra para a construção de colunas da grade, desde que a largura de uma coluna seja igual à largura do pôster.
Agora você precisa trazer todas as telas grandes para o mesmo tamanho do layout e ajustá-las à grade geral. A Apple TV e o Roku estão sendo desenvolvidos no tamanho de 1920x1080, Android TV - 960x540, Smart TV, dependendo do fornecedor, eles são iguais e existem 1280x720. Quando o aplicativo é renderizado e exibido em telas Full HD, 960 é multiplicado por 2, 1280 por 1,33 e 1920 é exibido como está.
Omitindo detalhes chatos, chegamos à conclusão de que, em geral, todas as telas, incluindo telas de TV em termos de elementos e tamanhos, são cobertas por um layout de design e todas as telas de TV são um caso especial de uma grade comum de plataforma cruzada e consistem em cinco ou seis colunas, como um tablet comum ou desktop. Quem se importa com os detalhes, vá para os comentários.
UI unificada para todas as plataformasAgora, 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, tudo o resto - 600–1280.
Dados → Desenvolvimento
Obviamente, não importa como gostaríamos de chegar a um design completamente unificado, cada plataforma tem seus próprios recursos exclusivos. Apesar de a Web e a Smart TV usarem a pilha ReactJS + TypeScript, o aplicativo Smart TV é executado nos clientes WebKit e Presto herdados e, portanto, não pode usar estilos comuns na Web. E os boletins por e-mail são completamente forçados a trabalhar com o layout da tabela. Ao mesmo tempo, nenhuma plataforma não-html usa ou planeja usar o React Native ou qualquer um de seus análogos, por medo da degradação do desempenho, pois temos muitos layouts personalizados, coleções com lógica de atualização complexa, imagens e vídeos. Portanto, um esquema comum não é adequado para nós - fornecer estilos CSS prontos ou componentes React. Portanto, decidimos transferir dados no formato JSON, descrevendo os valores em uma forma declarativa abstrata.
Portanto, como propriedade de rounding: 8 , o aplicativo Windows 10 converte para CornerRadius="8" , a web - border-radius: 8px , Android - android:radius="8dp" , iOS - self.layer.cornerRadius = 8.0 .
offsetTop: 12 OffsetTop offsetTop: 12 o mesmo cliente da Web pode ser interpretado em casos diferentes como top , margin-top , padding-top ou transform
A natureza declarativa da descrição também sugere que, se a plataforma for tecnicamente incapaz de usar qualquer propriedade ou seu valor, ela poderá ignorá-la. Em termos terminológicos, criamos um tipo de linguagem esperanto: pegamos algo do Android, alguns do SVG, outros do CSS.
Se for necessário exibir elementos de uma maneira diferente em uma plataforma específica, implementamos a capacidade de transferir a geração de dados correspondente como um arquivo JSON separado. Por exemplo, o estado está "em foco" para a Smart TV, dita uma alteração na posição do texto sob o pôster, portanto, para esta plataforma, este componente no valor da propriedade "recuo" conterá os 8 pontos de recuo necessários. Embora isso complique a infra-estrutura do sistema de design, oferece um grau adicional de liberdade, deixando-nos a oportunidade de gerenciar a “dissimilaridade” visual das plataformas, e não ser reféns da arquitetura que criamos.
Pictogramas
A iconografia em um produto digital é sempre um subprojeto volumoso e não o mais fácil, geralmente com um designer separado. Sempre existem muitos glifos, cada um deles com vários tamanhos e cores; além disso, as plataformas precisam deles, como regra em diferentes formatos. Em geral, não havia razão para não trazer tudo isso para o sistema de design.
Os glifos são carregados no formato SVG vetorial e os valores das cores são substituídos automaticamente por variáveis. Os aplicativos clientes podem prepará-los para uso - em qualquer formato e cor.
Pré-visualização
Além do JSON com dados, escrevemos uma ferramenta para visualizar componentes - um aplicativo JS que transmite dados JSON por meio de seus geradores de marcação e estilo em tempo real e exibe várias variações de cada componente no navegador. De fato, a visualização é exatamente o mesmo cliente que os aplicativos da plataforma e funciona com os mesmos dados.
É mais fácil entender como um componente específico funciona, interagindo com ele. Portanto, não usamos ferramentas como o Storybook, mas fizemos uma visualização interativa - você pode tocar, passar o mouse, clicar ... Quando você adiciona um novo componente ao sistema de design, ele aparece na visualização para que as plataformas tenham algo em que se concentrar ao apresentá-lo.
A documentação
Com base nos dados fornecidos no formato JSON para as plataformas, a documentação do componente é gerada automaticamente. A lista de propriedades e os possíveis tipos de valores em cada um deles são descritos. Após a geração automática, as informações podem ser esclarecidas manualmente, adicione uma descrição de texto. A visualização e a documentação são fornecidas com referências cruzadas entre si no nível de cada componente e todas as informações que caem na documentação estão disponíveis para os desenvolvedores na forma de arquivos JSON adicionais.
Deprecator
Outra necessidade era a capacidade de substituir e atualizar os 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 do cliente
Sem dúvida, a interpretação dos dados do sistema de design no código de todas as plataformas suportadas por nós se tornou o estágio mais extenso da complexidade. Se, por exemplo, grades modulares na Web não são novas, os desenvolvedores de aplicativos móveis nativos para iOS e Android suaram bastante antes de descobrir como viver com ela.
Para o layout das telas de aplicativos iOS, usamos dois mecanismos básicos que o iviUIKit fornece: layout gratuito de elementos e layout de coleções de elementos. Usamos o 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 organização dos elementos são especificados em termos de colunas e construções sintáticas trabalhando sobre as constantes nativas do SDK do iOS, tornando-as mais aplicadas. Isso simplificou especialmente nossa vida ao trabalhar com o UICollectionView. Escrevemos alguns layouts personalizáveis para layouts, incluindo os bastante complexos. O código do cliente ficou mínimo e se tornou declarativo.
Para gerar estilos no projeto Android, usamos Gradle, transformando os dados do sistema de design em estilos de formato XML. Ao mesmo tempo, temos vários geradores de vários níveis:
- Basic . Analisando dados de primitivos para geradores de nível superior.
- Recurso . Faça o download de fotos, ícones e outros gráficos.
- Componente Eles são escritos para cada componente, que descreve quais propriedades e como converter em estilos.
Versões de aplicativos
Depois que os projetistas desenham um novo componente ou retrabalham um existente, essas alterações caem no sistema de design. Os desenvolvedores de cada plataforma estão finalizando sua geração de código, fornecendo suporte para alterações. Depois disso, ele pode ser usado na implementação de novas funcionalidades, onde esse componente é necessário. Portanto, a interação com o sistema de design não ocorre em tempo real, mas apenas no momento da montagem de novos lançamentos. Essa abordagem também permite controlar melhor o processo de transferência de dados e garante o desempenho do código em projetos de desenvolvimento de clientes.
Sumário
Logo, como um sistema de design, um ano se tornou parte da infraestrutura que atende ao desenvolvimento do cinema on-line Ivy, e algumas conclusões já podem ser tiradas:
- Este é um projeto grande e difícil de implementar, que exige recursos alocados 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 visual e funcionalmente atrasadas.
Visualizar os componentes do sistema de design Ivy -
design.ivi.ru