2

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

在来自 Google IO 的这段视频中，强烈建议实施这种类型的历史管理，实际上它被认为是富网络应用程序的一部分。

我看到了这种方法的价值，但我不相信它真的支持普通用户的期望。在对 StackOverflow 上的这个问题进行研究时，我发现很多人抱怨覆盖“返回”功能的邪恶，难道不能说这种方法属于这一类吗？

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

最后，我真正的问题是：我们如何在不覆盖“返回”的情况下支持富 Web 应用程序的历史管理？

编辑（最佳实践综述）：

  • 在阅读 Michael 的博客文章后，我现在在想，对于非链接用户控件（下拉菜单、文本字段等）的撤消，我将依赖 Control-Z 和/或按钮 - 一种被广泛支持的 UI 模式。

  • Back 最多应该恢复富Web 应用程序提供的最粗粒度的视图更改。它应该通过只记住导航树中的一个分支来模拟浏览器历史记录：重复返回总是指向根目录，然后是访问的最后一页。

4

4 回答 4

2

Back 应该反转由链接完成的导航，仅此而已。用户将 Back 和链接与导航联系起来，因此从链接到 Backing 对他们来说是很自然的，只要所有链接看起来都像用户的链接。

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

你不能在一个丰富的应用程序中让 Back 反转每一个小输入，因为当用户想要做的是查看他们刚刚打开的页面时，这将非常乏味。更糟糕的是，这意味着用户必须撤消设置当前页面的所有工作（甚至可能在文本框和组合框中输入输入）才能看到以前看到的页面。

您不能让 Back 恢复页面中任意大的更改（例如，选项卡选择），因为该更改是任意的。用户将无法预测何时使用 Back。他们会害怕，因为它可能会恢复得比他们想要的要多得多。

Web 应用需要的不是对 Back 或 History 的重新定义，而是一个完全独立的 Undo 函数，具有自己的 Undo 缓冲区，以处理页面内的用户输入。

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

于 2009-12-15T22:18:26.763 回答
1

这取决于您要返回的应用程序的状态。例如，在 gmail 中，当我从一条消息转到我的收件箱时，back 将我带回该消息是非常明智的。在非 ajax 网络邮件中，这自然会发生。

但是，如果单击返回让我完成了我对收件箱中的邮件所做的所有选择和取消选择操作，那将很快变得烦人。因此，如果页面状态的变化大到足以保证它的存在，则应该使用历史管理，但如果它只是页面的一小部分发生了变化，则不应该使用。

于 2009-12-15T17:44:14.247 回答
0

“富 Web 应用程序”必须非常小心用户会认为什么是“新页面”，以及更愿意在页面上采取什么行动。这种对“页面”的感知应该通过浏览历史的行为来反映（“后退”和“前进”按钮只是与浏览历史交互的一种方式）。

许多“富 Web 应用程序”最好是简单的 HTML 页面。在这样的应用程序中，“页面”是什么通常是显而易见的。

其他应用程序最好使用真正的客户端-服务器模型：应该可以只下载一次客户端，而不是每次新会话。此类应用程序通常没有明显的“页面”模型，因此每个用户都有自己的想法，“返回”按钮应该做什么。在这种情况下，最好不要呈现“类似网络浏览器的界面”，以免引起错误的期望。我相信像 Java Web Start 这样的技术是此类应用程序的良好基础。

于 2009-12-15T18:34:18.310 回答
0

在我看来，页面历史和应用程序状态历史是两个完全不同的东西。所以我们有两个工具： 1. 我们将应用程序视为一个网站——在这种情况下，Back（和 Forward）应该像用纯 html 编写一样工作。正如 gmail 所做的 rjmunro 提到的那样。2. 我们将应用程序视为应用程序（一页） - 在这种情况下，后退按钮将为您带来应用程序启动之前的页面。那是你的99%，对吧？

BWT，退格是最烦人的。

于 2009-12-15T19:52:22.957 回答