20

We are building an enterprise which consists of tables with a lot of data. Our solution for the tables is to have an infinite scroll with a "Load More" button. There would be information of the total data entries and the shown ones. The header at the top would be fixed.

One of the important functionality is to have the possibility to select all of the entries. And here is our struggle - if the user has loaded 40 entries and has clicked the SELECT ALL button - all of the 40 entries are selected.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

What do you believe is the best option for the user clicks on LOAD MORE with SELECT ALL active?

Should:

  • all of the selection get deselected?
  • the newly shown entries also be selected?
  • the shown ones remain selected and the new ones not be selected?

The case the user will be using this is mostly to deactivate multiple accounts, print reports etc.

EDIT

In a pagination version - if the user has selected all of the entries in page 1 and than navigates to page 2:

  • Does the entries on page 1 stay selected but no action can be applied to them (like GMAIL)?
  • Or are the selected entries deselected when the user navigates to a new page?
  • @divy3993 Thanks a lot! I am definitely not stuck on this option - pagination is another option. This is just something that came up during discussions and was wondering what your experience was :) Thanks again for the answer – Loro Jul 20 '16 at 11:55
  • 8
    How about renaming it to "select all shown"? That will eliminate confusions on user side and on yours as well. – SpaceTrucker Jul 20 '16 at 12:27
  • Consider providing a file export option so that users could do whatever they please locally. – svavil Jul 20 '16 at 13:18
21

I think of 2 possible solutions.

First solution:

The newly show entries are also selected.

Since the user selected "SELECT ALL" it would be good to the program to... select all, since thats what the button calls.

Second solution:

Why not trying pages instead of "load more" like gmail form Google.

image from gmail

Note: The "load more" and "select all" functions as you mentioned works currently on yahoo's email service. Whenever someone selects all the emails (with the select all button) the first 50 emails are selected. But as he/she scrolls down more emails are being loaded. This new emails are not selected, but the previous 50 remain selected, making the user to click again on the "select all" to unselect them all to later press again the "select all" to finally select all the emails.

  • 5
    +1 for mentioning Gmail. It is a simple design that make Select All less confusing – Hoàng Long Jul 21 '16 at 1:49
  • @Gilberto De La Garza The team went for the second solution - using pages instead of pagination. The user will have the opportunity to select how much entries per page he wants. If he has clicked on select all - then the newly loaded entries are also selected. Thanks a lot for your answer! – Loro Jul 21 '16 at 4:58
5

The current mockup is pagination, just poorly implemented.

Load More/Infinite Scrolling are applied to data sets that are essentially infinite (such as Facebook's News Feed, or an e-commerce site's product results). When there are a finite number of results, "Load More" is functionally the same as "Next Page", but it lacks the "Previous Page" and "Navigate to Page N" functionality.

To answer the question as posted however, the items loaded by "load more" should load in deselected by default.

  • The reason why we considered the LOAD MORE approach is because in most cases the user is going to use this is to either list reports, select them and print them or he is going to search for a specific entry via filters. So the user can have up to 150 entries on a page which he can select them all. – Loro Jul 20 '16 at 14:20
  • 5
    @Loro then why not use pagination with a "show [x] entries per page" option? if i want 150 entries, but only 10 are shown at a time by default, i don't want to have to click "load more" 15 times. – Woodrow Barlow Jul 20 '16 at 17:33
  • @WoodrowBarlow This is exactly what we are going for! Thanks a lot! – Loro Jul 21 '16 at 4:59
3

'Select All' should be stateless.

It should not be implemented with a toggling behavior - i.e. on/off state. I cannot recall a single case where I saw it implemented this way. A good example case is Gmail, see how it works there.

So, it should work on the items currently in the table and in this case you should also add an 'Deselect All' button.

  • Thanks a lot! The toggling behavior is an interesting approach to the problem. – Loro Jul 20 '16 at 11:58
  • 3
    "it should not be implemented with a toggling behavior" Many, many sites, including your own example of Gmail, use a toggling behavior for this. Gmail has an additional submenu containing "all", "none", and some other common subsets, but just clicking the checkbox on and off toggles between select-all and select-none, using the state of the checkbox as an indicator for its next behavior. – Daniel Beck Jul 20 '16 at 15:27
  • By 'toggling behavior' I mean, for example: Are new loaded entries are automatically selected when the 'all' option is selected?. They are not. – Assimiz Jul 21 '16 at 5:36
2

You have just discovered that Load All and Select All don't work well together and now you are stuck as to how to make them work together. Every option you are looking at is further degrading the user experience. Your design is compromised so I recommend you reconsider your design.

I have designed Enterprise applications for nearly 20 years and I have yet to find a good example of where Load All works for working with enterprise data.

This Load All pattern is perfect for time-based conversation content, e.g. social media like Twitter and Facebook but rarely useful for reviewing and working with data, where the user goal is to perform specific tasks.

Looking at the data in your mock-ups, this looks like it is a list of employees. Why would anyone want to browse through long lists of employees?

I think you need to understand what your users want to do with employees and use this knowledge to inform your design.

1

Give them two buttons

  • Select Displayed
  • Select All
  • 2
    -1 for "when in doubt just do both things". Every widget on screen adds to the user's cognitive load -- a big part of UX design is deciding what not to include. – Daniel Beck Jul 20 '16 at 15:19
  • @DanielBeck Typically I would agree with you, however, this is a case where a user could very reasonably believe "Select All" performs two different actions--select all of what I see or select all that exist. In this case, it could be argued that providing explicit, unambiguous tools for each action would decrease the cognitive load--users would no longer wonder what will be selected. – maxathousand Jul 20 '16 at 15:28
  • @maxathousand Fair point, though I believe that ambiguity is more due to a lack of context in the question than is likely to be the case in a real interface. I think it comes more down to the utility of each of those options -- if there's no particular reason "select displayed" would be useful, I wouldn't include it, even if the rest of the interface is ambiguous enough to suggest that it's a plausible interpretation of "all". (And I'd try to correct that ambiguity in the first place, of course.) – Daniel Beck Jul 20 '16 at 15:32
  • @DanielBeck "When in doubt?" OP list both behaviors as options. It not only clarifies but user may legitimately want both behaviors. As a user I certainly would want both options. A big part of UX is to reduce the number of clicks. Selected Displayed next to Select All is going into cognitive overload? – paparazzo Jul 20 '16 at 17:46
  • Sure, you can always say "one more checkbox, what could it hurt? Somebody might find it useful, throw it in there." That sort of thinking leads to cluttered, overly complex interfaces. Consider the utility of a 'select displayed' option -- how frequently is a user likely to want to select specifically the first 10 (or 20, or etc) items in a list? For a searchable list, where the user has control over what's displayed, arguably often. For a paginated alphabetical list, much less useful. – Daniel Beck Jul 20 '16 at 22:54
1

What do you believe is the best option for the user clicks on LOAD MORE with SELECT ALL active

  • "all of the selection get deselected" Never do this. Users have no reason to expect that loading more data would remove their previous selections, which they may have put some effort into. Unexpected destruction of user input is Not Good.
  • "the newly shown entries are also selected" This would mean "select all" means "select all [of the employees who exist]". This may be appropriate in some cases, definitely not in others; see below.
  • "the shown ones remain selected, the new ones are not selected" This would mean "select all" means "select all [of what is visible]". This is probably not appropriate given the design you show above, but may be useful with some changes; see below.

As with many UX questions, the real answer depends more on the context and purpose of the control than on the bare fact of "we have a paginated data table, how should it work?" You need to think in terms of: what is the "select all" option useful for? Why would a user want to click on that button?

(You've mentioned that in this case the functionality is "mostly to deactivate multiple accounts, print reports etc" -- but I'm going to run through a few other potential purposes as well, for completeness)

Individual edits

If the purpose of the selection is to make edits to individual entries, then "select all" is unlikely to be useful (and for that matter, multiple selection of any kind is unnecessary; just let the user edit the individual entries -- preferably within the context of the table itself, rather than requiring a select -> edit -> return to table workflow.) In deciding this, consider whether the types of edit the user is doing are likely to apply to groups of employees, or if they're more likely to focus on one entry at a time.

An unsorted or arbitrarily sorted ("by last name" for example) table may not be the best approach here, especially if there are large numbers of entries: employees towards the end of the alphabet become unnecessarily tedious to reach.

Are users likely to need to browse through the list to find names? Or are they more likely to already know who they're trying to find, and just need to find them? If so, a search-based interface would be more appropriate than a browsable list.

(Allowing the user to sort the table by clicking on headers is also a possibility, and may be useful in some cases -- but this combines very poorly with pagination, and inherently has many of the same issues as your 'select all' question: sorting needs to apply to the full data set, not just what's on screen, which means you have to decide whether to repaginate, and what to do with already-selected items.)

Bulk edits

If the purpose is to make bulk edits to collections of entries -- for example, choose thirteen different employees and change their title to CEO in one operation -- then your multiple-select interface makes some sense, but you should reconsider your pagination strategy (if one of the employees is near the end of the list, the user has to keep clicking "load more" until the one they want is visible.)

Paginated or infinite-load data display is useful for inherently ordered data (show all entries in chronological order) or for effectively infinite data (show all tweets with hashtag #foo). It is less appropriate for fixed data sets likely to be accessed in nonlinear order -- such as employee lists.

As in the previous case, consider whether you might be better off with a search-based filter for the table itself, so the user can find the entries they need to select. Multiple selections complicate this, compared to the single-entry case: selections made by the user should be pulled out into a separate table so that the user can make a different search and continue to add to the list, without losing their previous selections. (i.e. I know I need employees Abel and Zagat; I search for Ab, pick Abel from the results, it moves to the 'selected' table. I clear the search and look for Za, select Zagat, now I have both employees I need and then move on. This is preferable to "pick Abel, click 'load more' a few dozen times, pick Zagat.")

As for how "select all" should behave:

In this case, "select all [that exist]" is unlikely to be useful at all (it's rare that you would need to make the same edit to every employee entry) and allowing the user to do so is potentially dangerously destructive. Think about "deactivate multiple accounts" combined with "select all" -- probably not something you want to make easy for users to do.

"Select all [of what happens to be visible in this paginated table]" is even less likely to be useful in a paginated list, since the user has no real control over what happens to appear in that table at any given time: you've set the page size and the table order, so only by happenstance will that come anywhere close to the user's desired group selection.

By contrast, in a search-based table, rather than a sorted + paginated table, "select all [of what is visible]" is very useful: if I need to edit all employees whose title is "Widget Manager", I can search for Widget Manager, "select all" the results, and I'm done.

Bulk, nondestructive selections

If the user is likely to be performing actions against the entire data set on a routine basis -- this is your "generate reports" case -- then "select all [that exist]" is useful, "select all [that are visible]" is not, and the existence of the table at all may not be necessary.

If users often need to generate reports on subsets of the full employee list, then they are probably going to be re-using those same subsets on a regular basis. Rather than making them go through the entire list selecting individual users every time they need to build a report, consider allowing them to predefine those subgroups and give them a name; that way, next time they need to make a report on the Foo team, they can just choose the Foo team instead of having to go through the entire employee list picking out each of the individuals they want every time.

(If it's not a routine reporting situation and the list of employees to be included will definitely change every time, you still might be better off with a search-based interface than a sorted+paginated list here.)

  • 1
    "As with many UX questions, the real answer depends more on the context and purpose of the control" - Totally agree. This is the important issue, but usually omitted. Why we don't ask the people who use the interface? They are the ones who will enjoy (or suffer) from it – Hoàng Long Jul 21 '16 at 1:55
  • 1
    @Daniel Beck - thanks very much for your thorough answer!!! – Loro Jul 21 '16 at 5:01
1

should all of the selection get deselected

No, this would make me angry as the user. I wouldn't trust the "load more" button any more.

the newly shown entries are also selected

No, my desire to "load more results" is orthogonal to me wanting to select results. Once again, as the user, I would no longer trust the "load more" button.

the shown ones remain selected, the new ones are not selected

This is closer to what I would expect. However, I think the pagination is poorly implemented, as other answers have pointed out. If you're going to stick with the "load more" idea, I would also suggest putting a "Load All Results" option. This way, as the user, I can click "Load All Results" and then click "Select All". However, that might be a bad idea of "Load All Results" tries to load, say, 10,000 results. In that case, you might want to re-think your pagination strategy.

0

I am currently working in similar long tables for b2b enterprise software solutions. We are using paging but let's deal with your requirement.

Given that you might have thousands of records to show and given that one of your possible actions is printing I would be extra worried if a large batch printing job begins by mistake.

When the user clicks on select all, 3000 records are selected even if the user sees only 50 of them. In other words select all should mean select all which means that when the user loads more rows these rows should be selected as well.

Actually it is better to keep a persistent special warning to notify to the user that he has selected more than enough rows (decide the threshold by statistics) like "Be aware: you have selected 3000 records. 450 of them are currently visible"

grid with warning

Should I deselect the select all checkbox if even one row is deselected? Yes, select all means select all without any discounts

Should I keep the warning if still more than enough rows are selected? Yes, the warning plays a different role than the select all button

Note that you must prevent the careless user of acting on many multiple records. A job that cannot be reverted manually. A warning that 3000 records will be printed could be a popup when the user tries to click on the action button when more than enough records are selected.

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.