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