Infinite Scroll with Caution
As a developer, I implement a lot of features that may be unique or emulate functionality on another site. Web design is like every other form of design — sometimes you lead, but most times you follow the aesthetics that are out there. Recently, infinite scroll is the feature I most commonly see.
Infinite scroll has its origins from the lazy-loading mechanism for displaying many images of large sizes on one web page. Instead of loading all images at once, lazy loading would add the direct link to image HTML tags in the DOM when the scroll bar reached a certain threshold.
This allowed you to have the structure of a finite set of images declared without having image downloads slow the rendering of the rest of the page. When the images were scrolled nearly into the viewport, the images would be downloaded.
Along came Web 2.0 with its heavy use of Asynchronous JavaScript and XML (Ajax) requests. Instead of lazy loading, Web 2.0 sites loaded content in chunks. So instead of rendering image structures sans links, they would load a subset of the data and include a load more button, which would fetch the next chunk.
The great thing about Ajax requests is they can be used to request information without reloading the entire page, making Ajax useful to more than just loading chunks of images. Large amounts of data like, activity feeds and long text started to be paged this way.
Over the past 5 years, big data has become a big thing. Users are generating so much data that paging would still result in more than 20 pages. Thus came a mashup of Ajax and lazy loading; why not asynchronously load more content when the user nears the end of the current content list? This is the birth of infinite scroll.
The problem with infinite scroll is that most sites are adopting it over paging or a load more button as the de-facto Ajax loading mechanism for content. This paradigm shift is used as a way to make the product easier to use by removing the load more step and really shines in two uses cases: massive amounts of content and shitty search mechanisms. The former is ideal use case, but that latter can be easily resolved by integrating Elastic Search or Solr into your stack.
If you have a product that on any given content list has data sets that can be paged in less than 10 pages, there is no need to implement infinite scroll. Infinite scroll implies that you have so much data, a user can spend 10 mins going through content. As a result of how widely used this UI feature is, users now have a certain threshold of how much scrolling they do (think Facebook's never-ending news feed). Users are not going to stick around to reach the bottom — they will resort to search sooner because of infinite scroll.
Paging gives users a visibly finite amount of data they can consume. The user evaluates a small amount of content at a time; as opposed to infinite scroll, where you have no clue when it will end. Essentially, the user makes a decision to continue going through content, which leads to longer user engagement sessions in discovery sections of your product.
When presenting content like text summaries, images, or products, paging works better. Users won't feel overwhelmed by the continuous flow of data and engage in pieces, which generally lasts longer. For examples, look at Amazon product list, Instagram user pictures (which has a hybrid), and Google search. However, if you're presenting activity feeds for plenty of users — like Facebook and Twitter — this is where infinite scroll shines.