Como arquitetar uma tabela da Web complexa

Imagine que você projeta um sistema para pesquisadores de dados. Ou um aplicativo para gerenciamento de energia. Ou um painel para comerciantes de milho. Talvez você esteja projetando algo assim agora. Em todos os casos mencionados, as pessoas esperam mesas. Não aqueles extravagantes de sites de inspiração de design, mas monstros com aparência de Excel com centenas de células e interação complexa.

Neste caso, um designer enfrenta muitos desafios. Por exemplo, combinar o design com os frameworks front-end existentes ou lutar com dados “desconfortáveis” que esmagam o layout. Vamos superar esses problemas por meio dos seguintes passos: sistematizar necessidades, ser atômico e definir interação.

1. Sistematizar Necessidades

Então, você entrevistou o público-alvo e descobriu suas necessidades e desejos. Agora é hora de juntar as descobertas e transformá-las em uma estrutura de interface. Por exemplo, um usuário disse: “Preciso ver como meus dados afetam outras partes do aplicativo”. Ou enquanto observa outra pessoa trabalhando com um software antigo, você notou que ela usa atalhos e não toca em nenhum mouse. O que isto significa?

As palavras do primeiro usuário são sobre validação de entrada e dicas. Você precisará considerar anexar informações de alerta ou ajuda a uma tabela. Ou desenvolva um sistema de cores significativas. Depende do domínio e do modelo mental. A observação do trabalho do segundo usuário pode ser um sinal de que você precisa projetar todas as ações acessíveis pelo teclado. E você provavelmente precisará pensar em atalhos mais profundos do que apenas “ Cmd + C ” e “ Cmd + V ”.

Aqui estão alguns pares de observação-suposição.

• “ Preciso operar dezenas de itens de uma vez com facilidade .”
  Permitir seleção múltipla de células? Adicionar caixas de seleção para selecionar muitas linhas?
• “ Agora fazemos todos os cálculos dessa maneira .” [ Mostra o Microsoft Excel ]
  O Excel é eficaz para esse fim? Quais recursos podemos emprestar?
• “ Podemos de alguma forma saber de antemão se este nome já está no servidor .”
  Validação de dados em tempo real? Mensagens de erro ou correção automática?
• “ Geralmente eu coloco essa informação. É bem genérico. ”
  Sugerir valores padrão, padrões ou modelos?
  

Como resultado, você terá uma lista das necessidades e desejos das pessoas. Perguntas abertas são úteis para descobrir necessidades reais e filtrar caprichos:

“O que ajuda você a trabalhar mais rápido? O que pode facilitar sua escolha? Como esse recurso está afetando a eficiência do seu trabalho? O que vai mudar se você não for capaz de fazer X?”

Então o que vem depois? Agora é hora de construir um esqueleto lógico para sua tabela. Um esquema do que ele contém e é capaz de fazer. Se você for diretamente para wireframing ou prototipagem, você pisa no caminho maligno de redesenho sem fim e lutando com o legado.

Abaixo está um exemplo do que você pode começar. É a árvore de características. E o bloco de construção básico de qualquer tabela é uma célula. As células se unem em linhas e colunas, que podem ter características específicas diferentes daquelas de células separadas. E, finalmente, vamos a suplementos tão importantes de uma tabela como uma barra superior com botões, comandos de teclado e manipulação de erros.

A árvore de recursos evita que você faça trabalho extra e ajuda a se concentrar no que é importante. Uma árvore de recursos bem organizada também é útil para a equipe de desenvolvimento. Eles podem combinar recursos planejados com bibliotecas de front-end disponíveis e encontrar a melhor maneira de transformar projetos em código.

Em um dos meus projetos, usamos o framework Angular Material. Infelizmente, as tabelas Angular eram muito simples. Encontramos uma biblioteca ag-Grid que suportava nossa funcionalidade, mas tinha uma limitação. Ele não tinha capacidade de expandir uma linha e colocar linhas de crianças dentro. Nós revelamos esse problema antes de nos esforçarmos e ajustarmos o design.

Em poucas palavras

• Comece a construir uma tabela complexa coletando e priorizando as necessidades do usuário. Considere uma solução que não seja de tabela, por exemplo, um gráfico.
• Desenhe um diagrama de árvore que sistematize todos os recursos necessários. Use-o como um plano para a produção de recursos visuais.

Leitura recomendada : Padrões de design de tabela na Web por Chen Hui Jing

2. Torne-se atômico

Assim, as necessidades e funcionalidades são definidas, e você conhece as limitações técnicas. É hora de maquete de sua mesa. Basicamente, a abordagem atômica é projetar pequenos componentes de interface do usuário primeiro e depois montar os maiores. Vamos gradualmente passar de partículas elementares como fontes e cores para módulos tão grandes como um cabeçalho ou coluna. Eu deliberadamente escolhi o estilo brutalista estrito para maquetes para que possamos nos concentrar na função, não na aparência.

Fontes, Cores, Ícones

Essas partes já podem ser definidas pelo sistema de design ou estrutura de interface do usuário que você usa. Se você criar uma tabela para um produto existente, verifique se sua paleta de cores, fontes e ícones atendem às necessidades da tabela. Na foto abaixo, mostrei alguns dos tons de cinza necessários para molduras de mesa, linhas, preenchimentos e texto. Tons de vermelho e azul significam coisas destrutivas de aviso com erro e ativadas para ativação ativa. Os estilos de texto servem para distinguir entre informações primárias e secundárias, títulos e corpo do texto.

Células e acessórios

Quando os átomos da mesa estiverem prontos, podemos prosseguir com as moléculas – diferentes tipos de células. Em primeiro lugar, é importante pensar nos estados normal, hover e ativo de cada elemento de antemão. Em seguida, vá clicado, desativado e outros estados.

Em um dos meus projetos, tínhamos oito tipos de células com interação própria. Os mais simples são células de texto e numéricas. No nosso caso, foi permitido preencher células numéricas com conteúdo não numérico, como “N/A” (não aplicado) e “N/C” (sem controle). Era a peculiaridade do domínio. As listas suspensas e os seletores de data são mais complexos e têm elementos filhos. Por fim, tínhamos células de tabela que representavam comandos em linha.

As células podem ter acessórios como dicas de ferramentas, dicas de entrada, mensagens de erro, espaços reservados, etc. Nesse estágio, elas são estáticas, mas um designer deve especificar posteriormente a lógica de como elas aparecem (animação, atraso, etc.).

Linhas e cabeçalhos

Quando as células são projetadas, você pode criar linhas e ver se várias combinações funcionam bem juntas. Uma vez eu projetei uma tabela que tinha lógica de edição complexa. Algumas das propriedades foram fornecidas pelos usuários, enquanto outras foram calculadas automaticamente ou preenchidas com valores padrão. Abaixo está uma combinação de células somente leitura e editáveis ​​em uma linha.

Observe que o cursor é diferente ao passar o mouse sobre células somente leitura e editáveis. Clicar neles aciona a seleção de uma linha ou o modo de edição da célula editável.

Na próxima imagem, você pode ver que as pessoas podem selecionar uma ou várias linhas:

Agora é hora de pensar no cabeçalho da tabela. Pela minha experiência, muitas vezes é impossível controlar o tamanho do título da coluna e manter uma linha. Mesmo com um bom escritor em uma equipe, você não manterá todos os textos curtos. Algumas das tabelas requerem longos títulos técnicos ou localização. As frases, que eram de uma linha em inglês, podem se tornar duas ou três linhas em grego, alemão ou húngaro. Portanto, mostrei diferentes variantes:

Os usuários de software baseado em dados geralmente precisam de classificação e filtragem. Isso os ajuda a encontrar informações valiosas nos grandes blocos de dados. O desafio da classificação e filtragem é combinar controles de classificação e caixas de filtragem com outros elementos de cabeçalho — títulos de colunas, unidades de medida, etc.

Ao contrário das células da tabela, as caixas de filtro geralmente têm o ícone “redefinir” à direita para que os usuários possam desativá-las explicitamente e ver o conteúdo não filtrado.

No meu exemplo, existem três tipos de caixas de filtro. O filtro alfanumérico permite a busca por letras e números. Ele suporta curingas — número desconhecido de caracteres desconhecidos. Por exemplo, se eu digitar 45*A1 , isso pode resultar na exibição das linhas com valores como 45A1 , 45982A1B , 45A109B e 096445-A1 .

Os curingas são um recurso complicado, pois dependem dos hábitos das pessoas. Quando desenhei tabelas para especialistas técnicos, atribuímos o sinal de asterisco (*) ao número desconhecido de símbolos desconhecidos. Para os analistas de seguros, escolhi o símbolo SQL tradicional — o sinal de porcentagem (%) — porque eles estavam acostumados. Quanto ao filtro suspenso, ele alterna entre um certo número de opções de texto, números ou intervalos numéricos mutuamente exclusivos.

O filtro do seletor de data tem um calendário e funciona como seu equivalente de célula. É bom permitir que os usuários insiram a data manualmente e escolham no calendário. Se eles sabem o que estão procurando, é muito mais fácil digitar do que clicar.

Mais uma coisa importante é formatar qualquer entrada significativa automaticamente e não incomodar as pessoas com erros de “formato inválido”. Em um dos meus projetos, permitimos inserir datas como 01/25/2017 , 6.12.17 e September 4 2016 , e também filtrar apenas por mês ou ano.

Colunas

Um dos recursos frequentes de tabelas complexas são as colunas fixadas. Normalmente, as colunas que contêm informações importantes, por exemplo, nomes de elementos ou status, não são roláveis.

Embora as colunas da tabela devam se ajustar de forma inteligente ao tamanho do conteúdo, isso acontece quando o texto é truncado. Nesse caso, o redimensionamento da coluna é útil. Os usuários podem arrastar a borda da coluna e ver o conteúdo longo. Eles também podem precisar espremer uma coluna sem importância ou aquela com um texto curto.

Outra maneira de lidar com cadeias de texto longas é esticar uma coluna pelo conteúdo mais longo ou envolvê-la e colocá-la em várias linhas. A primeira abordagem funciona melhor para strings de texto mais ou menos semelhantes. A segunda funciona melhor se ver o conteúdo completo for mais importante para as pessoas do que manter a mesa compacta verticalmente.

Em um dos meus projetos, definimos as larguras mínimas das colunas para evitar que as tabelas fossem redimensionadas sem graça. Desativamos a compressão de colunas atrás de uma certa largura dependendo do tipo de conteúdo.

Barra superior

O que constitui uma mesa? Células, colunas, linhas. Além disso, as tabelas complexas geralmente têm uma barra superior. Como o resto dos componentes, a barra superior é construída com elementos menores — um título e comandos.

Abaixo, coletei a lista de comandos com toda a variedade de estados, que usamos em um dos produtos. Tínhamos comandos de ícones para metáforas óbvias como plus = add / create , trash bin = remove , arrow = move . Comandos não genéricos (por exemplo, atribuir, arquivar, balancear) precisavam de nomenclatura textual explícita. Além disso, alguns dos comandos foram acompanhados por um menu suspenso.

Agora podemos tentar combinar diferentes elementos e ver se funciona. Aqui estão alguns exemplos.

Claro, esta não é a lista definitiva de recursos e elementos. Ele difere de um projeto para outro e pode incluir outras coisas, por exemplo:

• Ordenação por mais de uma coluna;
• Conjunto personalizável de colunas (capacidade de alterná-las);
• Linhas expansíveis (uma linha pai pode ter linhas filhas);
• Operadores lógicos para filtragem e busca (“and”, “or”, “else”, etc.).

Se você hesita em quais recursos projetar e quais não, aqui está um bom princípio. É a navalha de Occam, ou a lei da parcimônia. Um designer não deve criar novas instâncias se as existentes satisfizerem as necessidades. Você deve “cortar” os recursos nerds, que os usuários podem teoricamente precisar em um futuro indefinido. A mesma história para os recursos que se encaixam idealmente em uma das cem situações, mas são inúteis nos noventa e nove casos restantes.

Tabela inteira

Quando todos os blocos de construção estiverem prontos, você poderá montar algumas tabelas para vários propósitos. Esta é uma chance de detectar inconsistências. Na maioria das vezes, lidei com os três tipos a seguir.

Tabela somente leitura

O tipo de tabela mais simples de construir, pois mostra apenas os dados no estado em que se encontram. Não há opções de filtragem ou edição. A classificação ou hierarquia de linhas pode ajudar a analisar grandes blocos de dados. Essa tabela é usada para mostrar dados, informar as pessoas sobre algo.

Tabela de pesquisa

As células não são editáveis, o cabeçalho possui caixas de filtro e controles de classificação, é possível selecionar linhas. Da minha prática, essas tabelas ajudam a encontrar, comparar e selecionar um item ou vários itens de uma grande variedade. Por exemplo, filtre cinco das seis mil ferramentas irrelevantes de um catálogo e escolha uma ferramenta necessária.

Tabela Editável

Todas ou algumas células são editáveis. Normalmente, não há filtragem porque a ordem das linhas pode ser personalizada. Essas tabelas normalmente são acompanhadas por uma barra de ferramentas e permitem realizar ações com linhas.

Em poucas palavras

• Comece com os menores componentes e, em seguida, vá gradualmente para os maiores. Finalmente, zombe de tudo.
• Pense em todos os estados possíveis para cada componente de antemão.
• Use o princípio da navalha de Occam para manter o número de elementos mínimo, mas suficiente.

Leitura recomendada : Design Systems por Alla Kholmatova

3. Defina a interação

Blocos de construção não são suficientes para uma peça de interface tão complexa como uma tabela. Um designer deve pensar nas “regras do jogo” e projetar princípios lógicos e convenções por trás da parte visual. Vou descrever algumas coisas típicas que você precisa considerar.

Dados Numéricos

Quantas casas decimais os números devem ter em sua tabela? Um, dois, cinco? Qual é o nível de precisão ideal? Eu decido com base na precisão que os usuários precisam para tomar a decisão certa. Em algumas profissões, a flutuação entre 10932.01 e 10932.23 importante, enquanto em outras áreas os números 14 e 15 não fazem muita diferença.

Este é um exemplo de regras de dados numéricos que minha equipe usou em um produto de engenharia sofisticado.

• Comprimento
  Duas casas decimais (57,53 m, 3,16 km); espaços são usados ​​como separadores de milhar (403 456,56 m).
• Peso
  Duas casas decimais (225,08 kg, 108,75 t); espaços são usados ​​como separadores de milhar (12 032,17 kg).
• Dinheiro
  Duas casas decimais ($ 9,45); vírgulas são usadas como separadores de milhar ($ 16.408.989,00).
• Diâmetro
  Três casas decimais (10,375 cm); sem separadores necessários.
• Latitude e longitude
  Oito casas decimais (26,4321121); sinal de menos usado para a longitude oeste e longitude sul (-78.05640132).
• Predefinição
  Para unidades não listadas acima — duas casas decimais (32,05 g/m³, 86,13 C°).

Mais uma coisa que consideramos foi a diferença entre os dados “verdadeiros” salvos nos servidores e os dados “aproximados” na interface. O sistema usava números extremamente precisos com dezenas de decimais em todos os cálculos, mas as pessoas não precisavam ver isso o tempo todo. Então decidimos mostrar o número de decimais descrito acima e expor o número completo apenas quando uma célula da tabela estiver ativa. Por exemplo, um engenheiro poderia digitar 134432.97662301 , e uma vez que ele pressionasse Enter , a tabela mostrava 134 432.98 . Depois de clicar mais uma vez, o engenheiro veria 134432.97662301 novamente.

Validação de entrada

Ao contrário do item anterior sobre números, a validação é importante apenas para tabelas editáveis. Tem dois aspectos. Em primeiro lugar, as regras que qualificam os dados inseridos como válidos ou inválidos. Em segundo lugar, as mensagens que ajudam a corrigir dados inválidos ou mecanismos que os corrigem automaticamente. Normalmente, as regras de validação são muito complexas para refleti-las em maquetes ou protótipos. Assim, os designers podem documentá-los textualmente ou no formato de fluxogramas.

Este é um exemplo de modelos de mensagem que usei uma vez. O texto entre colchetes angulares é dinâmico e vem do mecanismo de cálculo ou banco de dados.

• Deve ser maior que a measurement unit do number . Optional explanation .
• Deve ser menor que a measurement unit number . Optional explanation .
• Deve estar entre measurement unit number 1 e number 2 . Optional explanation .
• O valor mínimo deve ser menor que o valor máximo.
• O valor máximo deve ser maior que o valor mínimo.
• Os valores mínimo e máximo não devem ser iguais.

Comandos

Tabelas editáveis ​​com barras de ferramentas geralmente precisam de um conjunto de regras quando os comandos da barra de ferramentas estão ativados e quando desativados. Esses estados podem depender do fato de uma linha estar selecionada, do número de linhas selecionadas, da posição ou conteúdo da(s) linha(s) selecionada(s) e de outras condições. Abaixo está uma das inúmeras maneiras de documentar essas regras lógicas.

Então, temos uma tabela com alguns produtos químicos. Possui comandos como “Adicionar uma linha”, “Mover para cima”, “Mover para baixo”, Excluir”, “Recalcular” e “Configurações”.

E aqui está a descrição dos estados de comando. Acontece que sua disponibilidade depende de uma ou várias condições.

O próximo passo é definir o resultado de cada comando. Por exemplo, o que acontece quando seleciono duas linhas remotas e clico em “Mover para cima”? Ou qual é o resultado de clicar em “Recalcular”? Todas essas perguntas devem ser respondidas ou pelo menos consideradas de antemão.

Recipiente e capacidade de resposta

Como a tabela será colocada na interface? Por exemplo, ele ocupará algum espaço dentro de um contêiner existente ou será um módulo separado? As respostas a essas perguntas dependem totalmente de um produto e é melhor prever possíveis problemas e definir minuciosamente os princípios.

Quando eu projeto aplicativos da web, geralmente penso em pelo menos três tipos de contêineres para tabelas. O caso mais típico é quando uma mesa grande é o centro de uma tela e ocupa o máximo de espaço possível. Essa tabela pode não ter seu próprio título, pois a tela inteira é dedicada ao trabalho com a tabela. Tabelas pequenas e médias podem se tornar módulos autônomos de um dashboard assim como outros itens como gráficos, diagramas, esquemas. Nesse caso, a barra superior de uma mesa desempenha o papel de cabeçalho do cartão. E, finalmente, em grandes aplicativos corporativos, as tabelas geralmente existem dentro de caixas de diálogo pop-up. Deve haver orientações sábias para que os diálogos não explodam por causa de muito conteúdo.

Outro aspecto de colocar uma tabela no ambiente de interface do usuário é a área de tela disponível. A maioria dos aplicativos corporativos deve ser usada principalmente no desktop. A capacidade de resposta da mesa é limitada ao comportamento simples de alongamento e compressão. Normalmente, tabelas com muitas linhas e poucas colunas ocupam 100% da largura disponível. Como resultado, as células são distribuídas uniformemente na tela e mais texto pode ser mostrado sem truncamento de quebra. Por outro lado, geralmente aparecem grandes lacunas entre as colunas, o que contraria a lei de projeto de proximidade. É por isso que alguns aplicativos usam linhas entre as linhas ou coloração zebra branca-cinza-final para tornar as informações mais legíveis.

Uma maneira melhor é definir larguras padrão racionais e permitir o redimensionamento manual, se necessário. Para ler uma tabela, é melhor ter algum espaço vazio à direita do que espaços entre as colunas.

Se uma tabela contém muitas linhas e colunas, as rolagens horizontais e verticais são inevitáveis.

A essência chave de uma tabela complexa é ser grande, dando assim uma visão panorâmica dos dados. Infelizmente, não posso citar um método realmente bom de usar tabelas grandes em telas de smartphones. As planilhas do Excel e do Google perdem seu poder em telas pequenas, embora existam maneiras eficazes de lidar com tabelas pequenas. Por exemplo, converter uma mesa em um conjunto de cartas.

Acessibilidade

Mesmo uma mesa excepcionalmente suave e agradável pode se tornar um pesadelo para os usuários. Portanto, é tão importante seguir os princípios de acessibilidade. As Diretrizes de Acessibilidade de Conteúdo da Web (WCAG 2.0) têm um capítulo sobre tabelas. A maior parte do material é sobre codificação adequada; no entanto, um designer também tem muito em que pensar.

Aqui estão as principais considerações de design em termos de acessibilidade.

• Dê um título e prepare um resumo conciso.
  Um usuário com deficiência visual deve ser capaz de ter a ideia de uma mesa sem processar por voz todas as suas células.
• Atenção ao tamanho da fonte.
  Embora não haja um tamanho mínimo oficial para a web, 16 px (12 pt) é considerado o ideal. Além disso, um usuário deve ser capaz de aumentá-lo em até 200% sem quebrar todo o layout.
• Teste cores para pessoas com daltonismo.
  O texto e os controles devem ter contraste suficiente com o plano de fundo. A proporção de cores 3:1 é minimamente necessária (quanto mais, melhor). Além disso, a cor não deve ser a única maneira de marcar as coisas. Por exemplo, as mensagens de erro não devem depender apenas de texto vermelho, um ícone de aviso fornecerá pistas adicionais para usuários daltônicos.
• Evite controles pequenos e ambíguos.
  Os componentes clicáveis ​​são considerados amigáveis ​​ao toque se tiverem pelo menos 40×40 px. Os comandos representados por ícones devem ser rotulados ou ter dicas de ferramentas e texto alternativo. Os designers não devem abusar dos ícones porque os usuários podem não entender metáforas complexas corretamente.

Você também pode utilizar ferramentas online para verificar a acessibilidade, por exemplo, Wave. Ele não apenas encontra problemas e recursos de acessibilidade, mas também os destaca diretamente em uma página e explica como corrigi-los.

Em poucas palavras

• A unificação e formatação de conteúdo também é trabalho do designer.
• Pense além de “coisas”, elementos de sua interface, e considere casos de uso e padrões frequentes.
• Quando tudo dentro é consistente e compatível, é hora de pensar em como ele se encaixa no resto da interface.

Conclusão

Acabamos de percorrer o processo de construção de uma tabela complexa. Projetos diferentes requerem abordagens diferentes, mas há um princípio universal. Um designer deve fazer com que todos os elementos funcionem juntos em qualquer combinação. É por isso que é bom começar coletando necessidades e fazendo pequenos blocos primeiro. E, claro, testando com os usuários assim que tiver algo clicável e realista.

Leitura adicional

• “Design Atômico”, Brad Frost
• “Projete tabelas de dados melhores”, Andrew Coyle
• “Refactoring UI,” Adam Wathan & Steve Schoger