Qual é a melhor experiência do usuário: destacar erros ou bloquear pressionamentos de tecla errados?
Tenho algumas informações para inserir em uma caixa de texto. Os dados são estruturados e apenas algumas seqüências são válidas. Para um número de telefone, por exemplo, uma letra como A é inválida.
Portanto, devo interceptar os eventos do teclado e impedir que as letras digitadas cheguem à caixa de texto, ou devo desenhar algumas linhas onduladas vermelhas (ou outra dica visual) para informar ao usuário que a letra não é aceitável? Qual é a melhor experiência do usuário?
A substituição do controle de um usuário pelo computador sempre será uma interrupção e, muitas vezes, será percebida como uma invasão do fluxo de trabalho desse usuário. O site "não deveria" ter o controle de nossos computadores, portanto, exercer esse controle será pelo menos um pouco alarmante.
Dito isso, você aborda um tópico realmente importante, sendo a importância de informar ao usuário que sua entrada é inválida antes de preencher um conjunto inteiro de campos e enviá-los.
A abordagem que eu achei menos intrusiva, mas que fornece a resposta mais rápida, é o fluxo abaixo.
Essencialmente, espere que eles preencham seu primeiro campo e, à medida que clicam/separam um novo campo (ou um campo que foi invalidado), verifique o campo que acabou de ser concluído. Se o campo que acabou de ser preenchido for válido, imprima um ícone "bom" discreto ao lado dele (verde, marca de seleção, sorriso no rosto, você entendeu). Se falhar nas regras de validação, imprima discretamente um ícone "ruim" (vermelho, "X" etc.) e uma linha curta sobre o que falhou.
Mas lembre-se, não interrompa o fluxo de trabalho:
- Sem pop-ups
- sem sobreposições
Quando terminarem o campo para o qual foram movidos, eles voltarão ao campo inválido ou seguirão em frente e voltarão mais tarde. De qualquer forma, eles verão que têm uma edição para fazer, mas podem fazê-lo em seu próprio tempo.
No final, eles terão um formulário completamente válido antes de enviá-lo, o que significa
- Eles só terão que enviar uma vez
- Eles não perdem tempo ficando bravos ou frustrados quando a submissão "falha"
- Eles vão gostar mais do seu site
- Todo mundo vai ter bolo
Sendo nas duas extremidades do uso de um formulário, aqui estão algumas diretrizes que eu prefiro:
- As entradas do usuário quase nunca devem ser evitadas. Ou seja, se eu digitar a letra 'A' em um campo de número de telefone, esperaria ver 'A'.
- Começo minha validação de campo de texto em um evento
onBlur(), e não antes disso. Isso dá ao usuário a chance de corrigir o erro 'A' antes que eu mostre uma mensagem de erro. Permitir que o usuário corrija um erro enquanto ainda está no campo de entrada oferece menos uma chance para o tipo de mensagem "ei, você errou, cara".
Se você impedir caracteres inválidos enquanto digitam, eles podem pensar que o teclado está com defeito. As coisas do usuário funcionam da maneira que esperam. Se você deseja impedir que certos caracteres sejam pressionados com a tecla pressionada, você também deve exibir uma mensagem de erro ao lado da entrada ao mesmo tempo. Dessa forma, eles sabem por que não está digitando.
Outra coisa que pode ser irritante é quando você termina de preencher um formulário longo e o site usa a validação no servidor, então você precisa voltar ao formulário para descobrir o que está errado. Eu gosto de usar a validação do lado do cliente principalmente, mas recuo no lado do servidor. Eu exibirei um erro enquanto eles estão digitando ou quando a entrada perde o foco. Dessa forma, o usuário sabe imediatamente que há um problema e sabe exatamente qual é o problema.
Acho que impedir os usuários de cometer erros é sempre 10 vezes mais difícil do que eu pensava inicialmente. Exemplo: o número de telefone de alguém pode ter um ramal, como x2333. Eu usei o plugin da máscara de entrada do jQuery para cartões de crédito e funcionou bem. Uso a sugestão automática sempre que possível.
Em qualquer sistema complexo, você terá circunstâncias caras para detectar em linha e precisará informar após o fato. Para mim, a resposta é caso a caso e certifique-se de cobrir todos os casos do Edge.
Eu sugeriria um híbrido de ambas as abordagens, mas apenas para campos estritamente validados, como números de telefone (SSN, códigos postais, etc ... qualquer coisa que deve seja numérica por definição).
Acompanhe cada pressionamento de tecla e, quando o usuário digitar um caractere inválido, mostre-o ... mas sinalize imediatamente que algo está errado. Talvez deixe o campo de entrada vermelho e exiba "Por favor, digite apenas caracteres numéricos" à direita do campo.
O bloqueio de entrada é um não-não, porque pode ser mal interpretado pelo usuário. Eles podem assumir um problema com sua máquina ou dispositivo de entrada, não que não devam digitar uma letra em uma caixa de entrada numérica.
A validação após a entrada é concluída pode ser irritante. Particularmente em campos como os usados na criação de senhas. Alguns sites exigem senhas de 6 caracteres com apenas caracteres alfanuméricos. Outros exigem senhas de 9 caracteres e permitem qualquer caractere (incluindo! @ # $% E outros). Digitando uma senha e descobrindo depois de digitar, é o tipo de formulário mais irritante que encontrei e, na verdade, me afastou de vários serviços .
Fornecer feedback dinâmico à medida que o usuário insere dados os ajuda
- Saiba qual campo teve o erro enquanto ainda está no campo
- Corrija de forma proativa os erros de entrada antes de enviar dados
- Aprenda com a experiência à medida que avançam
A entrada de bloqueio falha nas 3 contas. Destacar erros de validação após o preenchimento da caixa de texto também falha nos três.
Depende do caso. Se possível, use a sugestão automática. Se você intercepta a entrada do usuário, um feedback imediato é crucial. Uma das soluções possíveis é a "caixa de pista" que aparece imediatamente após a chave ser interceptada. Você pode vê-lo na tela de login do Windows; ele aparece se você pressionar $ sign, por exemplo.
Como na maioria das coisas, depende do contexto. Eu tenho uma visão mais especializada sobre o assunto. A maioria dos aplicativos em que eu, ou meu grupo, trabalho, são de natureza técnica e são usados apenas por profissionais razoavelmente treinados. Como tal, podemos colocar mais responsabilidade e liberdade nas mãos dos usuários do que você poderia com o público em geral. Resumidamente, algumas das diretrizes que usamos ...
- Ignore qualquer entrada inválida .... bloqueie pressionamentos de tecla inválidos.
- Indique campos inválidos, um estado que deve ser praticamente impossível, por contraste e cor *.
- O foco está sempre sob controle do usuário. Não prenda o usuário ou evite uma mudança de foco.
- Nunca jogue uma caixa de aviso/erro modal. Sempre.
- Nunca faça perguntas ao usuário. Software é uma ferramenta, não uma pessoa. Sim eu tenho certeza.
- As teclas Enter/Return sempre significam: Aceitar alterações e seguir em frente. Não altere isso usando o foco em um botão de cancelar/sair como padrão em Enter.
- A tecla Escape sempre significa: descartar e sair.
- Forneça o preenchimento automático sempre que possível.
- Forneça entrada de atalho para números que tenham um limite mínimo/máximo. por exemplo. Se um valor válido estiver entre 0,12 e 100,387, as entradas maiores que 100,387, como 999, serão consideradas 100,387 etc.
- Estabeleça regras em preto e branco muito claras sobre o comportamento ... regras que o usuário pode entender. Se isso se tornar excessivamente complexo ... repense.
Quase todos os exemplos são solicitados pelo usuário e, sim ... a implementação às vezes é um verdadeiro urso/pesadelo/assassino, mas raramente impossível.
Advertência: Novamente, esses exemplos são dados no contexto de um sistema vertical com uma base técnica de usuários ... não uma forma pública geral da web, etc. Sua milhagem pode variar.
* Exceto vermelho. Nos nossos negócios, vermelho significa: Perigo, você pode ser morto ... ou pior.