哪些技术可以成功地监控 UI 事件以识别与应用程序可用性有关的摩擦点？
哪些技术/算法可以成功监控 UI 事件以识别与应用程序可用性有关的摩擦点？
大多数经过实战考验的实际软件都包含广泛的错误检查和日志记录。 我们经常使用复杂的日志系统来帮助诊断，有时还可以在故障发生之前进行预测。 我们通常专注于报告服务器端的灾难性故障。
这些失败当然很重要，但我认为还有另一类错误被忽视，但也许同样重要。 无论您使用 iPhone、黑莓、笔记本电脑、台式机还是销售点触摸屏，用户交互通常都会作为离散事件进行处理。 我怀疑识别 UI 事件的模式可能会暴露用户在与应用程序有效交互方面遇到困难的区域。 我发现了一篇关于这个主题的有趣的学术论文 这里。 我认为论文中提出的想法很棒，但也许其他更简单的技术可能会产生不错的结果。 您在这方面有什么想法和经验？
What techniques/algorithms might be successful in monitoring UI events for the purpose of identifying friction points regarding the usability of an application?
Most battle-tested, real-world software contains extensive error checking and logging. We frequently employ complex logging systems to help diagnose, and occasionally predict, failures before they happen. We generally focus on reporting the catastrophic failures on the server-side.
These failures are important of course, but I think there is another class of errors that are overlooked, and yet perhaps equally important. Whether you are using an iPhone, blackberry, laptop, desktop, or point-of-sale touch screen, user interaction is typically processed as discrete events. I suspect that identifying patterns of UI events can expose areas where the user is having difficulty regarding efficiently interacting with the application. I found an interesting academic paper on this subject here. I think the ideas presented in the paper are great, but perhaps other, simpler, techniques might yield nice results. What are your ideas and experiences in this area?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有趣的论文。 我从中得到的一件事是，除非您有一个非常具体的假设要尝试测试，否则要理解用户事件日志并不容易。 例如，如果您知道用户完成任务 X 花费的时间太长或者他们完全无法完成任务，那么它们可能非常有用。 尝试在没有任何其他支持信息的情况下分析序列并理解它们显然是完全不同的游戏（尽管如果您使用本文中提到的复杂技术就可以做到）。
一种更简单的方法是简单地测量完成您知道常见且重要的给定任务的总时间。 例如，如果它是购物应用程序，则完成购买结帐的时间可能是值得收集的有用信息。 但这并不是那么简单，因为您至少必须考虑到中断（例如，用户的老板走进房间，他放弃了购物而去从事实际工作——我从来没有这样做过：—— P）。 您可以有一个简单的规则，即如果 X 秒内没有记录任何事件，则假设用户没有注意屏幕。
您可以做的另一件简单的事情是检查明显的错误迹象，例如用户使用“撤消”功能或在 Web 应用程序的输入框中输入信息，导致触发验证检查（例如，未能输入所需的信息以及以错误的格式输入信息）。 如果某些输入框导致大量错误，则可能表明您应该更灵活地允许不同的格式（例如，允许用户输入日期为“6/28/09”、“6-28-09”） ”、“2009 年 6 月 28 日”而不是要求单一格式）。
另一个想法：如果您的应用程序有上下文帮助，当然要计算人们在应用程序的每个页面/部分/模块中使用它的次数。
我怀疑我所说的任何事情都是惊天动地的，但也许它会给你一些想法。
-担
Interesting paper. One of the things I get out of it is that it's not easy to make sense out of user event logs unless you have a very specific hypothesis you are trying to test. They can be very useful, for example, if you know it's taking users too long to complete Task X or they're failing to complete it altogether. It's clearly a whole different ballgame to try to analyze sequences without any other supporting information and make sense out of them (though it can be done if you use the sophisticated techniques mentioned in the paper).
One simpler method would be to simply measure the total time to complete a given task that you know is common and important. If it's a shopping application, for example, the time to complete the check-out on a purchase would probably be something useful to collect. It's not quite that simple, though, because you'd have to at least take into account interruptions (e.g., the user's boss came into the room and he abandoned his shopping for actual work--not that I've ever done this :-P). You could have a simple rule that says, if there were no events logged for X seconds, assume the user is not paying attention to the screen.
Another simple thing you could do would be to check for obvious signs of errors, such as a user employing the "undo" facility or inputting information into an input box in a web app that causes a validation check to trigger (e.g., failing to enter required information and putting information in the wrong format). If certain input boxes result in a high number of errors, it might be a sign you should be more flexible in allowing different formats (e.g., allow users to enter a date as "6/28/09", "6-28-09", "june 28, 2009" instead of requiring a single format).
One other idea: if your application has contextual help, certainly count how many times people use it for each page/section/module of your application.
I doubt anything I'm saying is earth shattering, but maybe it will give you some ideas.
-Dan
我曾经编写过一个应用程序，用于跟踪每个命令是否通过菜单或等效命令键访问； 它让我们很好地了解了哪些密钥等价物是消耗性的。 我们当时没有工具栏，但同样类型的日志记录和分析当然可以应用于它们，或者上下文相关的菜单：任何您想要提供一组有限的有价值选项的地方。
I once wrote an app that tracked, for each command, whether it was accessed via the menu or a command-key equivalent; it gave us pretty good insight into which key-equivalents were expendable. We didn't have toolbars at the time, but the same kind of logging and analysis could of course apply to them, or to context-sensitive menus: anywhere you want to provide a limited set of valuable options.
您可能需要 Google 可用性测试。 我从未听说过它是通过让程序识别事件模式来完成的，而是通过让人类观看人类使用该程序来完成的。
You might want to Google usability testing. I've never heard of it being done by having a program recognize patterns of events, but rather by having humans watch humans use the program.