algorithm - 哪些技术可以成功地监视 UI 事件以识别有关应用程序可用性的摩擦点？

Question

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

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

Answer 1

有趣的论文。我从中得到的一件事是，除非您有一个非常具体的假设要尝试测试，否则很难从用户事件日志中理解。它们可能非常有用，例如，如果您知道用户完成任务 X 花费的时间太长或者他们无法完全完成它。尝试在没有任何其他支持信息的情况下分析序列并从中理解它们显然是一个完全不同的球类游戏(尽管如果您使用论文中提到的复杂技术就可以做到)。

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

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

另一个想法:如果您的应用程序有上下文帮助，当然要计算人们在您应用程序的每个页面/部分/模块中使用它的次数。

我怀疑我所说的任何事情都是惊天动地的，但也许它会给你一些想法。

-丹