Bulk actions: what to do when not all items support an action

Question

Picture the following scenario: user selects a bunch of items, and the 'bulk actions' box appears; user selects an action that not all items support (for one reason or another).

What do you do in this case: apply the action to items that support it? don't apply the action at all and show an error message?

My current ideas are to either:

• Apply the action to items that support it; for actions that cause the items to disappear (like 'delete item'), I'd leave the offending items behind, still selected, with an error message: "some items could not be deleted".
• Disable the actions that are not supported by all the items and provide a 'fix this' link that deselects the offending items for the action.

Also, can you point me towards any relevant real-world examples?

Answer 1

Without more information from you (e.g. is it a desktop or web app?), here is an idea:

When the user selects which action she wants to accomplish, do nothing to the list items if the action can apply to all selected items. If it can't, then show in bold (or a different color) the ones that the item applies to, along with an explanatory text on the right, e.g.:

You should definitely show the total number of items that can be relocated as the list may be quite long.

Of course, this is just one of several possible variations.

Answer 2

The simple answer is don't let the user make the mistake in the first place. If an action can't be performed on all the selected items you should disable the action, explain to the user why the action can't be performed and suggest a solution.

Answer 3

I think that most UI solutions are context-dependent: a solution that works for "delete" maybe doesn't work for "move" and a solution that works in an e-commerce maybe doesn't work in an industrial tool.

That said, in abstract I'd probably add a numeric indicator in the "appearing box" you've cited, telling the user something like: "29 items targeted, 5 locked" so he can proceed without problems if he wants to, or check what are the "warning items" by clicking on the "5 locked" part.

In any way, I'd avoid any "error message": it's your problem, not user's problem. ;)

Answer 4

Building on the counter-example below - I would like to see a list with all items pop up stating that only specific items will have the (named) action applied (and those marked differently in the list) - and offer a "Sure, go ahead" and a "Cancel" action.

It doesn't feel comfortable to re-display a similar list but in the interest of going forward I think that'd be my first take.

Atleast don't do it like Microsoft Exchange 2010 Console does - it throws an error for all the items the action is not supported on (a long list in a small non-resizeble modal popup window) and it also doesn't apply it to the items supporting it (sic). There's no way to get out of the situation except either cancelling the idea completely and dig out Powershell, or try to cross-reference the small modal error dialog to manually de-select the offending items one by one behind it... ^^

Answer 5

I've seen a couple of approaches for dealing with this situation, neither of them particularly satisfactory:

• Silently deny multi-selection. CorelDraw, for example, avoids the issue by not letting users multi-select a mix of editable and non-editable (“locked”) objects even for just viewing read-only information. Likewise, IronCAD won’t let you multi-select objects of certain different classes (e.g., a camera and a part). That seems like an unnecessary restriction to me.

• Silently deny command. Windows XP simply ignores you if try to open a properties window for multiple items of different classes (e.g., My Computer and a pdf file). That could be confusing and frustrating.

It seems to me you want to allow the user the greatest flexibility by allowing multi-selection of anything and do as much as possible on whatever is selected. At the same time, you don’t want to swamp your user with message boxes as described by Oskar Duveborn on this page.

It’s debatable if the users are making a mistake: perhaps they wanted to commit Command X on all objects scattered throughout the window that Command X applies to, knowing full well that it doesn’t apply to certain objects. So they type Ctrl-A and select Command X. Supporting that “trick” would be very convenient. Or maybe they’ve multi-selected a bunch of things to apply Command X and then Command Y. It would be helpful if they didn’t have to re-multi-select or adjust the multi-select between commands to exclude objects that don’t apply.

Here’s some ideas:

• First, try to indicate the relevant information in the main/parent window so the user can guess that some actions won’t affect certain selected objects. For example, give read-only objects a distinct appearance, perhaps only on selection (I’m imagining little padlocks for handles for a CAD-type app). Each class of object should have a distinct appearance, perhaps by tagging each with a particular icon. This way, as the users multi-select, they can anticipate what commands do and don’t make sense (e.g., this item is a camera, so it can be moved but obviously can’t be resized).

• If the app can’t tell what applies to what until the dialog is opened, then maybe change the appearance of selection of objects for which the action does not apply. For example, when the user changes a property value, all objects that lack that property take a “secondary” selection appearance on the parent window.

• If the criteria for applying an action isn’t obvious, you may need some text cues. The menu item of button invoking the action may include in its caption how many items it affects or what it affects (e.g., “Sheet metal only”). In a Properties box, you can include a column beside the column of properties that says for many items each property applies to or can be changed for.

• That may be too space intensive, but maybe you only need to indicate that only some objects are affected (not the exact number, identity, or proportion). In that case, maybe you can use a footnote in the dialog. Create a symbol that means “partial,” maybe a half-filled circle? (Don’t use an asterisk –that too often means “required”). Put this symbol by any control that affects a subset of the selection. At the bottom of the dialog, show the symbol with the text “= applies to only some selected items.” For actions that don't use a dialog, use the same symbol in menu item or command button captions, including a tooltip to explain what it means.

• Ideally, you should indicate that the action only partially applies before the user commits that action, but as a fallback, you could provide some feedback after the action. In general, you want to make the effect of any action visually apparent in your objects in the parent window, and that may be sufficient. However, if you’re still worried about users being confused (e.g., by objects that have scrolled out of view that they later noticed weren’t changed), then maybe you can provide a modeless text notification (self-dismissing) that says “[actioned] [n] of [m] selected items” when the action is completed. Maybe provide a Help link in case the user doesn’t understand why.

I don’t know how any of these will actually work, so it’ll be a good idea to test out whatever you decide on users.

Answer 6

Why not do what the property / object inspectors of many Integrated Development Environments do: only display properties common to all selected objects on a form?

In your scenario: offer only the bulk actions supported by all selected items. And update the availability (enabled look) vs non-availability (disabled look) of all bulk actions with each selected/deselected item. This way the user will get feedback and quickly pick up on which bulk actions are available on which items (and which items have which bulk actions in common).

Answer 7

It appears the second solution offered in the question itself works best:

Only enable the action when all the selected items support it.

You can show it disabled, with an explanation either next to it, or in a tooltip to let the user know why this action is disabled.

I believe it can be very confusing to allow the user to do an action that affects only part of their selection, even notifying them after or before the fact might not work since users don't read text.

Hence chances are that any warnings or explanations will not prevent the user from simply clicking the button AND then immediately dismissing the notifications dialog.

Having said that, it depends on the action and the application - if the action triggers a life-cycle change of an object, affecting its state, etc. I would enforce the "allow action only when all selected items support it". For non-mission-critical stuff, you might prefer better flow than accuracy.

Answer 8

I would go for applying the action to the items that accept it and leave the rest. I think the user is smart enough to know that the action can't be applied to the other items.

If you make the rest of the interface so that the user would directly understand this, it shouldn't be any problem, and you can leave the other items without a special message.

This is also the way it is done in Gmail for example. Take two messages, one unread and one read, select both, and choose mark as read. The unread message gets marked as read and the already read one doesn't change. The rest of the interface (bold text and other background color) makes it clear that the read message was already read.

(Gmail even sais that 2 messages got marked as read, which seems a bit strange, but ok.)

Answer 9

The simple answer is don't let the user make the mistake in the first place. If an action can't be performed on all the selected items you should disable the action, explain to the user why the action can't be performed and suggest a solution.

Answer 10

As for a real world example, Jira comes to mind. And it shows at least one possible downside of the hiding actions: when people don't realize a certain action isn't available it can be quite frustrating. You can't move issues that are closed, but I didn't know that at first. I have searched long and hard before finding out why there suddenly was no move-action when I was very certain I moved issues that way before.

I think for that reason that blanket hiding isn't the best way. You could mark the actions that are not available to all, preferably with an explanation why they are marked. I think it could work very well if you allow people to select it regardless and let them apply to 'those available'. If not, I think disabling the items is better than hiding. (On the other hand, care needs to be taken that you don't end up with a list of actions that is endlessly long.)

Answer 11

I'd do something like: post a message that not all the items have the possibility to delete/edit/move/etc. and have a list with their entity defining field values afterward. Or if their not to many have a temp. reordering with the n/a items on top of the list, highlighted.

Answer 12

My approach:

Let users select the items they want, let users select the action they want if at least a item can be affected by the action and after the action is made return a info message: "the items x,y,z don't support *action because *motif."

Filtering the actions which can be applied to at least one selected item can be a little tricky tho'.