Quanta informação sobre um erro deve ser mostrada ao usuário?


38

Os aplicativos sempre podem gerar erros. Se ocorrer esse erro, o usuário deve ser notificado, porque o que ele pediu para o aplicativo não ter êxito.

No entanto, quanta informação o usuário deve receber? Acho que a maioria de nós concorda em não mostrar um rastreamento de pilha ( um rastreamento de pilha deve estar na mensagem de erro apresentada ao usuário? ), Mas não consigo encontrar uma pergunta sobre o restante do conteúdo do erro ou o que mostrar ao do utilizador.

Por exemplo, um idioma que suporta exceções (.net, java) tem o tipo de exceção a ser compartilhado, onde ocorreu a exceção, e uma mensagem um pouco esclarecedora para acompanhar a exceção. Isso também deve estar oculto para o usuário? Ou devemos mostrar isso de qualquer maneira? Ou devemos mostrar uma mensagem genérica? ou devemos mostrar uma de várias mensagens com base em qual é a exceção subjacente?

Respostas:


34

o que mostrar ao usuário. Isso também deve estar oculto para o usuário?

Você mostra ao usuário o que é acionável para ele.

Por exemplo, se você tiver um erro causado por alguma exceção de ponteiro nulo e mais um bug que um erro de usuário, não deseja uma explicação completa, porque eles não podem fazer nada diferente.

Ou devemos mostrar isso de qualquer maneira? Ou devemos mostrar uma mensagem genérica?

Mostrar a exceção como o conteúdo principal da mensagem de erro não faz sentido para a maioria dos usuários . Talvez se sua base de usuários-alvo for desenvolvedores, você poderá mostrar as informações como erro completo o tempo todo (talvez você tenha um aplicativo interno para testes automatizados). Mas geralmente os usuários não podem fazer nada diferente, mesmo com esse conhecimento.

devemos mostrar uma de várias mensagens com base em qual é a exceção subjacente?

A melhor estratégia é fazer o seguinte:

  • Interprete o erro em texto que seja significativo para o usuário.
    • Parte disso é "o que o usuário pode fazer de diferente?"
    • Se eles não puderem fazer algo diferente, diga algo como "ocorreu um erro inesperado".
  • Adicione uma descrição detalhada "opcional" do erro
  • Permitir que os usuários enviem o relatório de erros (ou faça isso automaticamente, dependendo da base de usuários)

Exemplo

insira a descrição da imagem aqui

  1. Ele mostra o "aqui está o que aconteceu" (erro inesperado)
  2. Informa ao usuário o que fazer (reabra o Mail, inclusive inclui um atalho para fazer isso)
  3. Também possui "visualizar detalhes" se alguém estiver curioso para ver o erro técnico completo
  4. Fornece notificação, um relatório de erro é arquivado (veja abaixo)

Observe que, em alguns casos, você pode desejar que o relatório de erros seja manual ou automático.


20
Discordo. Não há nada tão irritante quanto um aplicativo que imprime "ocorreu um erro". para a tela e depois sai. Sempre que isso acontece, sempre me pergunto por que o desenvolvedor foi tão preguiçoso a ponto de imprimir uma mensagem tão pouco informativa. Explique algo ao usuário para que ele possa entender o que deu errado em um sentido geral, mesmo que não haja nada que ele possa fazer. Na melhor das hipóteses, eles podem pesquisar no Google a mensagem de erro e talvez encontrar uma solução que outra pessoa tenha descrito, o que é quase impossível se cada erro diferente imprimir a mesma mensagem genérica.
Jon Bentley

3
@ JonBentley Você está vendo isso como um desenvolvedor, que quer entender essas coisas. O usuário médio simplesmente fica preocupado com o fato de que deve entender, o que não é necessário.
deworde

12
@deworde Pelo contrário, estou considerando isso como um usuário . Como usuário, não quero entendê- lo em termos técnicos, mas quero informações suficientes para não parecer que a pessoa que escreveu o software é incompetente ("ocorreu um erro" dá a impressão de que o desenvolvedor não ' não sei o que eles estavam fazendo) e para que eu possa procurar respostas. Se cada falha diz "ocorreu um erro", uma pesquisa no Google não vai me ajudar. É muito mais provável que uma mensagem exclusiva para cada situação me leve a um fórum em que outra pessoa tenha o mesmo problema, e talvez tenha resolvido.
Jon Bentley

3
@ JonBentley alguns pontos para consideração. Primeiro, o ponto principal desta resposta é fornecer informações acionáveis ​​ao usuário. Se houver um erro, eles podem corrigir a necessidade de informar informações para resolvê-lo. Isso se encaixa You show the user what is actionable for them. Se você souber a causa do problema, mostrará isso ao usuário na descrição. Mas, geralmente, se você souber o motivo de um erro, conhecerá a resolução do problema para informar o usuário adequadamente.
enderland

2
Segundo, você superestima bastante a capacidade média do usuário de resolver problemas automaticamente. A grande maioria da população é o que a maioria dos desenvolvedores / programadores / pessoal do Stack Exchange chamaria de analfabetos do computador. A maioria dessas pessoas, francamente, não está preparada para diagnosticar, solucionar problemas e resolver problemas. Os detalhes podem realmente piorar as coisas porque as pessoas podem interpretar mal coisas que fariam sentido completo para os desenvolvedores. Programadores e tecnologia savvy pessoas são quase universalmente não o público-alvo para a maioria das aplicações, para a decepção de todos aqui ... :)
enderland

12

Depende de quem é o usuário e o que eles podem fazer com as informações.

Geralmente, tente mostrar a eles apenas informações úteis sobre as coisas que eles mesmos podem resolver. Um rastreamento de pilha de 40 linhas com um erro de expressão regular na parte superior não é muito útil. Muito melhor seria uma mensagem informando que Data deve ser formatada como "aaaa-mm-dd" . Qualquer outra coisa, e o usuário pode não saber como responder ao erro e, em seguida, pode não querer usar seu aplicativo, por medo de causar mais erros enigmáticos e assustadores (e sim, às vezes, usuários não técnicos ficam assustados com a pilha traços). E isso pode ser ruim para os negócios.

Para aplicativos internos usados ​​por outros desenvolvedores, estou um pouco mais relaxado em exibir um rastreamento de pilha, além de algo mais útil , porque sei que o usuário pode lidar com a visualização de um rastreamento de pilha e provavelmente saberá o que fazer sobre isso.

Para usuários não técnicos, a única vez em que acho que seria bom mostrar a eles um rastreamento de pilha está em uma situação de erro crítico em que você precisa resolver o problema e eles são solicitados a copiar e colar o rastreamento de pilha e enviá-lo para você, embora realmente seja uma maneira muito melhor de fazê-lo, peça que eles enviem um arquivo de log ou, melhor ainda, solicite ao aplicativo que envie um arquivo de log ao desenvolvedor, depois de pedir ao usuário permissão para compartilhar o arquivo.


5
Eu não ficaria bem com um aplicativo que envia logs para qualquer lugar sem me perguntar. Em vez disso, a caixa de diálogo da mensagem de erro deve fornecer uma opção para relatar o erro. O usuário deve poder revisar toda e qualquer informação, incluindo o rastreamento de pilha, antes de enviar o relatório.
Piedar

1
@ piedar: Esse é um bom ponto.
FrustratedWithFormsDesigner

4
@piedar: Ter um botão "Ver mais detalhes" na caixa de diálogo de erro ou um link para o arquivo de log do aplicativo é provavelmente uma boa maneira de apresentar todos os detalhes sangrentos aos usuários avançados que desejam essas informações. Mesmo uma caixa de seleção "mostrar detalhes por padrão", se você quiser ter o problema de codificá-la. Mas nem todos os usuários desejam ver isso, e alguns usuários serão desativados por isso.
FrustratedWithFormsDesigner

2
@ Paddy: Você está correto, mas: 1) É um exemplo. : P 2) Talvez eu esteja consertando e limpando esse código, e é por isso que está fresco em minha mente ...
FrustratedWithFormsDesigner

2
@NateKerkhofs "E se ele é o desenvolvedor, ele pode replicar o bug" .. - ah, se isso fosse verdade :(
Blorgbeard

1

As mensagens para os usuários devem ser tratadas da mesma maneira que a criação de uma nova exceção a ser lançada - você fornece as informações necessárias para decidir o que fazer.

Obviamente, isso dependerá do seu aplicativo e da base de usuários, mas deve ser o seu principal orientador - sua intenção deve fornecer as informações necessárias para o "responsável pela chamada" para determinar o que eles podem fazer para executar com êxito a ação desejada. . Se for algo simples como um erro de acesso a um arquivo, você fornece um caminho para o arquivo e a mensagem que não pôde acessá-lo. Se for uma exceção de ponteiro nulo, basta fornecer uma mensagem de erro genérica.

É claro que haverá mais mensagens "incapazes de executar a ação desejada" do que aquelas que o usuário pode consertar, mas isso é apenas vida - a maioria das exceções ocorre porque cometemos um erro, não porque o usuário configurou o ambiente incorretamente.


1

Este é um tema comum:

Como você pode ajudar analfabetos desinformados / computador, ao mesmo tempo em que mostra informações que usuários mais avançados, como programadores, desenvolvedores, testadores, etc. podem usar.

Eu acho que a resposta é você fazer as duas coisas!

A ordem é importante e eu recomendo que você tenha:

  • O que aconteceu.
  • O que fazer agora
  • Detalhes técnicos

Detalhes técnicos é a parte que contém informações para pedidos avançados ou para usuários regulares ao relatar um problema


0

O que você quer mostrar depende de quão envergonhado você está por estragar tudo.

O objetivo é obter os detalhes da falha no suporte técnico o mais rápido e sem problemas possível. Isso pode significar que você envia o arquivo de log, incluindo o rastreamento de pilha do erro de encerramento automaticamente, para casa ou pede ao usuário para clicar em um botão que iniciará a transferência. Talvez através do pen drive, se não houver conexão com a internet.


0

Gosto da lógica por trás da resposta aceita, mas devo discordar respeitosamente, pelo menos com a minha interpretação de limitar as informações ao que é "acionável" . Eu quero saber um pouco mais do que isso como usuário do que "erro inesperado" .

E, reconhecidamente, sou um pouco experiente em computadores e tenho esse viés, mas não acho que essa seja uma visão particularmente tendenciosa. Porque posso fazer o possível para remover esse viés aplicando essa mentalidade a domínios para os quais tenho pouca experiência, como a aviação.

Embora eu saiba pouco sobre a aviação, diga que meu voo está atrasado ou cancelado e a única coisa que a equipe me disse é: "Tivemos um erro inesperado. Aguarde 3 horas para um voo subsequente". Você pelo menos vai me achar um cliente mais insatisfeito nesses casos porque, mesmo que isso não afete meu curso de ação, quero apenas saber um pouco mais sobre o motivo de estar sendo incomodado dessa maneira como cliente pagante.

Se eles apenas disserem: "Estamos enfrentando um clima turbulento" ou "Tivemos uma emergência médica em nosso voo anterior" ou um mau funcionamento do equipamento ou o que seja, basta o bastante para simpatizar muito mais do que "erros inesperados" e fique um pouco mais satisfeito esperando e aguardando 3 horas pelo próximo vôo. Na verdade, eu até prefiro algumas conversas tecnológicas que passam pela minha cabeça a "erros inesperados" como "Tudo bem, as palavras que saem da sua boca estão entrando no meu ouvido, mas não atingindo o processador central. Mas agora percebo que existe algum tipo da questão lá e eu vou pegar um café e sentar lá! Espero que vocês resolvam esse problema com essa coisaamajig! "

E, geralmente, em termos de tratamento de exceções, acho que você normalmente tem esse tipo de informação básica do que aconteceu no catchsite, mesmo que queira ocultar os detalhes mais técnicos da exceção, como:

try
{
     load_file(file_name);
}
catch (const exception& ex)
{
     exception_dialog("Failed to load file: '{1}'.", file_name);
}

E isso nem está exibindo o que potencialmente pode ser a informação muito técnica anexada à exceção, mas pelo menos está nos dizendo consideravelmente mais do que "erro inesperado". Pelo menos, fornece um "quê / onde / quando" contextual, mesmo que não diga "por que / como". Acho que pelo menos o desejo por esse nível básico de informação não é particularmente influenciado pela minha inteligência em computadores.

O resto é provavelmente muito específico para seus clientes e necessidades particulares. Mas meu apelo é pelo menos para algo um pouquinho mais do que "erro inesperado".


Bem, é uma visão tendenciosa. O usuário médio não se preocupa com o motivo pelo qual não pode fazer o que não pode fazer. Eles só se importam se e como podem resolver seu problema.
gnasher729

"O usuário médio não se preocupa com o motivo pelo qual não pode fazer o que não pode fazer. Eles só se importam se e como podem resolver seu problema." Se o usuário médio nem mesmo entende como o que é um arquivo ou servidor, talvez sim, mas isso ainda pode estar relacionado ao que é "acionável", então, porque eles podem dar um tapinha no seu ombro e dizer: "Ei , este aplicativo diz que não pode encontrar este arquivo de configuração necessário "ou algo nesse sentido, onde você poderá procurar o problema e corrigi-lo rapidamente para eles, por exemplo,
Dragon Energy
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.