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.)
