Padrão de Estrutura de UI

O que Padrão de Estrutura de UI faz?

As interfaces tornam-se difíceis de usar por causa da estrutura, não do tamanho. Um aplicativo com 300 configurações pode ser fácil de navegar e um aplicativo com 30 pode ser um labirinto. As causas são sempre as mesmas poucas: o mesmo controle vivendo em vários lugares, menus que espelham o código ou a equipe, ações misturadas com preferências, ícones não rotulados, escopo invisível e nada sendo jamais removido.

A correção é fazer o que as grandes plataformas já fazem, da mesma forma em todos os aplicativos, para que as pessoas possam usar o que já sabem:

• Um layout familiar. Uma lista pesquisável de categorias à esquerda, a página aberta à direita, linhas com o rótulo à esquerda e o controle à direita.
• Um conjunto de nomes de categorias. Conta, Notificações, Privacidade e segurança, Acessibilidade, Aparência, Idioma e região, Dados e armazenamento, depois os próprios assuntos do produto. Sete questões arquivam qualquer configuração em exatamente uma.
• Menos controles. A melhor configuração é aquela que nunca é lançada porque um padrão melhor a tornou desnecessária.
• Um lar para cada controle que permanece. Cada configuração, destino e comando é um registro em um registro, cada registro tem exatamente um lar, e a interface é desenhada a partir dos registros. Quando ninguém coloca um controle manualmente, a estrutura não pode se desviar.

Escolha o trabalho

Encontre a solicitação nesta tabela e leia apenas essa seção, mais os arquivos que ela nomeia.

A solicitação	Seção	Leia também
"Adicionar uma configuração / item de menu / botão"	Adicionando um controle	Nada mais, geralmente
"Esta UI está uma bagunça", "revise isto", "usuários não conseguem encontrar as coisas"	Auditando uma interface existente	references/audit.md, references/rules.md
"Construir / projetar / redesenhar uma tela de configurações, barra lateral ou barra de ferramentas", ou uma lista de recursos para transformar em um	Construindo uma nova superfície	references/categories.md, references/visual-design.md, references/record-schema.md
"Organizar nossas configurações", "quais categorias devemos ter"	As categorias padrão	references/categories.md
"Configurar isto para o nosso projeto"	Adotando o registro	references/record-schema.md

Seja qual for o trabalho, respeite o projeto em que você está. Se o código-fonte já tiver um registro de configurações, uma biblioteca de componentes ou suas próprias regras sobre marcação, estenda-os; não introduza um sistema paralelo. O padrão descreve estrutura, não tecnologia.

A pasta evals/ contém casos de teste para esta habilidade. Não é material de referência; não a leia enquanto realiza uma tarefa.

Adicionando um controle

Faça estas cinco perguntas em ordem e pare na primeira resposta sim. Diga ao usuário essa decisão e o motivo; não os guie por perguntas que não se aplicam mais.

1. Um padrão melhor o tornaria desnecessário? Se a necessidade pode ser atendida para todos alterando o padrão, detectando a situação ou simplesmente removendo o comportamento que as pessoas não gostam (uma confirmação que ninguém precisa, um prompt para algo que salva automaticamente), faça isso. Não há configuração.
2. O sistema ou um administrador já decide isso? Tema, tamanho do texto, permissão de notificação e similares pertencem à camada abaixo. Siga-a. Se o produto tiver um motivo real para oferecer sua própria escolha, a escolha inclui "Usar configuração do sistema" e esse é o padrão; nunca é uma simples chave liga/desliga.
3. É feito uma vez, não uma escolha duradoura? Então é uma ação: um botão, mantido separado das alternâncias, no contexto ou em um grupo rotulado no final de sua página.
4. É alterado semanalmente ou com mais frequência? Então o controle vive no contexto, ao lado do recurso que altera, com um link para sua página inicial. A página inicial ainda o lista.
5. Menos de cerca de 1 em cada 20 pessoas o alteraria? Então seu nível é avançado. Uma página com três ou mais itens avançados os mostra em uma seção Avançado; com menos, é uma linha comum colocada por último.

Caso contrário, é uma linha padrão em sua página de assunto.

Se a resposta à pergunta 1 ou 2 foi sim, diga isso claramente e proponha essa alteração em vez da configuração. Toda configuração tem um custo em testes, em suporte e na capacidade de todos os outros de encontrar as coisas, então o usuário deve ouvir a opção mais barata primeiro. Eles ainda podem querer a configuração; é escolha deles. Ofereça-a como alternativa em algumas linhas.

Escolhendo o lar. Use as sete perguntas sob As categorias padrão, mapeadas nas páginas que existem. Se o controle não se encaixar em nenhuma, isso é evidência de um assunto faltando: diga isso e proponha um. Não crie uma página chamada Geral, Diversos, Outro ou Avançado. Quando a interface existente já tiver tal página, coloque o novo controle na página específica de melhor nome e mencione o agrupamento genérico em uma linha como algo que vale a pena corrigir depois. Uma solicitação para adicionar um controle não é uma solicitação para uma auditoria.

Controles que fazem uma pergunta. Uma confirmação com "Não perguntar novamente" é um controle no contexto para uma configuração (pergunta 4): a caixa de seleção e a linha de configurações são o mesmo registro, então a escolha pode ser encontrada e revertida depois. Nunca ofereça "Não perguntar novamente" sem uma linha em algum lugar que a desfaça.

Quanto mostrar ao usuário. Se o projeto tiver um registro, escreva o registro completo (campos abaixo) e verifique se a página em que ele cai ainda está dentro dos limites. Se não tiver, ou o usuário só pediu conselho, responda em palavras simples: o que adicionar, onde, como se chama, qual é o padrão e por quê, e se se aplica a este dispositivo ou a toda a conta. Campos como id, tier, owner e reviewed são administrativos; deixe-os de fora de uma resposta conversacional. Quando você não souber algo que o registro precisa (se as configurações sincronizam entre dispositivos, quais páginas existem), declare sua suposição em uma cláusula e prossiga.

Auditando uma interface existente

O objetivo é uma lista de descobertas concretas e corrigíveis vinculadas a números de regras, e uma estrutura proposta. Leia references/rules.md primeiro para que as descobertas possam citar regras, e use o modelo de relatório em references/audit.md.

Uma auditoria pode cobrir configurações, navegação, barras de ferramentas ou todos os três. Audite o que o usuário perguntou e o que você pode ver. Se a tela não tiver configurações, pule as partes de configurações do modelo; não as estique para caber.

1. Inventário. Liste todos os lugares onde uma pessoa pode alterar ou acionar algo: telas de configurações, menus de conta, menus de contexto, diálogos por item, listas de navegação, barras de ferramentas, faixas de ícones, sinalizadores de linha de comando, arquivos de configuração. Em uma base de código grande, delegue a varredura ou procure pelos padrões (rótulos, alternâncias, construtores de menu); não leia arquivos enormes por inteiro. Para cada controle, registre seu rótulo como mostrado, seu tipo, onde vive e como é alcançado. Quando um controle não tiver rótulo algum, diga, descreva-o por posição e marque qualquer palpite sobre o que faz como um palpite.
2. Meça. Conte o que as regras limitam: lugares para alterar coisas, entradas de navegação de nível superior, configurações por página, profundidade, botões por barra de ferramentas, controles apenas de ícone, controles sem nome acessível, caixas de pesquisa, e quantos conjuntos de comandos distintos objetos do mesmo tipo mostram.
3. Encontre os sintomas.
   • a mesma configuração ou comando acessível em mais de um lugar, ou dois controles que se sobrepõem ou entram em conflito
   • um assunto espalhado por várias páginas
   • uma coisa com vários nomes; um link cujo rótulo difere do título do seu destino; nomes quase duplicados lado a lado
   • páginas nomeadas Geral, Diversos, Outro, Avançado
   • ações (exportar, excluir, sair) entre preferências ou entre destinos
   • escopo explicado apenas no texto de dica, ou não explicado
   • vocabulário do construtor em rótulos
   • grupos com um item e listas mais longas que seu limite
   • ícones sem palavras visíveis; um ícone usado para dois significados
   • barras de ferramentas com mais de cinco botões; conjuntos de comandos que diferem entre objetos do mesmo tipo
   • nenhum marcador para a localização atual
   • mais de uma caixa de pesquisa em uma tela
   • mostrar, ocultar ou reordenar controles oferecidos como a cura para a desordem
4. Proponha. Para configurações: as categorias padrão que se aplicam mais até dois assuntos do produto, no máximo nove no total, com cada controle mapeado para exatamente um. Para navegação: no máximo nove entradas de nível superior, o resto sob grupos rotulados. Para barras de ferramentas: um conjunto de comandos por tipo de objeto, cinco na barra, o resto sob Mais. Liste o que sai da superfície completamente e para onde vai. Diga que os agrupamentos são propostas a confirmar com um card sort e um tree test (cinco pessoas encontram os grandes problemas; aponte para 80% de sucesso na tarefa), porque os agrupamentos devem corresponder a como os usuários pensam e isso não pode ser lido no código.
5. Ordene as alterações de modo que aquelas que ninguém precisa reaprender venham primeiro: palavras em ícones e um marcador de localização atual, depois colapsar duplicatas e unificar nomes, depois barras de ferramentas consistentes, depois reagrupar. Mover as coisas vem tarde porque custa algo aos usuários existentes. Se adotar um registro for justificado, vai por último e é oferecido, não empurrado; o usuário perguntou o que mudar na tela.

Ordene as descobertas por quanto prejudicam um novo usuário. Credite o que já funciona: um registro existente, pesquisa, redefinição ou mecanismo de endereço é a base sobre a qual a correção se constrói, e dizer isso evita uma reescrita que ninguém precisa.

Construindo uma nova superfície

1. Execute as cinco perguntas em cada item primeiro. Uma lista de desejos de produto sempre contém coisas que deveriam ser um padrão melhor, pertencem ao sistema, ou são ações em vez de preferências. Deixe os itens cortados fora do registro e liste-os em seu resumo com o motivo, para que o usuário possa anulá-lo.
2. Escreva os registros antes de qualquer marcação, seguindo references/record-schema.md. Se um registro existir, adicione a ele.
3. Arquive cada registro com as sete perguntas (próxima seção). Deixe de fora categorias que estariam vazias. Uma categoria com uma ou duas configurações é aceitável quando as pessoas a procuram pelo nome (Notificações); caso contrário, dobre-a em sua vizinha. Status sobre um assunto permanece na página desse assunto; apenas informações de todo o aplicativo vão para Sobre.
4. Verifique os limites (abaixo), manualmente ou com o verificador.
5. Desenhe o layout padrão a partir dos registros, seguindo references/visual-design.md para disposição, tamanhos, controles e estados, e references/patterns.md para comportamento. Em resumo: lista de categorias ao lado da página em telas largas e antes dela em telas estreitas; uma coluna limitada perto de 1.100 px; rótulo à esquerda, controle ou valor atual à direita; linhas relacionadas em grupos contidos; interruptores para ligado e desligado, botões de opção para duas a cinco opções, sem botão Salvar; alvos de pelo menos 24 px e 44 a 48 px para toque; contraste de texto 4,5:1; nada mostrado apenas por cor. Cada linha mostra seu escopo e, quando difere do padrão, um marcador de alterado com Redefinir. A pesquisa fica no topo. Cada registro tem um endereço estável. As ações ficam separadas das preferências, as destrutivas separadas novamente.
6. Diga o que você assumiu: padrões, escopos e proprietários que você teve que adivinhar são do usuário confirmar. Use unassigned para um proprietário desconhecido; não invente nomes de equipe.

As categorias padrão

Faça estas perguntas em ordem e pare na primeira resposta sim. A ordem é o desempatador.

#	A pergunta	Categoria
1	É sobre quem você é, como você entra ou o que você paga?	Conta
2	Decide quando ou como o produto interrompe você?	Notificações
3	Controla o que outras pessoas, outros aplicativos ou o serviço podem ver, guardar ou fazer?	Privacidade e segurança
4	Existe para que alguém com uma necessidade específica possa ver, ouvir ou operar o produto?	Acessibilidade
5	Muda apenas a aparência das coisas?	Aparência
6	É sobre idioma, hora ou formatos?	Idioma e região
7	É sobre onde os dados são mantidos, quanto ou em qual rede?	Dados e armazenamento
	Caso contrário: qual recurso ele altera?	Um de até dois assuntos do produto (Mensagens, Editor, Reprodução)

Sobre (versão, ajuda, legal) é um link no rodapé e não é contado. Configurações que um administrador faz para todos são uma superfície separada. Um aplicativo pequeno com menos de cerca de 15 configurações usa uma página com esses nomes como cabeçalhos de grupo.

Portanto, um toque para chamadas é Notificações, não Chamadas; "reduzir movimento" é Acessibilidade, não Aparência. Quando uma configuração puder se encaixar em duas, arquive-a pelo primeiro sim e coloque as palavras da outra categoria em suas palavras de pesquisa. references/categories.md cobre produtos grandes, suítes, nomenclatura e o raciocínio.

Estes nomes são os que os sistemas operacionais já usam. Comece por eles e mude-os apenas quando os próprios usuários do produto, em um card sort, agruparem as coisas de forma diferente.

O registro

Campo	A pergunta que ele responde	Valores permitidos
id	Qual é seu nome permanente?	Um caminho pontilhado como chat.notifications.sound. Nunca reutilizado ou renomeado.
kind	Que tipo de coisa é?	preference, action, status, list, destination, command
subject	Sobre qual substantivo único é?	Exatamente um assunto. Este é seu lar.
scope	Quem ou o que ele altera?	item, device, account, organization
tier	Quantas pessoas precisam dele?	everyday, standard, advanced
label, summary	Como se chama e o que faz?	Um rótulo simples; uma frase sobre o resultado
search	O que uma pessoa digitaria para encontrá-lo?	Sinônimos, o nome antigo, o termo técnico
value	Que tipo de valor ele contém?	Um tipo, com opções ou um intervalo
default, default_reason	O que acontece se ninguém tocar nele?	O valor que a maioria das pessoas escolheria, e por quê
risk	O que quebra se for alterado?	safe, care (recuperável), destructive (perdido para sempre)
owner, reviewed	Quem decide quando ele desaparece?	Um proprietário e a data em que foi justificado pela última vez

Destinos e comandos usam um conjunto mais curto de campos. O esquema completo está em references/record-schema.md, e assets/registry.example.json é um exemplo funcional.

Os limites

| Limite | Valor | De onde vem |

…

[truncado para tradução]