Hoje o Figma praticamente domina o mercado de Aplicativos de Interface de Design Web, mas existem inúmeros aplicativos muito bons por aí onde todos visam que o seus Layouts espelhem 100% ao que será desenvolvido seja para Web ou Mobile, só que existe uma coisa em comum que nenhuma delas faz que é espelhar 100% do que é possível ser feito em HTML e CSS (todas menos o Webflow, mas é polêmico o assunto). Sabendo que nem toda ferramenta consegue simular 100% do código, como podemos reduzir essa discrepância?
Por outro lado existe também uma grande maioria de pessoas que criam interfaces para dispositivos (Web e Mobile) entendendo pouquíssimo (ou quase nada) do que pode ser feito no final do código, sendo assim…
…como podemos criar layouts se não sabemos como eles se comportam no código?
Atualmente sim é possível (necessário) criar layouts sem entender de HTML e CSS, porém, como dizia Charles Dickens “Uma vaga noção de tudo, e um conhecimento de nada” e é assim que no fim das contas acontece, o pouco conhecimento sobre o que o HTML e CSS pode limitar a entrega final para o desenvolvimento o que acaba se tornando uma briga onde um lado (dev) fala que a entrega não foi detalhada corretamente e o outro lado (design) fala que o layout não foi implementado da forma que foi desenhado.
Agora voltando um pouco no passado quando comecei a trabalhar com Design em Janeiro de 2006, o Designer fazia Layout e “recortava” o HTML e CSS também, aprendi da pior (ou melhor) forma possível como o código funcionava, entrei em um time de Sustentação que era o time responsável por arrumar os Bugs de toda a fábrica de software (simples assim), naquela época não existia o Inspecionar código dos browsers, era o Internet Explorer 6 e tínhamos que abrir o código e inserir borda vermelha em todo CSS e alerts nos JavaScripts. Era mais ou menos assim e se não funcionasse era só colocar !important no fim do css.
Contudo em 2008 quando comecei a trabalhar na SKY eu já tinha um entendimento de como o Designer e o Desenvolvedor deveriam trabalhar e até hoje eu penso exatamente igual, seria algo assim:
O Tiago Goncalves e a Tamires Dias não me deixam mentir, o trabalho era lado a lado e sabíamos que era importante o compartilhamento mas não era saudável se aprofundar muito, então desenvolvemos um padrão de que um deveria conhecer minimamente como o outro lado funcionava.
Tentando resolver o problema
Como podemos pensar em um estudo de acordo com a sua necessidade ou carreira tendo em vista que existem muitos cargos que podem exigir mais ou menos desse entendimento, pensando nisso, criei uma categorização do tema onde podemos facilmente entender seus níveis e em que momento podemos aplicar cada etapa da sua carreira:
- Semântico (Estruturação de Layouts)
- Responsivo (Prototipação com Multi-Resoluções)
- Interativo (Animações, Micro Interações, UX Motion)
1 – Semântico
Essa etapa é voltada para quem trabalha mais com desenho de telas a nível de interface sem se aprofundar em interações ou componentes.
Entender a semântica do código ajudará você a nomear suas layers de acordo com a vocação da Tag HTML, elevando demais a entrega de seus layouts para o time de desenvolvimento.
Abaixo temos 2 exemplos, o primeiro uma estrutura de layout de dashboard com as áreas de conteúdo nomeadas, logo a seguir uma estrutura de Card com os elementos internos bem nomeados para facilitar assim a identificação dos itens.
Agora pense em como seria uma entrega desse mesmo layout sem semântica? Indo mais além, imagine isso em um fluxo de 50 páginas?
Claro que nem sempre é possível detalhar cada elemento do seu layout, mas quanto mais ele estiver organizado melhor será o seu conhecimento semântico porque com o tempo você evoluirá essa parte e também seu handoff será melhor e o reuso das suas telas e componentes em outros fluxos terá muitos ganhos.
Pontos positivos para um site semântico
O uso de HTML Semântico contribui para que os motores de busca (SEO) consigam interpretar melhor o conteúdo e o contexto das informações presentes nas páginas e dessa forma posicione melhor sua página em buscadores. Exemplo:
https://www.oncrawl.com/technical-seo/page-content-html5-tags/
Resultado foi um crescimento de +30% de visitas e isso é só o começo do que pode ser feito.
2 – Responsivo
Essa etapa acredito que seja interessante detalharmos 2 formatos que são muito confundidos dentro dos layouts, o Media Query (Breakpoints) e o Container Query, ambos trabalham o comportamento do elemento de acordo com alguma dimensão acima deles. Exemplo de suas aplicações abaixo:
Precisamos identificar a forma de uso de cada um para conseguirmos criar experiências ricas e personalizadas de acordo com o momento mais adequado para a tela ou para o elemento.
2.1 – Breakpoints (Media query)
Media Query: Recurso do CSS 3 que permite que a renderização do conteúdo se adapte a diferentes condições de resolução da tela. Tornou-se um padrão recomendado pelo W3C em junho de 2012.
Quando trabalhamos tipos de largura de tela usamos os Breakpoints da página que são configurados pelos Media Queries para que possamos adaptar nosso conteúdo de acordo com a largura da janela do navegar, essa parte é muito importante pois podemos alterar praticamente TUDO de uma tela a cada Breakpoint da página, desde posicionamentos, larguras, cores, efeitos, tudo.
Extra: Se utilizarmos Javascript podemos aumentar o leque de opções de uso (window.outerWidth, window.innerWidth, window.outerHeight e window.innerHeight) conforme imagem abaixo:
2.2 – Container Query – Largura (ou dimensão) do elemento pai
Container query: Os recursos de largura de containers permitem aplicar estilos a um elemento com base no tamanho do contêiner do elemento, ou seja, podemos alterar outros estilos dentro de um Container Query. Não é a largura da página e sim a largura do elemento pai conforme abaixo:
Como é o código em CSS?
@container (min-width: 500px) {
.card {
grid-template-columns: 1fr 2fr;
grid-template-rows: auto 1fr;
align-items: start;
column-gap: 20px;
max-width:100%;
}
}
Outro exemplo:
Contudo nem tudo são flores, nem todas ferramentas conseguem automatizar essas regras, então a imagem acima mostra possibilidades onde a configuração vai de acordo com a aplicação e suas regras de uso em tempo real, com isso, tanto o Breakpoint quanto o Container Query devem documentados no Handoff do componente ou na entrega do layout onde se aplica a regra.
Seria maravilhoso se essas regras fossem automatizadas no Figma em um futuro não? Tomara que isso chegue um dia (sonho).
3 – Interativo
Trabalhar com UX Motion e Micro Interações de um componente ou tela requer uma visão ampla de animações e noção de mínimos e máximos, nem toda interação cabe em determinado lugar e para que a animação seja fluída, padronizada e faça sentido com o contexto é importante conhecermos a fundo todas possibilidades de aplicação e suas limitações técnicas.
Micro Interações
São movimentos ou animações de elementos onde podem transformar uma tarefa simples em uma experiência significativa, saindo do simples estático que antes poderiam ser despercebidos para movimentos impactantes.
Exemplo de micro-interações:
E como as micro-interações são aplicadas? Esse é um cenário amplo que vale até outro artigo, mas em Resumo na maioria dos casos ela é feita (hoje em dia) via Json, mas já foi feito muito no passado com Gif e CSS.
UX Motion
As animações e transições de UX Motion ajudam a guiar o uso de telas e fluxos tornando a experiência do usuário mais agradável e com propósito. Mas o Motion como conhecemos hoje feio de outra área mais conhecida como Motion Graphics, também conhecido como motion design, videografismo ou design de animação, é uma técnica de design gráfico que mescla princípios de design, animação, vídeo e cinema, gerando um grande impacto visual.
Abaixo os 12 princípios de UX Motion mais conhecidos:
Já no Motion, diferente de Micro-interações, podemos usar outros recursos como CSS, Javascript, Jquery e até Json se for o caso de uma animação de elemento de ilustração. Abaixo alguns exemplos reais de UX Motion:
Mas o que UX Motion e Micro-Interações estão fazendo aqui nesse artigo de HTML e CSS? No final das contas mesmo que o processo seja feito em outras ferramentas, o resultado final será aplicado em código e é muito importante conhecer as limitações do código para que a aplicação da animação seja fluída e não seja uma dor de cabeça para o time técnico. Já vi muito processo ser feito e no final não ser possível a aplicação por falta de conhecimento final da aplicação, como também já vi muito projeto sendo aplicado da forma errada e ao invés de melhorar a experiência piorar.
Uma dica em Motion é: Saiba pesar a mão e converse com o time de desenvolvimento. Não tente aplicar todo o seu conhecimento em uma única tela, seja simples.
HTML e CSS – Conclusão:
Quer trabalhar com UI ou Design System e se destacar? Abra sua mente para o código. Aprender linguagem de formatação e animação te trará uma nova visão de como tudo funciona além de te dar mais força para interagir com o time técnico (desenvolvedores), no final os times de desenvolvimento são seus parceiros de time e não o time concorrente.
Me sigam nas redes sociais:
Bruno Biagioni Neto
De 0 a 10, o quanto você recomendaria este artigo para um amigo?