web-applications - "Back"富网络应用程序中的行为，真实的用户假设？

Question

许多客户端代码库和工具包，例如 Yahoo 的 YUI 和 Google 的 GWT 支持管理状态历史记录以提高用户体验。实现后，当用户单击“后退”按钮或 Backspace 键时，它允许用户在同一页面上恢复到以前的应用程序状态。

在 this video Google IO 强烈建议实现此类历史记录管理，并且事实上将其视为富 Web 应用程序的一部分。

我看到了这种方法的值(value)，但我不相信它真的支持普通用户的期望。在 StackOverflow 上研究这个问题时，我发现很多人都在提示覆盖“后退”功能的罪恶，难道不能说这种方法属于这一类吗？

就我个人而言，当“后退”仅更改页面状态时，我曾多次感到沮丧，而我真正想要的是退出到上次浏览的位置。 就我的使用情况而言，99% 的 Back 用例不是状态更改，而是页面更改。

最后，我真正的问题是:我们如何支持丰富的网络应用程序的历史记录管理而不覆盖“返回”？

编辑(最佳实践综述):

• 阅读 Michael 的博文后， 我现在在想，对于撤消 非链接用户控件(下拉菜单、文本 字段等)我会依赖 Control-Z 和/或按钮 - UI 得到广泛支持的模式。

• 返回应该至多恢复富网络应用程序提供的最粗粒度的 View 更改。它应该通过仅记住导航树中的单个分支来模拟浏览器历史记录:重复返回始终会导致根，然后是最后访问的页面。

Answer 1

后退应该反转链接完成的导航，而不是其他。用户将后退和链接与导航联系起来，因此从链接到后退对他们来说是很自然的，只要所有链接看起来都像指向用户的链接。

具体来说，我看到的唯一好的解决方案是“后退”让用户返回浏览器中的整个页面。换句话说，将“后退”视为胖客户端应用程序中的“关闭”或“取消”(或只是单击另一个窗口)。这与我的第一段一致，因为用户通常希望链接能够导航整个页面。因此，Back 也应该如此。

您不能让“后退”功能丰富的应用程序中的每个小输入都反转，因为当用户想要做的是查看他们刚刚所在的页面时，这将非常乏味。更糟糕的是，这意味着用户必须撤消设置当前页面的所有工作(甚至可能在文本框和组合框中输入内容)才能查看以前看到的页面。

您不能让“后退”恢复页面内的某些任意大的更改(例如，选项卡选择)，因为该更改是任意的。用户将无法预测何时使用“后退”。他们会害怕这样做，因为它可能会比他们想要的恢复得更多。

网络应用程序需要的不是重新定义“后退”或“历史记录”，而是一个完全独立的撤消功能，并配有自己的撤消缓冲区，以便处理页面内的用户输入。

我在 http://www.zuschlogin.com/?p=41 有所有血淋淋的细节。