在 UI 中决定显式分页还是隐式分页时应考虑什么？
当列表变得非常大时，在 UI 中呈现它会引发设计问题。 用户应该获取项目页面还是用户应该获取在滚动时隐式分页项目的列表控件？
在谷歌搜索中，结果分页是明确的。 您会获得一组结果，然后点击链接即可获得下一组结果。 在 iPhone 上，应用程序商店中的应用程序名称是隐式分页的。 在这种情况下，滚动会导致它们加载。 Outlook 中的收件箱是隐式分页的，但 Outlook Web Access 中的收件箱是显式分页的。
在做出 UI 设计决策时应考虑哪些因素？
编辑：术语非常大需要进行一些解释。
为了给出一些结构，请考虑以下不同的情况：
情况 A：列表： 1. 可能会随着时间的推移而增长。 2.拥有至少20亿件物品。
案例 B： 清单： 1. 可能会随着时间的推移而增长。 2.拥有数千种物品。
我认为案例 A 和 B 在本质上是不同的，尽管我当然愿意被证明我错了。
When a list becomes very large, presenting it in a UI raises a design issue. Should the user get pages of items or should the user get a list control that pages items implicitly as it is scrolled?
In google search, paging of results is explicit. You get a set of results and hit a link to get the next set. On the iPhone the application names in the app store are implicitly paged. In that case scrolling causes them to load. The inbox in Outlook is implicitly paged, but the inbox in Outlook Web Access is explicitly paged.
What factors should be considered when when making this UI design decision?
Edit: The term very large is subject to some interpretation.
To give some structure consider these different cases:
Case A: The list:
1. May grow over time.
2. Has at least 2 Billion items.
Case B: The list:
1. May grow over time.
2. Has thousands of items.
I'd claim case A and B are qualitatively different, though I'm certainly open to being shown that I'm wrong.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
假设天空是无限的，并且您不受正在使用的本机工具包或框架的限制，则有几个考虑因素：
Assuming the sky's the limit and you are not constrained by the native toolkit or framework under which you are working, there are several considerations:
我们是否可以说显式寻呼基本上是在以下情况下实现的：（1）带宽有限且（2）没有直接可用的过滤/排序/搜索选项？ Outlook 就是一个完美的例子：富客户端版本不关心显式分页，并提供用于过滤/排序/搜索数据的所有奇特选项。 Web版本实现了显式分页，并且没有这样的选项（至少不实现它们是相同的直接方式）。
因此，显式分页是数据分页的“简化/有限”版本，其中隐式格式是原始标准。 如果您可以向用户建议“隐式”数据分页格式，那就采用吧。 查看 Excel 工作表，了解如何允许数据过滤/排序/搜索的一些想法。 您甚至可以查看我的一篇帖子< /a>，我确实受到了 Excel 的启发，为我们自己的用户界面建立了标准。
编辑：
根据 Steve Steiner 对我的回答的评论，我应该补充一点，显式分页很少符合“面向业务”的请求，您想查看上个月的发票或获取 ACME 自去年以来的完整交付列表，最后将这些列表导出到 Excel、Outlook 或 PDF 文件。 在这些需要彻底答复请求的情况下，显式寻呼可能会造成混乱或限制用户的工作效率。
Can we say that explicit paging is basically implemented where both (1) bandwidth is limited and (2) no filtering/ordering/searching options are directly available? Outlook is the perfect example for that: the rich-client version doesn't care about explicit paging, and offers all the fancy options for filtering/ordering/searching data. The web version implements explicit paging, and does not have such options (at least do not implement them is the same straight way).
So explicit paging is a 'reduced/limited' version of data paging, where the implicit format is the original standard. If you can propose to your users the 'implicit' data paging format, go for it. Have a look at Excel sheets to get some ideas on how to allow data filtering/ordering/searching. You can even have a look at one of my posts, where I was definitely inspired by Excel to set up the standards for our own user interface.
EDIT:
following Steve Steiner's comment on my answer, I should add that explicit paging rarely complies with 'business-oriented' requests, where you want to have a look at last month's invoices or get the complete list of deliveries by ACME since last year, and finally export theses lists to Excel, Outlook or PDF file. In these situations, where requests need to be exhaustively answered, explicit paging can be a source of confusion or limits user's productivity.
还有一个问题是谷歌是基于网络的。 对于基于 Web 的应用程序，您将突破数千行以上（甚至可能更少）的限制。 列表框可能支持更多，但如果你像谷歌一样渲染 html，你会用超过几千行的响应将大多数浏览器炸到黑暗的一面，通常需要的要少得多。
因此，网络浏览器的技术限制是非常现实的。 有时，大型数据集在大多数浏览器中运行良好，但在其他浏览器中会遇到问题。 并且没有任何一件事可以修复以使其在所有浏览器中正常运行。
There is also the issue that google is web based. With web based applications you're pushing the limits with anything more than a few thousand rows, probably less. A listbox may support more, but if you're rendering html like google you're going to blast most browsers to the dark side with more than a couple of thousand lines of response, most often a lot less is required.
So the technical limits are very real on web browsers. Sometimes large datasets work well in most browsers, but you get problems in others. And there's no single thing you can fix to make it work well in all browsers.
以下是我要考虑的一些问题：
从用户的角度来看，拥有数百或数千个条目（甚至数十个条目）的列表有什么价值？
用户必须滚动（或翻页）大量值与仅查看列表的第一部分的可能性有多大？
是否存在一种自然的顺序，可以将“最佳”值放在列表的前面？
排序是否应该由用户首选项控制（例如，排序键等）？
不是将决策硬连接到应用程序中，而是可以将其公开为用户选择/配置吗？ 是否可以允许用户决定（并且应用程序记住！）使用哪种策略、显示多少元素等等？
Here are some questions I'd consider:
From the perspective of the user, what's the value in having a list with hundreds or thousands of entries (or even tens of entries)?
How likely is the user to have to scroll (or page) through a large set of values vs. simply looking at the first part of the list?
Is there a natural ordering that makes it possible to put the "best" values early in the list?
Is the ordering something that should be controlled by user preferences (e.g. what sort key, etc.)?
Instead of hard-wiring the decision into the application, could this be exposed as a user choice/configuration? Could the user be allowed to decide (and the app remember!) which strategy to use, how many elements to display, etc.?
与滚动相比，分页没有可用性优势。 分页是 Web 界面的产物，旨在最大限度地减少出于技术原因（例如，网络或服务器负载、拨号上的页面加载率）而一次发送的内容量。 如果您没有遇到此类限制，请使用滚动。
与分页相比，滚动具有以下优点：
滚动条控件是标准化的，因此大多数用户已经熟悉它。 分页缺乏标准化，因此需要注意并学习使用它（例如，页面链接所在的位置，是否有第一个链接或最后一个链接）。
无论用户位于窗口中的哪个位置，都可以访问滚动条。 分页界面通常仅在页面的顶部和/或底部提供页面链接，这些页面链接可以滚动到视图之外。
用户一次只需移动一个项目即可显示他们想要一起查看的项目。 分页将项目拆分为任意组，这可能会导致感兴趣的项目被跨页拆分。
用户只需拖动一下即可滚动到列表中的任意位置。 分页仅限于显示的页面链接，通常限制用户只能在附近移动。
用户可以多选任何一组项目来对其执行操作（例如，复制、删除），并且用户可以在保持当前选择的同时查看任何其他项目。 分页通常只允许并维护对当前页面上的项目的选择。
用户仍然可以通过单击滚动条的“轨道”一次移动一页。
There’s no usability advantage of paging over scrolling. Paging is an artifact of web interfaces that seek to minimize the amount of content sent out at once for technical reasons (e.g., network or server load, page load rates over dial-up). If you are not faced with such limitations, use scrolling.
Scrolling has the following advantages over paging:
The scrollbar control is standardized so most users are already familiar with it. Paging lacks standardization so it takes attention and learning to use it (e.g., where it the page links are located, whether there’s a First or Last link).
The number of items shown automatically adjusts with window resizing, allowing users to optimize the number of items visible in one step and avoiding situations when there is both scrolling and paging.
The scrollbar is accessible no matter where the user is in the window. Paging interfaces typically provide the page links at only the top and/or bottom of the page which can scroll out of view.
Users can move as little as one item at a time to show the items they want to see together. Paging splits items into arbitrary groups which can result in the items of interest being split across pages.
Users can scroll to anywhere in the list with a single drag. Paging is limited to the page links shown, generally limiting the user to move only around the immediate neighborhood.
Users can multi-select any set of items to perform an action on them (e.g., copying, deleting), and users can look at any other item while maintaining the current selection. Paging generally allows and maintains only selection of the items on the current page.
Users can still move one “page” at a time anyway by clicking the “track” of the scrollbar.