Infinite Scroll on a classifieds list page, opinion on which is better

[csdude55]

Last year, I posted a rather detailed and lengthy script that I had mashed together to make a pretty passable infinite scroll system. I had to take a break on development, but now that I'm back in it I've hit a conundrum and I'm not sure which option would be better.

This is on the page where I list the classified ads. The user first selects a category or category / subcategory, which could be up to about 2000 results. The selected page shows the first 20 results.

As they scroll down and get to the bottom of the list, I load the next 20 results by sending an Ajax fragment for the same page, but with a GET variable of s=20 (which means "starting point = 20"). Then as they continue to scroll and get to the bottom again, I send s=40. And so on, until they get to the end of the results.

Now, here's where I hit the conundrum:

1. I can have the script update the address bar with the new variable, eg:

example.com/classifieds/category/subcategory/?s=20

The pro is that when the user clicks to view a listing and then clicks on back, their browser loads the page with the GET variable so they won't accidentally get pushed to the top of the list and have to start over... you can imagine how annoying it would be to be halfway down a list of 2000 items, and then have to start over!

The con is that they click to go on through the site and then try to return back, there's no way to scroll back up the list to see older results. I could add a button to the top when there's an s variable that says "show previous results" or something, but I'm not sure that it wouldn't be confusing to a lot of my users (many of whom are older or very computer illiterate).

2. I can have the script to NOT update the address bar, so that it always stays the same as the user scrolls.

The pro here is that they'll always load from the top (eg, s=0), so the problem with wanting to see older results is eliminated.

But, obviously, the con is that it brings back the problem of potentially having to scroll through the entire page to find where you were before.


Other potential solutions include:

3. When they click to view a listing, instead of linking directly to the listing I could make it run a function to set a cookie or SessionStorage with the ID of that item. Then when they come back, if s=0 then I could make it load results in MySQL until it gets to that ID and then drop down to it with an anchor. The coding would be a little complicated, but it could be done.

4. When they click to view a listing, instead of redirecting to a second page I could open it as an innerHTML on the current page. That would make it load faster (a great advantage!), and closing it would keep them exactly where they were, but with some negative side effects:

a. it would be confusing on mobile, where the screen isn't really big enough to make it obvious that they're on the same page; and

b. it's harder to copy or share the address, since the direct link for the listing wouldn't be in the address bar.


The easiest solution is #2, which would also be the most understandable to everyone. But it doesn't solve a common complaint that I've had over the years, so I'm not in love with it. After typing this all out, I'm kind of thinking about #2 (not changing the address bar), and then writing the script that I described in #3.

What would you guys and gals suggest?

[NickMNS]

Are you updating the URL as new sections are added?

eg:

at initial page load: example.com/classifieds/category/subcategory/?s=0 
at first AJAX call for more content: example.com/classifieds/category/subcategory/?s=1 
at second AJAX call for more content: example.com/classifieds/category/subcategory/?s=2
...

This can be done with JS using History.pushState();

The other issue is that each URL above should be reachable if requested directly. In other words if a user shares a link, and the next person goes to the link, the page should display the same content. This also ensures that Googlebot can crawl and subsequently index the URL.

If both these things are implemented correctly then your scenario 1 becomes the best solution. pushState() will store the various URL's, clicking back will take the user back. If the user refreshes, bookmarks or leaves and returns later the page can still be displayed as expected.

Don't forget that you can't keeping adding content to a page infinitely. At some point the browser will run out of memory and crash. If you progressively have a lot of content to add with AJAX remember that you also need to remove previously loaded content progressively. This adds to the complexity of the page/url structure.

[csdude55]

That's exactly how I'm doing it, Nick, using history.pushState(). On the PHP side, I'm currently loading the whole category of results in MySQL, and then I have an array that starts at $_GET['s'] and loops through the next 20 (or to the end, whichever comes first):

$start = 0;
$max = 20;
$sizeArr = [size of the final array, calculated separately];

if (is_numeric($_GET['s']))
 $start = $_GET['s'];

$end = $start + $max;
if ($end > $sizeArr)
 $end = $sizeArr;

for ($i = $start; $i < $end; $i++) {
 ...
}

So the problem with my #1 is that if someone shares the link like:

example.com/classifieds/category/subcategory/?s=200

then that will run the loop as:

for ($i = 200; $i < 220; $i++) { ... }

... skipping the first 200 results, and no way for the user to scroll up to see them.

Don't forget that you can't keeping adding content to a page infinitely.

True... right now the maximum that I've had to worry about is 100 iterations, and it seems to be fine on all of the browsers I've tested with. I'm not sure if my rebuild will increase the number of posts, decrease them, or have no impact, but if it increases posts to the point that I have a problem then I'll happily spend time perfecting it, as that will (hopefully) mean that I'm making more money :-D

[NickMNS]

From the bottom to the top...

True... right now the maximum that I've had to worry about is 100 iterations, and it seems to be fine on all of the browsers I've tested with

It is not a browser issue but a device issue. If the user has a phone or any device really, with limited memory they will reach the limit much sooner.

... skipping the first 200 results, and no way for the user to scroll up to see them.

You should have an AJAX call for both directions up and down. When the user lands on s=200 he/she sees the content for that block, if the user scrolls down, naturally you append the block for s=201. So, the opposite should work as well it the user scrolls up then you need to prepend the block for s=199 to the page. To allow for scrolling up, when page s=200 is requested display a page with s=199 to 201 and place the user with an anchor or JS at s=200, then when user scrolls up to 199 prepend 198 and delete 201. With this pattern you allow the user navigate as expected and limit the size of the page.