A busca por formulários da Web mais inteligentes

Formulários on-line são uma das áreas mais difíceis de desenvolvimento de sites para se acertar, especialmente com tantas coisas que podem dar errado. A natureza mutável de como as pessoas acessam o conteúdo on-line também teve um impacto em uma tecnologia que foi desenvolvida anos antes que as pessoas esperassem poder fazer com um telefone o que normalmente fariam com um computador. É uma tecnologia que sofreu muito pouca evolução.

O design de formulários da web deve ser uma profissão autônoma. Os designers de sites devem envolver os serviços de designers de formulários web profissionais em tempo integral para ajudá-los em suas tarefas. Mas isso não é visto como econômico o suficiente e, na maioria das vezes, o designer do site também é responsável pelo design de qualquer formulário usado no site.

Mas projetar formas é uma habilidade altamente especializada. É necessário entender como as pessoas interagem com as informações e entender as melhores maneiras de coletar e apresentar informações. Onde o web design geral é centrado principalmente em apresentar informações e imagens de maneiras atraentes, mas práticas, o design requer que focemos nossa atenção na natureza da informação e então decidamos a melhor maneira de estruturá-la na página para que ela funcione como pretendido. A estética é uma consideração menos importante neste caso, mas ainda não deve ser esquecida.

Neste artigo, vamos dar uma olhada na arte do design de formulários da web e ver se podemos encontrar uma maneira de tornar nossos formulários da Web mais inteligentes em termos de como eles são e como funcionam.

As ferramentas de construção de formulários web

As ferramentas padrão que nos foram dadas pelos desenvolvedores de navegadores e W3C para unir nossos formulários da web não são exatamente ideais, e antes de aplicar o CSS a elas, elas são realmente horríveis. É assim que eles se parecem:

Há também outro controle de entrada padrão chamado selecionar, mas você deve evitar usar isso a menos que economizar espaço seja uma preocupação séria. Existem maneiras melhores de lidar com a tarefa executada pelo controle de seleção, como discutiremos mais adiante. Os controles de textarea também devem ser evitados sempre que possível porque são tão problemáticos e antiquários.

Além desses itens de entrada padrão, há também novos especiais criados para HTML5. Exceto quando um documento está sendo preparado estritamente para uso interno e onde o ambiente do navegador é conhecido, somente os componentes que funcionam no Firefox e no Chrome devem ser usados. É bom se um componente também funciona em outros navegadores, mas não deve apenas trabalhar em outros navegadores. Aqui estão os componentes HTML5 como aparecem no Firefox:

E sua aparência ligeiramente diferente no Chrome:

Agora, obviamente, é muito importante estar ciente de que suas entradas HTML5 terão aparência e funcionamento diferentes entre o Chrome e o Firefox, mas ainda funcionarão. Os controles de entrada padrão também parecem um pouco mais legais no Chrome do que no Firefox. Observe que o Chrome impõe o padrão de data norte-americano, que os usuários podem não apreciar. Além disso, a versão do Chrome do controle de data a torna inadequada para exibição e só deve ser usada para entrada. A adição de um selecionador de data é a principal melhoria no Chrome, mas provavelmente esperamos ver isso em versões futuras do Firefox.

Como o Firefox é open source, você pode fazer sua própria versão pessoal do Firefox renderizar as entradas da mesma forma que o Chrome baixando o código-fonte do navegador Chromium no qual o Chrome é baseado e portando a seção relevante do código para a fonte do Firefox código (mas você terá que fazer isso toda vez que atualizar o Firefox para uma nova versão).

O ponto principal é, no entanto, que mesmo com os aprimoramentos do Chrome, a aparência padrão dos controles de entrada é pequena e pouco atraente. Existem alguns outros controles disponíveis, mas como eles não funcionam no Chrome e no Firefox, eles não devem ser usados ​​em sites destinados ao público.

Resposta de Bootstrap (quase adequada)

O Bootstrap aplica o estilo aos controles padrão que melhoram sua aparência até certo ponto. Porém, devido à filosofia de design centrada em dispositivos móveis do Bootstrap, ele causa alguns efeitos indesejáveis ​​em formulários que não devem ser exibidos como uma única coluna, e faz com que campos de entrada curtos pareçam engraçados quando ocupam uma coluna inteira por padrão. O mundo pode ter sido móvel, mas os formulários não foram inventados com os usuários móveis em mente.

O Bootstrap expande os controles para preencher a largura horizontal de seu contêiner, o que significa que todos os controles terão a mesma largura, quer você goste ou não (a menos que você supere esse comportamento manualmente), e permite que você vista alguns tipos de controle com bling adicional. A solução do Bootstrap é elegante e supera alguns dos problemas dos controles terem aparências diferentes em diferentes navegadores, mas só funciona com os controles padrão. Os controles HTML5 não são implementados nas versões atuais do Bootstrap, então você terá que modelar os mesmos por conta própria.

O Bootstrap também permite combinar controles juntos. Às vezes isso é bom e às vezes não é tão bom. Combinar uma entrada de texto com um botão e uma caixa de seleção pode parecer boa, mas pode confundir o usuário sobre como eles devem interagir com um controle tão desconhecido.

O que o Bootstrap fornece é dois dos meus dispositivos de criação de formulário favoritos, o painel e a bem. Eles são muito úteis para agrupar dados de formulário para fornecer uma indicação visual de quais dados estão relacionados a quais outros dados e também para segregar dados.

Edifício Smart Form 101

Agora estamos prontos para pensar em como as formas podem ser construídas de maneiras mais inteligentes. Para fazer isso, precisamos estar pensando bem além dos padrões. Precisamos estar cientes das raízes ligadas ao desktop dos controles de formulário e também da necessidade de compatibilidade com dispositivos móveis. E precisamos nos preocupar com coisas como usabilidade e validação (se o formulário for usado para coleta de dados).

Esse último ponto é bom porque, embora os controles de formulário sejam usados ​​para coletar entradas, eles também são usados ​​para exibir dados armazenados. O usuário médio da web é (e deve estar) mais interessado em obter informações de você do que dar informações a você.

A coleta de dados é fácil. As pessoas vão preencher tudo o que você colocar na frente delas, mesmo que seja uma bagunça. Mas quando se trata de exibição de dados, eles são mais exigentes. Consequentemente, aqui nos concentraremos mais no uso de formulários para exibir dados do que coletá-los, pois a exibição exige mais cuidado e mais "inteligência".

1. Precisamos de um formulário?

Antes de construirmos um formulário, devemos verificar se realmente precisamos de um. Se os dados puderem ser representados de maneira adequada e não confundida como uma tabela, uma tabela geralmente será mais eficiente e prática.

Um formulário é necessário se:

  • Estamos coletando informações do usuário
  • Temos muitos dados para exibir
  • Os dados precisam ser claramente segmentados
  • O usuário provavelmente acessará os dados de um dispositivo móvel

Se algum dos itens acima não for verdadeiro, não será necessário usar um formulário, e uma tabela será suficiente. O desafio que enfrentamos com a compatibilidade móvel é que nem as tabelas nem os formulários são realmente adequados para uma exibição móvel. O fato de que os projetistas de smartphones deram aos usuários a opção de usar um navegador na orientação retrato e que a maioria dos usuários prefere manter seus telefones dessa maneira causa a maioria dos problemas de compatibilidade com dispositivos móveis que os designers de sites precisam enfrentar.

Independentemente disso, os formulários são mais adaptáveis ​​a uma exibição móvel do que as tabelas. Então, se você realmente precisa garantir que todos os dados possam ser facilmente visualizados em um display móvel, os formulários são uma opção melhor do que as tabelas ... às vezes!

2. Projetar o layout da área de trabalho

É verdade que, em geral, você deve projetar um layout móvel primeiro, mas quando se trata de formulários, essa não é a melhor maneira, porque precisamos saber como os dados serão agrupados, e só podemos fazer isso se pode ver todos os campos de uma só vez, o que é algo que não pode ser feito em um dispositivo móvel, a menos que você esteja exibindo tão poucos dados que não precisamos nos preocupar com o design do formulário.

A maneira mais rápida de criar um design de formulário é com o InkScape. Neste exemplo, criaremos um sistema para gerenciar registros de RH. Aqui está o mock up para o protótipo de desktop:

O retângulo externo representa todo o espaço de uma exibição 1024 x 768 px. Em qualquer navegador de desktop, não temos acesso a muitos pixels, a menos que o usuário esteja no modo de tela inteira (o que raramente é o caso). Então nossa

O design é 900 x 600px, que deve caber na área disponível da maioria das telas de desktop.

Quando a área disponível for menor que 900px, nossas colunas 2 x 450px serão quebradas e aparecerão como uma coluna 450px contínua. Isso resolve o problema da compatibilidade com dispositivos móveis, pelo menos até que o Google exija que todos os nossos sites possam caber em uma tela de relógio de pulso.

Você notará que a maior parte da tela é composta apenas de caixas de entrada comuns, o que pode parecer chato, mas na realidade é quase sempre a melhor maneira de fazê-lo. Observe também o uso de uma fonte de largura fixa. Isso ajuda a manter a uniformidade no design de formulários.

Nossas colunas serão realmente um pouco maiores que 450px, mais como 600px cada, mas se quisermos forçar a largura da coluna a ser sobre 450px, apenas reduzimos o tamanho de nossa coluna de 6 para 5. Mas uma coluna 600px deve caber em uma tela móvel no modo retrato sem quebra automática, de qualquer maneira.

Vamos testar nosso layout com este código:

E podemos ver que tudo parece bem (porque temporariamente acrescentamos fronteiras para nos mostrar).

O widget de régua de tela do Linux obviamente não faz parte da página da Web, mas está lá para nos mostrar que nossas colunas não vão quebrar muito em uma tela menor. Vamos o que acontece em diferentes larguras de tela comuns:

3. Criando tamanhos de entrada personalizados e posição de rótulo

Se deixarmos tudo como padrão, sem adicionar CSS personalizado, isso é o que acontecerá quando adicionarmos nossa primeira linha de controles de entrada:

Isso acontece porque o rótulo de cada entrada é padronizado à esquerda da entrada e porque não definimos uma largura personalizada para os controles de entrada. Podemos corrigir os dois problemas com CSS.

Agora, apenas definimos a propriedade de exibição dos elementos de rótulo como "block", definimos os campos First e Last como "in40w" e o campo MI como "in10w", e tudo deve ser mais bonito.

Como você pode ver, ele parece melhor, mas o layout não está mais correto. Agora as caixas estão empilhadas. Então, como consertamos isso é acabar com a idéia de usar o elemento label, porque realmente não precisamos disso. Nós vamos apenas aplicar o nosso in40w e in10w classes, além de fazer uma nova classe chamada inLeftOf.

Que, uma vez aplicado, corrige o problema que vimos anteriormente, assim:

Mas isso não está deixando espaço suficiente para o campo SSN. Isso porque nossa coluna da esquerda é maior do que o esperado, então 40% é na verdade mais espaço do que o necessário para esses campos, então podemos realmente reduzi-los a in30w, e o campo do meio é maior do que o necessário, então podemos fazer isso in5w. Veja o que acontece:

Portanto, agora há espaço mais que suficiente para adicionar o campo SSN, que completa a primeira linha do nosso formulário de entrada. Depois de suavizar todos esses detalhes, construir o resto da coluna da esquerda deve ser muito fácil. Podemos nos livrar da borda temporária agora e também aplicar o plano de fundo correto à coluna. Aqui está a metade superior do painel, antes de chegarmos a áreas especiais do formulário:

Algumas coisas aconteceram nesta fase. A primeira foi a parte fácil de definir a cor de fundo para a coluna (rgb (235,235,246)), e embora você não possa vê-la aqui, a cor do texto de todas as entradas foi definida como #427DB4 e o peso da fonte foi definido para negrito, de modo a reduzir a fadiga ocular. O texto foi configurado para se transformar automaticamente em maiúsculas usando a propriedade text-transform CSS, para acelerar a entrada de dados e reduzir os erros.

A questão mais complexa de alinhar os controles e certificar-se de que eles manteriam um alinhamento decente em qualquer tipo de tela exigia mais reflexão. Você já viu a técnica usada para a primeira linha de entradas e seus rótulos. Essa técnica funcionará quando não precisar de espaçamento adicional entre as entradas, mas se precisarmos adicionar espaço, é melhor usar outra técnica.

Essa outra técnica envolve a criação de uma linha aninhada de colunas dentro de nossa coluna principal, o que ajudará a manter os controles corretamente espaçados. O número de colunas e seus tamanhos muda dependendo dos requisitos de cada conjunto de controles. Lembre-se de que tudo é responsivo, portanto, quando uma coluna é redimensionada, tudo dentro da coluna tentará redimensionar para corresponder à alteração. Esta é uma boa notícia para usuários com deficiências visuais, pois eles podem ampliar a ampliação de sua tela e tudo será alinhado corretamente como para qualquer outro usuário.

Passando para a parte mais complexa da coluna da esquerda, o conceito original delineado no mock-up exigia uma estrutura que teria sido difícil de implementar. Felizmente, percebi que os dados no painel de direitos poderiam ser duplicados se as caixas de seleção padrão fossem usadas, e isso resolveu bem o problema de complexidade de layout:

Os painéis mais leves ao redor das seções especiais são apenas poços comuns do Bootstrap. Para inserir dados religiosos, é necessário escolher entre uma lista de religiões oficiais predefinidas (incluindo “outras”). Desenvolver as colunas do lado direito foi ainda mais fácil, e usei as mesmas técnicas do primeiro conjunto de controles na coluna da esquerda, organizando os controles em um formato de tabela, mas sem usar uma tabela.

Para que esse projeto fosse um sucesso, ele precisava fornecer uma capacidade de resposta perfeita em todos os tamanhos de exibição oficiais. Vamos ver como o resultado acabou. Primeiro com a versão de resolução completa:

Isso está perto o suficiente do protótipo de que podemos ficar satisfeitos com isso. Na verdade, é até uma melhoria. Agora vamos ver o layout responsivo em cada uma das diferentes seções da página:

O Bootstrap e o HTML5 tornaram o desenvolvimento de formulários mais rápido e fácil do que antes, mas muitos desenvolvedores solapam esse progresso, tornando os formulários muito complicados (usando os elementos especiais do formulário HTML5 apenas porque eles estão lá para serem usados ​​em vez de porque são necessários para o projeto ), e criando formulários unidimensionais que nem sequer tentam tirar proveito do design responsivo. Com um pouco de cuidado e trabalho extra, qualquer dado pode parecer mais apresentável em qualquer tamanho de tela.

Você pode ter alguns pequenos defeitos no menor tamanho de tela no layout de retrato no menor tamanho de tela (no caso deste projeto, o campo Middle Initial na primeira linha é um pouco menor do que seria ideal), mas os usuários móveis geralmente Aceite que este é o trade-off que eles têm que fazer para não segurar seus telefones corretamente.

Faça certo, e seus formulários de dados podem ser assim:

Em vez de, uh, isso:

imagem de cabeçalho cortesia de

Bogdan Rancea

Bogdan é um membro fundador da Inspired Mag, acumulando quase 6 anos de experiência neste período. Em seu tempo livre, ele gosta de estudar música clássica e explorar artes visuais. Ele é muito obcecado com fixies também. Ele é dono do 5 já.