Conteúdo e Navegação

Formulários

A principal forma de interação dos utilizadores numa página de internet, e especialmente em portais públicos, são os formulários e neles residem alguns problemas de usabilidade.

Os formulários e o seu preenchimento devem ser intuitivos para os utilizadores, evitando bloquear o seu caminho e facilitando a concretização dos seus objetivos.

Relativamente ao preenchimento do formulário, é importante que, para além de simples, este apenas tenha os campos necessários. Em relação à componente visual, é importante respeitar as convenções e padrões mais comuns, a não ser que algo o justifique. Assim, devemos evitar elementos dissonantes, como campos de preenchimento estilizados, pois estes podem provocar dúvidas nos utilizadores.

Um exemplo é a utilização de um design diferente do que é considerado standard nas checkboxes e que podem depois ser confundidas com botões rádio sendo que estes têm objetivos e funções diferentes.

Devemos também considerar sempre que a principal função do formulário se centra na submissão de informações. Assim, é necessário garantir a diferenciação do botão submeter das outras ações secundárias, como o botão de Cancelar, para que os utilizadores não cliquem no botão errado por engano e percam os dados que acabaram de inserir.

 

Distinguir os itens de preenchimento obrigatório

Os campos de preenchimento obrigatório devem distinguir-se claramente dos outros. Atualmente, uma grande parte dos sítios da internet usa um asterisco à frente do nome do campo para os identificar como obrigatórios. No entanto, há outros sítios que preferem o uso da palavra “obrigatório” em vez do asterisco.

 

Qualquer uma destas duas soluções é válida, embora a utilização do asterisco cria a obrigatoriedade de criar um aviso, no topo do formulário, indicando que os campos marcados com * são de preenchimento obrigatório.

Em ambas as alternativas, a nota relativamente à obrigatoriedade de preenchimento dos campos marcados deve estar incluída na label do campo e não fora dele.

 

Também é possível efectuar a validação inline (em linha) do preenchimento dos formulários, utilizando o atributo required com a etiqueta <label> no código do vocabulário, possibilitando o envio de informação de aviso ao utilizador, se este não preencher os campos obrigatórios.

Código
Ocultar Código
  • HTML

<div>
  <label for="nome">Nome <em>(obrigatório)</em></label>
  <input id="nome" type="text" required name="nome" placeholder="O seu nome" value="" />
</div>

Isto permite que os conteúdos sejam lidos corretamente pelos screen-readers (software de leitores de páginas). Nestes casos, o nome do campo e a informação de que é de preenchimento obrigatório, são transmitidos oralmente ao utilizador.

No caso de a maioria dos campos serem de preenchimento obrigatório, pode-se simplificar optando por indicar simplesmente os campos que são opcionais.

Nota: devemos levar em conta que quando se valida por intermédio do atributo required, este comando não funciona de raiz em todos os navegadores. Sempre que o navegador não faz a validação automaticamente, é necessário que esta seja feita do lado do servidor (server-side).

 

Colocar as etiquetas (labels) perto do respetivo campo

As labels, ou etiquetas, devem posicionar-se de forma a que estejam visualmente próximas em relação ao campo a que dizem respeito. Há várias maneiras de as posicionar perto dos campos, sendo que todas têm vantagens e desvantagens.

Os exemplos que se seguem fazem parte de um aprofundado estudo, desenvolvido por Luke Wroblewsky, sobre formulários.  

Consulte aqui o estudo completo: http://static.lukew.com/webforms_lukew.pdf

 

Etiquetas (labels) no topo (recomendado)

 

Vantagens: Leitura e preenchimento mais rápidos e os títulos estão próximos dos respetivos campos. 

Desvantagens:  Os formulários ficam verticalmente maiores, forçando por vezes o scroll na página.

 

Aconselha-se o uso deste tipo de alinhamento quando se pretende diminuir o tempo de preenchimento e quando não existe constrangimentos de espaço.

 

Etiquetas (labels) à esquerda com alinhamento à direita

 

Vantagens: Os títulos também se encontram muito próximos dos respetivos campos e ocupa um espaço vertical reduzido, evitando muitas vezes o scroll.

Desvantagens: A legibilidade é reduzida.

Aconselha-se o uso deste tipo de alinhamento quando existem constrangimentos de espaço na vertical.

 

Etiquetas (labels) à esquerda, com alinhamento à esquerda

Vantagens: Espaço vertical mais reduzido, o que permite mais campos sem recorrer ao scroll e uma melhor legibilidade dos títulos, já que estes se encontram todos alinhados à esquerda.

Desvantagens: Maior afastamento entre os títulos e os campos do formulário, que pode dificultar a perceção a que campo corresponde um determinado título.

Aconselha-se o uso deste tipo de alinhamento quando se pretende que os utilizadores possam fazer uma leitura rápida de todas as perguntas, mas só têm que responder a algumas.

 

Etiquetas (labels) dentro dos campos

Nesta solução, tal como o nome indica as labels, ou etiquetas, surgem dentro do campo de preenchimento. Trata-se de uma solução que só deve ser usada quando há constrangimentos extremos de espaço ou quando os campos usados são poucos e rapidamente percetíveis, como por exemplo num formulário de autenticação, onde os únicos requisitos são o “nome de utilizador” e a “palavra-passe”.

Para que seja evidente a distinção entre o texto das etiquetas e o texto que é preenchido pelo utilizador no mesmo campo, o que normalmente acontece é que o texto das etiquetas surge a cor cinzenta e o texto preenchido pelo utilizador surge a preto. Os navegadores modernos conseguem por norma garantir esta distinção através do atributo placeholder.

Por fim, é de evitar alinhamentos diferentes no mesmo formulário, pois pode quebrar o padrão de leitura dos campos. Deve-se manter a coerência de um tipo de alinhamento ao longo do formulário em questão, e até mesmo dos outros que possamos ter no mesmo sítio da internet.

 

O texto nos botões deve ser claro

Os botões do formulário devem indicar claramente a ação que resulta do seu clique. Os textos típicos que surgem nestes botões costumam ser: “Atualizar”, “Gravar” e “Enviar”.

 

Botões com o texto “Sim”, “Não”, “OK” são de evitar pois, isso obriga o utilizador a ter que ler o texto que lhes antecede com o propósito de entender o que pode resultar do clique numa dessas opções.

 

Anular o cancelamento

Sempre que um utilizar carregar num botão “cancelar”, deve surgir uma nova questão para confirmar esta ação. Nesta caixa de diálogo, não devemos apresentar opções de resposta como “ok” e “cancelar”, já que ambas entram em conflito causando confusão pois parecem representar respostas semelhantes.

Este conflito pode ser resolvido adaptando o texto dos botões de forma a torná-lo o mais esclarecedor possível, evitando o surgimento de dúvidas. Utilizar por exemplo: “Cancelar a Conta”, “Anular o Cancelamento”, ou “Manter Conta e Voltar”.

 

Ações principais e secundárias

De forma a evitar que o utilizador cometa erros, é essencial haver um fator diferenciador a nível visual entre a ação principal e a secundária.

Uma ação principal é aquela que cumpre o seu objetivo, caso por exemplo da submissão de um formulário, as ações secundárias neste processo são as que limitam e atrasam o cumprimento deste objetivo, caso do voltar atrás, limpar ou cancelar.

Assim para ajudar a diferenciar estas ações podem usar-se botões desde que estes correspondam sempre a ações que o utilizador pretende realizar como por exemplo: Guardar, Atualizar, Enviar, Encerrar, Terminar, Abrir, etc.

Um exemplo desta utilização é nos formulários, onde as ações principais deverão ser possíveis através de botões e nunca através de ligações.

Ações secundárias como “Cancelar”, “Limpar” ou “Voltar Atrás” contrariam e atrasam o objetivo da ação principal do formulário (ex.: submissão de um pedido de alteração de morada). Estas opções secundárias, se não forem usadas corretamente, podem revelam-se mais perigosas do que úteis. O utilizador não vai gostar de saber que apagou os todos dados que acabou de preencher, porque clicou sem querer no botão “Limpar”. Assim sendo, as opções secundárias só devem aparecer quando são realmente necessárias. Por exemplo, quando surge a opção” Cancelar” ao lado da opção principal “Gravar”, sendo que esta distinção de ações deve ser bem clara para o utilizador.

Após alguns testes com utilizadores onde se pôs em prática o contraste ente as duas opções de ação primária e secundária, os utilizadores referiram que tiveram que ler o que estava escrito em cada botão para não clicarem no botão errado. Isto acontece porque às vezes temos o hábito de clicar sempre no primeiro botão que surge, ignorando a sua leitura e perder os dados do formulário que acabámos de completar. Este resultado reforça a importância de definir claramente a ordem em que os botões de ação aparecem.

 

Localização dos botões

Os botões que permitem continuar a ação ou retroceder devem estar alinhados os botões no seguimento dos campos do formulário. Desta forma, uma vez que os campos estão encostados à esquerda, é natural que o botão de ação principal também esteja encostado à esquerda. Esta lógica pretende que o utilizador tome uma decisão mais eficaz e intuitiva. Só precisa de continuar para baixo e submeter o formulário de forma natural sem ter que pensar muito.

 

Depois de alguns testes com utilizadores, concluiu-se que a colocação de botões ao centro ou à direita obriga um desvio do olhar e do rato para poder submeter o formulário. Estes desvios causam a perda de alguns segundos nesta interação. Caso não haja uma distinção evidente entre os botões de ação principal e os de ação secundária, o facto de estarem alinhados à direita, pode levar os utilizadores a carregarem no botão que se encontra mais à direita, independentemente deste ser ou não o botão principal do formulário.

Porém, podem surgir algumas exceções à regra. Em situações que envolvam um processo que consiste no preenchimento de vários passos, podem ser apresentados botões à esquerda com as ações de “voltar atrás” e botões à direita com as ações de “continuar” seguindo a lógica de que o botão à esquerda consiste em voltar para trás e o à direita para continuar a preencher o formulário.

 

Submeter formulários através de HTML

Os formulários devem ser submetidos exclusivamente com HTML. Apesar disto, pode ser usado código Javascript "submit()" ou "onClick()" permitindo desta forma que que os formulários enviem os dados preenchidos pelo utilizador. A submissão dos formulários (submit) deve ser sempre realizada com o recurso de um botão/input e nunca através de um link.

Código
Ocultar Código
  • HTML

<input type="submit" value="Gravar Alterações" />
<!-- ou: -->
<button type="submit">Gravar Alterações</button>

Esta situação não anula a possibilidade de usar JavaScript para fazer validações dos dados preenchidos pelo utilizador no sentido de dar mensagens de erro/sucesso correspondentes.  No entanto, é preciso ter a certeza que se o JavaScript for desativado, o formulário é enviado, juntamente com os erros detetados e registados no formulário, via “server-side”.

 

Aceitar várias formas de preenchimento dos dados

A informação requerida nos formulários pode ser inserida de várias formas e é necessário salvaguardar que essas mesmas formas são aceites.

Os dados inseridos pelo utilizador, para o formato aceite pelo sistema, são convertidos pelo formulário que por sua vez deve ser suficientemente inteligente para o interpretar e converter. Um exemplo são os campos numéricos que podem ser configurados para assumir logo o formato da métrica europeia, ou da data.

As mensagens de erro só devem ser dadas ao utilizador quando este inserir um dado inválido.

Por outro lado, também se pode usar pistas de preenchimento, ou formatar os campos de forma a obrigarem ao preenchimento de uma determinada maneira. No caso da inserção de um código postal, por exemplo, a inserção deste é feita em dois campos, o primeiro só aceita 4 dígitos e o segundo 3. Ambos os campos só aceitam números e rejeitam qualquer outro caractere. O ideal é evitar que os erros de preenchimento aconteçam, até porque em muitos casos os utilizadores inserem os dados sem ler as instruções sobre como o devem fazer corretamente.