Ainda precisamos nos preocupar com “Pixel Perfection”?

Quando foi a última vez que você ouviu o termo Pixel Perfection (ou Perfeição de Pixel)? Dependendo de para quem (e com quem) você trabalha, a última vez pode variar de hoje até anos atrás.

Grosso modo, “Pixel Perfection” (às vezes, “Pixel Perfect”) é um termo cunhado por designers e clientes que solicitam que seus mockups reflitam o planejamento visual perfeitamente, sendo uma espécie de cópia exata dele.

Mas, depois de todos esses anos de desenvolvimento Web, ainda precisamos nos preocupar com pixel perfection?

Ao comparar o antigo cenário da Web com o atual, é possível ter uma idéia sobre o que mudou ao longo dos anos e por que precisamos rejeitar a ideia de pixel perfection.

Afinal, o que é Pixel Perfection?

Pixel Perfection é o processo de implementação de um wireframe/mockup de um projeto Web em HTML e CSS, levando em consideração que o resultado codificado deve ser uma correspondência exata desse wireframe ou mockup — para saber a diferença entre ambos, leia nosso artigo específico sobre o tema.

Considere a seguinte figura:

Como exercício didático, imagine que o design original foi criado no aplicativo Sketch e sua respectiva implementação do código está sendo visualizada no navegador Google Chrome.

Conseguiu perceber alguma diferença entre eles?

• A altura do cabeçalho;
• Espaçamentos internos (paddings) do cabeçalho;
• O espaçamento abaixo do cabeçalho;
• Número de cards por linha.

Tais diferenças podem afetar o resultado final, que pode ser considerado por alguns como uma implementação imperfeita. Mas é mesmo imperfeito? Essa questão será respondida mais à frente.

O cenário Web em 2010

O iPhone 4 foi lançado pela Apple em 7 de junho de 2010. Segundo o statista, o número de smartphones vendidos em 2010 foi de 296,65 milhões de dispositivos. Em 2020, (por enquanto) o número é de 1,56 bilhões!

Em 2010, podia ser bom para um designer ou cliente solicitar que o design fosse uma implementação perfeita de pixels. O número de laptops era bem menor do que temos agora, e o iPad acabara de ser lançado.

O número de tamanhos de tela que um desenvolvedor devia levar em conta não era grande. O design de um único desktop de dimensões 1024×768 podia ser mais do que suficiente.

Mas a dura realidade é que isso não pode ser feito hoje em dia devido à grande quantidade de dispositivos (e diferentes tamanhos de viewport) disponíveis.

Para resumir a coisa, pixel perfection foi possível até 2010 devido à gama de dispositivos disponíveis até então. Mas com os (literalmente) milhares de dispositivos que temos hoje (smartwatches, telefones, tablets, laptops, desktops, TVs), a perfeição de pixels não tem como funcionar conforme o esperado — e é até ingenuidade pensar que não seja assim.

Pixel perfection e Look & Feel

Existe o termo em inglês look & feel que, no contexto de web design, seria como um site se parece em termos de UI (look) e qual(is) sensação(ões) ele transmite em termos de funcionalidade e interatividade (feel).

Antes de mais exemplos serem mostrados, veja as 2 figuras a seguir. O primeiro representa o YouTube; o segundo, um ajuste de look&feel para tentar fazê-lo parecido como o Twitter.

As mudanças foram:

• Background do header e sombras;
• Campo de busca;
• Iconografia;
• Cor primária.

Essas pequenas mudanças podem passar despercebidas se você não estiver focado o suficiente… E aqui começa a ficar mais claro o que realmente é look & feel.

Vamos a exemplos mais detalhados.

Considere a figura a seguir, que mostra vários componentes para um site.

Alguns sentimentos/percepções (feel) que podem ser suscitados ao olhar para esses componentes podem ser:

• Tipografia arrojada e incomum;
• Cores modernas e chamativas;
• Muitos componentes têm sombra;
• Uso sistemático de cantos arredondados.

Consideremos o componente de Card como exemplo para mostrar uma implementação boa e ruim.

Notou as diferenças entre ambos? Vamos explorar isso.

1. A espessura da borda é diferente;
2. Marcador de dificuldade mais próximo da lateral;
3. Altura da imagem é menor;
4. Tamanhos de fonte diferentes;
5. Raio de borda (border-radius) diferente.

As diferenças acima afetaram significativamente o resultado e são apenas para um componente, o Card. Seu amigo desenvolvedor pode dizer que essas diferenças são sutis e não importam.

Para 1 componente, isso pode estar correto. No entanto, você pode imaginar essas mudanças sutis em larga escala? Eventualmente, você acabará implementando um resultado imperfeito.

Veja as diferenças lado-a-lado:

Se você for o UI Designer desses componentes, dificilmente vai ignorar essas diferenças. O motivo é que você trabalhou duro no espaçamento, tamanhos e alinhamento. Além disso, as diferenças acima não são impossíveis de corrigir — na verdade, essas correções são até simples.

Os motivos de um desenvolvedor cometer erros de UI e problemas de inconsistência podem variar, passando por:

• O design, em si;
• Cronograma do projeto;
• Habilidades de design e CSS;
• Boa atenção aos detalhes.

Provavelmente, a maioria dos desenvolvedores front end sabem como fazer essas correções para aproximar o resultado final do design original. Mas, talvez, esse tipo de discrepância também tenha a ver com mentalidade.

Quando o desenvolvedor conhecer design e desenvolvimento, geralmente é possível notar menos diferenças de design; se o desenvolvedor não possui habilidades de design, geralmente se espera que as diferenças sejam maiores.

Decidindo se um resultado de código é aceitável ou não

O cerne da questão é: como decidir se um resultado codificado é aceitável sem ser muito exigente?

E aqui entra a razão pela qual o conceito de look & feel foi explicado antes: Em vez de se buscar um resultado codificado perfeito, é possível almejar a concordância do look & feel do design.

Voltemos ao componente cartão, mas considerando diferenças aceitáveis.

As diferenças são sutis:

• Marcador de dificuldade menor (algo OK);
• Sem borda cinza.

Esses detalhes não importam muito e está tudo bem. O mais importante é concordar com o look & feel do design.

Se você é alguém que mexe com design e desenvolvimento front-end, provavelmente chega aquele momento em que você se pega dando aquele sorrisinho maroto: a hora de codar um design que você mesmo criou.

É o momento propício para ter 2 abas no navegador abertas:

1. O design original (como uma imagem) em um InVision ou Figma Preview da vida;
2. O ambiente de desenvolvimento da máquina (localhost).

Quando chega uma hora em que praticamente não se consigue diferenciar entre as 2 abas, o look&feel está ajustado e provavelmente o código ficou pronto.

Sendo que o termo “pronto” não quer dizer que as medidas exatas e larguras são 100% idênticas, mas o look & feel geral pode “enganar” alguém facilmente ao ficar alternando entre as abas.

Variações e contexto

No fim do dia, a largura de um componente pode variar dependendo do elemento do contêiner em que ele se encontra. Isso significa que um componente Card, por exemplo, pode ter diversas variações (assim como limitações).

Observe como a segunda variação ainda está relacionada à primeira. A aparência é semelhante; a única coisa que mudou foi que o display ficou na horizontal.

Por outro lado, um componente deve ter limitações que a equipe de design precisa comunicar ao time de desenvolvimento. Considere o seguinte:

Quando o componente Card ficou muito largo, a imagem também herdou esse aspecto. Para um site de culinária, a imagem da receita é muito importante e deve ficar clara com a maioria dos detalhes. Quando o cartão é muito largo, alguns detalhes podem ser cortados ou perdidos.

Pode não ser o caso para esse componente, em especial, mas o que se está querendo mostrar é que, quando um designer trabalha no design de sites, deve haver limitações. Ao fazer isso, é possível definir as expectativas para o resultado implementado sem muitas surpresas.

Cenário atual

O CSS se desenvolveu muito nos últimos 10 anos, oferecendo aos desenvolvedores muitas maneiras de implementar um determinado layout. Web design responsivo tornou-se padrão.

Ao trabalhar em um site responsivo, você não pode usar o termo pixel perfection; isso não faz sentido!

Pensar em termos de look & feel é mais lógico. Tem-se um certo estilo para o site e seu objetivo como dev front end é implementá-lo em diferentes tamanhos de tela com o estilo/look & feel.

CSS moderno

Nesta seção, veja algumas das técnicas modernas de CSS disponíveis atualmente, que permitem criar sites flexíveis e fluidos.

CSS Grid

Com CSS Grid sendo suportado já há alguns anos, temos uma ferramenta muito poderosa que pode ser facilmente usada para criar grids.

Com somente essas linhas de código, cria-se uma grid dinâmica que redimensiona os itens nela com base no espaço disponível.

Unidades de viewport

Dimensionar um elemento com base nas dimensões de viewport com CSS era um sonho há 10 anos atrás. Hoje, isso é possível graças às unidades de viewport.

Se não entendeu bem, leia nosso artigo mostrando unidades de CSS moderno.

Funções de comparação

As chamadas funções de comparação de CSS (não sei se é um nome oficial) são min(), max() e clamp().

Agora que elas já são suportadas em todos os principais navegadores, é possível usá-las para definir um valor mínimo e máximo para um componente, e isso pode mudar fluidamente, dependendo de uma regra específica.

Considere, por exemplo, a necessidade de se alterar o border-radius de um elemento em diferentes tamanhos de viewport.

O border-radius mínimo é 7px e o máximo é 20px. O valor médio 2vw é chamado de valor recomendado. Quando a largura da viewport é redimensionada, o border-radius muda de acordo.

Inclusive, já mostramos outros usos de clamp(), para fazer grids intrinsecamente responsivas, textos responsivos e mais.

As técnicas CSS mostradas acima são apenas algumas das que temos hoje. Ao sumarizar as diferenças de 10 anos atrás até agora, poderia-se chegar a algo como:

Há uma tendência a se designs para tamanhos fixos de telas, esperando-se que sejam implementados por desenvolvedores com base em pixel perfect. Isso não é condizente às técnicas e mentalidade modernas que temos agora.

O efeito de frameworks CSS

Digamos que você é um designer e entregou um design completo de aplicativo; agora, a equipe de desenvolvimento deseja implementá-lo usando o famoso framework Bootstrap.

Depois de ver as primeiras páginas implementadas, você notará que alguns elementos/componentes herdaram detalhes de design do próprio Bootstrap.

Considere o exemplo a seguir, no qual se projetou um botão personalizado, e o outro é a implementação codificada.

Alguns desenvolvedores julgariam que não há problema em ignorar os detalhes originais do design do botão, alterando somente o background e usando os estilos de hover e focus do Bootstrap.

Mesmo que sejam considerados meros detalhes, eles podem diferenciar um site de outro. É fácil personalizar esses estilos, mas nem sempre fica claro o motivo de se ignorar esses detalhes. Preguiça, talvez? Ou o designer não forneceu estados suficientes para os componentes?

Só para esclarecer, o uso de frameworks não é uma coisa ruim, em si. Se eles funcionam em determinado projeto, tudo bem. O mais importante é a capacidade de personalizá-los e usá-los de acordo com as necessidades atuais, sem deixar de fora os pequenos detalhes.

Não se trata de escolhas, mas de expectativas

Atuando como designer, quando você define um espaçamento de 32px entre um componente e outro, é muito claro e óbvio. Alguns desenvolvedores usam 30px por motivos vários e também está tudo bem.

Se um desenvolvedor obtém os recursos e medidas do projeto, o que o impede de fazer seu trabalho conforme o esperado?

Sem querer colocar lenha nessa fogueira, mas há, também, casos em que o codificador identifica inconsistência e/ou falhas no planejamento visual e, por sua conta, faz correções por conta (com as melhores intenções, obviamente).

Dicas gerais para designers

Faça espaçamentos e tamanhos consistentes

Não é justo ser muito exigente com resultados de codificação do design entregue e, ao mesmo tempo, não dar muita atenção a espaçamento e tamanhos.

Consistência é muito importante. Aqui está um exemplo que pode confundir um desenvolvedor front-end.

Por que o espaçamento é inconsistente?! Acredite, esse problema acontece com muita frequência — você mesmo já deve ter passado por isso.

É confuso e desorientador para um desenvolvedor front-end receber este tipo de material, além de um potencial desperdiçador de tempo. Lembra que comentamos há pouco que, às vezes, é mais prático o próprio desenvolvedor dar seu jeito?

Lembre-se de planejar estados de componentes

Um componente pode ter muitos estados. O desenvolvedor precisa saber sobre todos eles, enquanto um designer pode entregar apenas em uma versão.

Um exemplo disso é um cabeçalho de site. O designer pode entregar a versão mobile e desktop e pensar que isso é suficiente.

Mas e quanto ao estado intermediário? Em outras palavras, como o cabeçalho deve ficar entre o tamanho pequeno e grande?

No cenário brasileiro de desenvolvimento Web isso é muito, muito comum — infelizmente, talvez seja a situação comum de entregas de design e planejamento visual de componentes…

Use conteúdo real (e preveja diferentes cenários)

Se um designer quiser fazer um desenvolvedor feliz, então deve usar conteúdo real e contemplar no planejamento visual o que deve acontecer caso haja textos de tamanhos além do normalmente esperados.

No exemplo acima, o nome da pessoa é longo. Como o design deve lidar com isso? Ele deve quebrar em uma nova linha ou truncar o texto? Fornecer essas decisões previamente ajuda bastante e evita retrabalhos.

Se você, como designer, tiver dúvidas sobre algo em que está trabalhando, pergunte ao cliente, ao desenvolvedor ou a qualquer responsável por isso. Não mantenha as dúvidas até o final do projeto; quanto antes você se comunicar, melhor para todos os envolvidos no projeto.

Dicas gerais para desenvolvedores

Saiba considerar cenários para tomar decisões

Na hora do código, desenvolvedores precisamos decidir sobre como criar determinados componentes.

Considere o seguinte:

O designer forneceu um botão com uma altura de 45px. Como você o implementaria?

Não é incomum fazer algo como:

Usar um valor fixo, nesse caso, não está correto. Em vez disso, é possível usar padding vertical ou min-height para fazer com que o botão tenha a altura calculada de 45px.

É mais sobre pensamento e mentalidade (e experiência) do que fazer valores de pixel iguais.

Treine seu olho para prestar atenção aos detalhes

Pode ser um processo não muito rápido, mas é possível se treinar para capturar pequenos detalhes de UI; treinar-se a si mesmo pode ajudá-lo a melhorar muito.

Algumas idéias:

• Clone uma interface de um site popular como o Twitter, por exemplo, e tente torná-lo o mais próximo possível (certifique-se de obter feedback de terceiros sobre a precisão);
• A pratica leva à perfeição, então, quanto mais você implementa projetos em HTML e CSS, mais seus olhos aprendem sobre detalhes;
• Jogue Can’t Unsee, um jogo divertido que desafia o conhecimento de detalhades de UI.

Use réguas diretamente no navegador

A verificação de alinhamentos direto pelo navegador ainda não é um recurso oferecido por padrão. Felizmente, é possível usar algumas extensões para isso, como Grid Ruler para Chrome e para Firefox.

Observe como o capo de busca não está alinhado com o avatar. A razão pode ser uma margem ou padding desnecessário.

Seja qual for o motivo, nem todos percebem esse problema de primeira; se você conseguir, certamente será um diferencial.

Conclusão

Pela perspectiva do desenvolvimento Web moderno, pixel perfection está morto e não é mais relevante.

Em vez disso, recomenda-se o uso consistente de dimensionamentos e espaçamentos e em manter o look & feel conforme o planejamento visual.