You will also end up losing your reading position after a browser restart or on iOS where Mobile Safari reloads a page to save memory.
It's a dumb, pointless feature that at the very least shouldn't be the default option. I'm sure there are hypothetical scenarios that may or may not warrant it, but it is a pain and a half for the user. Tumblr blogs have it in spades, and it's a miserable experience to browse.
That said, the problem of losing your reading position can be solved using something like history.replaceState(). As the user scrolls, update the history entry with a reference to the current reading location. Then, when the browser restarts, the website can know where the user was previously at and can return them to that location. This is the approach Discourse uses [1]. Alternatively, I suppose cookies could be used, but that's a slightly messier solution, imo.
Unfortunately, I haven't seen many websites adopt such a feature. Which is a shame because infinite scroll can make for a great user experience -- if done right. But too many websites actually suffer as a result of poorly implemented infinite scroll.
[1] https://eviltrout.com/2013/02/16/infinite-scrolling-that-wor...
Infinite scroll has other UX problems. For example, you cannot see the footer of a page or cannot navigate to the items by page number. As there is no page numbers you cannot even remember how to find some item.
Regarding footers, who's to say the footer needs to go beneath the infinite scroll area? You could instead place the contents of the footer in a sidebar that stays in a fixed position. Alternatively the footer could be overlayed at the bottom of the page so it is always visible (a recent design trend would have it hide when the user scrolls down, but reappear when the user scrolls up).
As for page numbers, there's nothing stopping you from adding them. Each item should probably have some sort of permalink to allow you access it directly, and there should be suitable navigation to allow you to find individual items.
I find it quite sad that infinite scroll gets a bad rap due to poorly designed implementations. Perhaps it will get a better reputation if more websites actually put some thought into how infinite scroll is used.
- usually breaks the back button (e.g. scroll to the 20th page, click something, go back. welcome to page 1!)
- usually breaks links (how do you show someone things-on-page-10?) (fixable by tweaking the URL as you go, but nothing is really consistent + predictable by non-technical users)
- usually performs hideously on low-power machines (e.g. mobile) due to memory growth (there are techniques, but few use them). can even tank powerful machines in time.
- footers. headers. etc.
This is easily overcome by pushState or what have you. As you scroll, the URL in the address bar changes to like `/page/20/` and then going back takes you to that URL where only the results from page 20 are displayed.
Another approach is with "virtual scrolling", by preserving space for the items above and loading whatever you scroll to - I've seen that once (I forget where) and it was really nice. They didn't tackle the linkability problem tho, and had other issues.
But all of this is fairly complex, and very few sites (or apps!) actually do so. Which is part of the problem.
I sometimes hate it (e.g. in facebook because it bluntly breaks the scrollbar), but at other times I miss it (e.g. in gmail).
Amazing how nice it is on the phone, but how broken it is (because of modal inconsistencies, the way you'll eventually have to press your browser back button) on the web version.
Similar is google maps. If you make it a large canvas where the missing data is paged in then it becomes quite natural.
Salient points seem to be:
# Update URL during scrolling so links don't break, and link to the "deep" item not just the first page.
# Don't break history, so back/forward/reload buttons act as would be expected.
# Truly endless scrolling kills browsers due to consuming increasing resources, so don't do it. Seems that a compromise might be: larger page sizes that lazy-load content up to a sensible max length. For example, in a data set of 1,000 results perhaps display the first 10 immediately and lazy-load up to 50 during scrolling. Then normal paging occurs. (Max items per page could be user-selected, as is currently seen sometimes.) Items that have scrolled off the top of the page could be removed from the DOM too, and lazily reloaded on demand.
# Endless scrolling is not always appropriate, but there may be appropriate use cases. It would be good to identify these cases, perhaps through user testing.
# Obviously, it shouldn't break screen readers or text-only browsers etc. These should be handled gracefully.... which raises the question of how to effectively navigate through a large list, possibly of unknowable length, in these browsers.
I feel sure I've seen various of these, but not all together in one implementation. Anyone seen somewhere that does all this well?
Any further suggestions/criticisms of this pattern?
I think I might start overriding the existing methods which users are used to with this method because I've build websites for a couple of years and think I know better than years of UI development by much more experienced people than I.
It would be nice to know if we're making progress on problems like this. Paging and scrolling both evolved to solve problems. Perhaps they're imperfect, or could stand improvement. Perhaps not. Regardless, an open-minded discussion would probably shed some light on current thinking.