问题标签 [user-experience]

我真的很喜欢 Flex 框架，但是我经常处理大约 500KB 的 SWF 文件。

我不知道什么时候一个文件被认为“太大”而不能在互联网上提供，但我认为仅仅为了使用 Web 应用程序而下载 500KB 肯定会惹恼一些用户。

是否有任何减少已编译 SWFS 大小的提示或技术？

作为旁注，500KB SWF 文件真的不是那么大的应用程序......

我有一个关于在 J2EE 应用程序中处理错误的问题。我们当前的应用程序被许多用户使用，因此我们得到了很多支持票。这些票证中的大多数与用户相关，但 5-10% 是系统相关的异常、未处理的错误等。

我们在代码中有基本的异常处理检查（需要工作），但根据我的经验，向用户显示一般消息并不能帮助加快故障排除过程。

我正在寻找的是关于良好错误处理设计模式的建议，以便让我们考虑一个场景：

1. 代码有错误
2. 错误已处理
3. 向用户显示带有特定错误代码的非技术错误消息。
4. 非技术支持团队可以使用此错误代码来查看应用程序中发生这种情况的区域（页面、部分、..）以及用户可能一直在做什么（开发团队在客户支持参考指南中预先填充的信息）。
5. 技术支持团队可以在类/JSP 等和触发该异常的代码行中使用代码归零。
6. 我们使用一个日志模块，其中大多数（不是全部）Tomcat 标准输出错误都由用户会话记录……到用户将收到的错误代码中，如果它也存在，我们可以包含日志 ID，以便技术团队可以查看也。

基本上，我感兴趣的是减少支持分析-解释-研究周期，让每个部门都能触手可及地访问信息，这可以让他们更快地开始各自的工作：

1. 客户支持可以对此错误代码给出预设解释，或者提供用户可以遵循的替代步骤。
2. 技术团队可以开始对代码行或触发该行的用户正在做什么进行故障排除。

本质上，每个错误代码都会触发每个部门所需的后续步骤，实际上减少了问题的研究阶段并进入解决阶段。

我不确定以上是否是个好主意。对于这种需要的良好“设计模式”，任何建议都将不胜感激。或者如果它甚至是一个很好的途径。

提前致谢。

SP

当我使用网络时，我经常会通过弹出窗口报告运行时错误（通常是 javascript）。这可能会在许多其他优秀的网站上造成非常不令人满意的用户体验，也让我想知道我无法访问哪些功能。

为什么这是一个如此普遍的问题？这是由于缺乏测试还是浏览器兼容性问题？可以做些什么来尽量减少此类问题？

顺便说一句，我没有选中“显示有关每个脚本错误的通知”。

我正在使用 Struts 和 Hibernate 在 JSP 中编写一个网站。我正在寻找一种实现丰富 UI 的方法，在其中您可以拥有的不仅仅是按钮。例如，拖放、下拉列表会在您输入更多字母时实时更新等。有没有办法将 Swing 与 Struts 和 Hibernate 一起使用？或者是否有任何其他选项可用于制作丰富的 UI？（如果有更好的选择，我愿意放弃 Struts 和/或 Hibernate）

基本问题：我工作的组织对我们可以使用或不可以使用哪些开发工具和开源库有严格的规定，并且在更新他们的批准列表方面非常缓慢。AJAX 的所有东西（例如 GWT、dojo）都没有在列表中。

感谢您花时间阅读这篇文章！

从理论上讲，最终用户永远不会看到内部错误。但在实践中，理论和实践是不同的。所以问题是向最终用户展示什么。现在，对于完全非技术的用户，您希望尽可能少地显示（“单击此处提交错误报告”之类的东西），但对于更高级的用户，他们会想知道是否有解决方法，如果它已经知道了一段时间，等等。所以你想包括一些关于什么是错误的信息。

执行此操作的经典方法是使用文件名：行号的断言或具有相同的堆栈跟踪。现在这对开发人员来说是件好事，因为它把问题指向了他；但是它对用户来说有一些明显的缺点，特别是它非常神秘（例如不友好）并且代码更改会更改错误消息（谷歌搜索错误仅适用于此版本）。

我有一个程序，我正计划在我想解决这些问题的地方编写程序。我想要的是一种将唯一身份附加到每个断言的方法，这样编辑断言周围的代码不会改变它。（例如，如果我将它剪切/粘贴到另一个文件，我希望显示相同的信息）有什么想法吗？

我正在考虑的一种方法是对错误进行枚举，但是如何确保它们永远不会在多个地方使用呢？

（注意：对于这个问题，我只关注由编码错误引起的错误。而不是像错误输入这样可能合法发生的事情。OTOH 这些错误可能会引起整个社区的兴趣。）

（注 2：有问题的程序将是在用户系统上运行的命令行应用程序。但同样，这只是我的情况。）

（注 3：目标语言是D，我非常愿意深入研究元编程。非常欢迎其他语言的答案！）

（注 4：我明确不想使用实际的代码位置，而是使用某种符号名称来表示错误。这是因为如果代码以任何方式更改，代码位置也会发生变化。）

在软件开发的历史上已经开发了许多可用性评估技术。但在我看来，它们在实践中很少使用。

为什么可用性评估工具和方法实际上没有被大量使用？

或者它们的使用比我被引导相信的更多？

我在某处读过（我忘记了来源，抱歉 - 我认为是 MS Office 开发人员的博客？），当您对用户进行调查时，询问他们希望在您的软件/网站中看到哪些功能，他们会更多通常说他们想要每一件小事，而收集的指标表明，最终，大多数人并没有使用 99% 的这些功能。博客文章的一般信息是，您不应该问人们他们使用什么，您应该自己跟踪它。

当试图弄清楚接下来要添加什么新功能时，这会导致不幸的先有鸡还是先有蛋的情况。如果没有该功能，我无法衡量它实际使用了多少。由于资源有限（且资源严重紧张），我也无法添加所有功能，然后删除未使用的功能。

你如何找出对你的用户有用的东西？如果调查是唯一的选择，您是否必须以某种方式组织您的问题（例如：不要显示可能的功能列表，因为这会引导他们）？

这个问题是 Ed Burns 在他的著作《骑在顶峰》中提出的。我记得几乎所有的摇滚明星程序员都发现如果有新的和酷的小工具会很有帮助。程序员与最新的设计、硬件和软件实现保持联系，这也可能影响他的工作。

你对这个问题有什么看法？

我有一个典型的阻抗不匹配，其中数据以标准化方式存储：

但是用户以非规范化的方式消费、可视化和理解它：

这一切都很好——我有各种解决方案可以在渲染和持久性之间旋转和取消旋转数据。然而，在现实世界的情况下，非规范化渲染有几十列，这变得难以使用并且让人难以理解。

请记住，用户目前以非规范化的方式探索数据，并且我不想弄乱他们的思维导图来尝试改变这一点，有哪些策略可以更好地呈现宽表格数据？我知道这不是一个新问题，但我不知道在哪里寻找好的见解。

我不是在寻找特定于任何一种演示环境的答案。无论是在 Web 浏览器还是电子表格中，掌握广泛的数据表示只是一项心理上的困难任务，我正在寻找一般策略或表示转变——或指向资源的指针——来减轻这种困难。

Adobe AIR 使我们能够突破浏览器围栏之外创建富 Internet 应用程序 (RIA) 的界限。一些公司已经区分了诸如富桌面应用程序 (RDA) 之类的应用程序。

我们分别为 Web、桌面和 RIA 应用程序提供了可用性指南。但是，由于 Adob​​e AIR 使我们能够使用 Web 技术（HTML、Java 脚本、AJAX、Flex、AS..）创建桌面应用程序，这种类型的应用程序似乎不适合上述任何类别。

所以我的问题是：将 AIR 应用程序与 RIA 区分开来是否正确，因为 AIR 应用程序存在于用户桌面中，并且用户在使用桌面应用程序与浏览器上的应用程序时会有不同的心理模型？

湾。在为 Adob​​e AIR 创建应用程序时需要遵循哪些可用性准则？