Decisões do desenvolvedor para construir componentes flexíveis

No mundo real, o conteúdo geralmente difere muito do conteúdo organizado e perfeitamente adequado apresentado nos designs. Além disso, na web moderna, os usuários têm uma gama cada vez maior de opções de como acessam os sites que construímos.

Neste artigo, abordaremos o processo de fazer um design aparentemente simples para um componente de texto e mídia e decidir a melhor forma de traduzi-lo em código, tendo em mente as necessidades dos usuários e dos autores de conteúdo. Não vamos nos aprofundar em como codificá-lo - em vez disso, nos fatores que determinarão nossas decisões de desenvolvimento. Consideraremos as perguntas que precisamos fazer (tanto a nós mesmos quanto a outras partes interessadas) em cada etapa.

Mudando nossa mentalidade de desenvolvimento

Simplesmente não podemos mais projetar e desenvolver apenas para conteúdo ou condições de navegação “ótimas”. Em vez disso, devemos abraçar a flexibilidade e imprevisibilidade inerentes da web e construir componentes resilientes. Mockups estáticos não podem atender a todos os cenários, então muitas decisões de design cabem aos desenvolvedores no momento da construção. Goste ou não, se você é um desenvolvedor de interface do usuário, você é um designer - mesmo que não se considere um!

Em meu trabalho na agência da web especializada em WordPress Atomic Smash , criamos sites para clientes que precisam de flexibilidade máxima dos componentes que fornecemos, garantindo que o site ainda tenha uma ótima aparência, independentemente do conteúdo que eles lançam nele. Às vezes, interpretar um design significa pedir ao designer para elaborar melhor suas ideias (ou até mesmo reavaliá-las). Outras vezes, significa tomar decisões de design em tempo real ou fazer recomendações com base em nosso conhecimento e experiência. Veremos algumas das vezes em que essas abordagens podem ser apropriadas neste estudo de caso.

O design

Começamos com um design simples para um componente de texto e mídia – algo bastante comum nas páginas de destino dos produtos. Consiste em uma imagem ou vídeo à esquerda e uma coluna à direita contendo um título, um parágrafo de texto e um link de chamada para ação. Este design é para uma startup (fictícia) que ajuda pessoas que desejam aprender uma nova habilidade a encontrar um tutor.

Nota: Se você quiser pular direto para o código e ver todas as soluções possíveis que encontramos para este componente, você pode encontrá-lo nesta demonstração do Codepen.

Esquema e Ordem

O designer estipulou que todos os outros componentes devem ter o layout invertido para que a imagem fique à direita e a coluna de texto à esquerda.

No layout móvel, no entanto, a imagem é empilhada acima do conteúdo do texto em todos os casos. Supondo que construímos esse layout usando Grid ou flexbox, poderíamos usar flex-direction ou a propriedade order para reordenar o layout para cada segundo componente:

 .text-and-media:nth-child(even) { flex-direction: row-reverse; }

Vale a pena ter em mente que, embora isso reordene o conteúdo visualmente, isso não altera a ordem do DOM. Isso significa que para uma pessoa com deficiência visual navegando no site usando um leitor de tela, a ordem do conteúdo pode não parecer lógica, pulando da esquerda para a direita para a direita para a esquerda.

Falando pessoalmente, no caso em que o único conteúdo em uma das colunas é uma imagem, sinto que usar a propriedade order é mais ou menos correto. Mas se tivéssemos duas colunas de texto, por exemplo, reordenar com CSS pode tornar a experiência confusa. Nesses casos, temos algumas outras opções disponíveis para nós. Poderíamos:

1. Apresente nossas preocupações de acessibilidade e recomende que, para layouts móveis, a ordem visual seja alterada para corresponder à ordem da área de trabalho.
2. Use Javascript para reordenar os elementos no DOM.

Também precisamos considerar se devemos impor a ordem por meio do seletor :nth-child ou permitir que o cliente controle a ordem (adicionando uma classe ao componente, digamos). A adequação de cada opção provavelmente dependerá do projeto.

Lidando com diferentes tamanhos de conteúdo

No design, a proporção do conteúdo do texto em relação à imagem é bastante agradável. Ele permite que a imagem mantenha uma proporção ideal. Mas o que deve acontecer se o texto for mais longo ou mais curto do que o apresentado? Vamos lidar com o primeiro primeiro.

Conteúdo mais longo

Podemos definir um limite de caracteres no campo de texto em nosso CMS escolhido (se quisermos), mas devemos permitir pelo menos alguma variação em nosso componente. Se adicionarmos um parágrafo mais longo, a coluna de mídia oposta pode se comportar de várias maneiras:

1. A imagem ou vídeo permanece no topo, enquanto o espaço é adicionado abaixo (fig. 1).
2. A imagem ou vídeo é centralizado, adicionando espaço na parte superior ou inferior (fig. 2).
3. As proporções da imagem ou vídeo são dimensionadas para corresponder à altura, usando object-fit: cover para evitar distorções e garantir que a imagem preencha o espaço disponível. Isso significaria que algumas partes da imagem podem ser cortadas (fig. 3).

Decidimos que a opção 3 era a mais agradável visualmente e que, na maior parte, os autores de conteúdo seriam capazes de obter imagens apropriadas onde uma pequena quantidade de recorte seria aceitável. Mas apresentou mais um desafio para o conteúdo de vídeo, onde há mais risco de partes importantes serem cortadas. Descobrimos outra opção, que era criar uma variação diferente do design onde o vídeo mantivesse sua proporção original e ficasse dentro de uma largura máxima em vez de se alinhar à borda da página.

Os autores de conteúdo podem escolher essa opção quando melhor atendesse às suas necessidades.

Além disso, optamos por estender essa opção para instâncias em que uma imagem foi usada em vez de um vídeo. Ele oferece ao cliente uma variedade maior de opções de layout sem afetar negativamente o design. Visto no contexto mais amplo da página, pode até ser considerado uma melhoria, permitindo páginas mais interessantes quando vários desses blocos são usados ​​em uma página.

Conteúdo mais curto

Lidar com menos conteúdo é um pouco mais simples, mas ainda nos apresenta alguns problemas. Como a imagem deve se comportar quando o conteúdo do texto é menor? Deveria ficar mais raso, de modo que a altura total do componente seja determinada pelo conteúdo do texto (fig. 4)? Ou devemos definir uma proporção mínima, para que a imagem não fique com o formato letterbox ou permita que a imagem ocupe sua altura natural e intrínseca? Nesse caso, também temos a consideração de alinhar o texto no centro ou no topo (fig. 5 e 5a).

Comprimento do título

Não vamos esquecer que também precisaremos testar títulos de diferentes comprimentos. No design, os títulos são curtos e rápidos, raramente envolvendo uma segunda linha. Mas e se um título tiver várias linhas ou o conteúdo usar muitas palavras longas, resultando em quebra de texto diferente? Isso pode ser especialmente um problema em idiomas como o alemão, onde as palavras tendem a ser muito mais longas que o inglês, por exemplo. O tamanho da fonte do cabeçalho no design permite um comprimento de linha apropriado quando usado neste layout? As palavras longas devem ser hifenizadas quando se envolvem? Este artigo de Ahmad Shadeed aborda a questão do tamanho do conteúdo e inclui algumas dicas úteis sobre como lidar com isso em CSS.

Os autores de conteúdo podem omitir completamente um título quando lhes for conveniente? Isso nos leva à próxima consideração.

Omitindo conteúdo

Construir esse componente da forma mais flexível possível significa garantir que os autores de conteúdo possam omitir determinados campos e ainda ter a aparência do design e funcionar corretamente. Parece razoável que o cliente queira omitir o corpo do texto, o link ou mesmo o título ao usar esse componente em estado selvagem. Precisamos ter o cuidado de testar com todas as combinações concebíveis de conteúdo, para que possamos ter certeza de que nosso componente não quebrará sob estresse. É uma boa prática garantir que não estamos renderizando tags HTML vazias quando o conteúdo do campo não estiver presente. Isso nos ajudará a evitar erros de layout imprevistos.

Podemos restringir os autores de conteúdo com campos “obrigatórios” no CMS, mas talvez também possamos considerar cenários em que um cliente pode optar por omitir a imagem ou, inversamente, sem nenhum conteúdo de texto? Pode ser útil fornecer-lhes essas opções. Aqui está um exemplo de como podemos optar por renderizar o componente nesses casos:

Ao recuar um pouco mais o texto e aumentar a largura do corpo do texto, podemos mantê-lo equilibrado, mesmo quando não há imagem.

Vários links

Omitir conteúdo é um cenário. Mas no Atomic Smash, descobrimos que, com mais frequência, os clientes queriam a opção de adicionar mais de um link ao componente. Isso nos apresenta outra opção: como fazer o layout de vários links? Colocamos lado a lado (fig. 8) ou empilhamos verticalmente (fig. 8a)?

Como lidamos com títulos de links de comprimentos muito diferentes? Um bom truque é definir as larguras de ambos os links para a largura máxima do mais longo (fig. 9). (Este artigo aborda exatamente isso.) Isso funciona bem para botões empilhados verticalmente, enquanto colocá-los horizontalmente nos apresenta ainda mais opções (fig. 9a).

Precisamos de um estilo de link secundário, para diferenciá-los? Todas essas são questões a serem consideradas.

Também podemos precisar considerar (no caso de um único link) se, de fato, a área clicável do link deve abranger todo o componente — para que os usuários possam clicar em qualquer lugar para ativar o link. Essa escolha talvez dependa do contexto mais amplo. Certamente é comum em UIs baseadas em cartão.

Vídeo

Quando o componente é usado para vídeo em vez de uma imagem estática, podemos notar que o design omite algumas informações importantes. Como a reprodução de vídeo é controlada? Em foco? Ele roda automaticamente no scroll? Deve haver controles visíveis para o usuário?

Se o vídeo for reproduzido em foco, devemos considerar como o usuário de um dispositivo sem recursos de foco acessa o conteúdo do vídeo. Alternativamente, se o vídeo for reproduzido automaticamente, devemos considerar a prevenção disso para usuários com preferência por movimento reduzido, que podem sofrer de distúrbios vestibulares (ou simplesmente desejam evitar animações chocantes). Também devemos fornecer uma maneira de todos os usuários interromperem o vídeo quando quiserem.

Colocando em Contexto

Um problema em focar tão de perto nos componentes quando se trata de web design é que às vezes nos esquecemos de considerar como os componentes que construímos aparecerão no contexto da página geral da web. Precisaremos considerar o espaçamento, tanto entre componentes do mesmo tipo quanto em um layout de página onde outros componentes são intercalados.

Esses componentes de texto e mídia são projetados para serem usados ​​com moderação, criando um toque de cor atraente e uma quebra de um layout linear. Mas usando o WordPress, um autor de conteúdo pode facilmente decidir construir uma página inteira composta apenas por esses componentes. Isso pode acabar parecendo um pouco maçante, e não o efeito que esperávamos!

Durante o processo de construção, decidimos adicionar uma opção para omitir a cor de fundo. Isso nos permite dividir a página e torná-la mais interessante:

Poderíamos impor um padrão usando :nth-child ou adicionar um campo no CMS para dar ao cliente mais controle criativo.

Embora isso não fizesse parte do design original, mostra que uma linha aberta de comunicação entre designer e desenvolvedor pode ajudar a criar melhores resultados em termos de designs mais flexíveis e robustos.

Estilos de texto WYSIWYG

Ao considerar o conteúdo, precisamos considerar não apenas o comprimento do texto, mas os elementos HTML reais que podem ser permitidos no campo de texto do corpo. Os autores de conteúdo podem querer adicionar vários parágrafos, links de âncora, listas e muito mais ao corpo do texto. Na Atomic Smash, gostamos de fornecer um campo WYSIWYG (What You See Is What You Get) ou rich text para essas áreas, que pode permitir muitos elementos diferentes. É importante testar com diferentes tipos de conteúdo e estilizá-lo adequadamente — incluindo testar o contraste de cor suficiente em todas as cores de fundo usadas.

Empacotando

Tocamos em muitas decisões diferentes envolvidas na construção desse componente aparentemente simples. Você pode até pensar em alguns outros que não abordamos aqui! Ao considerar todos os aspectos do design e como ele pode ser usado no contexto, acabamos com algo muito mais versátil, o que esperamos resultar em clientes mais felizes!

Às vezes, quanto mais omitido de um projeto, mais tempo e atenção serão necessários de um desenvolvedor. Eu montei uma lista de verificação abaixo de coisas para testar e questionar ao construir um componente, que você pode achar útil. Pode ser adaptado para diferentes componentes também.

Ser capaz de olhar além da aparente simplicidade, dividir um componente em suas partes constituintes, fazer perguntas-chave (mesmo antes de qualquer desenvolvimento) e até mesmo considerar usos futuros, são habilidades que servirão bem a qualquer desenvolvedor ao criar sites - e irá ajudá-lo a fornecer estimativas muito mais precisas quando necessário. A boa comunicação da equipe e um forte processo colaborativo são inestimáveis ​​para a construção de sites resilientes, mas o resultado final faz com que valha a pena investir no cultivo dessa cultura. Vamos incorporar a flexibilidade em nossos processos de design e construção.

A Lista de Verificação

Coisas para testar:

1. Acessibilidade do layout (mobile e desktop).
2. Imagens de diferentes proporções intrínsecas — elas são cortadas adequadamente?
3. Corpo de texto mais longo e mais curto (incluindo vários parágrafos).
4. Título mais longo e mais curto (incluindo vários comprimentos de palavras).
5. Omitindo (diversamente) o título, corpo do texto, links e imagem.
6. Vários links (incluindo diferentes comprimentos de texto de link).
7. Acessibilidade do conteúdo de vídeo.
8. Conteúdo de texto WYSIWYG (incluir links, listas, etc. no corpo do texto).
9. Teste no contexto — inclua vários componentes (com diferentes opções de conteúdo), bem como outros componentes misturados no layout da página.