Categorias
Projetos

Traga de volta o design idiomático

Traga de volta o design idiomático

John Loeber faz parte da geração do software desktop. De Windows 95 a Windows 7, ele cresceu usando software majoritariamente offline em computadores operados com mouse e teclado, bem antes de tablets e smartphones.

Recentemente, tem sentido falta de uma parte específica daquela era: a consistência no design.

Este artigo fala sobre design idiomático, enfatiza a importância de interfaces homogêneas e sugere que algo importante foi perdido.

Idiomas de design

Suponha que se está fazendo login em um site, e ele pergunta: “deseja permanecer conectado?” Existem muitas formas pelas quais o site poderia pedir uma resposta: por exemplo, um campo de texto onde se digita “Sim” ou “Não”, ou um dropdown onde se seleciona “Manter-me conectado” ou “Desconectar-me ao fechar esta janela.”

Mas, na prática, sempre será um checkbox. Por quê?

Exemplo de interface com checkbox

O checkbox é um idioma de design: é um padrão tão comum que, como usuário, sabe-se como usá-lo sem pensar, e se alguém estivesse criando um site e precisasse fazer essa pergunta, também colocaria um checkbox sem pensar.

Para quem constrói e para quem usa, é um padrão de design no qual todos podem confiar.

Interfaces homogêneas

Um checkbox também é parte de uma interface. Ele é usado para interagir com um sistema fornecendo dados.

Interfaces são melhores quanto menos pensamento exigem: seja a interface um volante ou um formulário online, se é preciso gastar qualquer tempo descobrindo como usá-la, isso é ruim.

Ao interagir com muitas coisas, o ideal são interfaces homogêneas que proporcionem experiências consistentes. Se Command + C é o atalho de teclado para copiar, espera-se que funcione em todos os lugares.

Ninguém quer ter que lembrar de usar CTRL + Shift + C em certas circunstâncias ou clicar com botão direito → copiar em outras. Isso seria irritante.

Ilustração de consistência de atalhos de teclado

Mas é exatamente onde se chegou… O software está na internet agora, e as interfaces não são homogêneas de forma alguma.

Existem centenas de maneiras pelas quais diferentes sites pedem para escolher datas, digitar o número do cartão de crédito ou realizar qualquer quantidade de tarefas comuns. Atalhos de teclado diferem de app para app.

Há tantas formas diferentes de interação que não é possível lembrar ou aprendê-las todas.

Usar aplicações web atualmente é um exercício de “onde encontro o que quero fazer?” repetidamente.

John Loeber @johnloeber

É curioso que inserimos dados de cartão de crédito na internet há mais de 20 anos, e ainda há pouco consenso sobre a melhor forma de inserir essa informação. Campos de texto ou dropdowns para datas de validade? Hoje encontrei uma nova: botões para cada opção.

Formulário de cartão de crédito com botões para selecionar mês e ano de validade

A era do software desktop

Em contraste, uma das forças da era do software desktop era a alta consistência entre interfaces por meio do uso de idiomas de design. Observe esta imagem do Windows 2000:

Interface do Windows 2000 com menu e barra de status

O visual parece um pouco feio e datado: é angular, a fonte não é ótima, e as cores são opacas. Mas a interface acerta em vários pontos:

  • A estrutura de menu File, Edit, View… era padrão. Não importava se o programa era Adobe Photoshop ou Microsoft Excel, sabia-se que save está em File, redo está em Edit, full-screen está em View, etc.
  • O menu é navegável por teclado: há um pequeno sublinhado em cada item do menu, por exemplo, F em File e N em New. Eles indicam atalhos de teclado. É possível pressionar ALT+F para abrir o menu File, depois N para abrir um novo arquivo. Isso atende a usuários avançados enquanto torna os atalhos fáceis de aprender.
  • A barra de status na parte inferior informa tudo sobre o estado atual: página, coluna, contagem de palavras, se está rastreando alterações, em modo de inserção, etc.
  • Os itens de menu são claramente rotulados. Palavras, não ícones, são a interface primária para ações. Ícones são usados apenas onde são mais óbvios. A interface inteira deixa pouco à imaginação. Na imagem acima, não existe “o que será que isso faz?”1 Sabe-se como usá-la, mesmo que nunca se tenha usado antes.

Crucialmente, esses idiomas de design eram usados não apenas no Microsoft Word, mas em todo o ecossistema Windows.

Observe esta tela de logout do Windows XP:

Tela de logout do Windows XP

Cada botão é claramente um botão visual e diz exatamente o que faz. E cada um tem um pequeno sublinhado para indicar seu atalho de teclado. Não é elegante?

A era do software desktop foi de interfaces homogêneas, talvez porque o sistema operacional e suas bibliotecas de GUI ditavam grandes porções do design,2 e essas restrições guiavam os desenvolvedores em direção a padrões conformes.

A era do software no navegador

A era do software no navegador é de interfaces heterogêneas. Observe estas capturas de tela de duas das aplicações web favoritas do autor:3 Figma e Linear.

Interface do Figma

Interface do Linear

Estes são provavelmente os dois melhores softwares corporativos disponíveis hoje. E, embora tenham muitas das mesmas funcionalidades — configurações de equipe, hierarquias abstratas de itens, comentários colaborativos etc. —, não compartilham um único ícone.

Não têm idiomas de design em comum. Possuem atalhos de teclado diferentes. Ambos são muito bem projetados a partir de princípios fundamentais, mas não se conformam ao que outras interfaces com as quais o usuário possa estar familiarizado oferecem.

Vive-se em uma era de aplicações web individualmente bem projetadas e úteis, e todas são únicas4.

Mesmo em produtos da mesma empresa, as experiências são heterogêneas: usar o Gmail não tem nada a ver com usar o GSuites, que não tem nada a ver com usar o Google Docs.

No conjunto, isso é muito frustrante. A falta de interfaces homogêneas significa que a maior parte do tempo digital não é gasta em um estado de fluxo produtivo, mas vasculhando a tela inteira, perguntando-se “posso clicar nisso? Isso abre em uma nova aba? O botão voltar do navegador vai me deixar voltar?”… Terrível!

Essa falta de homogeneidade, que vai contra os princípios fundamentais de design, tem 2 razões principais.

1. A transição para o mobile

Todos os padrões de design para aplicações de mouse e teclado tiveram que ser reinventados com o advento da tela touch. A maioria das aplicações web precisa oferecer tanto uma experiência mobile quanto desktop, e essas formas de interação são muito diferentes.

Portanto, a maioria das experiências de usuário ficou presa em um meio-termo desajeitado desde então, como menus hamburger pensados para apps mobile sendo usados também em apps desktop etc.

Consequentemente, há uma tonelada de padrões de design ruins por toda parte. O desenvolvimento frontend moderno tem uma cultura de copiar e reutilizar componentes modulares5, então, é fácil copiar e colar padrões de design ruins e perpetuar o problema.

Após mais de 10 anos disso, houve um efeito corrosivo geracional na qualidade do design de UI/UX.

2. Idiomas insuficientes além do HTML

Se todos seguissem os mesmos idiomas de design, as interfaces pareceriam bastante consistentes. Nos primeiros dias da internet, havia idiomas de design fortes: hyperlinks para outras páginas eram sublinhados em azul, e roxos se já tivessem sido visitados. Ótimo! Hoje, cada site apresenta seu próprio jogo de adivinhação sobre como os elementos da interface são estilizados. Isso é um link? Talvez6!

Pode surpreender que o web design moderno seja tão pouco idiomático, porque os padrões HTML/CSS são muito prescritivos7. A questão é que, embora existam padrões para escrever HTML, ninguém escreve HTML mais8.

As pessoas escrevem React em TypeScript ou o framework mais recente. Importam inúmeros pacotes npm. Tudo isso passa por um processo de build complexo para gerar algo que roda no navegador.

Os desenvolvedores frontend não estão errados em fazer isso. Os navegadores hoje são extremamente poderosos e oferecem APIs de propósito geral que permitem fazer praticamente qualquer coisa com criatividade9.

Por exemplo, o Figma não segue nenhum idioma de design HTML porque não há HTML. É escrito em WebAssembly; os desenvolvedores estão na vanguarda da implementação de software estilo desktop no navegador. Claro que isso quebra o modelo de página-web-como-documento10.

O botão voltar do navegador, os atalhos de teclado etc. ficam de lado enquanto um paradigma de interação humano-computador é reconstruído.

Em resumo, existem poucos idiomas de web design porque o desenvolvimento frontend está se movendo rápido demais — e as características de interfaces de sucesso acabam diluídas nesse processo.

Os engenheiros se preocupam mais com o que é possível do que com questões de polimento, e com razão. Colaboração multiusuário em tempo real é muito mais valiosa do que atalhos de teclado para usuários avançados. Há tanto pacotes frontend infinitos quanto formatos de interação para implantá-los, então instituir idiomas universais em um espaço tão grande é muito difícil11.

Será necessário tempo para que a vanguarda se estabilize, e para que os padrões mais bem-sucedidos se tornem aparentes e eventualmente idiomáticos.

O sucesso do design idiomático

Ainda assim, algumas das organizações de produtos mais bem-sucedidas da atualidade perseguem agressivamente seus próprios idiomas de design e alcançam alguma homogeneidade em suas interfaces.

A Apple é um ótimo exemplo. Falou-se sobre a Microsoft do passado, mas a Apple de hoje conduz um design system altamente opinativo. A biblioteca geral de fontes, botões, cores etc. da Apple e sua consistência em todas as aplicações e dispositivos nativos da Apple criaram um poderoso efeito de conformidade para aplicações de terceiros.

Mesmo ao usar um app de terceiros no iPhone, as interações via teclado, pinch-to-zoom e outras são toda controlada pelo iOS. Isso é uma grande parte do efeito it-just-works da Apple.

Design idiomático forte, com bom gosto, está no cerne do sucesso da Apple. O interessante sobre o efeito it-just-works é que faz os usuários confiarem nos padrões e evitarem customização.

Uma dinâmica semelhante é vista em plataformas como o Substack, onde o autor não tem capacidade de selecionar a fonte ou mesmo sublinhar texto. Mas os padrões restritivos são definidos com bom gosto, e funciona muito bem.

Os princípios de design do Substack e da Apple ganham adoção conforme esses produtos são bem-sucedidos, já que designers os observam como exemplos de sucesso.

Esses designs eventualmente se tornam idiomas por (1) pessoas convergirem neles como bons designs e (2) frequência de uso na comunidade.

O que fazer?

Como design de produtos, o ideal é seguir idiomas de design o mais próximo possível do que é praticável, porque isso torna o software mais fácil de usar e maximiza a compatibilidade entre dispositivos/navegadores.

Algumas regras gerais podem ser evidenciadas:

1. Estudar e seguir os idiomas HTML/CSS sempre que possível. Por exemplo, um link deve ser sublinhado, colorido, com cursor pointer no mouseover, e escrito como uma tag <a>.

2. Evitar reimplementações em JavaScript de elementos básicos do HTML, por exemplo, componentes React de Button em vez de elementos <button> estilizados — a grande expansão do CSS ajuda bastante neste sentido.

3. Estudar e seguir os idiomas do navegador sempre que possível. O botão voltar deve sempre funcionar. Copiar e colar a URL deve levar à mesma interface. Ctrl+clique em um elemento de navegação deve abri-lo em uma nova aba.

4. Se houver desvio dos idiomas gerais, garantir que os designs sejam totalmente consistentes internamente e pelo menos “idiomáticos” dentro da organização.

5. Preferir palavras a ícones. Usar apenas ícones que sejam universalmente compreendidos.

6. Na dúvida, tornar os elementos visuais óbvios. Nunca deve haver confusão sobre se algo é um botão ou uma aba. Os princípios de User Interface Design reforçam essa ideia.

7. Preferir o que é fácil de entender ao que é visualmente bonito.

8. Em caso de impasse, consultar 2 tipos de recurso para auxiliar no julgamento:

  1. Os sites mais bem projetados que se conhece;
  2. Livros sobre design de interface de décadas passadas. A maioria dos problemas de design de interface de hoje não são novos, mas repetições da história, com analogias resolvidas no passado.

Muitos sonhamos com o dia em que cada datepicker ou formulário de cartão de crédito na internet será exatamente igual: quando, após 30 anos de desenvolvimento iterativo e milhões de tentativas, finalmente terá se convergido no melhor.

Não custa nada sonhar…


Notas de rodapé

  1. Talvez não se saiba o que os rótulos REC, TRK, OVR na barra de status significam. Nesse caso, seria beneficioso outro padrão: tooltips no mouseover que informam mais sobre o que aquela coisa é ou faz.

  2. Vale mencionar também que, nas últimas décadas, a Microsoft sempre publicou guias de centenas de páginas altamente prescritivos sobre como projetar aplicações idiomáticas junto com os lançamentos de seu sistema operacional Windows. É possível ver um exemplo recente aqui.

  3. Existem outras aplicações web comuns como Facebook, Twitter, etc., mas neste artigo o autor decidiu se ater a software corporativo utilitário para evitar comparar o que poderia parecer coisas completamente diferentes.

  4. Apesar disso, existem ciclos de moda no design visual. Houve design esqueumórfico no final dos anos 2000 e início dos anos 2010, Material Design em meados dos anos 2010, aquelas ilustrações 2D vetoriais coloridas no final dos anos 2010, etc.

  5. A grande ironia é que componentes modulares foram feitos para viabilizar o design idiomático! Deixe a comunidade projetar muitos datepickers, e então que o melhor vença! Os desenvolvedores poderão integrar facilmente os melhores módulos de design! É o que diz a teoria. Na realidade, existem apenas centenas de bibliotecas de design concorrentes e nenhuma orientação definitiva que se sustente a longo prazo.

  6. Pior ainda, mesmo em nível técnico, idiomas corretos são frequentemente ignorados por desenvolvedores correndo para a linha de chegada. Já se viram elementos <span> com eventos onclick em vez de elementos <a> em codebases open source. Isso é caos, e quebra leitores de tela e outros recursos de acessibilidade.

  7. Para especificações formais, consulte as RFCs. De forma menos formal, veja o W3. Claro, organizações como Mozilla, Google, etc. todas publicaram seus próprios guias de estilo complementares.

  8. Exceto dinossauros contrários como o próprio autor, é claro.

  9. Há uma piada de que sempre é possível implementar completamente no navegador o que era possível no desktop há X anos. Por exemplo, frequentemente existem implementações de jogos de vídeo populares da época (como Diablo 2, AOE 2) no navegador.

  10. Em outras palavras: muitos desafios do web design contemporâneo derivam do fato de que o HTML/CSS e o navegador em geral foram construídos sobre um modelo de página-web-como-documento, que os engenheiros sempre tentaram esticar ao máximo. Um “documento” simplesmente não é mais uma boa analogia para uma página web em 2023. Mesmo a noção de “página web” é suspeita aqui: o desenvolvedor frontend moderno realmente quer que uma aba do navegador funcione como um ambiente de execução sandboxed universal.

  11. Concretamente, parece muito mais difícil do que no ambiente de software desktop de antigamente, quando os graus de liberdade eram muito menores. Sem telas touch, apenas alguns tamanhos de tela, e assim por diante.