Validação e divulgação progressivas
Estou tentando encontrar um exemplo de validação progressiva. Temos uma interface do usuário para um editor visual em que um usuário faz coisas como indicar dimensões em pixels ou porcentagem.
As propriedades do editor estão em conjuntos de guias, portanto, nem todos os campos são visíveis ao mesmo tempo. Temos discutido como e se fazemos a validação nesta interface do usuário.
Sou da perspectiva de que: a) A validação é útil porque cria um canal de comunicação onde o usuário pode aprender as expectativas do software e "melhorar" o que é necessário. b) É sempre melhor indicar erros de validação diretamente nos campos de entrada (se um resumo é ou não usado em outro lugar) para que os usuários tenham uma dica visual do que precisa ser alterado.
Meu colega, por quem não tenho nada além do maior respeito, discorda. Sua lógica é a seguinte: a) Será mais conveniente impedir certos tipos de entrada ou, no caso de alguma entrada, alterá-la para um valor mais apropriado se for inválida. Por exemplo, se alguém usar um valor percentual maior que 100, a interface do usuário redefinirá o valor para 100 em um evento de foco perdido. b) Como estamos em um ambiente de guias, alguns dos erros não serão visíveis para o usuário. Usar um resumo é inútil, pois pode haver "muitos" erros de validação.
Eu pensei que uma solução para isso poderia ser uma divulgação progressiva de valores inválidos. Como um usuário insere valores que podem estar incorretos, eles são sinalizados em algum tipo de resumo. O resumo permite que os usuários navegem até os campos em questão sem que eles estejam visíveis.
Eu gostaria de ser uma pessoa original, mas tenho certeza de que há precedentes aqui. Minhas perguntas são as seguintes:
Algo a acrescentar às perspectivas de mim ou do meu colega?
Algum exemplo de uma interface do usuário como esta com entrada complexa que faz validação progressiva?
No momento, estamos enfrentando o mesmo problema em um aplicativo de desktop, embora não com base em guias. Você pode tentar uma abordagem como esta:
onde um pequeno ícone aparece se algo exigir a atenção do usuário. Talvez até use duas cores: amarelo para avisos e vermelho para itens que devem serão corrigidos antes que o usuário possa ir mais longe.
A melhor coisa que você pode fazer nessa situação complexa é criar um protótipo do máximo possível da interface do usuário e teste-o na sua base de usuários para ver o que acontece. Você pode usar HTML em combinação com algo como a interface do usuário do jQuery para obter rapidamente vários controles interativos disponíveis e prontos para testar rapidamente.
Seu sistema de guias parece complicado, então eu tenho que sugerir algumas coisas para simplificar:
- Crie botões "aplicar" em cada guia para que o estado possa ser salvo apenas para as propriedades que o usuário pode ver agora. Se isso resultar em um estado de aplicativo inválido, redesenhe suas guias para que os usuários tenham propriedades agrupadas que podem ser salvas independentemente umas das outras.
- Se você não puder fazer isso, poderá destacar as guias com um ícone "inválido" e uma cor para indicar que as propriedades nessa guia precisam de atenção. Embora qualquer guia seja inválida, o botão "Aplicar" está desativado. Você pode considerar adicionar uma notificação ao botão se ele for clicado para exibir uma mensagem indicando que ainda existem erros. Resumos do que está errado seriam exibidos em cada guia, em vez de ter um resumo abrangente.
- Um resumo global pode funcionar, mas hesito em sugeri-lo, pois parece que não haveria um local imediatamente óbvio para colocá-lo, e, a menos que seja esse o caso, os usuários perceberão?
- Como as propriedades são agrupadas? Provavelmente funcionalmente? Tente observá-los de um ângulo diferente, por exemplo, com probabilidade de uso. Isso faz parte de como a Microsoft abordou o design da faixa de opções para seus produtos do Office 2007. Talvez você possa projetar suas guias de maneira que a maioria dos usuários precise mexer nas propriedades da primeira ou imediatamente visível, e as outras guias possam ser consideradas "avançadas" ou contextuais.
Por fim, e eu já disse isso, teste seu design! :-)
Quanto a lidar com erros, minha experiência foi que, se você impedir determinadas entradas, os usuários ficarão confusos. Por exemplo, se não estiver claro em um campo de entrada que apenas números são permitidos, mas você desaprova outros caracteres de qualquer maneira, isso será frustrante para o usuário - eles não o experimentarão como uma forma inteligente que está tentando ajudá-los . Portanto, sugiro que você use uma microcópia clara em todo caso decida seguir o caminho do uso de eventos e detecção de entrada para corrigir automaticamente as coisas.
Mas tudo isso é anedótico - eu não fiz nenhuma pesquisa nesta área. Em vez de aceitar minha palavra, consulte o livro de Luke Wroblewski, Design de formulários da Web: preenchendo os espaços em branco , e sua pesquisa sobre tratamento de erros para obter algumas informações úteis sobre como lidar com situações como essa (para Por exemplo, este postado no redesenho do formulário de checkout da Apple discute como eles lidam com os erros em detalhes).
Recentemente, trabalhei em um projeto que encontrou um problema semelhante. Você pode ver uma captura de tela de como a resolvemos no meu artigo " Minimizing Complexity " do ano passado.
Pensei em um caso em que um resumo de muitos erros é usado e talvez funcione.
Em qualquer IDE como, digamos, no Visual Studio, há potencial para infinitas quantidades de erros ao criar ou usar qualquer ferramenta de análise estática ao escrever código. Geralmente existem dezenas ou centenas de arquivos e muitos deles são abertos no guias, com uma ou duas visíveis a qualquer momento,
Os erros são listados em uma lista redimensionável rolável que desliza (por padrão) abaixo da interface do usuário principal. Isso pode ser feito assim que um erro for capturado. Quando um erro é clicado ou clicado duas vezes, ele leva você ao lugar certo e o foco para corrigi-lo - e o erro desaparece da lista quando não é mais válido.
(Na verdade, muitos desses erros precisam de uma ação iniciada pelo usuário para serem reavaliados, mas existem muitos suplementos de análise estática que fazem isso em segundo plano e atualizam dinamicamente a lista de erros ao editar o código) .
a) Por exemplo, se alguém usar um valor percentual maior que 100, a interface do usuário redefinirá o valor para 100 em um evento de foco perdido.
Bom ponto, mas você precisa ter certeza de:
- O usuário percebe que sua entrada foi corrigida.
Talvez, por exemplo, faça o campo piscar por um segundo se você fixar o valor. - Você pode adivinhar razoavelmente o que o usuário realmente quis dizer.
Por exemplo, pegue um seletor de cores com o qual lutei ontem. Eu queria que alguns elementos correspondessem aos de outro site, então obtive os valores hexadecimais e os colei em pequenas caixas de texto ad-hoc. O primeiro valor foi#202040, mas por alguma razão eu só colei#20204, que foi prontamente "corrigido" para#020204. O segundo valor em que colei foi#BCD(abreviação de#BBCCDD), que também foi "corrigido" para ...#000BCD. Suspiro.