用户会犯什么错误，以及如何更新应用程序以解决这些错误？[关闭]

实际上，此问题与要采取的谨慎措施有关，以提高质量的用户体验并减少可避免的支持电话。

缺乏适当的输入验证是其中的一件事，当应用程序确实应由程序员处理时，往往会很快导致用户使用您的应用程序执行“不良”操作。

我见过旧版应用程序，其中的用户已受过以下培训：

• 不要在名称中输入撇号
• 除了输入任何符号 a-z0-9,
• 确保输入的文本前后没有空格
• 检查是否在该email字段中输入了正确格式的电子邮件地址，否则后续向该用户发送的邮件将使用该字段中的任何内容，并且将失败
• 确保将“ http://”放在网址之前

等

以上所有问题都是应用程序开发人员应解决的问题。当您的输入验证实质上是“确保用户知道该字段应采用的格式并相信他们输入的内容正确”时，那么意外的事情就必然会进入应用程序。除了明显的安全隐患之外，用户还会犯错误。作为程序员，我们经常通过向后弯腰来生产我们最好的产品，以确保无论他们多么努力，用户都不会出错。

我曾经接到客户支持电话，因为我的应用程序不见了。原来他们在它之上打开了另一个应用程序。

...我决定不确保不再发生这种情况，因为造成问题的是用户的计算机知识，而不是应用程序。我可以做的任何修复工作都会给其他用户带来糟糕的用户体验。

我编写的几乎每个程序都严格从命令行调用。我还写了一些更奇特的东西，它们最初是作为CLI界面开始的，后来迅速发展成为比其他东西更像shell的东西。

所以，我只能说我所知道的。这是命令行程序的一些常见问题：

太多的选择

除非您正在编写编译器或行编辑器，--help否则/?在传递或时，应尽量将选项限制为在80x25帧缓冲区上的一个屏幕上全屏显示。拥有更多的选择是完全可以的，但是可以将它们分为子类别。例如

foo --help

foo --help option_name

没有长的选择

记住foo --attach_to [argument] --volatile --verbose比记住容易得多foo -a [arg] -v +V。这并非总是可能的，但在大多数情况下是这样。

没有输入验证

几乎每个平台都有多个在解析和验证参数时经过尝试，测试和验证的库。几乎每个平台都具有经过验证的真正的词法分析器，该工具可验证来自CLI的输入。使用一个或另一个。如果您的程序由于用户提供的东西而出现段错误或除以零，那真令人尴尬。

您可能不需要像词法分析器那样复杂的东西，或者，如果您希望以某种顺序在某些地方放置某些东西，则可以只对字符串进行标记化。

我实际上得到了一个错误报告，该错误报告中应有一个整数，并且有人f*** my life用引号引起来。我没有编写该程序，但不幸地继承了它。

没有“详细”旋钮

让经验丰富的用户可以轻松地发现如何从程序中获得比大多数人所能承受的更多的噪音，但默认情况下，仅打印严重和重要的内容。我无法告诉您我必须启动多少次strace才能意识到某些段已出错，因为它在NULL文件流上运行。

您还可以包装断言，以便通过NDEBUG或其他方式将其关闭，仍然会导致打印或记录内容供用户查找。

说到日志文件，请尝试确保放置在日志文件中的任何东西对您以外的其他人来说（至少有一点点）有意义。如果每个条目的开始都是UNIX纪元日期，那么您将使真正想要帮助您重现该错误的人感到沮丧。

在调试模式下没有“ bug伙伴”

许多程序提供某种“调试”开关，从而使程序发生了更多的变化，但是很少提供以下功能：

• 一种通过HTTP / HTTPS自动发送报告并获取某种服务参考号的方法
• 一种将有用信息转储到文件的方法，该文件可以作为支持请求的附件发送

或者，也许您喜欢听别人通过电话阅读以下内容：

它说零效率的意外情况哦四个零哦....好吧，我读回给你...

过于复杂的配置文件

不要以需要解析配置为借口来获取大量语法糖的理由。尝试使用人们真正知道的格式，即使解析时这意味着额外的工作。我尝试尽可能使用INI样式格式。您会惊讶于使用简单的key-> value字典可以实现的功能。

没有配置文件

不要让人们仅仅为了使用您的程序而编写Shell脚本或批处理文件，除非它打算用作执行任一任务的工具。给我一种方法，指向一个包含我常用选项的文件，并仅提供一些附加参数。

没有“湿地板”迹象

如果某些功能可能会给用户带来麻烦（也许高级用户可以使用该功能），请清楚地进行标记。此外，如果有人手指输入错误或忘记了某些内容，请让您进行编程以打印一个非常友好的链接到在线文档的链接。您可能正在与某个正在通过KVM使用您的程序并且无法剪切和粘贴的人打交道。

如果可能，（这与输入验证一致）请使用Google方法：

您的意思是foo --bar FILENME，您只键入了foo --bar

提供摆脱破坏性指示的方法

目的是告诉用户为什么它不起作用，让他们再尝试几次，同时确保您没有做任何可能造成破坏性的操作，除非用户似乎真的希望您这样做。允许一个开关，关闭“唠叨”，例如-Y或/Y否则允许出路的人谁只是有“胖手指”。

我可能会忘记一些指针。我经常要处理这个问题，因为很难使“低级”界面具有足够直观的含义，以使大多数人避免犯错。

“确定要删除此文件/记录吗？是/否”。单击“是”，然后接到一个呼叫，它“错误地”单击了红色的删除按钮，并且需要返回该数据：）

我不认为获得特定的中断/修复示例与实现此目标一样重要：

• 用户不会阅读您的手册或观看您的教程。他们通过探索学习您的软件。

如果通过这种探索他们破坏了某些东西，作为程序员，您要警告他们危险或首先防止它发生。我不记得现在看到了什么，但是在我的内心深处，我总是试图为软件用户“ 轻松完成正确的事情 ”。

如果您坚持使用示例：

• 用户能够通过执行输入验证来输入破坏集成代码的小写名称/已修复
• 用户只能通过显示正确的按钮来执行操作/修复后单击错误的按钮。
• 用户能够通过警告他们即将进行X操作来意外地/修复了X。

看到这是怎么回事？:)

这是我本周听到的。用户要求功能“事件发生时向我发送通知”。足够简单，开发人员可以继续并实施它。当然，第一个问题应该是“此通知试图解决什么？”。我不会说的。几天后，用户停在开发人员的旁边，并问“我收到了此通知。我应该如何处理？”。

我记得这本Dilbert漫画，并向开发人员建议“编写一个应用程序以弄清楚用户应如何处理该通知”。

就像mpeterson所说的那样，用户在他们的专业领域非常有竞争力。他们只是不像软件开发人员或设计师那样思考。

我不认为用户是愚蠢的。他们根本不想使用您的程序或任何程序。他们想要做的只是把事情做好。帮助他们并防止在此过程中对他们造成伤害。

拥有良好的用户界面并提供足够的学习体验，对于防止用户做出不良行为大有帮助。

• 好的用户界面应该毫无摩擦。

  无需抛出对话框来确认删除，执行删除并提供撤消的方法（一个昂贵的操作，而用户稍后会忽略该操作）。

• 好的用户界面应该是可发现的。

  尽管Microsoft Office中的功能区由于迫使Word的老用户改变其方式而引起很大的困扰，但功能区是如何使界面可发现（即易于发现）的一个光辉的例子。

• 好的用户界面，如好的代码，应该是不言自明的。

  没有人阅读手册。我让用户阅读的唯一手册是PowerPoint演示文稿，其中包含该软件的逐步演练。我已经看到这些是通过Camtasia等视频工具完成的，但是PowerPoint更好，因为您可以轻松地在各个步骤中前后移动。

用户不要犯错误。错误在于未能创建可用接口的程序员。

每个发行版都进行可用性测试！