当列表变得非常大时，在UI中显示它会引发设计问题。用户是否应该获取项目页面，或者用户是否应该获得一个列表控件，该页面控件在滚动时会隐式页面？
在Google搜索中，结果的分页是明确的。您将获得一组结果并点击链接以获取下一组结果。在iPhone上，应用程序商店中的应用程序名称被隐式分页。在这种情况下，滚动会导致它们加载。 Outlook中的收件箱是隐式分页的，但Outlook Web Access中的收件箱是明确分页的。
在进行此UI设计决策时应考虑哪些因素？
编辑：非常大一词需要进行一些解释 给出一些结构考虑这些不同的情况：
案例A：清单： 1.随着时间的推移可能会增 2.至少有20亿件物品。
案例B：清单： 1.随着时间的推移可能会增 2.有数以千计的物品。
我声称案件A和B在质量上有所不同，但我当然愿意证明我错了。
答案 0 :(得分：4)
假设天空是极限，并且您不受您工作的本机工具包或框架的限制，有几个注意事项：
答案 1 :(得分：2)
我们可以说显式分页基本上是在（1）带宽有限且（2）没有直接可用的过滤/排序/搜索选项的情况下实现的吗？ Outlook就是一个很好的例子：富客户端版本不关心显式分页，并提供过滤/排序/搜索数据的所有奇特选项。 Web版本实现了显式分页，并且没有这样的选项（至少不实现它们是相同的直接方式）。
因此，显式分页是数据分页的“简化/限制”版本，其中隐式格式是原始标准。如果您可以向用户建议“隐式”数据分页格式，请选择它。查看Excel表格，了解如何允许数据过滤/排序/搜索。你甚至可以看一下one of my posts，我肯定会受到Excel的启发，为我们自己的用户界面设置标准。
编辑：
根据Steve Steiner对我的回答的评论，我应该补充一点，明确的分页很少符合“面向业务”的请求，你想看看上个月的发票或者从去年开始获得ACME的完整交付清单，最后将这些列表导出到Excel，Outlook或PDF文件。在需要详尽回答请求的情况下，显式分页可能会引起混淆或限制用户的工作效率。
答案 2 :(得分：1)
还存在谷歌基于网络的问题。使用基于Web的应用程序，您可以使用超过几千行，甚至更少的行程来推动极限。列表框可能支持更多，但如果你像谷歌一样呈现html，那么你将会把大多数浏览器推向黑暗的一面，反应超过几千行，大多数情况下需要更少的浏览器。
因此，Web浏览器的技术限制是非常真实的。有时大型数据集在大多数浏览器中运行良好，但在其他浏览器中会出现问题。并且没有一件事可以解决，以使其在所有浏览器中都能正常运行。
答案 3 :(得分：1)
以下是我要考虑的一些问题：
从用户的角度来看，拥有包含数百或数千个条目（甚至数十个条目）的列表的价值是什么？
与简单地查看列表的第一部分相比，用户有多大可能需要滚动（或翻页）一大组值？
是否有自然排序可以在列表的早期放置“最佳”值？
订购是否应由用户偏好控制（例如，排序键等）？
不是将决策硬连接到应用程序中，而是将其作为用户选择/配置公开？是否允许用户决定（和应用程序记住！）使用哪种策略，要显示多少元素等？
答案 4 :(得分：0)
分页滚动没有可用性优势。寻呼是Web界面的工件，其寻求由于技术原因（例如，网络或服务器负载，通过拨号的页面加载速率）一次最小化发送的内容量。如果您没有遇到此类限制，请使用滚动。
与分页相比，滚动具有以下优势：
滚动条控件已标准化，因此大多数用户已熟悉它。寻呼缺乏标准化，因此需要注意并学习使用它（例如，页面链接所在的位置，是否有第一个或最后一个链接）。
显示的项目数量会随着窗口大小调整自动调整，允许用户优化一步显示的项目数量，并避免同时滚动和分页时的情况。
无论用户在窗口的哪个位置，都可以访问滚动条。寻呼接口通常仅在页面的顶部和/或底部提供页面链接，这可以滚动出视图。
用户一次只能移动一个项目，以显示他们想要一起看的项目。分页将项目拆分为任意组，这可能导致感兴趣的项目在页面之间分割。
用户只需一次拖动即可滚动到列表中的任意位置。分页仅限于显示的页面链接，通常限制用户仅在附近区域移动。
用户可以多选任何一组项目以对其执行操作（例如，复制，删除），并且用户可以在保持当前选择的同时查看任何其他项目。分页通常只允许和维护当前页面上的项目选择。
用户仍然可以通过单击滚动条的“轨道”一次移动一个“页面”。