Managing mixed-state item selections in table-based UI actions

Question

See graphics below.

Context: There is a table-based layout that presents data. Within this table, two categories of actions exist: general actions that apply to the entire table and selection-specific actions that only work when certain items are chosen.

Located in the upper-right corner of this table, the "Action Center" (3 dots) button reveals a list of available actions when activated. However, some of these actions may appear grayed out or inactive when they are not applicable to the current situation.

Problem: The issue at hand pertains to actions that are meant for items with specific characteristics, referred to as "State A" and "State B" for simplicity. These actions should only be accessible when items in State A or State B are selected.

The challenge arises when multiple items are selected, and these items are in different states. What should be the behavior in this real-world scenario?

Possible Solutions:

1. Keep all actions enabled for mixed state items: In this approach, users are allowed to select items with different states, and all the actions remain enabled. However, these actions only affect the items that match their respective criteria. For instance, if items in both State A and State B are selected, the actions associated with State A only impact the State A items, and vice versa.

2. Disable buttons for mixed state items: Alternatively, the action buttons could be disabled when items with mixed states are selected, plus add tooltips visible on hover of these disabled buttons explaining that, to perform a particular action, items with the specific state required for that action need to be selected.

Additional comment From the psychological view, the question is: Should I force the user to select items in a status that allows the action to be performed, or should I allow them to perform actions on any selected items but - in fact, from the back end side - do it only on those on which the action can actually be performed (because this is how back end works - it won't allow the user to perform the action on non-matching state anyway, because it doesn't make sense)? The user who selects the wrong type of items will be someone who does not fully understand how the product works.

Any other ideas or comments on which solution is better?

🚀🚀🚀 Easy to understand example My product is quite abstract and complex, but as an example I will present a similar situation in an application for managing a food warehouse. The user of the supply system opens the table of food products, of which bananas and apples are almost finished (so they can order more of them) but cheese and milk is full in stock (so they can't order more, but can distribute it to the shops). The user - maybe by mistake, or perhaps because they want to supplement the warehouse with all the products (and there are thousands of rows in the table), selects all (using the 'select all' button) and wants to press the 'Order more' action. And here the question arises - whether the action buttons should be active (solution 1 - although ordering cheese and milk won't happen anyway because the warehouse is full of these products; and at the same time bananas and apples won't be distributed to the shops because these products are out of stock) or the buttons should be disabled and display a message that the user must select products only and exclusively that meet the 'out of stock' or 'full stock' criterion (solution 2).

Answer 1

Maybe you have some specific reasons to implement the software application in the way that you have described it, but it feels like the underlying structure of the data should conform to a more typical CRUD table operation if you want to present it in a data table interface and expose the features to the users.

So in a basic CRUD operation, the update feature that you provided which applies to items in the table depending on their state can be performed either on individual items or for a number of selected items. However, in your interface there is no differentiation of individual vs. bulk update actions. This leads to the scenario of having to intervene when there is a potential for the user to perform an action on an object that would lead to an inconsistent state.

My solution for this would be to make the individual and bulk actions clear. So this could be to provide an action menu or buttons for each data table row, and then have a bulk action somewhere else in the data table interface where you show error messages or disable actions when multiple items with incompatible behaviours are triggered. This will ensure that the users can see clearly what the possible actions are before they have to perform them and encounter errors.