We have an interesting challenge - we have a categorized listing and we need to limit the initial amount of entries to load.

This leads us into Pagination vs Infinite Scroll warfare, but quite honestly, the problem is a little more elaborate. I normally have quite a good feel for when to use one over the other.

Implementing either at a page level, you could load more easily, but then the page height increases and you lose context of where you are/were. Not so ideal.

Sure, pagination could work if we implement per category block, but it just has such a horrible flow to it. I'd rather avoid it if I can.

Implementing Infinite Scroll at a category level will stop you from easily scrolling over your list entries because of the load time and then your list will suddenly grow, leaving you clueless as to where in the list you are.

Any thoughts? I'm struggling to find examples of this out in the wild. I THINK I have an idea, which would then need to be tested, but if there is a common solution then that would be helpful

We cannot simply filter by category because the user may need context of Category 233rd entry but should still be aware that Category B's entries

  • I think a quick sketch that illustrates your problem would be very helpful. – Jung Lee Oct 17 '15 at 2:35

Here is an approach that worked well for us. In the application the end users search for many types of data at once and keywords are queried and displayed across multiple categories. The primary results screen limits the results within each category to top the 5 results or any set number. If the result is not present in the top results the users have the option to view full results in the primary categories or refine their search keywords. The full results are then on an infinite scroll with X number of results preloading ahead as they scroll. All of this can be done on grids so changes to data can be updated inline or via some kind of selection interface.

I hope that helps.

Primary Results Screen

Primary Results Screen

Detailed Category Results Screen

Detailed Category Results Screen


Without Filtering, You can use "Accordion" for Category wise to use the data in infinite scroll.

Still you have reference to Category with overall less area to scroll/move around.

Example: https://jqueryui.com/accordion/#no-auto-height

  • Hmm... so the categories are actually accordians already, but the open/closed state is user controlled for more control over what they want to see and when. I also worry that it goes the principle of the user staying aware of the items within closed accordians – Dayne Oct 16 '15 at 15:16
  • may be an item count will give more details about how many items are under the accordions. – Chinmay Chiranjeeb Oct 16 '15 at 17:02

on our e-commerce website we tried both and we realized that pagination works better for our particular demographic of users (i.e. fashion e-commerce in asia). we did some observations on how users browse on both and came across the following.

  • Users would skip to the 3,5 pages rather than go ..2,3,4.. after they couldn't find what they were looking for in the 1st page

  • Users were not used to infinite scroll so when they scrolled very deep down and wanted to find something they had passed by previously they couldn't find it. compared to when on pagination they roughly remembered which page it was on.

  • users skimmed through products more faster with infinite scrolling as they always expected there to be more.

  • the infinite scrolling effect didn't work well for categories that had a few products, they weren't 'infinite'.

  • In this case, pagination is the easy way out, but it doesn't provide a smooth task flow imo, especially when you have a large amount of categories, etc – Dayne Oct 16 '15 at 15:14
  • maybe using a grouping feature with sorting and filters so you could apply a combination of the 3 to find what you are looking for. – Ameen Akbar Oct 17 '15 at 6:55

What type of website are you working on? an E-commerce solution wouldn't work with an infinite scroll as this is difficult to bookmark / share the URL of the 'results' as technically, the is only one page with LOADS of content pieces.

Imagine the conversation; "Yeah check out these great shoes, just keep scrolling till you see the yellow t-shirt, then go down two more scrolls." — Er? These ones? Does she mean these ones? — Not a great experience, as it's ambitious.

Pagination works much better for sites when the content has some sort of 'Limit' — in the case of Pinterest, the content is user generated and infinite in scale. Designed to show alot and save alot by the users. It's more of a 'showcase' than a place to get more detailed information about specific products.

What it the nature of the site again?

  • You could think of it as list of documents. Documents are sorted into categories and prioritized within that category- each category is equal in importance. The user should theoretically be managing these documents to an extent that no further loading is needed, but the reality is that it can and probably will happen AND the user needs to be able to see and compare items in the same list – Dayne Oct 16 '15 at 15:11

We cannot simply filter by category because the user may need context of Category 233rd entry but should still be aware that Category B's entries

I think this is the key component to your decision. I think infinite scrolling is useful when the only factor to how the user orients him or herself is by time - like Twitter, or a blog feed, or whatever.

Rather, from what you describe, your users need more of a grasp of where they are in their task. David Keiras, from University of Michigan, makes the point that reaching an endpoint improves the sense of control.

The question to your answer is determined by what is more important to the success of your site / app: control or aesthetic.

I think the overall user experience of pagination begins to suck when there are an overwhelming number of pages or options, but this has more in common with too many menu items than pagination specifically.

Anyway, I'm totally interested in what you end up with. Definitely a unique issue.


If you have a large number items (20+), an accordion is not that great for scanning because as you've mentioned, it's very easy to lose track of category groupings when the expanded group exceeds the screen height.

I would recommend removing your category accordion, and place categories to the left as navigation, then provide infinite scrolling per category if the user does not need to reference the specific location of the item on the list in future visits. If the user would need to reference an item further down the list, then pagination should be used instead of infinite scrolling. E.g. I need the 2nd/3rd item on page 2, is a lot easier to find then scrolling down to find the 53rd item. See this question for more info on deciding between pagination and infinite scrolling.


download bmml source – Wireframes created with Balsamiq Mockups


Infinite scrolling has one major flaw: If used on a (landing)page that should inspire (e.g. "is there any product that you like?") - so not on a deep category level, but a low one - it is a good thing. At this stage, users want to see a variety, since they might not have decided on a category diving route yet. This is why usually we do NOT use infinite scrolling on pages that are below level 1.

In your case, though, the purpose of listed items seems to be being able to grasp the information contained in the list items.

I'd like to ask you one or two question on this: Do users want to COMPARE items? If yes, infinite scrolling might be a good idea. (I just read that you already answered that)

Second question: Is the item list filterable? That will make the whole story easier.

As said by other repliers, "knowing where it ends" makes users feel more in control, the overview is better. So instead of putting effort in infinite scrolling, I'd go for filtering (thus narrowing down the list) instead, since there is no "inspiration" part in your concept yet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.