Complexities of an infinite scroller
developers.google.com
developers.google.com
Especially when it's a list like favorites where you would what to browse to any point equally as often (im looking at you SoundCloud).
I'm hoping that infinite scroll looses the hipster appeal sooner or later and we can implement the best solution rather than jumping on the bandwagon all the time (SoundCloud's favorites were paginated a few years ago).
All infinite scrolls should come with a filter that lets you hide all of the stuff you are not looking for.
http://www.meda.co.uk/sandbox/infinitescroll/list.php
Fun project, but very challenging to make it work it fast on a mobile device.
Basically it adds placeholder elements and adds the items when they get close to the viewport.
It did have the advantage that you can link to a specific product in the list.
http://www.meda.co.uk/sandbox/infinitescroll/list.php?produc...
- Browser location: When you switch from basic pagination to infinite scroll, you either take full responsibility for the navigation controls that the browser would have handled, or you accept the loss of those features on behalf of your users. When the user scrolls, will you update a page parameter in the URL? Can a user share a link to a spot deep down the list with a friend? When someone follows that link, what happens if they scroll upward? What happens when they hit the home button?
- Home button: Throw away everything and load the first page of the list. But don't forget to reuse those expensive elements. And even though you're no longer using the elements before the window position, you might as well keep them around if you expect the user to scroll downwards again.
- Back button, after leaving the list: If a user follows a link from deep within the list, and then navigates back, where do you put their view in the list? If you ignore the problem, will some browsers try to scroll to the user's last scroll position at this URL (Firefox will, and it will get it wrong if you're removing elements as the user scrolls down).
- Back button, within the list: Is this just going to scroll the user upwards a bunch of times, which is consistent with classic pagination, or will it take them to wherever they were before they entered the list, which makes sense when you consider the entire list of be a single "page"?
- Ctrl-F to find: can we still do this? Are you going replace it with a search bar? Is there any text that is shown to users, but not indexed by your search implementation? Are you searching outwards from the current position, or from the top of the list?
- Scroll bar: Are we just giving up on these, or can we agree that they are common in applications because they are actually valuable from a UX perspective? Should it accurately represent the position of the viewport in the whole list, which requires the application to know the length of the list and the size of each item, or are we going to settle for just showing the view's position within the current subset of the list, which is not nearly as useful?
- What happens when the scrollbar jumps our from under the mouse on various platforms, as elements are recycled from one end of the list to the other? Do we need to prevent that from happening?
- Should we preallocate a large number of elements with placeholder content, so that we can create DOM elements only once, if we do not have enough recyclables for the next page of content?
- What is the optimal number of elements to keep around? What about on a mobile device or a crappy web-tv with 1GB ram? On a desktop with 16gb ram? Does it vary greatly depending on the DOM rendering engine? How does the latency / bandwidth ratio affect the optimal page size?
- Do your users move around much, or do they normally only browse forward, slowly, and then leave? Are the rare users who do move around alot likely to be significantly more valuable to you than the simple users?
- API request caching headers: if the user scrolls back, do they actually need to make another HTTP request for content that they just saw recently? If they do make that request, what happens when there is a new item to insert in the list?
TL;DR Do not take it for granted that infinite scroll is even a good idea for your content. I've built a bunch of these over past decade, not just on web, and now I cringe a little when a client quips "oh, and let's make it infinite-scroll, not paginated, ok?"
> Navigation controls
Definitely something that needs thinking and that we intentionally didn’t address here.
> Ctrl+F
We were think on how to solve this, but we weren’t able to come up with anything using the tools the platform provides currently. Maybe a future API will help here.
> Scrollbars
I thought we did a pretty good job on the scrollbar. You can still click the scrollbar indicator and drag it around to quickly jump from position to the other. It’s not AS accurate, but still useful and doesn’t diminish UX imo.
> Jumping scrollbar
Should barely happen! We are using a sentinel element to define the length of the runway, not the elements themselves to minimize jumping. I think it can only happen if elements grow drastically in height when going from tombstone to actual content.
> “Adaptive DOM pool”
This is definitely an improvement that could be made. Currently we just maintain N elements and N tombstones in memory. N could dynamically adapt to the capabilities of the device.
> Caching
How much caching is utilized is very much up to you. If the API doesn’t provide good caching headers you could implement that yourself in the data source. I think this falls outside of the technical scope of the scroller itself.
Anyway, as long as there are legitimate cases where infinite scroll is superior to click-to-page, I am glad that someone is focusing on this problem and treating it seriously. When you really stop to consider the problem, you start to see that it has all of the complexity of a one dimensional scenegraph over dynamic terrain, in a game where the "player" can warp and fly at high speeds, but can't reasonably store the full dataset locally.
a.i. CTRL+F to search current state, then click on option to search in the way that website implements and then perhaps use global search (optional).
I'm sure graybeards will argue this breaks web in some way, so pardon my ignorance.
1. When a search engine indexes something dynamic that has changed by the time I visit the page, and 2. When some part of the UI is in the DOM, but not visible.
#1 could probably be solved by judicious use of <aside> on the part of developers, and by SEO penalties imposed on sites that update indexed content without inviting a crawler over to see it within a timely manner.
As for #2, I avoid this problem in React by imposing a rule in the coding standards: Do not hide elements. Omit them from a render function when you don't need them. This idea of keeping a stash of recyclable elements complicates that a little.
What browser vendors could do to help, is identify non-visible elements and omit them from the Ctrl-F search index. They are probably already identifying invisible elements in order to prune them from the renderer's view of the DOM tree. I wonder how hard it is to submit a pull request to Chromium?
Speaking as a firefox user, I'm lucky if google docs even loads, let alone works properly. Yet a another example of google talking out of their ass about "supporting web standards"
Are you trying to add "standard Android scrolling inertia" or something? I mean you must be trying to change something, or will I not notice it when it's working?
We currently can’t scroll on the body element due to a limitation in Chrome, where an empty body layer is not being optimized. So we are scrolling in an element. However, that usually requires setting `-webkit-overflow-scrolling: touch;` so that you can scroll as usual on iOS. However, that in turn has a lot of hidden implications (like squashing layers, etc. Don’t know the details right now), that make performance suffer greatly.
AFAIK, Safari will change their scroll-on-element behavior. Let’s see what the future brings.
Not joking: http://www.creativebloq.com/web-design/parallax-scrolling-11...