许多客户端代码库＆amp;工具包，例如Yahoo的YUI和Google的GWT支持管理用户体验的状态历史。实现后，它允许用户在单击“后退”按钮或“后退”键时在同一页面上恢复到先前的应用程序状态。
在Google IO的this video中，强烈建议实施此类历史记录管理，事实上假设这是富网络应用的一部分。
我看到这种方法的价值，但我不相信它真的支持普通用户的期望。在研究StackOverflow上的这个问题时，我发现很多人都在讨论重写“后退”功能的邪恶，难道不能说这种方法属于那个类别吗？
我个人感到沮丧的是，当“Back”只是改变了页面状态时，我真正想要的是退出到我上一个浏览位置。 对于我的用法，Back的99％用例不是状态更改，而是页面更改。
最后，我真正的问题是：我们如何支持富Web应用的历史记录管理而不会覆盖“返回”？
编辑（最佳实践综述）：
阅读Michael的博文后， 我现在正在考虑撤消 非链接用户控件（下拉列表，文本 田野等）我会依赖 Control-Z和/或按钮 - UI 广泛支持的模式。
返回应该最多还原 富Web应用程序提供的最粗粒度视图更改。它应该通过仅记住导航树中的单个分支来模拟浏览器历史记录：重复返回总是指向根，然后是最后访问的页面。
答案 0 :(得分：2)
返回应该反转链接完成的导航，而不是其他任何内容。用户绑定Back和链接与导航，因此从链接到Backing对他们来说很自然，只要所有链接看起来像链接到用户。
具体来说，我看到的唯一一个好的解决方案是Back用于将用户带回浏览器中的整个页面。换句话说，在厚客户端应用程序中对待它像关闭或取消（或只是单击另一个窗口）。这与我的第一段一致，因为用户通常希望链接导航整个页面。因此，Back也应该。
你不能让富的应用程序中的每一个小输入都反向转换，因为当用户想要做的是查看他们刚刚打开的页面时，这将非常繁琐。更糟糕的是，这意味着用户必须撤消他们设置当前页面的所有工作（甚至可能在文本框和组合框中输入输入），以便查看以前看到的页面。
你不能让Back在页面中恢复一些任意大的变化（例如，选项卡选择），因为这种变化是任意的。用户将无法预测何时使用Back。他们会害怕，因为它可能会比他们想要的还要多。
Web应用程序需要的不是Back或History的重新定义，而是完全独立的Undo功能，配有自己的Undo缓冲区，以便处理页面内的用户输入。
的所有血腥细节答案 1 :(得分：1)
这取决于您要返回的应用程序的状态。例如，在gmail中，当我从一条消息转到我的收件箱时，将我带回到消息中是非常明智的。在非ajax webmail中，这是自然会发生的事情。
但是，如果点击后退我完成了对收件箱中的邮件所做的所有选择和取消选择操作，那将很快变得烦人。因此，如果页面状态的变化足够大以保证它，则应该使用历史管理，但如果它只是页面的一小部分已经改变，则不应该使用历史管理。
答案 2 :(得分：0)
“富Web应用程序”必须非常小心用户将其视为“新页面”的内容，以及在页面上的某些操作。然后，浏览历史的行为（“后退”和“前进”按钮只是与浏览历史交互的一种方式）反映了对“页面”的看法。
许多“富Web应用程序”最好是简单的HTML页面。在这些应用程序中，通常很明显“页面”是什么。
其他应用程序最好使用真正的客户端 - 服务器模型：应该可以只下载一次客户端，而不是每个新会话。这些应用程序通常没有明显的“页面”模型，因此每个用户都有自己的想法“后退”按钮应该做什么。在这种情况下，甚至不提出“类似网络浏览器的界面”，以免引起错误的期望。我相信像Java Web Start这样的技术是这类应用程序的良好基础。
答案 3 :(得分：0)
在我看来，页面历史和应用程序状态历史是两个完全不同的东西。所以我们有两个chaises： 1.我们将应用程序视为一个网站 - 在这种情况下，Back（和Forward也应该）就像使用普通的html编写一样。正如gj所做的那样，rjmunro提到了。 2.我们将应用程序视为应用程序（一页） - 在这种情况下，“返回”按钮将在应用程序启动之前为您显示该页面。这是你的99％，对吗？
BWT，Backspace是最烦人的。