Lixando a UI
(blog.jim-nielsen.com)- O acabamento da UI não melhora logo após a implementação, mas no processo iterativo de continuar clicando de verdade, e o texto compara isso ao lixamento na marcenaria
- Transições de página e navegação devem ser verificadas por vários caminhos de entrada, como cliques, botão de voltar do navegador, “Back” no menu de contexto do botão direito, voltar dentro do app e atalhos de teclado
- Ao alinhar
labeleinput type="radio"com flexbox e adicionargap, o espaço entre o botão de opção e o rótulo se revelou uma dead zone que não era clicável - A solução foi remover o
gape adicionar padding aolabel, mantendo o espaçamento visual enquanto ampliava a área clicável - Mesmo pequenas falhas de interação, quando se acumulam, prejudicam a experiência de uso; por isso é preciso usar a UI repetidamente e refiná-la até não encontrar mais “farpas”
Encontrando as partes ásperas da UI clicando repetidamente
- Trabalhar em UI é muito parecido com criar algo, clicar bastante, corrigir e depois clicar de novo
- Para transições de página, verificar apenas um fluxo não é suficiente; é preciso voltar por diferentes métodos e observar
- Clicar e depois usar o botão de voltar do navegador
- Clicar e depois usar “Back” no menu de contexto do botão direito
- Usar a navegação de voltar dentro do app
- Usar atalhos de teclado para voltar
- Esse processo se parece com QA, no sentido de “clicar para tentar quebrar”, mas é mais próximo da sensação de lixar madeira e procurar partes ásperas e farpas
- Como uma UI de software pode ter estados e variáveis demais, o refinamento segue pelo uso repetido até não encontrar mais “farpas”
A dead zone de clique criada pelo gap do flexbox
- Em uma lista de opções de rádio, um
<input type="radio">associado a um<label>foi colocado na mesma linha - O CSS era uma estrutura simples, com
display: flex,flex-direction: row,align-items: centeregap: .5remaplicados ao contêiner - Durante cliques repetidos, foi encontrado um dead spot: ao pressionar o espaço entre o botão de opção e o rótulo, o controle não alternava
- A causa era o
gapdo flexbox- O
gapcria espaçamento visual com facilidade - Mas não faz parte da área clicável do rótulo nem do elemento de input, tornando-se um vazio na interação
- O
- A solução foi remover o
gape adicionar padding aolabel- O espaçamento foi mantido
- A área clicável do rótulo aumentou, e a dead zone desapareceu
- Um único pequeno defeito pode parecer trivial, mas quando muitas dessas “pequenas farpas” se acumulam, a experiência da UI pode se tornar dolorosa
1 comentários
Opiniões no Hacker News
Um desenvolvedor que também é um usuário que usa muito diretamente o produto que está criando tem uma vantagem enorme para encontrar esses pequenos problemas.
Isso porque o próprio desenvolvedor percebe pequenos incômodos antes que o usuário esbarre neles, e também está na posição de corrigi-los imediatamente.
Por isso, parece que equipes pequenas com forte senso de ownership são eficazes. Quando há sentimento de dono sobre o produto, até pequenos inconvenientes sofridos pelos usuários passam a parecer problema próprio, e tornar a UX o mais fluida possível vira uma questão de orgulho.
A menos que seja um produto corporativo difícil de usar internamente, mesmo que o ownership direto seja mais fraco, cria-se um interesse no sucesso do produto.
Fico curioso sobre qual seria a UI mais polida.
Com empresas do nível FAANG, que têm muito dinheiro, seria de esperar que UI/UX fossem bem boas, mas quem já usou Amazon.com ou AWS, GCP, Azure provavelmente sente diferente.
Pessoalmente, considero mcmaster.com a UI/UX mais bem polida. Dá para encontrar o que se precisa em poucos minutos.
Já em sites de grandes lojas como Home Depot ou Lowe’s, encontrar parafusos ou madeira no tamanho exato leva 10 a 15 minutos, e no mobile é ainda pior.
É incrivelmente simples e prático, mas ainda assim bastante poderoso. Você pode ir filtrando peças passo a passo ou pesquisar; a comparação de preços é automática, e as categorias de preço/qualidade também são agrupadas de forma útil.
Ao encontrar o número de uma peça, dá para ver compatibilidade por ano/fabricante/modelo, uma descrição simples, fotos e até se ela será enviada do mesmo depósito que outras peças no carrinho. Tudo isso em uma única página, sem atrito, funcionando muito rapidamente em qualquer plataforma.
É muito responsivo, e nunca vi bugs enquanto usava. Elevou meu padrão sobre até onde um web app pode chegar.
Na prática, eles até tiveram um período dedicado só a corrigir problemas de usabilidade.
https://linear.app/changelog/2022-12-01-polishing-season-202...
https://web.archive.org/web/20231003205004/https://linear.ap...
A foto de perfil temporária, em especial, é a mais irritante. Há quase um ano ela não funciona direito e não volta para a foto original.
Parece que ninguém está polindo nada por lá.
https://littlebigdetails.com é exatamente esse tipo de lugar.
A solução básica para este problema específico é colocar o elemento de input dentro do label.
Eu me perguntava o motivo, e acho que pode ser porque fica mais simples aplicar temas ao ajustar a posição/padding do label ou do elemento de input.
[1] https://getbootstrap.com/docs/5.3/forms/checks-radios/
for/idainda são necessários: https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...Radios e checkboxes devem alternar não só ao clicar na caixa e no padding, mas também ao clicar no rótulo de texto inteiro.
Flexbox parece um pouco exagerado. Mesmo com a sintaxe sem aninhamento, eles seriam posicionados inline, e acho que bastaria adicionar padding da mesma forma.
Para mitigar isso, é preciso envolver
Fooem um elemento separado.Esse tipo de coisa desapareceu demais no Agile
O engenheiro deveria ter tempo para polir o produto, mas na prática não tem. Se o QA não abre um ticket por causa de um problema de espaçamento, isso nunca é corrigido
O cliente provavelmente percebe essas coisas, mas já é um milagre ele reportar; outro milagre isso acabar virando um ticket; e mais outro milagre alguém dar prioridade e corrigir
Na prática, os boards de issues da maioria das empresas são tão opacos do ponto de vista do cliente que, quando se encontra um pequeno problema ou bug, é irritante ter que ficar indo e voltando por 50 horas para provar que aquilo é um bug e colocar um ticket no rastreador
Você acha que o modelo em cascata dava explicitamente tempo para testar e polir a UI?
Isso normalmente é um processo que um gerente de produto deve priorizar e tratar junto com um engenheiro ou designer de UX competente. Se quiser, dá para colocar essa prioridade em qualquer metodologia de desenvolvimento, então Agile é irrelevante aqui
Reportei isso várias vezes nos últimos 3 anos, porque editar texto enquanto se escreve é extremamente difícil e irritante
Como desenvolvedor web, fico curioso para saber como algo assim quebrou para começo de conversa. Não sei que nível de incompetência é necessário para quebrar algo que funciona por padrão. É uma correção que não deveria levar mais de 30 minutos e melhoraria 1000 vezes a experiência de todos os usuários, mas 3 anos depois de eu reportar continua igual
No Teams, também reportei via Microsoft Premiere Support um bug em que não era possível usar as teclas HOME/END no campo de telefone, e a resposta foi “funciona conforme projetado”
Não é de surpreender que clientes não reportem mais esse tipo de bug. Afinal, nem os funcionários/desenvolvedores nem a empresa se importam
Sou desenvolvedor líder de um produto e há muitos pequenos problemas espalhados por aí. Não tem como ser uma sensação boa ser responsável por algo, mas não ter autoridade para consertar
Do ponto de vista de negócios, a lógica vira: se não afeta a receita nem a marca, por que gastar tempo e dinheiro para corrigir? No longo prazo isso vai afetar a marca, mas a maioria muda de função ou de empresa em até 5 anos, então não se importa
Quando pelo menos se recebe uma resposta, já é o melhor dos casos
Há claramente um processo que não atende às necessidades dos clientes, então basta corrigi-lo junto com a equipe
Se houver cerimônias de Scrum, dá para levantar isso na retrospectiva, mas na verdade pode ser a qualquer momento. A retrospectiva é apenas um momento para olhar deliberadamente para as últimas semanas; aquilo que você percebe no meio do caminho deveria ser tratado no meio do caminho
Pessoas com sensibilidade para perceber e corrigir pequenos problemas de UX são realmente importantes
Em design de UX, costuma-se comparar isso a cortes de papel sofridos pelo usuário. Não são fatais, mas reduzem a satisfação do usuário
Acrescentando ao autor: aquele radio button não segue a convenção de usar um ponto, e não um check, para indicar o estado selecionado. À primeira vista, o usuário pode entender errado que é possível selecionar vários ou até não selecionar nenhum
Muito provavelmente é um efeito colateral do recurso que fecha ao clicar fora
Se existem “Papercuts” no lado negativo, no lado positivo há o Juice, que também foi abordado recentemente no HN
Este texto mostra bem por que eu detesto programação de UI
As coisas imprevisíveis e pequenas que podem sair do alinhamento ultrapassam a minha paciência. Até gosto, em certa medida, de pensar em como algo pode falhar e escrever testes, mas sair clicando aleatoriamente para ver se quebra é dispersivo e irritante
Fico me perguntando se a implementação de UI é intrinsecamente tão complexa assim, ou se ainda não encontramos o modelo de programação certo. Às vezes me pergunto se é unreasonable querer que algo já apareça e funcione como planejado desde o início
Só é preciso polir a UI quando o componente é criado pela primeira vez. Às vezes pode ser necessário combinar componentes de outra forma ou fazer uma implementação pontual
Sinceramente, se você sabe o que está fazendo, não demora tanto. Um bom engenheiro de design é especialista nesse papel
Há liberdade demais, e elementos básicos como formulários deveriam funcionar bem apenas com os valores padrão
Já existem boas maneiras de expressar UI por meio de código. O problema é o jogo de soma zero do lado do negócio. UI cross-platform fica cara demais se você não fizer com a pilha de UI mais feia que existe: HTML/CSS/JS
Mas a plataforma web, embora seja razoável para documentos, não tem o nível de abstração adequado para apps. Por isso a UI web é reinventada todos os anos com uma abstração nova e vazante
Só acompanhar tudo já dá trabalho demais
Em outras áreas é parecido. Se não há uma maneira fácil de enviar requisições ou colocar parâmetros em uma query, mesmo que as pessoas tentem tomar cuidado, a pressão natural as leva a inventar todo tipo de solução meia-boca
A plataforma web é de ponta na parte gráfica, mas como UI é realmente horrível. Só que ninguém quer admitir isso e mudar. As pessoas acreditam apenas na primeira parte, e o legado e a complexidade dos navegadores impedem mudanças. Se você criar como biblioteca, ninguém liga porque não é “padrão”
Enquanto isso, algumas UIs usam uma caixa quadrada em radio buttons
Há botões em destaque que não são ativados com a tecla Enter
E também há três menus escondidos atrás de símbolos diferentes (reticências, hambúrguer, kebab)
A variação de qualidade é grande. Pessoas que poliram UI são realmente dignas de agradecimento
Até a Apple está fazendo isso :(
Não entendo por que a abordagem de colocar elementos de entrada dentro do rótulo não é popular
Fazendo assim, o problema desaparece completamente, e nem é preciso criar um
idúnico para usar noforSó que, pelo que se sabe, ainda existem algumas tecnologias assistivas que não conseguem interpretar esse novo padrão válido, então seguir o padrão da Idade do Bronze acaba sendo a melhor prática [1]
Imagino que outros frameworks façam algo parecido. Se você envolver esses dois campos de entrada com um elemento
label, isso deixa de ser HTML válidoNão é um problema para botões de rádio, mas parece que algumas pessoas passam por isso e depois fazem assim “por garantia”. É parecido com colocar ponto e vírgula no fim das linhas em JavaScript. Quase nunca é necessário, mas como não sabem exatamente quando é, colocam em todo lugar
Nos casos de uso comuns de checkboxes/radio buttons, a sintaxe também fica muito mais limpa
Envolva o elemento de entrada com o rótulo e, se quiser estilizar o texto, coloque o texto em um
span. Dá para definir olabelcomodisplay:flexe tratar a posição do texto desse jeitoEm bug bashes, uso essa abordagem, e ela gera muito mais tickets do que quem monta as combinações de casos de teste como uma matriz multidimensional de produto cartesiano
É bom conhecer esses casos de teste como ponto de partida, mas, para encontrar problemas pequenos, testes aleatórios rapidamente superam os testes planejados
Testes planejados normalmente ficam no caminho feliz ou em erros previstos. Esse tipo de polimento encontra bugs de canto muito mais rápido
Sempre acabo encontrando problemas ou pequenas melhorias. Coisas que, na prática, provavelmente não apareceriam muito em testes planejados
Estou polindo meu site pessoal (https://dustinbrett.com) há quase 4 anos, e sinto que isso poderia continuar infinitamente
Felizmente, eu gosto de trabalhar nisso
Espero que tenha sido tudo :-)
Quando vejo um “SO de desktop em cima de uma página web”, a maioria parece meio inacabada e, honestamente, já ficou comum demais; este, por outro lado, é muito sólido e bem polido
Muito bem feito e inspirador. Também é bem divertido imaginar como tudo foi implementado
A vontade de usar um SO baseado em janelas no celular
Se eu fosse apontar algo que falta, é que não dá para usar mouse4/mouse5 no explorer. “Polir” pode mesmo continuar para sempre