[RFC] Auto-load additional content on scrolling to end

[DavidIQ]

After some discussion about this feature here and even though it was ikd that first brought it up, I felt the idea needed its own RFC to be properly decided on/discussed.

What is it?

• Upon scrolling to the bottom of a topic or a forum the next page would be loaded automatically using the AJAX jQuery implementation.

Why would you want that?

• Improves the reading flow when reading a topic.
• Reduces wait time.
• Reduces server load.

Details/History
In all versions of phpBB when you get to the bottom of a topic or a forum if you want to view the next page you'd have to click on one of several links (Next, Previous, 1, 2, 3, etc.). This causes an entirely new page to be loaded, causing the user to have to wait and doing a complete server postback/callback. This means the user must remember the details of what they were reading while they wait. Even if the auto-loading took a bit long the user could scroll up and re-read what was posted and keep the flow instead of having to go back to the previous page.

When receiving topic reply notifications the link in the e-mail takes the user directly to the post that was made at the time the e-mail was generated. If there are more pages the user would have to go through pagination yet again. If the next page auto-loaded there would be no need to do that.

This would just be basically on an on/off switch in the ACP that would be all-inclusive. I can't think of a reason why you would want to enable it only for specific areas. If there is a good use case for that then by all means share. A user setting for it could also be implemented.

Where would we do this at?
Some places that can be considered for auto-loading when reaching the bottom of the page:

• Topics
• Topic lists (i.e. viewforum.php)
• Forum lists (i.e. index.php)
• Search results
• Memberlist
• Who's online
• Others...

These may or may not be good locations for this feature and I may have missed some other places that could benefit from this so please suggest your own for addition.

[Oleg]

For anyone thinking about implementing this please make sure back and forward navigation works correctly, links to posts work correctly, etc.

Most if not all sites that adopt the approach of loading additional content on the bottom of the page that I have experience with (e.g. github, jira) make it practically impossible to actually navigate said lists, and back/forward navigation is completely ruined.

Gmail disallowed jumping to a particular page for as long as I can remember and now they even deleted the link to go to the end of search results. As a result both their search and navigation are now pretty much unusable.

[callumacrae]

I think I would prefer to use arrow keys

[ecwpa]

An then I said:

For anyone thinking about implementing this please make sure back and forward navigation works correctly, links to posts work correctly, etc.

I like Reddit's RES implementation.

No, IMO, endless page loading sucks, and what happen when you got a topic like this one http://www.celinedionforum.com/Whatand3 ... t1014.html where there like over 91,513 posts in that one topic?

That could be a problem. Maybe if the user has the choice? Like showing "Load more comments" at the botton of the screen but also showing at the right "Show pagination" or something like that.

Now, my question is, what are the cons? How should phpBB handle links to specific posts AND pagination at the same time since both would use internal links.

Like this:

viewtopic.php?f=108&t=42113#p231603

and

viewtopic.php?f=108&t=42113#page=3

How do you continue to page 4 coming from the first URL?

[imkingdavid]

In response to the comments in the other topic about load time/bandwidth issues due to the "endless page", imo it shouldn't make that big of a difference. The posts aren't automatically loaded until the page is scrolled to a certain point (beyond the last post?). The whole post isn't loaded all at once and then displayed in batches, but rather dynamically loaded only when requested and even then only loading a certain amount at a time.

And yes, the feature should be configurable, both in the the ACP (global on/off, how many to load at a time [although that would probably be the same as posts per page] etc.) and the UCP (use the feature or not). Of course if the feature is disabled, it would fall back to the traditional pagination that is currently in use.

One thing to consider, however, is how to handle the footer if this is enabled. Obviously the posts would continue to be added to the end of the topic if the user scolls to the bottom of the page, rendering the footer links and information (not only copyright stuff but the links and such specific to the topic itself) inaccessible until the final post is loaded.

One way to fix that would be, perhaps, only automatically loading the new posts once per page load and then simply displaying a "view more posts" link after the last post to be loaded. This way the auto-loading wouldn't get in the way of trying to access topic and footer links at the bottom.

Edit: Alternatively, we could have the footer in a fixed div or semi-fixed div (aka fixed after a certain point on the page, like in the Bug Tracker) so that it can still be accessed even when more posts are loaded behind/below it. Does that make sense?

Edit: In terms of pagination, I think this should be used alongside pagination. Here's what I mean: In Microsoft Word, as you scroll, the page number in the bottom of the program updates with the appropriate number. I think that it wouldn't be too difficult to do so by using spans or divs with page number ids (e.g. <span id="page-number">#</span>, where the # is the page number. These are hidden via CSS from view (visibility: hidden, rather than display: none, since items with hidden visibility are still there in the page source and can therefore be used by jQuery) and then as the page scrolls by them, jQuery grabs the automatically updates the page number shown as active in the pagination (which would now have to have an alternate positioning, I think). Of course I may have a fundamentally incorrect idea of what is possible with jQuery, so this may or may not be a possibility. Please let me know, if so.

Yet another Edit: Basically, there would need to be a way for jQuery to know the page's current scrolled position, i.e. what's currently in view. As the page scrolls the page number span into the viewable region, the page number is then updated. I'm not sure how or if that would work, but it's an idea.

As for dealing with starting on an inner page, I think that callumacrae had a workable idea, though it too could be difficult to implement. For those of you who can't be bothered to click the link, he basically suggested removing posts from the start of the topic as you scroll through, effectively leaving a maximum of X number of posts on the page. In that case, the posts would have to also be loaded as you scroll up (or at least you could click a "begin loading previous posts" button that would load the previous page and start taking into account whether or not you are still scrolling up and then load even less-recent posts.

[callumacrae]

As for dealing with starting on an inner page, I think that callumacrae had a workable idea, though it too could be difficult to implement. For those of you who can't be bothered to click the link, he basically suggested removing posts from the start of the topic as you scroll through, effectively leaving a maximum of X number of posts on the page. In that case, the posts would have to also be loaded as you scroll up (or at least you could click a "begin loading previous posts" button that would load the previous page and start taking into account whether or not you are still scrolling up and then load even less-recent posts.

As the posts are looped through and rendered as they are requested:

Code: Select all

if ($('.post').length > 50)
{
    $($('.post').get(0)).remove();
}

[Danielx64]

In the end, I really don't think it would be a good idea to have endless page loading. There are too many issues such as topics with alot of posts in it (like the one I posted about), not being able to jump between pages, linking to posts and other things.

For now, it a no from me.

[DavidIQ]

One thing to consider, however, is how to handle the footer if this is enabled. Obviously the posts would continue to be added to the end of the topic if the user scolls to the bottom of the page, rendering the footer links and information (not only copyright stuff but the links and such specific to the topic itself) inaccessible until the final post is loaded.

One way to fix that would be, perhaps, only automatically loading the new posts once per page load and then simply displaying a "view more posts" link after the last post to be loaded. This way the auto-loading wouldn't get in the way of trying to access topic and footer links at the bottom.

That would be the way I would handle it.

As far as pagination goes I think that the way it would work is that once you get to the bottom of the page you would then see the next page load up at the bottom of the current page and the pagination would update itself to reduce the number of pages to display. If coming in on a post in the middle of the topic I would just load the page the post is in as it does now then take care of the auto-loading as you reach the bottom of the page.

[imkingdavid]

In the end, I really don't think it would be a good idea to have endless page loading. There are too many issues such as topics with alot of posts in it (like the one I posted about), not being able to jump between pages, linking to posts and other things.

For now, it a no from me.

We're discussing each of those issues at the moment. Large topics are no different than small topics because you don't have to load the whole topic at once. There will still only ever be a maximum of X posts loading at a time, where X is the posts per page setting.

As for pagination, myself and DavidIQ just posted about how that could be handled. And you can jump between pages. And you can link to specific posts (it's handled like it is now).

[brunoais]

About this subject I have the following to say (note: some stuff may be repetitive to what has been told, I'll try not to repeat):

I like this idea, I agree it should be an option in the UCP and in the ACP.
The options for both ACP(forum specific option perhaps... One forum has infinite scrolling and other not) and UCP should consist in:
(Always/Press To Load/No) infinite down scrolling
(Int) Max number of posts in page. This number must be >=3 where any other number means infinite (translated to 0?) (ignored if upper option is N)
Extra: Should we differentiate anonymous from the registered users?

The next posts should load when the user is viewing the last post (or the post before that), not when reaches the end of the page.

There should be a page scroller somewhere. That page scroller would be a div fixed to the screen (position:fixed;) in a convenient place (on the left of the screen, perhaps...) and it should be thin, only with the buttons to access the pages that are currently loaded. It would be a convenient overlap to the page itself to help the scrolling.

Edit: In terms of pagination, I think this should be used alongside pagination. Here's what I mean: In Microsoft Word, as you scroll, the page number in the bottom of the program updates with the appropriate number. I think that it wouldn't be too difficult to do so by using spans or divs with page number ids (e.g. <span id="page-number">#</span>, where the # is the page number. These are hidden via CSS from view (visibility: hidden, rather than display: none, since items with hidden visibility are still there in the page source and can therefore be used by jQuery) and then as the page scrolls by them, jQuery grabs the automatically updates the page number shown as active in the pagination (which would now have to have an alternate positioning, I think). Of course I may have a fundamentally incorrect idea of what is possible with jQuery, so this may or may not be a possibility. Please let me know, if so.

This can actually be also a good idea. Something below, near the bottom of the screen
I don't really know how to implement that using jQuery but I do know that is possible I don't know if it's with divs. Anyway, Js does not care about the CSS, for the js, visibility:hidden or display:none or display:block, etc... are all the same. As long as the node is in the DOM it's treated the same way.
We should also alter the url as the user scrolls the page.

This ?f=108&t=42113#p231603 identifies a post in the page and then, as the pages change, it becomes this: ?f=108&t=42113#page=3. The user can use the back and forward of his browser to navigate between all loaded pages. Also, with this, he can use the link in the title of the post to jump between two different posts in the same page (if they are both loaded at the same time)

This should apply to all pages where pagination and scrolling exists (as stated in the OP post).

Edit: Alternatively, we could have the footer in a fixed div or semi-fixed div (aka fixed after a certain point on the page, like in the Bug Tracker) so that it can still be accessed even when more posts are loaded behind/below it. Does that make sense?

Yep, a lot. But I believe I have a better one:
Make The page footer with that concept of smi-fixed with an arrow to make it hide. Make a small icon for an arrow or an 'x' or these: "«" in a vertical way. This way we can navigate though the page with no cutting from the top or the bottom, open the footer to view it when we want. I believe that is the best option. Make a cookie to save whether it should be opened or closed by default (checkbox in the footer?)

I really agree that, not worrying to execute use the template at all is a great relief to the server. Making a JSON string form data from the DB is much, much easier than the full HTML. With some simple Javascript we can make new lines of posts on the fly. (for posts, as an example) Just make one post an Object and it even makes more sense and better workable. Creating the object, makes the post. Deleting the object, deletes the post (in the view, ofc).