You know the very common “Older posts”/“Show more” link at the bottom
of your Facebook news feed? You know, it functions as a way to show
more posts or whatever… it generates more content and allows you to
scroll down more.
I’m kind of surprised there isn’t a nice gem that creates that
functionality… After all, it is common. It’s kind of like
will_paginate, I guess.
I would love to make such a gem/plugin myself, but I don’t have the
experience/skills to…
This is just a thought to the Rails community - who knows, maybe
there’s someone out there who’s looking for something to do… a
plugin/gem like this would be awesome.
This is just a thought to the Rails community - who knows, maybe
there’s someone out there who’s looking for something to do… a
plugin/gem like this would be awesome.
You know the very common “Older posts”/“Show more” link at the bottom
of your Facebook news feed? You know, it functions as a way to show
more posts or whatever… it generates more content and allows you to
scroll down more.
I’m kind of surprised there isn’t a nice gem that creates that
functionality… After all, it is common. It’s kind of like
will_paginate, I guess.
I would love to make such a gem/plugin myself, but I don’t have the
experience/skills to…
This is just a thought to the Rails community - who knows, maybe
there’s someone out there who’s looking for something to do… a
plugin/gem like this would be awesome.
I have seen a number of implementations of this, but by far the best one
I have seen is implemented on the Apple store. They have
implemented this “endless page” concept in a way the user barely notices
it (as long as they have a decently fast internet connection).
One of the issues with the endless page is how to deal with the scroll
bar. On many endless page implementations I’ve seen, the scrollbar is
practically useless. Often the use may try to guess that what they are
looking for will be found near the end of the list. They may try to grab
the scrollbar thumb and pull it to the bottom of the scrollbar. A lot of
the endless page solutions don’t handle this well at all.
The trick employed in the endless page implementation on the Apple
store (best example know of using this technique) is to create a
container DIV large enough to hold the entire results. This forces the
scrollbar to behave properly. In order to do this one must be able to
calculate the total size of the unpaginated result set. This isn’t too
bad if you are able to render each item with the equal vertical heights.
This is the case for many scenarios, but not all.
Using AJAX each row is fetched and displayed as the row gets scrolled
into view. You’ll noticed that the Apple store uses their
standard spinner/loading animated icon and then nicely fades in the
row/cell content. It’s a very nice effect for those cases where this
works.
Okay, but it doesn’t have to be AUTOMATIC… I mean Facebook has a
very nice “show more” button at the bottom of its news feed so you
only show more if you want to.
And I could potentially have an unordered list of hundreds of
things… so I don’t think the div strategy you mentioned would be
good…
Okay, but it doesn’t have to be AUTOMATIC… I mean Facebook has a
very nice “show more” button at the bottom of its news feed so you
only show more if you want to.
And I could potentially have an unordered list of hundreds of
things… so I don’t think the div strategy you mentioned would be
good…
While using a “Show More” button is fine in many cases it is not that
different than pagination. This is why there are so many different
implementations for pagination. It’s really difficult to create a
“one-size-fits-all” solution.
For a few hundred results I would prefer an endless page style solution.
What difference does it make to the browser if the DIV is long enough to
fit a few hundred results? It still only has to render a single DIV. It
should make little difference to the browser if the DIV has a 500px
height or a 200,000px height. For a few thousand I would probably prefer
a paging solution. Whether that’s accomplished with a “show more” or
traditional pagination makes little difference in that case. It all
depends on the type of information being displayed.
In most cases, even in the cases of something like Google search
results, most people will never see the results beyond maybe 10 pages or
so. In cases like this it’s vital that the most important results are
shown first. Pagination works well in cases like this.
In fact pagination can work better than a “show more” in certain cases.
With a “show more” solution there is no convenient way to skip ahead.
Consider the search engine results once again. Say you have performed a
particular search before and remember that you found a link somewhere
around page 10. With pagination you can skip directly, or within a click
or two, to page 10. Then go forward or back from there to find that
elusive not-so-popular link. All I’m saying is that there is no “magic
bullet” solution here. We need different solutions for different
scenarios.
This discussion here was about creating a nice gem for managing paged
results. I think it would be difficult to create a single gem that can
deal with every case, while still providing an easier solution than
custom building a paging solution yourself. The previously linked
Railscasts episode illustrates that it’s not terribly difficult to begin
with.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.