深度链接无限滚动页面

发布于 2024-10-04 11:53:11 字数 539 浏览 2 评论 0原文

我正在创建一个无限滚动的页面,该页面递归加载下一页的内容并将其附加到当前页面中。我认为浏览体验可以是很棒的、身临其境的,但当前的方法并非没有可用性缺陷。

不完全的渐进增强。使用 Ajax 时,支持后退按钮并提供深层链接总是好的。当前的无限滚动实现不支持这一点。无法为状态添加书签。

关于改善无限滚动用户体验的一些想法。需要意见。

  1. 每次加载时更改 URL 哈希,例如 /!#/2 -> /!#/3
  2. 单击后退按钮应向上滚动页面。单击前进按钮应向下滚动。
  3. 访问深层链接的行为应该像 Ajax 之前一样。转到第 3 页并从第 3 页开始应该仅显示第 3 页的内容,而不显示第 2 页和第 1 页,因为用户没有要求它们。
  4. 应该仍然有办法让他转到第 2 页和第 1 页,就像常规分页一样。由于第3页加载时scrollTop为0,因此向上滚动事件没有用处。为此,我们可能仍然需要一个可点击的链接。
  5. 我们需要检查请求的页码是否大于当前页码,因为我们不应该在第 3 页的末尾加载第 2 页的内容。

你们觉得怎么样?

I'm creating a infinitely scrolled page that recursively loads and append the next page's content into the current page. I think the browsing experience can be great and immersive but the current method is not without usability drawbacks.

Incomplete progressive enhancement. It is always good to support the back button and provide deep linking when using Ajax. The current implementations of infinite scroll does not support this. There is no way a state can be bookmarked.

Some ideas on improving the UX of infinite scroll. Need opinion.

  1. Change the URL hash with each load, e.g. /!#/2 -> /!#/3
  2. Clicking the back button should scroll the page upwards. Clicking forward button should scroll it down.
  3. Accessing a deep link should behave like it was before Ajax. Going to and also starting at page 3 should show only page 3 content and not page 2 and 1, since the user is not asking for them.
  4. There should still be a way for him go to page 2 and 1, like if it was regular pagination. Since page 3 is loaded with scrollTop at 0, the scroll up event is not useful. For this we might still need a clickable link.
  5. We need to check if the requested page number is greater than the current because we should not loaded page 2's content at the end of page 3.

What do you guys think?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

旧时光的容颜 2024-10-11 11:53:11

有趣的问题。我建议以 #!/from/123/to/456 的形式更改 URL 哈希,并在页面加载时增加 to id。

无论您是使用哈希还是 History API 重写来修改 URL,从用户体验的角度来看,URL 始终代表当前内容的位置。例如,用户期望有一个书签,点击重新加载,或将 URL 复制到其他计算机并单击“Go”,将返回相同的页面。

让你的无限滚动页面完成URL逻辑的唯一方法就是我上面建议的URL hash。否则就离开它; Twitter 不会更新其主页上的 URL 哈希值。

Interesting question. I would suggest changing the URL hash in the form of #!/from/123/to/456, and increase the to ids as page loads.

Whether you are using hash or History API rewrite to modify URL, in UX sense, URL always represent the location of current content. For example, user will expect a bookmark, hitting reload, or copying the URL to other computer and click Go, will return the same page.

The only way for your infinite scrolling page to complete the logic of URL is the URL hash I suggested above. Otherwise just leave it; Twitter doesn't update URL hash on their home page.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文