Should items filtering be combined with dynamically loaded items (load more)? If so, how?

Question

I've run into this design pattern a few times:

• You have a grid of items with X number of items loaded by default.
• You have filters that will add/remove (hide/show) items from the grid
• You have a button to "load more" items to the grid (ajax calls, not just hidden from view)

When a filter is selected, what should happen?

1. Only filter visible items on the page?
2. Make another ajax request to load all items matching that filter?

When the load more button is clicked, what should happen?

1. Load more items matching the current filter?
2. Load more of all items (no filter)?
3. Load more of all items but hide the ones that don't match the filter? (this would cause offset issues).

I am not of fan of combining both, because either option above seems to create a confusing UI experience. You are not sure if you are filtering everything (including future calls), or just what was preloaded, or just what was visible.

In many cases "load more" button replaced items pagination. With pagination you typically applied the filter to all elements, and not just what was in view. But the pagination nav, gave you clues to how many items were there to begin with, and how many items were affected after filtering.

The "load more" button doesn't really give you clues.

So what's a good approach? Should I avoid mixing filters and dynamic loaded content?

Answer 1

I don't get how this is a question.

You NEVER load new items that don't fit a filter when a filter is already in place. Imagine you're vegetarian and you order a fixed set of vegetarian dishes and then the waiter brings out some dessert menus with zero vegetarian options. Or even worse, they gift you a new main dish of freshly cooked pork cutlets. Wouldn't that be absolutely insane if all persons were self-aware and of normal intelligence?

Load more of all items but hide the ones that don't match the filter? (this would cause offset issues).

What does this mean? Offset issues?

The normal fetch loop is something like this:

fetch(filters, limit, sort) -> list of items that match all - (and a flag that it is either finished or not)

if not finished:

fetch(filters + (offset), limit, sort) -> "

If the user has a filter set and is already offset through the results by say 3 times (More Results clicked three times), we should act as if the next results are identical. I.e., three sets of data will be loaded in (with filters) and the page will visually change significantly, but the results are always going to be a different orientation to the user. Some results may stay the same, but they'll move, this won't be disorienting because the new result set is not related to the past.

1. Fetch -> Filter: Fish -> Load more -> Load more = (30 Results on Fish)

2. Fetch -> Filter: Birds -> Load more -> Load more = (30 Results on Birds)

3. Fetch -> Filter: Fish -> Load more -> Load more -> Filter: Birds~ = (30 Results on Birds)

~ run 2. in the background

TL;DR: Don't change the state on the user. The search state should be a set of variables, changing one will be more intensive as the search becomes more complex, but you definitely don't want to mix filters nor show items outside the filter.

Answer 2

I must say I don't know the actual answer, but let me share a recent experience I had with the similar issue.

---

Our Scenario

We have a mobile app that have a list of videos, these videos can be filtered by different parameters. Also this videos are uploaded by users. So there is two behaviors that generate more content: scrolling to the bottom (like the Load more button you have) and pull to refresh, to fetch newly added videos.

The approach we took after a usability test was:

1. To maintain selected filters when new content is fetched
2. When altering filters, refresh the all content to match the new filter conditions.

TIP:

One tip though is that if you're going with the (2) approach I would recommend including a Loading... visualization when reloading the content to match the newly selected filters.

That's due to the fact that if the filter simply removes items from view (like many Angularjs native filters work), then the user will expect the amount of items may be different from when a full Loading information is shown.

---

Hope that gives you some insight into resolving your issue. I'll be glad to hear on which direction you decided to head. Cheers.

Answer 3

This is a difficult problem. I tried to break it down by suggesting some rules for how the different controls work:

1. Content filters are boolean : on/off but also with internal rules (matches value, ranges or for instance includes:text)
2. Filters are live. Applying a filter updates the result list. Always. Change a filters state reloads the whole dataset
3. Load more is a fetching operation of the database. Meaning it has to consider fetch size, and how to display current and new results. Load more needs to know that there is more and should be hidden if there are no more results to be fetched.

There are two options:

• Paginations, which means a "load more" button is not needed.
• Load more button which expands the set by including the next fetched batch.

Original questions:

When a filter is selected, what should happen?

Unless there are extreme restrictions on data traffic then reload the results. Airbnb is an example of how this works.

When the load more button is clicked, what should happen?

Option 1 is correct. Option 3 is just another version of option 1. Option 2 is wrong because it breaks the filter logic.

• If there are paginations then remove the "load more" button and show the information about how many results are shown and how many pages there. This is good if there are sometimes large amounts of data that will be taxing to show all at once.

• If instead we wish to use a load more functionality: It should load more results in an endless window, adding to the result page. A typical load more would not have paginations but simply expand endlessly until the dataset is exhausted. The problem is that this can make a page endlessly long and hard to use.

I don't have any references right now, but my recommendations are based on expected behaviour in my opinion.

Answer 4

IMO you just need clear system status message, right below the filter dropdowns. Something like;
- 120 items all together
- 34 items in category XY, or 34 items filtered by criteria "xy"

You should always show number of items that are all together there, not only the visible one as the context is like that. User understands there is more items under load more and if you have system message "there is 34 items" and only 9 items showed before load more button, its self explanatory.

Answer 5

The best approach is related to content sorting and quantity.
With the "load more" method reviewing and handling a catalog with thousands of sorted items is very difficult, if not impossible.
Its ok for a catalogue with unsorted or presorted items, were me as a user, I do not really care for what comes first or you as the catalogue provider, you don't give me an option to sort results.
Its also working for a few dozens of sorted items.

The answers to the first and the second question are obvious.
I'm visiting your furniture store and requesting to see dinner tables. Not beds, not chairs.
So please get me the dinner tables catalogue.
And please help me! I don't want to multiply pages x items per page to understand how many tables you offer. Please indicate the number of results in the table of contents (or next to the filter button for our case)

For the bounty: Filtering always generates a new catalogue. An obvious functionality for this new catalogue is to display the start, the beginning of it.
For example: I'm reviewing a catalogue with 1500 tables. Currently I'm in page 3, viewing the tables #300 to #399 and I decide to refine those results to "dinner tables". I will select the "dinner tables" filter and the program will generate and display to me the beginning of the new catalogue, 100 of the 150 dinner tables.