您的用户犯了哪些错误，如何更新应用程序来处理它们？ [关闭
-
16-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
实际上，这个问题是关于提高优质用户体验并减少可避免的支持呼叫的警告。
解决方案
缺乏适当的输入验证是其中之一，这些事情往往会很快导致用户在应用程序中真正由程序员处理时，对您的应用程序进行“不良”。
我已经看到了旧应用程序的旧应用程序：
- 不输入名称的撇号
- 没有输入任何符号
a-z0-9, - 确保他们输入文本之前或之后没有空格
- 检查是否正在将正确格式的电子邮件地址输入到
email字段，否则随后给该用户的邮件将使用现场中的任何内容，并且将失败 - 确保 ”
http://“被放在网站上
等等
以上所有问题都是 应该 由应用程序开发人员处理。当您的输入验证本质上是“确保用户知道该字段应采用的格式并相信他们输入的内容是正确的”，那么意外的事情必将找到进入应用程序的方式。除了明显的安全含义外，用户还会犯错误。作为程序员，我们经常通过向后弯曲来生产最好的产品，以确保用户 不能 弄错了，无论他们多么努力！
其他提示
我曾经接到客户支持电话，因为我的应用程序刚刚消失。原来，他们在上面打开了另一个应用程序。
...我决定不确保不再发生这种情况，因为是用户的计算机文盲引起了问题，而不是应用程序。我本来可以做的任何解决方法都会导致其他人的用户体验差。
我编写的几乎每个程序都严格从命令行调用。我还写了一些更典型的东西，这些东西最初是CLI界面，并且迅速发展成比其他任何东西都更像外壳。
因此，我只能为我所知道的说话。这是命令行计划的一些常见问题：
方式太多了
除非您编写编译器或行编辑器，否则请在80x25帧缓冲区上将选项限制在一个屏幕上 --help 或者 /? 通过。拥有更多的选择是完全可以的，但是将它们分为子类别。例如
foo --help
foo --help option_name
没有长期选择
记住要容易得多 foo --attach_to [argument] --volatile --verbose 比记住 foo -a [arg] -v +V. 。这并不总是可能的，但是在大多数情况下，是。
无输入验证
几乎每个平台都有多个库，这些库在解析和验证参数方面经过了尝试，测试和真实。几乎每个平台都有一个经过尝试的，测试和真实的Lexer，可以验证CLI的输入。使用一个，另一个或两者。如果您的程序Segfault或由于用户提供的内容而将其除以零，那真是令人尴尬。
您可能不需要像Lexer这样的复杂的东西，也许如果您期望在某些地方使用某些东西的某些顺序的东西，则可以将字符串化。
实际上，我曾经收到过一个错误报告，预计会有一个整数，有人打字了 f*** my life 用引号。我没有写那个程序，我的不幸继承了它。
没有“详细”旋钮
允许有经验的用户轻松发现如何从程序中获得比大多数人所容忍的更多噪音，但默认不用于仅印刷严重和关键的东西。我不能告诉你我要开火多少次 strace 只是要意识到某些东西是因为它在空文件流上操作的。
您还可以包装断言，以便通过ndebug或其他方式将其关闭，但仍会导致打印或记录的东西供用户找到。
说到日志文件，请尝试确保您放在其中的任何东西（至少有点）对您以外的人有意义。如果每个条目的开始是Unix Epoch日期，那么您将对真正想帮助您复制该错误的人感到沮丧。
在调试模式下没有“错误伙伴”
许多程序都提供了某种“调试”开关，可提供有关该程序正在发生的事情的额外chat不休，但很少有人提供以下内容：
- 一种通过HTTP/HTTPS自动发送报告并获取某种服务参考号的方法
- 一种将有用信息转移到文件的方法 可以 作为支持请求的附件发送
或者，也许您喜欢听到人们通过电话阅读以下内容：
它说零eff OH四零哦。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
过于复杂的配置文件
不要证明需要解析配置作为对大量句法糖的嗡嗡声的借口。尝试使用人们实际知道的格式，即使在解析时意味着额外的工作。我尽可能尝试使用INI样式格式。您会惊讶于可以使用简单的键 - > value字典来实现的目标。
没有配置文件
除非打算成为任一任务的工具，否则不要让人们编写外壳脚本或批处理文件来使用您的程序。给我一种指向包含我通常选项的文件，并提供一些其他参数。
没有“湿地板”标志
如果某些功能可能会使用户陷入困境（也许是为高级用户带来的），请清楚地将其标记。此外，如果有人发胖输入或忘记了某些东西，您是否编程打印了一个非常友好的在线文档链接。您可能正在与正在通过KVM使用您的程序并且无法剪切和粘贴的人打交道。
如果可能的话，（这与输入验证一致）使用Google Apporach：
您的意思是foo- bar fileme，您只输入foo -bar
提供摆脱破坏性指示的出路
目的是告诉用户为什么它不起作用，并让他们再尝试几次，同时确保您无能为力，除非看来用户真正希望您这样做。例如，允许关闭“ na naging”的开关 -Y 或者 /Y 但是，否则，对于那些只有“胖手指”的人来说，有一条出路。
我可能忘记了一些指示。我经常处理这个问题，因为很难为足够直观的东西制作“低级别”界面，以避免犯错误。
“您确定要删除此文件/记录吗？是/否”。单击“是”，然后接到一个“错误地”的呼叫，单击了红色删除按钮，它需要数据回:)
我不觉得要获得特定的休息/修复示例与意识到这一点一样重要：
- 用户不阅读您的手册或观看您的教程。他们通过探索学习您的软件。
如果通过探索他们打破了某些东西，作为程序员，您的工作是警告他们危险或阻止它首先发生。我不记得现在在哪里看到它，但是在我的脑海中，我总是试图“”让做正确的事“对于我的软件的用户。
如果您坚持示例：
- 用户能够输入一个小写名称，该名称通过执行输入验证来打破集成代码 /修复
- 执行操作 /仅通过显示正确的按钮，用户能够单击错误的按钮。
- 用户能够通过警告他们即将进行X进行意外 /修复。
看看这要去哪里？ :)
这是我本周听到的。用户要求“在发生事件时向我发送通知”功能。很简单，开发人员继续进行实施。当然，第一个问题应该是“该通知要解决什么？”。我不会参加。几天后，用户停下来开发人员，并问：“我收到了此通知。我应该处理什么？”。
我记得这部迪尔伯特漫画，并向开发人员建议“编写一个应用程序，以弄清楚用户应如何处理该通知”。
就像Mpeterson所说的那样，用户在其专业领域具有非常有竞争力。他们只是不像软件开发人员或设计师那样。
我不认为用户很愚蠢。他们根本不想使用您或任何程序。他们想要的就是完成他们的工作。帮助他们并防止在此过程中造成伤害。
拥有良好的用户界面并提供足够的学习体验，可以很大程度上可以防止用户做坏事。
好的用户界面应无摩擦。
与其抛出一个对话框（一个昂贵的操作，还有一个用户忽略了一段时间后）以确认删除，执行删除并提供撤消方法。
良好的用户界面应该可以发现。
尽管Microsoft Office中的功能区获得了很多漏洞，因为它迫使老式的Word用户改变自己的方式，但功能区是如何使界面可发现的界面（即易于发现）。
良好的用户界面（如良好的代码）应该是自我解释的。
没有人阅读手册。我唯一让用户阅读的手册是PowerPoint演示文稿，其中包含该软件的分步演练。我已经看到了使用Camtasia之类的视频工具完成的，但是PowerPoints更好，因为您可以轻松地通过步骤向前和向前翻转。
用户不会犯错误。错误在于未能创建可用界面的程序员。
因此，每个版本都会进行可用性测试！
