We have an html table component that we can add a checkbox as one of the columns to be able to select multiple rows. This table component can be paged with your typical next/previous/first/last buttons. Let's say that we have a table of all 50 states in alphabetical order, and we are only displaying 10 states at a time. We want to check Alabama, Alaska, Connecticut on the first page, and then page on to maybe 5 or 6 pages and check New Jersey, New York, North Carolina and North Dakota, and then click a button to process these states.

Is this a good idea for selecting multiple rows? I'm questioning the fact that the user might have to go back to the first page of this table component to verify if they did check off Alaska.

Now to add to the complication, this component also has filtering capabilities above the table. So again if the user checks Alabama, Alaska, and Connecticut, and instead of paging to find New Jersey, etc. the user types in the letter N, and that displays only the states that begin with the letter N. Now to add more to the complication, if you use the filter, the previous checkboxes state of Alabama, Alaska, and Connecticut are lost.

Are checkboxes a good idea for selecting multi rows in this case?

  • Gmail do exactly what you're describing – icc97 Feb 6 '16 at 2:20

Using checkboxes for selecting multiple rows is a very commonly used UI convention. Whether it suits your needs or not, depends on use case.

How many columns does the table have? How critical is it for user to keep track of every single row that has been selected? If it is critical, then you may want to consider using split view that lets you move rows from left box to right box. If it's just a list of 50 states, then you can consider multi-select combobox.

Again, i would be helpful to know more details about the data you're dealing with.

As for the filter and pagination complication, you can remedy by doing the followings:

  1. Display a running total of number of rows selected above the table. (or even values, if they're short enough)

  2. When filter is applied that causes number of rows to change, then it is generally good practice to reset the row checkbox selection.

  3. When you are simply paginating, the checkbox selection should be preserved from page to page.


Using checkboxes for rows is a well established solution to multi-row actions, and in general works well. There are however a few limitations that you should keep to if using this interaction method if you want to get the most out of it:

  1. Don't allow hidden checkboxes. By that I mean don't allow someone to have something checked that they can't see. What that translates to is that changing the page should clear all the checkboxes on the current page. You should have some sort of notification (I'll leave the choice of what type up to you) so that you don't have unexpected results. One possible exception to this would be if you kept a list of selected rows visible on every page, but this only works well when you're sparsely selecting from the list.
  2. Allow users to change the number of items shown on a page. If your default is 10 items (using the states example in the question), allowing a user to display up to 100 items on a page would solve this problem. Alternatively you could use infinite scrolling to load more items, but you will run into some practical limit here for large numbers of rows.
  3. Provide some summary of the number of rows selected. It could be something as simple as "5 items selected" or a simple "(5)" shown in the headers, to a smaller table with all the selected fields shown.

There are a lot more concepts to be aware of, but these are only those relevant directly to the question. They are also shown in what I would consider priority order if you aren't able to implement all 3.

  • For your #1, we can't display rows that were checked if a user paged to a different part of the list, the component does not allow that. That was my main concern about this interface - out of sight out of mind. Let's say like my example a user selected 3 states, then selected 3 more states in a different part of the list. What if the user forgot what they selected and had to go back to verify. I have an issue with that as a user interface. – tanker456 Oct 13 '15 at 10:52
  • @tanker456 by hidden I mean more checkboxes that aren't on the current page (regardless of scrolling). It's fine if you need to scroll to see the checkbox, but that is where having point 3 helps with the clarity. – JohnGB Oct 13 '15 at 11:35
  • The component that we are using does not keep the checked items when you paginate. If you check something on page 1, then go to page 2, that item is still technically checked but you will not see it until you page back to page 1. – tanker456 Oct 13 '15 at 13:09
  • Also, we can modify this component, but we are not in the business of modifying the component. At this point we have to just use the behavior of this component. My main issue is the checked items might not be visible on the screen as for your #1. Some people on my team are OK with this. – tanker456 Oct 13 '15 at 13:12
  • John, did you mean the following? "2. Allow users to change the number of rows shown on a page." I was pretty sure, but not quite sure enough to edit your answer. – Jon Coombs Feb 5 '16 at 23:37

Your Answer

