
Complexities of an infinite scroller - PhilipA
https://developers.google.com/web/updates/2016/07/infinite-scroller
======
qwertyuiop924
Infinite scrolling is typically annoying, often making you do busy work to
find content you want, and frankly a worse solution than just having multiple
pages. So if it's also harder, why do it?

~~~
crummy
I'd rather infinite scroll my twitter feed than keep clicking Next Page.

~~~
zappo2938
It really depends how people are using it. If people are looking for random
interesting content then an infinite scroll makes sense. If you add the amount
of internet time spent is using Twitter, Facebook, and Reddit (app or RES),
then we can conclude that it is at a deeper level a better user interface for
certain types of content. People calling something that most people just
prefer without thinking about it and is mainstream 'hipster appeal' is quite
ironic.

~~~
gkya
People use whatever is there. We used websites and apps before infinite scroll
was a thing. The fact that some hacker types (me included) prefer this or that
is mostly irrelevant to the plain user.

------
BostonEnginerd
My pet peeve: When there is a link that I need to click on the footer of a
page that has infinite scroll. If you use this - please don't put a footer on
your page. It will just run away from your users.

------
martin-adams
I attempted to prototype what it would be like loading the space in the full
viewport so you can have an accurate scroll bar. It uses lazy loading with a
deliberate 1 second delay server side.

[http://www.meda.co.uk/sandbox/infinitescroll/list.php](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...](http://www.meda.co.uk/sandbox/infinitescroll/list.php?product=100)

~~~
zappo2938
OCD kicking in. Try setting the header box-sizing property to border-box.

------
happyslobro
Complexities that the article doesn't mention:

\- 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?"

~~~
asurma
Lots of good points here! This article (and the implementation) were born out
of the frustration with the lacking performance of most infinite scrollers. We
were aware of some of the issues you list (I’m not going to claim we thought
of _everything_ ;) ), which is also the reason why we are not providing a
library for people to use. Too much left to do right.

> 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.

~~~
happyslobro
A faraway sentinel element is pretty clever, I never thought of that.

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.

------
tlammens
Is it me or is it impossible to scroll that page in Safari?

~~~
qwertyuiop924
Gee. Google code not working on non-google browsers. What a surprise.

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"

~~~
Flow
They are apparently aware of it at least.
[https://news.ycombinator.com/item?id=11882964](https://news.ycombinator.com/item?id=11882964)

~~~
kinlan
We are aware, and it certainly wasn't intentional. Waiting for fix in our impl
of Material Design Lite (ironically before we move off it)

~~~
Flow
What are you gaining by replacing the native scroll functionality?

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?

~~~
kinlan
We didn't replace anything, there seems to be a bug in Safari that we have to
work around with a translatez() hack.. should be fixed now.

------
coolmitch
For a React implementation, look no further than react-virtualized
([https://github.com/bvaughn/react-
virtualized](https://github.com/bvaughn/react-virtualized)). Performant, great
featureset, and one of the most accessible, responsive maintainers I've ever
seen in an open source project.

------
EGreg
If you're going to do infinite scroll, at least make it fun and introduce
parallax scrolling fx. Especially on mobile, whoo!

Not joking: [http://www.creativebloq.com/web-design/parallax-
scrolling-11...](http://www.creativebloq.com/web-design/parallax-
scrolling-1131762)

~~~
gkya
Oh, cat litter with perfume.

------
romaniv
Hm. As far as perceived performance, I recently wrote a proof-of-concept
library using a timer and calculating viewport intersection of an element. It
_feels_ less annoying than a registered scroll event, although I did not do
any instrumented performance comparisons. (The point of the library was
progressive enhancement, not performance.)

------
swah
Page down failed for me. Is this really from google??

