|Deletions are marked like this.||Additions are marked like this.|
|Line 22:||Line 22:|
|Additional list types can be combined. Both '''[[Thumbnail Lists]]''' and '''[[Select Lists]]''' as well as conventional *Vertical Lists* can be employed with the features of an Infinite List.||Additional list types can be combined. Both '''[[Thumbnail List]]''' and '''[[Select List]]''' as well as conventional *Vertical Lists* can be employed with the features of an Infinite List.|
A Vertical List is called for, but the information set is very large, and not locally stored, so retrieval time is inconveniently long.
Use an Infinite List to retrieve and display smaller amounts of information at a time. The first displayed set will fill the viewport.
Information displayed, and interactivity with the listed items, is the same as for any other list view. Variations of the Vertical List can be employed as an Infinite List.
Information outside the viewport should be preemptively loaded, with precedence to the existing direction of scrolling if detectable.
The preferred method of interacting with the Infinite List is "predictive retrieval" and is largely transparent to the user. No explicit action is required to load additional information, although scrolling may be used as an implied action to retrieve information outside the viewport. To reduce network load, the entire data set will usually not be downloaded in the background, so limits are imposed.
A useful sub-variation of "explicit retrieval" is for new-only or otherwise filtered data sets (such as RSS feeds). The user must select which set of information to retrieve, not for systematic purposes but because that defines the additional information set in which the user is interested.
For "predictive retrieval" the user takes no explicit actions to load additional information. If an error occurs, a "refresh" or "reload" button may appear, and the list will temporarily function as an "explicit retrieval" list. The number of items loaded with each retrieval (especially the first) must be carefully designed by taking into consideration the speed with which items will be browsed by the user. Rules should be developed that react to a user scrolling repeatedly in the same direction by pre-loading more information than usual in the direction being scrolled.
For "explicit retrieval," an informational box will be displayed as the last item in the list, with details on the required behavior, and a button to allow loading more items. It should be clear how many more items will be loaded, or some other definition of the range of items, such as "load next day" for calendar items.
For "explicit retrieval" where specific filters may be applied, the available filter criteria should be made available at the end of the list. A button may be provided to show "all" information, which will then load the remainder as an Infinite List -- just a bit at a time. A series of selectors may be provided to allow selection of a specific limited set of information (such as all items within the last 30 days, 60 days, year).
Some information sets may be browsed in arbitrary order. Compare an address book with an email client. Arbitrary-access lists will require Location Jump, Search Within, and/or Sort and Filter Controls to provide access to the desired information without excessive scrolling (and excessive data retrieval). In these cases, waiting indicators will be more commonly seen as predictive loading cannot be smart enough for all cases. The action of jumping or searching should always load the retrieved data set, and not require an additional step to load the items.
Under absolutely ideal conditions, the operation of the Infinite List is transparent to the user, and appears to be a conventional Vertical List.
If the end of the retrieved information is reached, a message area should become visible. Depending on the variation employed, this will be a Wait Indicator that more information is being retrieved, or a selector to manually load more information. Error messages may also appear here if there were errors in retrieving the information. This informational area should be much larger than a single line item and be visually differentiated by color or style. A good practice is to have the information at the top of an area at least as tall as the viewport. The user can continue scrolling into the empty area, implying more information is available, and adding to clarity when scrolling at high speeds.
Retrieve a count of the list length and display the scrollbar -- or other scroll position indicators -- as though the whole set has been loaded. Do not allow it to re-adjust when additional content is loaded. For literally unlimited data sets (if scrolling decreases constraints, such as a geographical search sorted by distance) it is best to eliminate all location indicators.
For all types of "explicit" lists, the end of the list may not be the bottom. If the end of the information can be encountered when scrolling up, the explicit request should be at that point, above the list. Do not use a single location, or one that can be misleading.
There are almost no good non-technical reasons to require explicit lists for arbitrarily ordered sets. Use "predictive retrieval" whenever technically feasible.
Data costs are going down, and more and more users have unlimited plans. Unless you know your users are on limited plans or bad networks, load much more information than they are likely to need, to avoid them running into the end of the list.