Allowing bulk actions on Detail view

Question

I have a table view with possibly thousands of records. I should be able to select multiple (via checkbox) and also change the view to display a list of those records + details of the active item.

Active does not mean selected. Bulk selection in this detail view is still possible.

If I have 2 items selected, what do you expect the behavior to be if you click in a new item (e.g. to preview if this is the one you want to add to the selection)? We don't want to clear the selection.

Currently there are different states - selected and active. Would you expect an active item to be automatically added to the selection?

There are a couple of options:

• If 1 item is selected then instead of details we show "1 item selected". Problem: when there is a selection, we can't see the details to make sure we are adding the right item to it.

• We always show the details of the active item. Problem: when acting on the selection (e.g. submitting), we might not be acting the one we are viewing the details of, if it is not selected.

Any thoughts?

Answer 1

This is a great question and while I'm not 100% sure of the context you're working with, I thought a few solutions could be possible. I didn't see your other answers at the time so I'll give some background to my thought process as I go!

My first focus was essentially, "I want to preview something before I decide if it should be part of the group I will make an action on or not."

For the most basic solution, I thought why not use the table? The table will give several indicators that might help me with making my decision already. In that case there wouldn't be tabs for the table and detail view, and I probably use column sort/filtering to help me cut through the thousands of results faster.

But I was guessing you weren't using the table because there might be some complicated info that didn't appear on the table that you still need to see, so that brought me to the next one, which is something that allows me to see some information one at a time, yet doesn't conflict with the checkbox behaviour. So here my added focus was, "How to trigger a preview without conflicting with the checkbox". Presumably, the user could interact with the different rows and expand, collapse, expand, etc. This area could handle larger or more complex content (depending on responsive / screen size expectations) while the active area of the checkbox would restricted to the left side of the row so that there's clear delineation of actions.

The above were my first thoughts because a data table could also allow the basic sort/filtering that will help me move through hundreds / thousands of options, so that's why I wanted to explore those. If I'm sticking with the original structure as you shared in your question, then the main thing I would focus on is to make sure that 1) the number of items selected is very clear before the action is applied, and 2) the possibility of accidentally mixing checkbox and preview with each other is reduced as much as possible. To address this I group the number of selected items together visually with the actions, so it's reinforced strongly by proximity (maybe even directly on the label, ie: "Export 317 items") and dedicate a space specifically for previewing. So the checkbox and preview triggers are far apart and visually distinct. (Note that the preview icon here was just chosen quickly, maybe some user testing could help here with deciding if a text label, radio button, other icon, or some combination could be a better choice.)

In summary the design principles that were guiding my thoughts were most of all to avoid having an interaction conflict, followed by letting the users have the ability to filter/sort if I could (since there would be hundreds/thousands to go through) and where possible, to show all the relevant content right in the table.

Thanks for reading! My colleague and I also chatted about this in a short video touching on these points here in case you were curious. I hope it helps spark any more thoughts! Take care and have a lovely day :)

Answer 2

From what I can see, your design suffers from a few possible issues:

1. It is a fairly well-trained expectation that the label for the checkbox be tappable. Especially so on touch devices, where the checkbox control has a notoriously small touch target size. However, if I've understood correctly, your design expects two distinct operations from tapping the label and the checkbox. One selects the item, whereas the other 'previews' the item. This is an ambiguity that might be disorienting to your users.

2. What happens when a user control+clicks multiple items to activate ('preview') them? This feels like a possible affordance of your current design, as it follows the pattern of the native 'multi checkbox' control. However, assuming you'd follow the pattern, you'll quickly run into problems when the preview pane is insufficiently large to display them all.

3. Ask yourself how important it is to the user to know how many items are selected, and at which moments they need to be informed. You're already showing this under the form, but it's dimly visible. Consider moving this up in the hierarchy, and/or provide a temporary micro-alert indicating the number of items selected after each selection?

Also, out of curiosity, if your list can grow to thousands of records, how will the user be able to navigate through them? Will there be pagination of sorts and/or maybe a search function?

What I suggest you try as part of your design study is to implement the list as vertical tabs. Each item might have its own add/remove (plus/minus?) button, thereby avoiding the control/label ambiguity, and also avoiding the issue pointed out in #2. When you try this, make sure that the item labels clearly signify that they're clickable/tappable.

I'm curious to know how this will progress. Hope this helps.

Answer 3

1. I agree. But in this case, if I use a binary state of checked / unchecked, the user will have to uncheck every time he previews something he doesn't want to add to the selection. My suggestion was to remove the checkboxes on this view and only allow for bulk actions on the table view. That didn't fly...

2. Right now, there is only 1 preview at a time. This is because every item has a lot of information (imagine a long form with many fields for each item). But you got me thinking if every time I click to see details it should open a new tab or something ... like in most dev applications... it should be interesting to explore, even if it's not a pattern we are using.

3. I think it is not very important to know exactly how many items you are selecting, but it is very important to know you are not doing an action on a single element, but on a selected group instead.

There are filter and search functionalities, but the user can still have a very large list of items at a time. The items are lazy loaded. We do have a "list builder" in another place with "+" and "x", and I didn't consider having something like that until now ... so I appreciate your input, it already sparked some things I didn't think of. Thank you :)