Infinite scroll and "Select all"

Question

I have question about how Select All should work (in your opinion/research) together with Infinite Scroll in table.

So I've got this table, which shows 40 items by default. After scrolling to bottom of screen, system loads another 40 items. We also added indicator that says how many items are shown, like: "Items loaded: 40 of 90"

Now, back to Select All.

When showing 40 items should top-checkbox (Select All) select ALL items (in eg. 90 items) in database or just visible (40 items)?

So in first option, user would select all and delete all his data. In second option, user would have to first scroll down to very bottom then scroll back to top and click on Select All checkbox.

Which option is better for ux?

Here's rough lo-fi example:

Clicking checkbox next to column label "name" should select visible items (40) or every item in results (290)?

Answer 1

We do this in several places within our application.

Select All should mean select all, not select visible as that isn't generally useful. Although i guess everything has a use somewhere and it may make sense for you to be working on pages of data (at which point paging instead of infinite scroll might be more appropriate)

It was our finding that if a user wants to select all they generally want to select all, selecting visible was considered as an extra option but the value was deemed less then that added complication to the UI.

The fact that you are using infinite scroll should not matter, the two states are something you as someone aware of the technology in use is aware of but as far as the user is concerned they are looking at the list of things, whether you load them all at once or defer the loading of some until later is immaterial.

Consider the functionality you actually want to give to the user, if selecting visible is actually useful?

For example we have 10,000+ users and the new version of the software adds a new role and we want to allow the users to easily add this role to all/most users. Having the user scroll or click or anything like this would be a horrible UX.

Where appropriate we allow for select all / deselect. We allow for an exception list, so allowing you to say select all except x y and z or deselect all except x, y, & z. (if you select all and load the next page it starts with all items selected, you can then deselect specific items, on save we send a selectAll boolean flag and an exception list to a batch processing endpoint)

We also allow for filtering which then generally gives users all manner of batch processing options.

Answer 2

Because of the issues you describe, I would not use "Select All" with an infinite scroll.

Even if your decision about how it should behave is comfortable for you, I wouldn't expect users to have the right mental model about what will happen and what will be affected by "Select All." I'd use different technique.

Edit: Other answers are giving good alternatives. I'll add the old "Click what you want to select" technique. For selecting ranges you can allow shift-click and cmd-click. However, not all users know about and use click modifiers.

Another option would be to provide filters that narrow the result set down to a finite number that can then be easily managed.

Answer 3

it's dependent on what the context is. We have cases where we don't have infinite info, but we do have tons of data (30,000) and the customers do need to select ALL because they want to do an action on all of the items. In our case, select all items for a Country and update a profile. You can try to see if you have some kind of a group, and write in the title Select all XXX. I'm not sure if it fits your case

Answer 4

Users should only be deleting items they can see, and after a confirmation.

If selecting and deleting large numbers of rows is important, infinite scrolling probably isn't the right pattern. A combination pager/ "show number of rows" dropdown like Google Analytics provides might be good for this.

Answer 5

I would suggest that you should give both options.

The reasons are that sometimes users just want to work on part of the data (for instance in Gmail, marking 40 emails as "read"), and sometimes users want to baulk action all the data (for instance, in Gmail, move all emails to archive). I find it very tiresome to work on large baulks of data and reload every time a new set and mark it.

Answer 6

Under the circumstances, I would definitely avoid a "Select All" button . . . as others (and even you ;) ) have pointed out, there is no innate, clear understanding of what "select all" means when there are, arguably, two states of "all". :D

However, there are good patterns existing for handling what you are trying to allow for with "ACTION_NAME All" style controls.

In your example, it only looks like you have two actions that would be impacted by selections: Edit and Delete

In the case of Edit, whether or not you want to support an Edit All function (even if you do support "multi-edit") is a whole separate discussion, given that triggering 90 edits seems like a potentially logistical and user experience nightmare, but the possibility is still technically there to use, if desired.

For Delete, however, various forms of Delete All controls are extremely common (think "Empty Trash" in email applications). Having that as a separate control both adds some implied clarity to how the Delete control will work (i.e., only on the selected items), while also providing support for the specific "select all" use case that you were looking to support (i.e., "select all" + "delete").

Obviously, you also want to avoid overloading the page with controls, but, if Delete All is all you need, your design appears to have room for it without adding too much visual clutter.

Also, if you go this route, don't forget to have some sort of confirmation process (e.g., an "Are you sure you want to delete all 90 items?" confirmation modal), to avoid allowing the user to accidentally delete all of the items.