Mensagens de erro no Windows 7

As mensagens de erro no Windows 7 alertam os utilizadores para problemas que já ocorreram. Em contrapartida, as mensagens de aviso alertam os utilizadores para condições que podem causar problemas no futuro. As mensagens de erro podem ser apresentadas usando caixas de diálogo modais, mensagens in-loco, notificações ou balões.

Uma mensagem de erro modal típica.

Mensagens de erro eficazes informam os usuários de que um problema ocorreu, explicam por que ele aconteceu e fornecem uma solução para que os usuários possam corrigir o problema. Os usuários devem executar uma ação ou alterar seu comportamento como resultado de uma mensagem de erro.

Mensagens de erro úteis e bem escritas são cruciais para uma experiência de usuário de qualidade. Mensagens de erro mal escritas resultam em baixa satisfação do produto e são uma das principais causas de custos evitáveis de suporte técnico. Mensagens de erro desnecessárias interrompem o fluxo dos usuários.

Nota: Diretrizes relacionadas a caixas de diálogo , mensagens de aviso, confirmações, ícones padrão, notificaçõese layout são apresentados em artigos separados.

Esta é a interface de usuário correta?

Para decidir, considere estas questões:

• A interface do usuário (UI) está apresentando um problema que já ocorreu? Caso contrário, a mensagem não é um erro. Se o usuário que está sendo alertado sobre uma condição que pode causar um problema no futuro, use uma mensagem de aviso.
• O problema pode ser evitado sem causar confusão? Em caso afirmativo, evite o problema. Por exemplo, use controles restritos a valores válidos em vez de usar controles não restritos que podem exigir mensagens de erro. Além disso, desativar os controles ao clicar resultaria em erro, desde que seja óbvio por que o controle está desativado.
• O problema pode ser corrigido automaticamente? Em caso afirmativo, manipule o problema e suprima a mensagem de erro.
• É provável que os usuários executem uma ação ou alterem seu comportamento como resultado da mensagem? Caso contrário, a condição não justifica a interrupção do usuário, por isso é melhor suprimir o erro.
• O problema é relevante quando os usuários estão usando ativamente outros programas? Em caso afirmativo, considere mostrar o problema usando um ícone de área de notificação .
• O problema não está relacionado com a atividade atual do utilizador, não requer uma ação imediata do utilizador e os utilizadores podem ignorá-lo livremente? Em caso afirmativo, use uma de notificação de falha de ação.
• O problema está relacionado ao status de uma tarefa em segundo plano dentro de uma janela primária? Em caso afirmativo, considere mostrar o problema usando uma barra de status .
• Os principais usuários-alvo são profissionais de TI? Em caso afirmativo, considere o uso de um mecanismo de feedback alternativo, como entradas de de arquivo de log ou alertas por email. Os profissionais de TI preferem fortemente arquivos de log para informações não críticas.

Conceitos de design

As características de mensagens de erro ruins

Não deve ser surpresa que existam muitas mensagens de erro irritantes, inúteis e mal escritas. E como as mensagens de erro geralmente são apresentadas usando caixas de diálogo modais, elas interrompem a atividade atual do usuário e exigem ser reconhecidas antes de permitir que o usuário continue.

Parte do problema é que há muitas maneiras de fazer errado. Considere estes exemplos do Error Message Hall of Shame:

Mensagens de erro desnecessárias

Incorreto:

Este exemplo do Windows XP pode ser a pior mensagem de erro de sempre. Isso indica que um programa não pôde ser iniciado porque o próprio Windows está em processo de desligamento. Não há nada que o usuário possa fazer sobre isso ou mesmo queira fazer sobre isso (o usuário optou por desligar o Windows, afinal). E ao exibir essa mensagem de erro, o Windows se impede de desligar!

O problema: A mensagem de erro em si é o problema. Além de descartar a mensagem de erro, não há nada para os usuários fazerem.

Causa principal: Relatar todos os casos de erro, independentemente dos objetivos ou ponto de vista dos usuários.

Alternativa recomendada: Não reporte erros com os quais os usuários não se importam.

mensagens de erro "Sucesso"

Incorreto:

Esta mensagem de erro resultou da escolha do utilizador de não reiniciar o Windows imediatamente após a remoção do programa. A remoção do programa foi bem-sucedida do ponto de vista do usuário.

O problema: Não há erro do ponto de vista do usuário. Além de descartar a mensagem de erro, não há nada para os usuários fazerem.

Causa principal: A tarefa foi concluída com êxito do ponto de vista do usuário, mas falhou do ponto de vista do programa de desinstalação.

Alternativa recomendada: Não reporte erros para condições que os utilizadores considerem aceitáveis.

Mensagens de erro completamente inúteis

Incorreto:

de erro desconhecido

Os usuários aprendem que houve um erro, mas não têm ideia do que foi o erro ou o que fazer a respeito. E não, não está tudo bem!

O problema: A mensagem de erro não dá um problema específico e não há nada que os usuários possam fazer a respeito.

Causa principal: Muito provavelmente, o programa tem má manipulação de erros.

Alternativa recomendada: Projete um bom tratamento de erros no programa.

Mensagens de erro incompreensíveis

Incorreto:

Neste exemplo, a declaração do problema é clara, mas a explicação suplementar é totalmente desconcertante.

O problema: A declaração ou solução do problema é incompreensível.

Causa principal: Explicar o problema do ponto de vista do código em vez do ponto de vista do usuário.

Alternativa recomendada: Escreva o texto da mensagem de erro que os usuários-alvo possam entender facilmente. Forneça soluções que os usuários possam realmente executar. Projetar a experiência de mensagem de erro do seu programa não tem programadores compor mensagens de erro no local.

Mensagens de erro que comunicam em excesso

Incorreto:

Neste exemplo, a mensagem de erro aparentemente tenta explicar cada etapa de solução de problemas.

O problema: Demasiada informação.

Causa principal: Dar muitos detalhes ou tentar explicar um processo de solução de problemas complicado dentro de uma mensagem de erro.

Alternativa recomendada: Evite detalhes desnecessários. Além disso, evite solucionadores de problemas. Se for necessária uma solução de problemas, concentre-se nas soluções mais prováveis e explique o restante vinculando-se ao tópico apropriado na Ajuda.

Mensagens de erro desnecessariamente duras

Incorreto:

A incapacidade do programa de encontrar um objeto dificilmente soa catastrófica. E assumindo que é catastrófico, por que OK é a resposta?

O problema: O tom do programa é desnecessariamente duro ou dramático.

Causa principal: O problema deve-se a um bug que parece catastrófico do ponto de vista do programa.

Alternativa recomendada: Escolha cuidadosamente o idioma com base no ponto de vista do usuário.

Mensagens de erro que culpam os usuários

Incorreto:

de caracteres ilegais

Por que fazer com que os usuários se sintam como um criminoso?

O problema: A mensagem de erro é formulada de uma forma que acusa o usuário de cometer um erro.

Causa principal: fraseado insensível que se concentra no comportamento do usuário em vez do problema.

Alternativa recomendada: Concentre-se no problema, não na ação do usuário que levou ao problema, usando a voz passiva conforme necessário.

mensagens de erro bobas

Incorreto:

de relatório de erros

Neste exemplo, a declaração do problema é bastante irônica e nenhuma solução é fornecida.

O problema: Instruções de mensagem de erro que são bobas ou não-sequitors.

Causa principal: Criação de mensagens de erro sem prestar atenção ao seu contexto.

Alternativa recomendada: Ter suas mensagens de erro criadas e revisadas por um escritor. Considere o contexto e o estado de espírito do usuário ao revisar os erros.

Mensagens de erro do programador

Incorreto:

Neste exemplo, a mensagem de erro indica que há um bug no programa. Esta mensagem de erro tem significado apenas para o programador.

O problema: Mensagens destinadas a ajudar os desenvolvedores do programa a encontrar bugs são deixadas na versão de lançamento do programa. Essas mensagens de erro não têm significado ou valor para os usuários.

Causa principal: Programadores usando a interface do usuário normal para fazer mensagens para si mesmos.

Alternativa recomendada: Os desenvolvedores devem compilar condicionalmente todas essas mensagens para que elas sejam automaticamente removidas da versão de lançamento de um produto. Não perca tempo tentando tornar erros como esse compreensíveis para os usuários, porque seu único público são os programadores.

Mensagens de erro mal apresentadas

Incorreto:

Este exemplo tem muitos erros comuns de apresentação.

O problema: Obtendo todos os detalhes errados na apresentação da mensagem de erro.

Causa principal: Não saber e aplicar as diretrizes de mensagem de erro. Não usar escritores e editores para criar e revisar as mensagens de erro.

A natureza do tratamento de erros é tal que muitos destes erros são muito fáceis de cometer. É perturbador perceber que a maioria das mensagens de erro poderia ser indicada para o Hall da Vergonha.

As características de boas mensagens de erro

Em contraste com os maus exemplos anteriores, as boas mensagens de erro têm:

• Um problema. Indica que ocorreu um problema.
• Uma causa. Explica por que o problema ocorreu.
• Uma solução. Fornece uma solução para que os usuários possam corrigir o problema.

Além disso, boas mensagens de erro são apresentadas de uma forma que é:

• Relevante. A mensagem apresenta um problema com o qual os usuários se preocupam.
• Acionável. Os usuários devem executar uma ação ou alterar seu comportamento como resultado da mensagem.
• Centrada no usuário. A mensagem descreve o problema em termos de ações ou metas do usuário alvo, não em termos do que o código está insatisfeito.
• Breve. A mensagem é tão curta quanto possível, mas não mais curta.
• Claro. A mensagem usa linguagem simples para que os usuários-alvo possam entender facilmente o problema e a solução.
• Específicos. A mensagem descreve o problema usando uma linguagem específica, fornecendo nomes, locais e valores específicos dos objetos envolvidos.
• Cortês. Os usuários não devem ser culpados ou feitos para se sentir estúpidos.
• Raros. Exibido com pouca frequência. As mensagens de erro frequentemente exibidas são um sinal de mau design.

Ao projetar sua experiência de tratamento de erros para ter essas características, você pode manter as mensagens de erro do seu programa fora do Salão da Vergonha de Mensagens de Erro.

Evitar mensagens de erro desnecessárias

Muitas vezes, a melhor mensagem de erro não é nenhuma mensagem de erro. Muitos erros podem ser evitados através de um melhor design, e muitas vezes existem alternativas melhores para mensagens de erro. Normalmente, é melhor evitar um erro do que reportá-lo.

As mensagens de erro mais óbvias a evitar são aquelas que não são acionáveis. Se for provável que os usuários descartem a mensagem sem fazer ou alterar nada, omita a mensagem de erro.

Algumas mensagens de erro podem ser eliminadas porque não são problemas do ponto de vista do usuário. Por exemplo, suponha que o usuário tentou excluir um arquivo que já está em processo de exclusão. Embora isso possa ser um caso inesperado do ponto de vista do código, os usuários não consideram isso um erro porque o resultado desejado é alcançado.

Incorreto:

Essa mensagem de erro deve ser eliminada porque a ação foi bem-sucedida do ponto de vista do usuário.

Para outro exemplo, suponha que o usuário cancele explicitamente uma tarefa. Para o ponto de vista do usuário, a condição a seguir não é um erro.

Incorreto:

Essa mensagem de erro também deve ser eliminada porque a ação foi bem-sucedida do ponto de vista do usuário.

Às vezes, as mensagens de erro podem ser eliminadas concentrando-se nos objetivos dos usuários em vez da tecnologia. Ao fazê-lo, reconsidere o que é realmente um erro. O problema está nos objetivos do usuário ou na capacidade do seu programa de satisfazê-los? Se a ação do usuário faz sentido no mundo real, deve fazer sentido no software também.

Por exemplo, suponha que dentro de um programa de comércio eletrônico um usuário tente encontrar um produto usando a pesquisa, mas a consulta de pesquisa literal não tem correspondências e o produto desejado está fora de estoque. Tecnicamente, isso é um erro, mas em vez de dar uma mensagem de erro, o programa poderia:

• Continue a procurar os produtos que mais se aproximam da consulta.
• Se a pesquisa tiver erros óbvios, recomende automaticamente uma consulta corrigida.
• Lide automaticamente com problemas comuns, como erros ortográficos, grafias alternativas e pluralização incompatível e casos verbais.
• Indique quando o produto estará em stock.

Desde que o pedido do usuário seja razoável, um programa de comércio eletrônico bem projetado deve retornar resultados razoáveis e não erros.

Outra ótima maneira de evitar mensagens de erro é prevenindo problemas em primeiro lugar. Você pode evitar erros:

• Usando controles restritos. Use controles restritos a valores válidos. Controles como listas, controles deslizantes, caixas de seleção, botões de opção e seletores de data e hora são restritos a valores válidos, enquanto as caixas de texto geralmente não são e podem exigir mensagens de erro. No entanto, você pode restringir caixas de texto para aceitar apenas determinados caracteres e aceitar um número máximo de caracteres.
• Usando interações restritas. Para operações de arrasto, permita que os usuários soltem somente em destinos válidos.
• Usando controles desativados e itens de menu. Desative controles e itens de menu quando os usuários puderem deduzir facilmente por que o controle ou item de menu está desativado.
• Fornecendo bons valores padrão. Os usuários são menos propensos a cometer erros de entrada se puderem aceitar os valores padrão. Mesmo que os usuários decidam alterar o valor, o valor padrão permite que os usuários saibam o formato de entrada esperado.
• Fazer as coisas simplesmente funcionarem. Os usuários são menos propensos a cometer erros se as tarefas forem desnecessárias ou executadas automaticamente para eles. Ou se os usuários cometem pequenos erros, mas sua intenção é clara, o problema é corrigido automaticamente. Por exemplo, você pode corrigir automaticamente pequenos problemas de formatação.

Fornecendo mensagens de erro necessárias

Às vezes, você realmente precisa fornecer uma mensagem de erro. Os usuários cometem erros, redes e dispositivos param de funcionar, objetos não podem ser encontrados ou modificados, tarefas não podem ser concluídas e programas têm bugs. Idealmente, esses problemas aconteceriam com menos frequência, por exemplo, podemos projetar nosso software para evitar muitos tipos de erros do usuário, mas não é realista evitar todos esses problemas. E quando um desses problemas acontece, uma mensagem de erro útil faz com que os usuários se recuperem rapidamente.

Uma crença comum é que as mensagens de erro são a pior experiência do usuário e devem ser evitadas a todo custo, mas é mais preciso dizer que a confusão do usuário é a pior experiência e deve ser evitada a todo custo. Às vezes, esse custo é uma mensagem de erro útil.

Considere os controles desativados. Na maioria das vezes, é óbvio por que um controle está desativado, portanto, desativar o controle é uma ótima maneira de evitar uma mensagem de erro. No entanto, e se o motivo pelo qual um controle está desativado não for óbvio? O usuário não pode prosseguir e não há feedback para determinar o problema. Agora o usuário está preso e tem que deduzir o problema ou obter suporte técnico. Nesses casos, é muito melhor deixar o controle ativado e dar uma mensagem de erro útil.

Incorreto:

Por que o botão Avançar está desativado aqui? Melhor deixá-lo ativado e evitar a confusão do usuário, dando uma mensagem de erro útil.

Se você não tiver certeza se deve dar uma mensagem de erro, comece compondo a mensagem de erro que você pode dar. Se for provável que os usuários executem uma ação ou alterem seu comportamento como resultado, forneça a mensagem de erro. Por outro lado, se for provável que os usuários descartem a mensagem sem fazer ou alterar nada, omita a mensagem de erro.

Projetando para um bom tratamento de erros

Embora a criação de um bom texto de mensagem de erro possa ser desafiadora, às vezes é impossível sem um bom suporte de tratamento de erros do programa. Considere esta mensagem de erro:

Incorreto:

É provável que o problema seja realmente desconhecido porque o suporte de tratamento de erros do programa está faltando.

Embora seja possível que esta seja uma mensagem de erro muito mal escrita, é mais provável que reflita a falta de um bom tratamento de erros pelo código subjacente, não há informações específicas conhecidas sobre o problema.

Para criar mensagens de erro específicas, acionáveis e centradas no usuário, o código de tratamento de erros do seu programa deve fornecer informações de erro específicas e de alto nível:

• Cada problema deve ter um código de erro exclusivo atribuído.
• Se um problema tem várias causas, o programa deve determinar a causa específica sempre que possível.
• Se o problema tiver parâmetros, os parâmetros devem ser mantidos.
• Problemas de baixo nível devem ser tratados em um nível suficientemente alto para que a mensagem de erro possa ser apresentada do ponto de vista do usuário.

Boas mensagens de erro não são apenas um problema de interface do usuário, elas são um problema de design de software. Uma boa experiência de mensagem de erro não é algo que possa ser abordado mais tarde.

Solução de problemas (e como evitá-la)

A solução de problemas resulta quando um problema com várias causas diferentes é relatado com uma única mensagem de erro.

Incorreto:

Correto:

A solução de problemas resulta quando vários problemas são relatados com uma única mensagem de erro.

No exemplo a seguir, um item não pôde ser movido porque já foi movido ou excluído, ou o acesso foi negado. Se o programa pode facilmente determinar a causa, por que colocar o fardo sobre o usuário para determinar a causa específica?

Incorreto:

Bem, qual é? Agora o usuário tem que solucionar problemas.

O programa pode determinar se o acesso foi negado, portanto, esse problema deve ser relatado com uma mensagem de erro específica.

Correto:

Com uma causa específica, nenhuma solução de problemas é necessária.

Use mensagens com várias causas somente quando a causa específica não puder ser determinada. Neste exemplo, seria difícil para o programa determinar se o item foi movido ou excluído, portanto, uma única mensagem de erro com várias causas pode ser usada aqui. No entanto, é improvável que os usuários se importem se, por exemplo, não puderem mover um arquivo excluído. Para essas causas, a mensagem de erro nem é necessária.

Tratamento de erros desconhecidos

Em alguns casos, você realmente não saberá o problema, a causa ou a solução. Se seria imprudente suprimir o erro, é melhor ser franco sobre a falta de informação do que apresentar problemas, causas ou soluções que podem não estar certas.

Por exemplo, se o programa tiver uma exceção sem tratamento, a seguinte mensagem de erro é adequada:

Se você não pode suprimir um erro desconhecido, é melhor ser direto sobre a falta de informação.

Por outro lado, forneça informações específicas e acionáveis se for provável que sejam úteis na maioria das vezes.

Esta mensagem de erro é adequada para um erro desconhecido se a conectividade de rede é geralmente o problema.

Determinar o tipo de mensagem apropriado

Algumas questões podem ser apresentadas como um erro, aviso ou informação, dependendo da ênfase e fraseado. Por exemplo, suponha que uma página da Web não pode carregar um controle ActiveX não assinado com base na configuração atual do Windows Internet Explorer:

• Erro. "Esta página não pode carregar um controle ActiveX não assinado." (Formulado como um problema existente.)
• Atenção. "Esta página pode não se comportar como esperado porque o Windows Internet Explorer não está configurado para carregar controles ActiveX não assinados." ou "Permitir que esta página instale um controle ActiveX não assinado? Fazê-lo a partir de fontes não fidedignas pode danificar o seu computador." (Ambos formulados como condições que podem causar problemas futuros.)
• Informação. "Você configurou o Windows Internet Explorer para bloquear controles ActiveX não assinados." (Formulado como uma declaração de fato.)

Para determinar o tipo de mensagem apropriado, concentre-se no aspeto mais importante do problema que os usuários precisam saber ou agir. Normalmente, se um problema bloquear o usuário de prosseguir, você deve apresentá-lo como um erro; Se o usuário puder prosseguir, apresente-o como um aviso. Crie o de instruções principal ou outro texto correspondente com base nesse foco e, em seguida, escolha um ícone ( padrão ou não) que corresponda ao texto. O texto de instrução principal e os ícones devem sempre corresponder.

de apresentação de mensagem de erro

A maioria das mensagens de erro em programas do Windows são apresentadas usando caixas de diálogo modais (como são a maioria dos exemplos neste artigo), mas há outras opções:

• No local
• Balões
• Notificações
• Ícones da área de notificação
• Barras de status
• Arquivos de log (para erros direcionados a profissionais de TI)

Colocar mensagens de erro em caixas de diálogo modais tem o benefício de exigir atenção e reconhecimento imediatos do usuário. No entanto, esta também é a sua principal desvantagem se essa atenção não for necessária.

Você realmente precisa interromper os usuários para que eles possam clicar no botão Fechar? Caso contrário, considere alternativas ao uso de uma caixa de diálogo modal.

Os diálogos modais são uma ótima opção quando o usuário deve reconhecer o problema imediatamente antes de continuar, mas muitas vezes uma escolha ruim de outra forma. Geralmente, você deve preferir usar a apresentação mais leve que faz bem o trabalho.

Evite a comunicação excessiva

Geralmente, os usuários não leem, eles verificam. Quanto mais texto houver, mais difícil será digitalizar o texto e maior será a probabilidade de os utilizadores não lerem o texto. Como resultado, é importante reduzir o texto ao seu essencial, e usar divulgação progressiva e links de Ajuda quando necessário para fornecer informações adicionais.

Há muitos exemplos extremos, mas vejamos mais um típico. O exemplo a seguir tem a maioria dos atributos de uma boa mensagem de erro, mas seu texto não é conciso e requer motivação para ler.

Incorreto:

Este exemplo é uma boa mensagem de erro, mas se comunica demais.

O que diz realmente todo este texto? Algo assim:

Correto:

Esta mensagem de erro tem essencialmente as mesmas informações, mas é muito mais concisa.

Usando a Ajuda para fornecer os detalhes, essa mensagem de erro tem um estilo de pirâmide invertida de apresentação.

Para obter mais diretrizes e exemplos sobre comunicação excessiva, consulte de texto da interface do usuário .

Se você fizer apenas oito coisas

1. Projete seu programa para tratamento de erros.
2. Não dê mensagens de erro desnecessárias.
3. Evite a confusão do usuário dando as mensagens de erro necessárias.
4. Certifique-se de que a mensagem de erro fornece um problema, causa e solução.
5. Certifique-se de que a mensagem de erro é relevante, acionável, breve, clara, específica, cortês e rara.
6. Projetar mensagens de erro do ponto de vista do usuário, não do ponto de vista do programa.
7. Evite envolver o usuário na solução de problemas, use uma mensagem de erro diferente para cada causa detetável.
8. Use o método de apresentação mais leve que faz bem o trabalho.

Padrões de utilização

As mensagens de erro têm vários padrões de uso:

Rótulo	Valor
Problemas do sistema O sistema operacional, dispositivo de hardware, rede ou programa falhou ou não está no estado necessário para executar uma tarefa.	Muitos problemas do sistema podem ser resolvidos pelo usuário: Os problemas do dispositivo podem ser resolvidos ligando-o, reconectando-o e inserindo mídia. Os problemas de rede podem ser resolvidos verificando a conexão de rede física e executando de diagnóstico e reparo de rede. Os problemas do programa podem ser resolvidos alterando as opções do programa ou reiniciando o programa. Neste exemplo, o programa não consegue encontrar uma câmara para executar uma tarefa de utilizador. Neste exemplo, um recurso necessário para executar uma tarefa precisa ser ativado.
Problemas com arquivos Um arquivo ou pasta necessária para uma tarefa iniciada pelo usuário não foi encontrado, já está em uso ou não tem o formato esperado.	Neste exemplo, o arquivo ou pasta não pode ser excluído porque não foi encontrado. Neste exemplo, o programa não suporta o formato de arquivo fornecido.
Problemas de segurança O usuário não tem permissão para acessar um recurso ou privilégio suficiente para executar uma tarefa iniciada pelo usuário.	Neste exemplo, o usuário não tem permissão para acessar um recurso. Neste exemplo, o usuário não tem o privilégio de executar uma tarefa.
Problemas de tarefas Há um problema específico ao executar uma tarefa iniciada pelo usuário (diferente de um sistema, arquivo não encontrado, formato de arquivo ou problema de segurança).	Neste exemplo, os dados da Área de Transferência não podem ser colados no Paint. Neste exemplo, o usuário não pode instalar uma atualização de software.
Problemas de entrada do usuário O usuário inseriu um valor incorreto ou inconsistente com outra entrada do usuário.	Neste exemplo, o usuário inseriu um valor de tempo incorreto. Neste exemplo, a entrada do usuário não está no formato correto.

Orientações

Apresentação

• Use caixas de diálogo de tarefas sempre que apropriado para obter uma aparência e um layout consistentes. As caixas de diálogo de tarefas requerem o Windows Vista ou posterior, pelo que não são adequadas para versões anteriores do Windows. Se você precisar usar uma caixa de mensagem, separe a instrução principal da instrução suplementar com duas quebras de linha.

Erros de entrada do usuário

• Sempre que possível, evite ou reduza os erros de entrada do usuário:
  • Usando controles que são restritos a valores válidos.
  • Desativar controles e itens de menu ao clicar resultaria em erro, desde que seja óbvio por que o controle ou item de menu está desativado.
  • Fornecendo bons valores padrão.

Incorreto:

Neste exemplo, uma caixa de texto sem restrições é usada para entrada restrita. Em vez disso, use um controle deslizante.

• Use o tratamento de erros sem moderação (erros no local ou balões) para problemas contextuais de entrada do usuário.
• Use balões para problemas de entrada de usuário não críticos, de ponto único, detetados em uma caixa de texto ou imediatamente após uma caixa de texto perder o foco.Balões não exigem espaço disponível na tela ou o layout dinâmico necessário para exibir mensagens no local. Exiba apenas um único balão de cada vez. Como o problema não é crítico, nenhum ícone de erro é necessário. Os balões desaparecem quando clicados, quando o problema é resolvido ou após um tempo limite.

de caracteres incorretos

Neste exemplo, um balão indica um problema de entrada enquanto ainda está no controle.

• Use erros in-loco para deteção de erros atrasados, geralmente erros encontrados clicando em um botão confirmar. (Não use erros in-loco para configurações que são imediatamente confirmadas.) Pode haver vários erros no local ao mesmo tempo. Use texto normal e um ícone de erro de 16x16 pixels, colocando-os diretamente ao lado do problema sempre que possível. Os erros in-loco não desaparecem, a menos que o usuário cometa e nenhum outro erro seja encontrado.

Neste exemplo, um erro in-loco é usado para um erro encontrado clicando no botão confirmar.

• Use o tratamento modal de erros (caixas de diálogo de tarefas ou caixas de mensagem) para todos os outros problemas, incluindo erros que envolvem vários controles ou são erros não contextuais ou não de entrada encontrados clicando em um botão confirmar.
• Quando um problema de entrada do usuário for relatado, defina o foco de entrada para o primeiro controle com os dados incorretos. Role o controle para a exibição, se necessário. Se o controle for uma caixa de texto, selecione todo o conteúdo. Deve ser sempre óbvio a que a mensagem de erro se refere.
• Não limpe a entrada incorreta. Em vez disso, deixe-o para que o usuário possa ver e corrigir o problema sem começar de novo.
  • Exceção: Limpe as caixas de texto incorretas de senha e PIN porque os usuários não podem corrigir a entrada mascarada de forma eficaz.

Solução de problemas

• Evite criar problemas de solução de problemas. Não confie em uma única mensagem de erro para relatar um problema com várias causas detetáveis diferentes.
• Use uma mensagem de erro diferente (normalmente uma instrução suplementar diferente) para cada causa detetável. Por exemplo, se um arquivo não puder ser aberto por vários motivos, forneça uma instrução suplementar separada para cada motivo.
• Use uma mensagem com várias causas somente quando a causa específica não puder ser determinada. Neste caso, apresente as soluções por ordem de probabilidade de resolução do problema. Isso ajuda os usuários a resolver o problema de forma mais eficiente.

Ícones

• As caixas de diálogo de mensagem de erro modal não têm ícones da barra de título. Os ícones da barra de título são usados como uma distinção visual entre janelas primárias e secundárias.

• Use um ícone de erro. Exceções:

  • Se o erro for um problema de entrada do usuário exibido usando uma caixa de diálogo modal ou balão, não use um ícone. Fazê-lo é contrário ao tom encorajador do Windows. No entanto, as mensagens de erro in-loco devem usar um pequeno ícone de erro (16x16 pixel) para identificá-las claramente como mensagens de erro.

    

    

    Nesses exemplos, os problemas de entrada do usuário não precisam de ícones de erro.

    

    Neste exemplo, uma mensagem de erro in-loco precisa de um pequeno ícone de erro para identificá-la claramente como uma mensagem de erro.

• Se o problema for para um recurso que tem um ícone (e não um problema de entrada do usuário), você pode usar o ícone de recurso com uma sobreposição de erro. Se você fizer isso, use também o nome do recurso como assunto do erro.

  

  Neste exemplo, o ícone do recurso tem uma sobreposição de erro e o recurso é o assunto do erro.

• Não use ícones de aviso para erros. Isso geralmente é feito para fazer com que a apresentação pareça menos severa. Erros não são avisos.

  Incorreto:

  

  Neste exemplo, um ícone de aviso é usado incorretamente para tornar o erro menos grave.

Para obter mais diretrizes e exemplos, consulte Ícones padrão.

Divulgação progressiva

• Use um botão de divulgação progressiva Mostrar/Ocultar detalhes para ocultar informações avançadas ou detalhadas em uma mensagem de erro. Isso simplifica a mensagem de erro para uso típico. Não oculte as informações necessárias, porque os usuários podem não encontrá-las.

Neste exemplo, o botão de divulgação progressiva ajuda os usuários a detalhar para obter mais detalhes, se quiserem, ou simplificar a interface do usuário, se não quiserem.

• Não use Mostrar / Ocultar detalhes a menos que realmente haja mais detalhes. Não se limite a reafirmar as informações existentes num formato mais detalhado.
• Não use Mostrar/Ocultar detalhes para mostrar informações da Ajuda. Em vez disso, use os links de Ajuda.

Para obter diretrizes de rotulagem, consulte Progressive Disclosure Controls.

Não mostrar esta mensagem novamente

• Se uma mensagem de erro precisar dessa opção, reconsidere o erro e sua frequência. Se ele tem todas as características de um bom erro (relevante, acionável e pouco frequente), não deve fazer sentido para os usuários suprimi-lo.

Para obter mais diretrizes, consulte Caixas de diálogo .

Valores padrão

• Selecione a resposta mais segura, menos destrutiva ou mais segura como padrão. Se a segurança não for um fator, selecione o comando mais provável ou conveniente.

Ajuda

• Crie mensagens de erro para evitar a necessidade de Ajuda. Normalmente, os usuários não devem ter que ler texto externo para entender e resolver o problema, a menos que a solução exija várias etapas.
• Certifique-se de que o conteúdo da Ajuda é relevante e útil. Não deve ser uma reafirmação detalhada da mensagem de erro, em vez disso, deve conter informações úteis que estão além do escopo da mensagem de erro, como maneiras de evitar o problema no futuro. Não forneça um link de Ajuda só porque você pode.
• Use links de Ajuda específicos, concisos e relevantes para acessar o conteúdo da Ajuda. Não use botões de comando ou divulgação progressiva para este fim.
• Para mensagens de erro que você não pode tornar específicas e acionáveis, considere fornecer links para o conteúdo da Ajuda online. Ao fazer isso, você pode fornecer aos usuários informações adicionais que você pode atualizar após o lançamento do programa.

Para obter mais diretrizes, consulte Ajuda.

Códigos de erro

• Para mensagens de erro que você não pode tornar específicas e acionáveis ou que se beneficiam da Ajuda, considere também fornecer códigos de erro. Os usuários geralmente usam esses códigos de erro para pesquisar na Internet para obter informações adicionais.
• Forneça sempre uma descrição em texto do problema e da solução. Não dependa apenas do código de erro para esta finalidade.

Incorreto:

Neste exemplo, um código de erro é usado como um substituto para um texto de solução.

• Atribua um código de erro exclusivo para cada causa diferente. Isso evita a solução de problemas.
• Escolha códigos de erro que são facilmente pesquisáveis na Internet. Se você usar códigos de 32 bits, use uma representação hexadecimal com "0x" à esquerda e caracteres maiúsculos.

Correto:

1234

0xC0001234

Incorreto:

-1

-67113524

• Use Mostrar/Ocultar detalhes para exibir códigos de erro. Frase como código de erro: <error code>.

Neste exemplo, um código de erro é usado para complementar uma mensagem de erro que pode se beneficiar de mais informações.

Som

• Não acompanhe mensagens de erro com um efeito sonoro ou bipe. Fazê-lo é chocante e desnecessário.
  • Exceção: Reproduzir o efeito sonoro Critical Stop se o problema for crítico para o funcionamento do computador, e o usuário deve tomar medidas imediatas para evitar consequências graves.

Texto

Geral

• Remova o texto redundante. Procure-o em títulos, instruções principais, instruções suplementares, links de comando e botões de confirmação. Geralmente, deixe o texto completo em instruções e controles interativos e remova qualquer redundância dos outros lugares.
• Use explicações centradas no usuário. Descreva o problema em termos de ações ou objetivos do usuário, não em termos do que o software está insatisfeito. Use uma linguagem que os usuários-alvo entendam e usem. Evite jargões técnicos.

Incorreto:

de chamada síncrona de entrada

Correto:

Nesses exemplos, a versão correta fala o idioma do usuário, enquanto a versão incorreta é excessivamente técnica.

• Não use as seguintes palavras:
  • Erro, falha (use o problema em vez disso)
  • Falha ao (uso incapaz de em vez disso)
  • Ilegal, inválido, ruim (use incorreto em vez disso)
  • Abortar, matar, terminar (use stop em vez disso)
  • Catastrófico, fatal (usar grave em vez disso)

Estes termos são desnecessários e contrários ao tom encorajador do Windows. Quando usado corretamente, o ícone de erro comunica suficientemente que há um problema.

Incorreto:

Correto:

No exemplo incorreto, os termos "catastrófico" e "fracasso" são desnecessários.

• Não use frases que culpem o usuário ou impliquem erro do usuário. Evite usar você e o seu no fraseado. Embora a voz ativa seja geralmente preferida, use a voz passiva quando o usuário é o sujeito e pode se sentir culpado pelo erro se a voz ativa for usada.

Incorreto:

de início de sessão incorreto

Correto:

O exemplo incorreto culpa o usuário usando a voz ativa.

• Seja específico. Evite formulações vagas, como erros de sintaxe e operações ilegais. Forneça nomes, locais e valores específicos dos objetos envolvidos.

Incorreto:

Arquivo não encontrado.

O disco está cheio.

Valor fora do intervalo.

O caractere é inválido.

Dispositivo não disponível.

Esses problemas seriam muito mais fáceis de resolver com nomes, locais e valores específicos.

• Não dê problemas, causas ou soluções possivelmente improváveis na tentativa de ser específico. Não forneça um problema, causa ou solução, a menos que seja provável que esteja certo. Por exemplo, é melhor dizer Ocorreu um erro desconhecido do que algo que provavelmente será impreciso.
• Evite a palavra "por favor", exceto em situações em que o usuário é solicitado a fazer algo inconveniente (como esperar) ou o software é o culpado pela situação.

Correto:

Aguarde enquanto o Windows copia os ficheiros para o seu computador.

• Use a palavra "desculpe" apenas em mensagens de erro que resultem em problemas sérios para o usuário (por exemplo, perda de dados ou incapacidade de usar o computador). Não peça desculpas se o problema ocorreu durante o funcionamento normal do programa (por exemplo, se o usuário precisa esperar que uma conexão de rede seja encontrada).

Correto:

Lamentamos, mas a Fabrikam Backup detetou um problema irrecuperável e foi encerrada para proteger os ficheiros no seu computador.

• Consulte os produtos usando seus nomes curtos. Não use nomes completos de produtos ou símbolos de marcas comerciais. Não inclua o nome da empresa, a menos que os usuários associem o nome da empresa ao produto. Não inclua números de versão do programa.

Incorreto:

Correto:

No exemplo incorreto, nomes completos de produtos e símbolos de marcas comerciais são usados.

• Use aspas duplas em torno de nomes de objetos. Isso torna o texto mais fácil de analisar e evita declarações potencialmente embaraçosas.
  • Exceção: Caminhos de arquivo, URLs e nomes de domínio totalmente qualificados não precisam estar entre aspas duplas.

Correto:

Neste exemplo, a mensagem de erro seria confusa se o nome do objeto não estivesse entre aspas.

• Evite iniciar frases com nomes de objetos. Fazê-lo é muitas vezes difícil de analisar.
• Não use pontos de exclamação ou palavras com todas as letras maiúsculas. Pontos de exclamação e letras maiúsculas fazem parecer que você está gritando com o usuário.

Para obter mais diretrizes e exemplos, consulte Estilo e Tom.

Títulos

• Use o título para identificar o comando ou recurso do qual o erro se originou. Exceções:
  • Se um erro for exibido por muitos comandos diferentes, considere usar o nome do programa.
  • Se esse título for redundante ou confuso com a instrução principal, use o nome do programa.
• Não use o título para explicar ou resumir o problema esse é o objetivo da instrução principal.

Incorreto:

Neste exemplo, o título está sendo usado incorretamente para explicar o problema.

• Use maiúsculas no estilo de título, sem pontuação final.

Principais instruções

• Use a instrução principal para descrever o problema em linguagem clara, simples e específica.
• Seja conciso, use apenas uma única frase completa. Reduza a instrução principal às informações essenciais. Você pode deixar o assunto implícito se for o seu programa ou o usuário. Inclua a razão do problema, se puder fazê-lo de forma concisa. Se tiver de explicar mais alguma coisa, utilize uma instrução suplementar.

Incorreto:

Neste exemplo, toda a mensagem de erro é colocada na instrução principal, dificultando a leitura.

• Seja específico se houver objetos envolvidos, dê seus nomes.
• Evite colocar caminhos de arquivo completos e URLs na instrução principal. Em vez disso, use um nome curto (como o nome do arquivo) e coloque o nome completo (como o caminho do arquivo) na instrução suplementar. No entanto, você pode colocar um único caminho de arquivo completo ou URL na instrução principal se a mensagem de erro não precisar de uma instrução suplementar.

Neste exemplo, apenas o nome do arquivo está na instrução principal. O caminho completo está na instrução suplementar.

• Não forneça o caminho completo do arquivo e a URL se for óbvio a partir do contexto.

Neste exemplo, o usuário está renomeando um arquivo do Windows Explorer. Nesse caso, o caminho completo do arquivo não é necessário porque é óbvio pelo contexto.

• Use o tempo presente sempre que possível.
• Use maiúsculas no estilo de frase.
• Não inclua períodos finais se a instrução for uma declaração. Se a instrução for uma pergunta, inclua um ponto de interrogação final.

Principais modelos de instruções

Embora não haja regras rígidas para fraseado, tente usar os seguintes modelos de instruções principais sempre que possível:

• [nome do assunto opcional] não pode [executar ação]
• [nome do assunto opcional] não pode [executar ação] porque [razão]
• [nome do assunto opcional] não pode [executar ação] para "[nome do objeto]"
• [nome do assunto opcional] não pode [executar ação] para "[nome do objeto]" porque [razão]
• Não há [recurso] suficiente para [executar ação]
• [Nome do assunto] não tem um [nome do objeto] necessário para [finalidade]
• [Dispositivo ou configuração] está desligado para que [resultados indesejados]
• [Dispositivo ou configuração] não está [disponível | encontrado | ativado | ativado]
• "[nome do objeto]" está indisponível no momento
• O nome de utilizador ou palavra-passe estão incorretos
• Você não tem permissão para acessar "[nome do objeto]"
• Você não tem privilégio de [executar ação]
• [nome do programa] teve um problema sério e deve fechar imediatamente

Naturalmente, faça as alterações necessárias para que a instrução principal seja gramaticalmente correta e cumpra as principais diretrizes de instrução.

Instruções complementares

• Use as instruções complementares para:
  • Forneça detalhes adicionais sobre o problema.
  • Explique a causa do problema.
  • Liste as etapas que o usuário pode tomar para corrigir o problema.
  • Forneça medidas para evitar que o problema volte a ocorrer.
• Sempre que possível, proponha uma solução prática e útil para que os usuários possam corrigir o problema. No entanto, certifique-se de que a solução proposta é suscetível de resolver o problema. Não perca tempo sugerindo soluções possíveis, mas improváveis.

Incorreto:

Neste exemplo, embora o problema e sua solução recomendada sejam possíveis, eles são muito improváveis.

• Se o problema for um valor incorreto que o usuário inseriu, use a instrução suplementar para explicar os valores corretos. Os usuários não devem ter que determinar essas informações de outra fonte.
• Não forneça uma solução se ela puder ser deduzida trivialmente da declaração do problema.

Neste exemplo, nenhuma instrução suplementar é necessária; A solução pode ser trivialmente deduzida da declaração do problema.

• Se a solução tiver várias etapas, apresente as etapas na ordem em que devem ser concluídas. No entanto, evite soluções em várias etapas porque os usuários têm dificuldade em se lembrar de mais de dois ou três passos simples. Se forem necessárias mais etapas, consulte o tópico da Ajuda apropriado.
• Mantenha as instruções suplementares concisas. Forneça apenas o que os usuários precisam saber. Omitir detalhes desnecessários. Visar um máximo de três frases de duração moderada.
• Para evitar erros enquanto os usuários executam instruções, coloque os resultados antes da ação.

Correto:

Para reiniciar o Windows, clique em OK.

Incorreto:

Clique em OK para reiniciar o Windows.

No exemplo incorreto, os usuários são mais propensos a clicar em OK por acidente.

• Não recomende entrar em contato com um administrador, a menos que isso esteja entre as soluções mais prováveis para o problema. Reserve tais soluções para problemas que realmente só podem ser resolvidos por um administrador.

Incorreto:

Neste exemplo, provavelmente o problema é com a conexão de rede do usuário, então não vale a pena entrar em contato com um administrador.

• Não recomendo entrar em contato com o suporte técnico. A opção de entrar em contato com o suporte técnico para resolver um problema está sempre disponível e não precisa ser promovida por meio de mensagens de erro. Em vez disso, concentre-se em escrever mensagens de erro úteis para que os usuários possam resolver problemas sem entrar em contato com o suporte técnico.

Incorreto:

Neste exemplo, a mensagem de erro recomenda incorretamente entrar em contato com o suporte técnico.

• Use frases completas, maiúsculas no estilo de frase e pontuação final.

botões Confirmar

• Se a mensagem de erro fornecer botões de comando ou links de comando que resolvam o problema, siga suas respetivas diretrizes em Caixas de diálogo.
• Se o programa precisar ser encerrado como resultado do erro, forneça um botão Sair do programa. Para evitar confusões, não use Close para este fim.
• Caso contrário, forneça um botão Fechar. Não use OK para mensagens de erro, porque esta formulação implica que os problemas estão OK.
  • Exceção: Use OK se o mecanismo de relatório de erros tiver rótulos corrigidos (como com a API MessageBox).

Documentação

Quando se refere a erros:

• Consulte os erros pela instrução principal. Se a instrução principal for longa ou detalhada, resuma a instrução.
• Se necessário, você pode se referir a uma caixa de diálogo de mensagem de erro como uma mensagem. Consulte como uma mensagem de erro somente na programação e em outra documentação técnica.
• Sempre que possível, formate o texto em negrito. Caso contrário, coloque o texto entre aspas apenas se necessário para evitar confusões.

Exemplo: Se receber uma mensagem Não há nenhum disco de CD na unidade, insira um novo disco de CD na unidade e tente novamente.