为了识别关于应用程序可用性的摩擦点，有哪些技术可以成功监控UI事件？

Question

哪些技术/算法可能成功监控UI事件，以便识别有关应用程序可用性的摩擦点？

大多数经过实战考验的真实软件都包含大量的错误检查和日志记录功能。我们经常使用复杂的日志记录系统来帮助在故障发生之前进行诊断并偶尔预测故障。我们通常专注于报告服务器端的灾难性故障 当然，这些失败很重要，但我认为还有另一类错误被忽略了，但也许同样重要。无论您使用的是iPhone，黑莓，笔记本电脑，台式机还是销售点触摸屏，用户交互通常都会作为离散事件处理。我怀疑识别UI事件的模式可以暴露用户在与应用程序有效交互方面遇到困难的区域。我发现了一篇关于这个主题的有趣的学术论文here。我认为论文中提出的想法很棒，但也许其他更简单的技术可能会产生很好的结果。您在这方面的想法和经验是什么？

Answer 1

有趣的论文。我得出的一个问题是，除非你有一个非常具体的假设，试图测试，否则从用户事件日志中理解起来并不容易。它们非常有用，例如，如果您知道它会花费太长时间来完成任务X，或者它们无法完全完成它。这显然是一个完全不同的球赛，试图分析序列而没有任何其他支持信息并从中理解（尽管如果你使用本文中提到的复杂技术就可以完成）。

一种更简单的方法是简单地衡量完成您知道的常见且重要的给定任务的总时间。例如，如果它是购物应用程序，那么完成购买结账的时间可能是收集的有用的东西。然而，这并不是那么简单，因为你必须至少考虑到中断（例如，用户的老板走进房间，他放弃了购买实际工作 - 而不是我曾经这样做过： - P）。您可以有一个简单的规则，如果没有记录X秒的事件，则假设用户没有注意屏幕。

您可以做的另一件简单的事情是检查明显的错误迹象，例如用户使用“撤消”工具或将信息输入到Web应用程序的输入框中，导致验证检查触发（例如，未能输入所需信息并以错误的格式输入信息）。如果某些输入框导致大量错误，则可能表示您应该更灵活地允许不同的格式（例如，允许用户输入日期为“6/28/09”，“6-28-09 “，”2009年6月28日“而不是要求单一格式。”

另一个想法：如果您的应用程序具有上下文帮助，请确定人们将其用于应用程序的每个页面/部分/模块的次数。

我怀疑我说的是惊天动地，但也许它会给你一些想法。

-Dan

Answer 2

我曾经写过一个应用程序，它跟踪每个命令是否通过菜单或等效的命令键来访问它;它让我们非常了解哪些关键等价物是可以消耗的。我们当时没有工具栏，但是相同类型的日志记录和分析当然可以应用于它们，也可以应用于上下文相关的菜单：您想要提供有限的一组有价值的选项。

Answer 3

您可能想要Google usability testing。我从来没有听说通过让程序识别事件模式来完成它，而是通过让人类观察人类使用该程序。