De fato, esta pergunta é sobre cuidados a serem tomados para aprimorar a experiência do usuário de qualidade e reduzir as chamadas de suporte evitáveis.
Respostas:
A falta de validação de entrada adequada é uma daquelas coisas que tendem a levar rapidamente os usuários a fazer coisas "ruins" com seu aplicativo, quando realmente deve ser tratado pelo programador.
Vi aplicativos herdados nos quais os usuários foram treinados para:
a-z0-9,emailcampo; caso contrário, as correspondências subsequentes para esse usuário usarão o que estiver no campo e falharãohttp://" foi colocado antes dos endereços da webetc etc
Todos os problemas acima são aqueles que devem ser tratados por um desenvolvedor de aplicativos. Quando sua validação de entrada é essencialmente "verifique se o usuário sabe em que formato esse campo deve estar e confie no que foi digitado corretamente", coisas inesperadas são obrigadas a encontrar o caminho para o aplicativo. Além das implicações óbvias de segurança, os usuários cometem erros. Como programadores, geralmente produzimos nossos melhores produtos, curvando-nos para trás, para garantir que o usuário não entenda errado, por mais que tente!
http://ponto de validação. Como exemplo, ASDFfaz isso de uma maneira ingênua e o resultado é que você não pode hospedar pacotes em domínios que usam https://.
Uma vez, recebi uma ligação de suporte ao cliente porque meu aplicativo simplesmente desapareceu. Aconteceu que eles abriram outro aplicativo em cima dele.
... Decidi não garantir que isso não acontecesse novamente, pois foram os analfabetos do computador que causaram o problema, não o aplicativo. Tudo o que eu poderia ter feito para corrigi-lo levaria a uma experiência ruim para os outros.
Quase todos os programas que escrevo são chamados estritamente a partir da linha de comando. Também escrevi algumas coisas mais sofisticadas que começaram como interfaces CLI e cresceram rapidamente para algo mais parecido com o shell do que qualquer outra coisa.
Então, eu posso falar apenas pelo que sei. Aqui estão alguns problemas comuns com os programas de linha de comando:
Muitas opções
A menos que você esteja escrevendo um compilador ou um editor de linhas, tente manter as opções limitadas a uma tela cheia em um buffer de quadro de 80x25 quando --helpou /?for aprovado. É perfeitamente bom ter mais opções do que isso, mas divida-as em subcategorias. Por exemplo
foo --help
foo --help option_name
Sem opções longas
É muito mais fácil lembrar foo --attach_to [argument] --volatile --verbosedo que lembrar foo -a [arg] -v +V. Isso nem sempre é possível, mas na maioria dos casos, é.
Nenhuma validação de entrada
Quase toda plataforma tem várias bibliotecas que são testadas, testadas e verdadeiras quando se trata de analisar e validar argumentos. Quase todas as plataformas possuem um lexer experimentado, testado e verdadeiro que valida a entrada de uma CLI. Use um, o outro ou ambos. Se o seu programa for segmentado por zero ou dividido por zero devido a algo fornecido pelo usuário, isso é embaraçoso.
Você pode não precisar de algo tão complexo quanto um lexer, talvez possa apenas tokenizar a string se estiver esperando coisas em uma certa ordem com certas coisas em determinados lugares.
Na verdade, recebi um relatório de erro uma vez em que era esperado um número inteiro e alguém digitou f*** my lifeaspas. Não escrevi esse programa, tive a infelicidade de herdá-lo.
Nenhum botão de 'verbocidade'
Permita que usuários experientes descubram facilmente como obter muito mais ruído do seu programa do que a maioria das pessoas toleraria, mas o padrão é imprimir apenas coisas sérias e críticas. Não sei dizer quantas vezes precisei iniciar straceapenas para perceber que algo havia falhado porque funcionava em um fluxo de arquivos NULL.
Você também pode agrupar asserções para que desativá-las via NDEBUG ou outros meios ainda resultem em algo impresso ou registrado para o usuário encontrar.
Falando em arquivos de log, tente garantir que qualquer coisa que você coloque neles faça (pelo menos um pouco) sentido para alguém que não seja você. Se o início de cada entrada for uma data da época do UNIX, você aumentará a frustração de alguém que realmente queira ajudá-lo a reproduzir o bug.
Nenhum 'bug buddy' no modo de depuração
Muitos programas oferecem algum tipo de opção 'debug' que oferece conversas extras sobre o que está acontecendo com o programa, mas poucos oferecem o seguinte:
Ou talvez você goste de ouvir as pessoas lerem o seguinte por telefone:
Diz condição inesperada em zero efeito oh quatro zero oh .... Deixe-me ler isso de volta para você ...
Arquivos de configuração excessivamente complexos
Não justifique a necessidade de analisar uma configuração como uma desculpa para obter um burburinho com muito açúcar sintático. Tente usar um formato que as pessoas realmente conheçam, mesmo que isso signifique trabalho extra ao analisar. Eu tento usar o formato de estilo INI sempre que possível. Você ficaria surpreso com o que pode fazer com um simples dicionário de chave-> valor.
Nenhum arquivo de configuração
Não faça as pessoas escreverem scripts de shell ou arquivos em lote apenas para usar o seu programa, a menos que se pretenda que seja uma ferramenta para qualquer tarefa. Me dê um meio de apontar para um arquivo contendo minhas opções habituais e fornecer apenas alguns argumentos adicionais.
Não há sinais de 'piso molhado'
Se algum recurso puder causar problemas ao usuário (talvez exista para usuários avançados), marque-o claramente como tal. Além disso, se alguém digitar um dedo grande ou se esquecer de algo, você programa imprime um link muito amigável para a documentação on-line. Você pode estar lidando com alguém que está usando seu programa via KVM e não pode recortar e colar.
Quando possível, (isso coincide com a validação de entrada), use a abordagem do Google:
Você quis dizer foo --bar FILENME, digitou apenas foo --bar
Oferecer uma saída para instruções destrutivas
O objetivo é dizer ao usuário por que não funcionou e fazê-lo tentar mais algumas vezes, garantindo que você não faça nada potencialmente destrutivo, a menos que pareça que o usuário realmente deseja que você faça isso. Permita um interruptor que desative 'irritante', por exemplo, -You /Yque permita uma saída para alguém que simplesmente tem 'dedos gordos'.
Provavelmente estou esquecendo algumas dicas. Eu lido com isso com frequência, pois é muito, muito difícil criar a interface de 'baixo nível' para algo intuitivo o suficiente para que a maioria das pessoas evite cometer erros.
"Tem certeza de que deseja excluir este arquivo / registro? Sim / Não". Clicou em sim e, em seguida, recebeu uma chamada que "por engano" clicou no botão vermelho de exclusão e precisa desses dados de volta :)
Não acho que obter exemplos específicos de interrupção / correção seja tão importante quanto perceber isso:
Se através dessa exploração eles quebrarem algo, como programador, é seu trabalho adverti-los do perigo ou impedir que isso aconteça em primeiro lugar. Não me lembro de onde o vi agora, mas no fundo, sempre tento " facilitar a tarefa certa " para o usuário do meu software.
Se você insistir em exemplos:
Veja onde isso está indo? :)
Aqui está um que ouvi esta semana. Um usuário solicita um recurso "envie-me uma notificação quando ocorrer um evento". Simples o suficiente e o desenvolvedor vai em frente e implementa. Claro, a primeira pergunta deveria ter sido "o que você está tentando resolver com esta notificação?". Eu não vou entrar nisso. Poucos dias depois, o usuário para o desenvolvedor e pergunta "Recebi esta notificação. O que devo fazer com ela?".
Lembrei-me dessa história em quadrinhos de Dilbert e sugeri ao desenvolvedor "escrever um aplicativo para descobrir o que o usuário deveria fazer com essa notificação".
Como mpeterson disse, o usuário é muito competitivo em sua área de especialização. Eles simplesmente não pensam como um desenvolvedor ou designer de software.
Eu não acho que os usuários são estúpidos. Eles não querem usar o seu ou qualquer outro programa. Tudo o que eles querem é fazer as coisas. Ajude-os e evite que ocorram danos ao longo do caminho.
Ter uma boa interface do usuário e fornecer uma experiência de aprendizado adequada ajuda bastante a impedir que os usuários façam coisas ruins.
Boas interfaces de usuário devem ser sem atrito.
Em vez de exibir uma caixa de diálogo (uma operação cara e que os usuários ignoram depois de um tempo) para confirmar uma exclusão, executar a exclusão e oferecer uma maneira de desfazer.
Boas interfaces de usuário devem ser descobertas.
Embora a faixa de opções no Microsoft Office seja muito criticada porque força os usuários antigos do Word a mudarem de forma, a faixa de opções é um exemplo brilhante de como você pode tornar uma interface detectável (ou seja, fácil de descobrir).
Boas interfaces de usuário, como bom código, devem ser auto-explicativas.
Ninguém lê o manual. O único manual que eu consegui ler meus usuários foi uma apresentação em PowerPoint contendo orientações passo a passo do software. Já vi isso com ferramentas de vídeo como o Camtasia, mas os PowerPoints são melhores porque você pode facilmente retroceder e avançar pelas etapas.
Usuário não cometer erros. Os erros estão no programador que não conseguiu criar uma interface utilizável.
O mesmo acontece com os testes de usabilidade a cada lançamento!