我正在开发这个类似于博客的应用程序。我正在考虑做一个用户可以使用Google阅读器等“无限滚动”功能滚动浏览所有帖子的事情。
以下是我期待的问题...如果用户点击帖子进行编辑，则会将他/她带到新页面。很快他们就会想要回到滚动视图，他们可能想要回到他们点击“编辑”时所在的地方。
我想如果他们在点击“编辑”时看不到相同的帖子集合，他们会感到震惊。他们不想回到滚动 - 逐渐加载 - 发布过程的开始，并且必须重新进行。
我想到了在会话中存储累积帖子的ID和滚动位置，并在用户返回时重建所有内容。但是如果他们在点击“编辑”之前滚动了几十个或几百个帖子呢？这可能是在合理的时间内加载太多数据。
然后就是使用对话框而不是转到新页面进行编辑的想法，但这引入了另外一组问题。例如，如果用户试图在新标签中打开对话框，应该会发生什么？
所以也许这不是“无尽卷轴”的好地方。也许传统的分页是可行的。
有没有人实现过这样的东西？有什么想法吗？
答案 0 :(得分：1)
小心：我发现'无尽的卷轴'很烦人。它将滚动拇指作为位置指示器，令人惊讶的变化和暂停。在某些时候它会变得笨拙 - 你提到的'数百个帖子'场景 - 除非更复杂（当你很深的时候丢弃顶部的项目，提供随机访问）。
但是，请考虑一下您所引用的示例Google Reader如何处理问题：您很少会离开无尽滚动窗口。一些每项操作（标记）内联发生，但大多数链接在另一个窗口中打开以完全回避问题。如果您要更改设置，那么“返回谷歌阅读器”您的滚动位置将返回到顶部 - 所以也许这不是什么大不了的事。 （虽然值得注意的是：当你返回时，列表的范围是所有以前加载的项目 - 不原始的顶部加载。更多信息如下。）
我会考虑非模态就地编辑 - 编辑框插入滚动区域，在正在编辑的项目的顶部或旁边。
或者，如果连续性的一个关键位是您想要让人们回来查看他们刚编辑的项目，请确保“返回列表”链接包含指向视图应自动滚动的一个位置的指针 - （例如，在#fragment锚中）。
此外，如果您的代码或浏览器有效地缓存了数百个到前面的项目（正如我上面提到的Google Reader似乎那样），前滚应该是即时的，不需要重新加载。
答案 1 :(得分：1)
众所周知，无尽的滚动界面会有一个学习曲线 - 根据您的用户群，它们可能是相当陌生的领域，而且比帮助更令人困惑。这可能会在未来几年或几个月内发生变化，所以这一切都取决于......
与往常一样，如果有疑问，请向您的用户自己查询。理想情况下，你应该进行一项观察性研究，你可以使用类似的无限滚动UI观察它们。他们完全陷入困境吗？或者他们是否能够快速“获得”并将其视为比传统分页更快的解决方案？
请记住，像我们这样的人（使用推特和谷歌阅读器的人）处于领先地位，我们的需求，目标和期望可能与您的目标用户群不同。
因此，简而言之，您应该首先了解无限滚动UI是否合适。它完全有可能不是 - 因此整齐地回避你上面的问题。
答案 2 :(得分：1)
无尽/长卷轴是糟糕的可用性练习。即使您在编辑后设法将用户重定向到正确的帖子，他们也可能忘记了在编辑过程中他们在哪里。然后他们会翻页确认他们所在的页面。
也许只是保持简单并限制每页的帖子和＆amp;提供分页功能。这是用户熟悉的UI功能。他们不应迷路。
或者只提供每个帖子标题，可以在点击时展开/收缩，分别查看和隐藏完整帖子。这将允许每页更多帖子而不会过度滚动。
答案 3 :(得分：0)
我已经做过像这样的动态数据。我输出一个锚标记，它是帖子的ID并通过POST或GET传递，或者根据用户点击的内容传递给帖子，这样当他们再次导航到页面时，我的代码就会放入锚点。
类似的东西：
header("location:http://www.myDomain.com/posts.php" . "#" . $post_id);