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:
- What was clicked on (the current document in the detail pane)
- 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.
