I'm bulding a User interface that the user has a split pane with a list and the detail of the selected item in the right. I chose to use these approach because the user could see the important information before take some actions and he has a lot of information to check early. In these context is also common that the user take actions for multiple items in the same time.

The user can see the details of the selection and there, he can see a lot of important documents and also can select a button in the top right to take action.

I was wondering if would be ok or a problem if the UI offered multiple selection by checkboxes and repeat the common actions to the selected items and also allow the navigation between items, so the user could select any item and see the details even if it was not checked.

But the user would be blocked to take action in the right pane because it only concerns to the selected items.

Wireframes below:

FIRST SCENARIO: Normal selection

Screen 1: User access split pane with an selected item. Ther he can navigate between documents and take actions in the right menu enter image description here

Screen 2: User access the menu enter image description here

Screen 3: User access the first action, which is navigate to the second level to analyze deeper enter image description here

SECOND SCENARIO: Multiple selection

Screen 4: User selects many items and can take the common actions to the checked items in the buttons that appear above the list.

Thee user still has the possibility to navigate between all the items in the list and see the content but is not allowed anymore to take individual actions ( in the menu of the top right) because the menu in this context becomes disabled.

enter image description here

I researched behaviors like these in other platforms and did not find any. My question is: Do you think this behavior is ok to the user? Any suggestions?

Gmail, for instance, has a possibility to check a lot of items, and take for the selected item or the checked items.

Nevertheless, i think my case is different, because one of the possible actions for my UI is the user navigate to a second level to analyze the documents and in a structured way. Gmail do not has this kind of navigation. The actions remais in the same view.

Bellow in the two images of Gmail you can see that the user can take actions for multiple items. But also can take actions for the selected item

Actions for selected item only

enter image description here

1 Answer 1


As general principle, you want to allow your users to do whatever they want, whenever they want. Therefore, try to avoid prohibiting actions.

Is This How Your Design Works?

I think you’re asking for how to support acting on a multi-selection with some commands but not others. If I understand your drawings, then when the user clicks anywhere in a row in the left pane (the “master pane”), then the document appears in the right pane (the “detail pane”), and the user can click the three-dot menu to select a command for that single document. On the other hand, if the user clicks one or more checkboxes in the master pane:

  • A button bank appears in the master pane with commands that act on all checked documents.
  • The three-dot menu disables.

Checking a check box does not change the current document shown in the detail pane.

Don’t Disable the Menu

If I’m right, I don’t see why you should disable the three-dot menu. Let the three-dot menu continue to act on the current document in the right pane, and let the button bank act on all checked documents. With the three-dot menu appearing inside with the detail pane, and the button bank appearing inside the master pane, the user should be able to guess what the commands act on. Don’t make the users uncheck everything so they can act on a single document in the detail pane. They may not be done with all the checked documents, but now you’re forcing them to uncheck and then recheck them all. You’re limiting the usefulness of allowing navigation among documents after some are checked if users can’t then act on the current document without a lot of work.

Two Kinds of Selection

My main concern with your design is that you have two kinds of selection in the master pane that may occur at once:

  1. What was clicked on (the current document in the detail pane)
  2. What was checked.

So now the user needs to expend brain CPU cycle recognizing and understand two kinds of selection.

When the users want to do Command A, they have to guess if you decided it works for the current document or a checked document. Where should the look for the command? How are they supposed to know what you decided as a designer? Even something like drilling down to the second level could be assumed to work for a checked document (or even multiple checked documents, as I’ll show). You’re forcing the user to click around hunting for a command, rather than providing “one-stop shopping.”

Generally, you want to organize you commands by the kind of action they are (e.g., editing versus navigating), because that’s how users will think, rather than by how you chose to implement the command.

You might be able to mitigate such hunting trips with the following:

  • Don’t hide the button bank. Instead, disable the buttons and enable them when the user checks a document. If the buttons are hidden, users may simply assume they can’t do the command.
  • Label the button bank “For checked documents:” so users know the scope of the commands and that they have to check some documents to use them. Otherwise, they may not understand why the buttons don’t enable when they’ve click on a document row for action.
  • Consider a button bank for the detail pane, rather than a three-dot menu, if there’s no space or consistency issues.

With these changes, users can see, “Okay, these commands work on checked documents, and these commands work on the current document.” Users still have to look in two places to find Command A, but at least it’s just looking, not clicking too.

One Kind of Selection

Nonetheless, I believe it would be a lot less confusing for your users if there was only one kind of selection, and you had a single button bank or menu for all commands placed at the top of the page so it’s associated with both the master and detail panes. That way the users don’t have to learn something idiosyncratic. If they want Command A, there is one place to look for it.

  • Clicking anywhere on a row in the master pane both shows the document in the detail and selects (checks) the document for any action. The detail pane always shows the last document the user clicked regardless of whether or not they clicked the checkbox.
  • Users can multi-select by using the check boxes, or, if you users are familiar with desktop conventions, by using shift- and ctrl-click. As long as users can unselect a document, they can browse around looking at documents while maintaining what set of documents is checked.

There are several ways to deal with commands that only work on a single document. In order of preference they are:

  • Make the command work on multiple documents anyway. For example, the second-level page could include a dropdown to select among the documents that were multi-selected, or have Previous and Next buttons to move among the selected documents. The last selected document in the master pane is the default document in the second-level page. This gives the user greater flexibility and power they wouldn’t otherwise have.

  • Make the command work on only the last selected document. As long as the users can see the results, they’ll probably figure out that the command didn’t work on the full selection, but just one document. However, you may want to give the user a hint beforehand by dynamically labeling the command button or menu item with the identity of the one document it acts on.

  • Disable the command when more than one document is selected. Include a label or tooltip for the command button or menu that says something like “Select a single document” so users know how the enable it. This has largely the same problem as your original design, so only do this if the other options are technically impossible.

  • I agree to everything except the "One Kind of Selection", with the additional remark that I would offer (almost) all functions in both places (table toolbar and detail panel toolbar). To my experience, the placement of the buttons makes the scope of the action clear enough (that assumes your target group can manage a complex UI like the master-detail pattern you use). Even if there is a singleton action (maybe Copy because it requires to provide a new name for the copy), the table toolbar buttons can be en-/disabled according to the number of selected rows. Feb 14 at 9:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.