Como você lidaria com usuários que não lêem caixas de diálogo? [fechadas]

StackOverflow https://stackoverflow.com/questions/125269

  •  02-07-2019
  •  | 
  •  

Pergunta

Um artigo recente sobre Ars Technica discute um estudo recente realizado pelo Departamento de Psicologia da North Carolina State University, que mostrou os usuários têm uma tendência a fazer o que for preciso para se livrar de uma caixa de diálogo para voltar a sua tarefa em mãos. A maioria deles, clique em OK ou sim, minimizar o diálogo ou fechar o diálogo, independentemente da mensagem que está sendo exibida. Algumas das caixas de diálogo exibida eram reais, e alguns deles eram falsos (como aqueles popups exibidos por páginas posando como um aviso antivírus). Os tempos de resposta indicaria que esses usuários não estão realmente lendo essas caixas de diálogo.

Então, sabendo disso, como é que este efeito o seu design, eo que você tentaria fazer sobre isso (se alguma coisa)?

Foi útil?

Solução

Eu tento projetar aplicações para ser robusto em face dos acidentes - ou deslizamentos (operações inadvertidas, como clicar no lugar errado) ou erros (erros cognitivos, como clicar Ok vs. Anular em um diálogo). Algumas maneiras de fazer isso são:

  1. infinito (ou, pelo menos, de multi-passo) desfazer / refazer
  2. integrar documentação com a interface, através de dicas de ferramentas dinâmicas e outros meios sensíveis ao contexto de comunicação (Um papel que é particularmente relevante é de cerca de 'Surprise, Explicar, Recompensa' (link direto: SER ) - utilizando respostas psicológicas típicas para um comportamento inesperado para informar os usuários)
  3. Incorporar o estado do sistema na dita documentação (use os dados do usuário atual como exemplos, e fazer o concreto documentação usando dados que eles podem ver agora )
  4. Esperar user erro. Se há uma chance de que alguém vai tentar escrever para a: \ quando não há um disco no lugar, em seguida, implementar um limite de tempo para que o sistema pode falhar normalmente, e aviso para outra localização. Guardar os dados na memória até que seja seguro em disco, etc.

Esta se resume a duas coisas principais: (1) defensivamente Programa, e (2) Mantenha o usuário tão bem informado quanto possível. Se a interface do sistema é fácil de usar, e se comporta de acordo com as suas expectativas, então eles são mais propensos a sei qual botão para clicar quando um aparece de diálogo irritante.

Eu também tento muito, muito difícil de evitar qualquer coisa modal, para que os usuários pode ignorar a maioria dos diálogos que tenho de usar, pelo menos por um tempo (e quando eles realmente precisam de prestar atenção a eles, eles têm informação suficiente para saber o que fazer com ele).

É impossível fazer um sistema à prova de idiota completamente, mas eu descobri que as técnicas acima percorrer um longo caminho na direção certa. (E eles foram incorporados nos sistemas usados ??para desenvolver Surprise Explique Recompensa e outras ferramentas que foram controladas por extensos estudos de usuários.)

Outras dicas

Em primeiro lugar o uso de cores e ícones devem ajudar a dar ao usuário alguma consciência visual da gravidade do problema, vermelho para transmitir excepcional, amarelo para transmitir um aviso, e branco para transmitir informação.

Em segundo lugar o uso de verbos em seus botões de diálogo dá aos usuários uma sensação de que eles estão dizendo ao sistema para se fazer se eles não lêem o texto da caixa de diálogo.

Por fim, se você estiver interessado em olhar para uma verificação de paradigma notificação completamente diferente fora da barra de informações ou Notificação Bar que é implementado no Firefox e Internet Explorer. StackOverflow usa o mesmo tipo de mecanismo para notificar os usuários quando eles têm obtido um novo emblema.

A barra de informações é não-intrusivos e estadias no topo da tela à espera de atenção do usuário. Eu acho que é um grande projeto metáfora.

Aqui estão alguns tutoriais de implementação:

Aqui está orientação da Microsoft no design de diálogo , que toca no conceito da informação Bar também.

Imediatamente livro de Steve Krug Não me faça pensar vem à mente.

No projeto de caixas de diálogo, mensagens de status de volta para o usuário, etc, é bom usar iconografia e cor dicas sobre o que as palavras realmente dizer.

mensagens de erro destaque tão vermelho, avisos amarelo, etc.

A Interface Humane, por Jef Raskin vale a pena ler. Uma caixa de diálogo é o último recurso, e um sinal de má concepção. A maioria são desnecessárias, e como você descobriu todos são ignorados pelos usuários.

Por que há uma caixa de diálogo? Resolver esse problema - não pedir aos usuários para confirmar uma operação, em vez se torna mais fácil para desfazer a operação. Não aparecer uma caixa de diálogo anunciando um erro - fazer o que a recuperação está indo fazer de qualquer maneira (ou o que é possível). Definitivamente não mostrar caixas de diálogo que têm apenas um resultado ( 'OK' apenas as caixas são o diabo) apresentar as informações dentro do aplicativo de forma discreta.

Um par de sugestões

  1. Use apenas caixas quando absolutamente necessário.
  2. Sempre definir a opção padrão para a opção menos perigosa

A .NET Rochas episódio vem à mente (eu acredito episódio 338, "Mark Miller sobre a Ciência do bem UI" ) discute este tema. Acho que o que é a chave para toda esta discussão é que este é o design da interface do usuário básica levado muito longe. Onde o modal era uma vez um meio aceitável de comunicação encontramos agora que se tornou a programação gafe. Os usuários a entender que 6 em cada 10 vezes a informação não é suficiente pertinente para eles para se preocupar. Como resultado, eles tratar todos os modais da mesma forma - desamparo aprendido. Se um modal vem e me diz que erro de aplicativo X ocorreu e tudo o que posso clique é "OK" --mesmo quando eu não acho que isso é "OK" eu aprender um comportamento particular. I assosciate modais com a idéia de que eu provavelmente não pode fazer muito sobre eles, mas se eu clicar OK / Sim, então eu posso voltar para o que eu preciso.

Então, por que é ainda usado? Talvez desenvolvedores têm tentado evitar o fato de que o desenvolvimento de aplicativos está se tornando mais do que apenas uma interface básica, e os usuários necessitam de um design de interface fluido - esperas velhas são difíceis de desistir ...

Eu acho que a chave aqui é entender que um bom design de interface do usuário agora indica que as interrupções (até mesmo o usuário mais novato computador) são incômodos e precisamos nos esforçar para ter uma experiência de usuário perfeita, onde o foco do aplicativo é o usuário - e não as necessidades da aplicação via alertando e relatório de erros -. não permitir que um usuário entrar em situações onde eles não se importam

Muitas vezes os desenvolvedores usam caixas de diálogo modais simplesmente porque é fácil de código-los.

No entanto, as notificações não-modais são muitas vezes mais conveniente para o usuário a lidar com eles.

Uma sugestão:

  1. Não use caixas de diálogo. Especialmente modal, OK / Cancelar caixas de diálogo.

Às vezes isso é difícil ... Como você lida com a abertura de um arquivo? Às vezes é fácil ... você realmente precisa para avisar o usuário que eles estão prestes a substituir um arquivo? As possibilidades são, se eu estou cegamente clicando em "OK", eu não vou atenção todos os avisos que seja.

Se você deve usar uma caixa de diálogo, colocar legendas descritivas sobre os botões na caixa de diálogo.

Por exemplo, em vez de botões OK e Cancelar tê-los dizer "Enviar Fatura" e "Go Back", ou o que é apropriado no contexto do seu diálogo.

Dessa forma, o texto é bem debaixo do seu cursor e eles têm uma boa chance de entender.

Mac OS X faz isso na maioria das vezes. Aqui está uma imagem de exemplo.

Editar:

Esta é uma imagem melhor , e I encontrados no site da interface da Apple Human orientação, que é uma grande referência, e muito legível. Este documento nesse local é toda sobre diálogos.

pergunta errada. "Como você lidaria com os usuários" começa no final errado.

A pergunta correta é "Dado que diálogos usuários distrair da tarefa em mãos, o que existem alternativas melhores?".

Ao trabalhar para atingir um objetivo ou terminar uma tarefa, podemos distinguir três situações:

(1) A aplicação chega à conclusão de que não há medidas que pode tomar que vai fazer o usuário atingir a meta. Aparecer uma mensagem, com um botão para rejeitá-lo. Você não se importa se o leitor entende que, uma vez que o resultado não importa de qualquer maneira.

(2) Há somente uma ação que você pode tomar, ou as alternativas são irrelevantes para o usuário. Não incomodá-lo em tudo.

(3) Existem duas ou mais formas de alcançar a meta. Deixar o usuário escolher entre estes. Não formular isso como uma pergunta sim / não. (Vista oferece este como um diálogo comum, para substituir a caixa de mensagem.) Se possível, não faça isso uma escolha irreversível.

A exceção a esta regra é a situação onde o usuário esperar uma pergunta sim / não. Mas, realmente, se for esse o caso, então por que não é a parte questão do fluxo de trabalho normal? caixas de diálogo estão fora do fluxo de trabalho normal.

Eu acho que você provavelmente vai querer ler este artigo: "Impacto de alta intensidade negociados em estilo Interrupções sobre End-User depuração ", TJ Robertson, Joseph Lawrance, e Margaret Burnett, Journal of Visual Línguas e Informática 17 (2), 187-202, Abril de 2006.

É uma pergunta semelhante. O resultado foi, que o usuário saiba que você quer a sua atenção e, em seguida, sentar e esperar para o usuário a responder. Não interrompa o usuário, porém, não é isso que ele ou ela quer.

A [Luz] ( http://en.wikipedia.org/wiki/ Lightbox_ (JavaScript)) modal diálogo parece uma técnica eficaz em alguns casos (web 2.0 derivação, mas pode ser implimented em outros contextos).

Um outro ponto: se você pode abrir mão de uma caixa de diálogo para um href="http://en.wikipedia.org/wiki/The_Humane_Interface" rel="nofollow noreferrer"> Undo função (Gmail para uma defendido este conceito como comportamento webapp standard) isso é algo a considerar.

Se você deve usar uma caixa de diálogo, premiar o usuário com muito curto texto explicativo divertidamente simpático ou mesmo satírica e. Se você ocasionalmente entregar algo hilariante escandalosa eles vão ler tudo .

Usuário está sendo executado perigosamente baixo em senso comum. Por favor, remova este utilizador e insira outro.

Eu tenho pouca paciência com os usuários que não lêem o que me levou muito tempo e esforço para desenvolver: 1) a aplicação 2) as instruções Além de que, se você não ler e apenas fazer "o que for preciso " Você está por sua conta. I estado que frente para cima. Eu desenho minhas aplicações para ser o mais intuitivo possível e ainda há pessoas que vão fazer telefonemas apoio fora do azul, como uma criança deixar escapar em sala de aula quando não deve ser. Eu não tenho nenhuma tolerância para isso. Leia o manual, leia os diálogos -. As respostas a 99% dos problemas estão ali

Uma coisa que você pode fazer é ter o botão OK desativada por 3 segundos.

O Firefox faz isso quando você instala uma extensão.

Editar: Tudo bem, algumas pessoas acham isso chato. Eu ainda acho que cerca de 1 segundo estaria tudo bem. Ele iria suprimir o instinto-OK-clique instantâneo que as pessoas (eu incluído) têm, e forçar um double-take. Claro, mesmo Isso vai irritar as pessoas se seu diálogo não é algo que eles realmente precisam de ler.

Em primeiro lugar, estúpido deve doer, mas geralmente não o faz ...

A próxima melhor coisa é incluir um ícone que tenta transmitir a gravidade do problema. Alguns percentagem dos que não vai ler pode mudar seu hábito, se o ícone do diálogo parece ameaçador. Alguns percentagem não vai lê-lo de qualquer maneira.

Inclua um questionário de escolha múltipla no final da caixa de diálogo, ao qual o usuário deve selecionar a resposta que mostra que eles realmente fez ler e compreender o texto. Aleatoriamente mudar a ordem das escolhas que eles nem sempre pode clicar no mesmo.

Alterar o texto e como funciona o diálogo ajuda. Por exemplo, ter OK / Cancelar botões tende a permitir que os usuários ignorar a maior parte do diálogo. Se você remover os botões normais e substituí-las por verborrágico ligações comandos, os usuários são mais propensos a ler cada botão porque a opção 'rápida, vá embora' não está disponível.

Eu chamo isso do problema "piloto automático".

  1. Não use o OK, Cancel botões na parte inferior da tela. Olhada na maneira que o Vista tenta forçar os usuários a tomar uma decisão real.
  2. Desativar os botões durante alguns segundos, exibir um "Tempo para pensar" temporizador / progressbar. Assim, o usuário não pode clicar no piloto automático. Os usuários tendem a achar isso muito chato.

Não use confirmação (Você tem certeza? Sim / Não), mas use Undo.

Não pop-up avisos que são bloqueando , porque os usuários vão tentar começar a trabalhar de novo o mais rápido possível, ignorando a mensagem e apenas clicando-lo afastado. Use algo como a barra de informações do Internet Explorer, que não está a bloquear.

Você pode evitar o uso de caixas de diálogo alltogether! Em alguns programas há uma minibuffer que os erros shows e avisos. Junto disso, ele também pode pedir-lhe uma coisa, onde você deve digitar o que você quer fazer. É bastante limpo e boa solução, que tendem a preferem sobre uma barra de menu.

Mas se você realmente deve usar caixas de diálogo, tente o seguinte:

  • Uma frase por diálogo somente
  • Na maioria dos dois ou três botões
  • Faça o texto legível dentro do diálogo (maior, preto sobre branco)
  • Em vez de diálogo uso um do que muitas pequenas repetidamente (dica: listbox)

O que eu penso sobre caixas de diálogo? Em poucas palavras: São coisas bobas e estúpidas. Programas que os utilizam chegar no meu caminho e me desacelera com as suas perguntas sem sentido estúpidas. Além disso, muitas vezes os programas que usam caixas de diálogo são bastante mudo.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top