Kibana: Surface table actions for discoverability, or hide actions that are inapplicable to current table state?

[cjcenizal]

Let's decide how to present table-level actions in the table header.

Surface actions for discoverability

In this example, all actions are surfaced, even those that cannot be taken (the Delete action can't be taken because no rows have been selected for deletion).

Conceptually, the UI surfaces all available actions to help the user discover what's possible.

Hide inapplicable actions

In this example, only actions which are possible or "make sense" are surfaced at any given time. When no rows have been selected, the Delete action is hidden because it can't be taken. When a row has been selected, the Delete action is revealed and the Create action is hidden because it doesn't "make sense" for the user to select a row if s/he wants to Create a new one.

Conceptually, the UI attempts to anticipate the user's mental state and only present information in which the user is interested, based on that state.

[epixa]

I'm not a fan at all of disappearing actions because they hide capabilities from users up front. For example, if I know I want to delete Alligator (from your screenshot), before I begin trying to delete it, I should know from the UI that it is in fact a capability of this UI to delete it.

I also think it's overly presumptuous of us to assume to know which actions "make sense" at any given time for a user to the extent that we'd be willing to remove capabilities from the user without any indication to them about why. Let's say I do have a row checked and decide I want to add a new row, why should I have to deselect that row before being able to proceed with what I want to do? If a user wants to context switch, we shouldn't be getting in their way. If we're concerned about them losing their check boxes if they accidentally click on something they shouldn't, then let's explore alternatives that also work when they accidentally click any of the dozens of other links on the page that might not be what they wanted.

[kobelb]

I agree that if we're going to have the checkboxes that the approach @epixa recommended is the best.

Tangentially, I've see a lot of this complexity reduced by eliminating the multi-actions and 'inlining' the actions; however, I'm not sure if this is the right place to question that design decision.

[uboness]

I'm not a fan at all of disappearing actions because they hide capabilities from users up front. For example, if I know I want to delete Alligator (from your screenshot), before I begin trying to delete it, I should know from the UI that it is in fact a capability of this UI to delete it.

Yes, we do hide capabilities up front, but I don't think it's bad as a general statement. It's not about going by the book but balancing between 1. clean and digestible UI that is not overly cluttered with useless elements, and 2. relying on the fact that the users will pretty quickly figure things out and know where things are at.

I do not want to optimize the UI for a first time user, but optimize for on going usage of the application. As a general statement, I'd say that deleting things happens less frequently than adding/editing things... when the user will need to delete things, they'll figure it out pretty quickly (just like you figure it out in gmail.. for example). But for the ongoing work of the user... they see what the really need to see and the interface is as clean as possible for what they need to do with it.

I also think it's overly presumptuous of us to assume to know which actions "make sense" at any given time for a user to the extent that we'd be willing to remove capabilities from the user without any indication to them about why. Let's say I do have a row checked and decide I want to add a new row, why should I have to deselect that row before being able to proceed with what I want to do? If a user wants to context switch, we shouldn't be getting in their way. If we're concerned about them losing their check boxes if they accidentally click on something they shouldn't, then let's explore alternatives that also work when they accidentally click any of the dozens of other links on the page that might not be what they wanted.

I agree that there's no reason to remove the "add" button when things are selected.

Tangentially, I've see a lot of this complexity reduced by eliminating the multi-actions and 'inlining' the actions;

it was an option we considered, but inline actions clutter the table data and leave very little space for data as well. This is the main reason we chose not to go down this route. Of course it all depends on the table and what you show in the table. Some tables have a single column of text (where adding another inline actions is not too bad on the eye), other tables may have quite a few columns (in which case the added inline actions bring A LOT of noise). The goal here was to design a reusable table component that will serve all cases.

[kobelb]

it was an option we considered, but inline actions clutter the table data and leave very little space for data as well. This is the main reason we chose not to go down this route. Of course it all depends on the table and what you show in the table. Some tables have a single column of text (where adding another inline actions is not too bad on the eye), other tables may have quite a few columns (in which case the added inline actions bring A LOT of noise). The goal here was to design a reusable table component that will serve all cases.

One approach that I've seen commonly is what Google Sheets does, there's an action menu off to the far-right, it can reduce the clutter while still providing the action inline:

[uboness]

One approach that I've seen commonly is what Google Sheets does, there's an action menu off to the far-right, it can reduce the clutter while still providing the action inline:

good one... we can definitely consider that (I was more referring to the inline editing we have in some table today)

Another thing to take into consideration is bulk action capability. With inline actions that doesn't work well. Now... thing is, bulk actions are don't necessarily make sense in the context of every table (dashboard is a good example where it's not very likely ppl will want to bulk delete dashboards). On the other, a table that shows, say... notification messages, this is something that bulk delete is very much appropriate. We need to figure this out - wether we'd like to mix & match or have 2 modes for a table...

[cjcenizal]

Notes from discussion:

• People on the team generally favor discoverability and disabling unusable actions, instead of hiding them.
• We should surface an "Actions dropdown" both in the ToolBar and in each row, which surfaces all of the actions you can perform, even if these actions are also directly available as buttons.
• This "Actions dropdown" lets us surface disabled actions, without cluttering the UI. It also gives us a scalable location to add more actions in the future (e.g. duplicate, share).
• I think we should default to provide the same bulk-edit functionality for all tables, instead of trying to remove functionality based on our assumptions, unless we have very compelling evidence that removing functionality improves the UX.

[uboness]

People generally favor discoverability and disabling unusable actions, instead of hiding them.

I'd challenge this assumption. Personally, I never felt anything was hiding from me when using Gmail and github issues... in both the available actions are contextual and change based on your selection.

We should surface an "Actions dropdown" both in the ToolBar and in each row, which surfaces all of the actions you can perform, even if these actions are also directly available as buttons.

This "Actions dropdown" lets us surface disabled actions, without cluttering the UI. It also gives us a scalable location to add more actions in the future (e.g. duplicate, share).

+1 on exploring this further

I think we should default to provide the same bulk-edit functionality for all tables, instead of trying to remove functionality based on our assumptions, unless we have very compelling evidence that removing functionality improves the UX.

+1 we should always try to be consistent across the board, up to the point it makes no sense

[kobelb]

Would there be a way to "toggle" the multi-actions, similar to what the iOS Notes application does? Since we've discussed the bulk-actions being more applicable on some screens but not others, this would expose that functionality without it being enabled by default.

clicking the "Edit" button:

enables the multi-action mode:

[uboness]

mobile design differs substantially from desktop one.... Desktop you have keyboard navigation and a mouse, in mobile you have your thumb - everything is (ideally) in a thumb movement away... in Desktop, jumping between the keyboard and the mouse + moving the mouse to different sides of the screen can be quite a burden.

Bottom line, we shouldn't take mobile design and try to apply it to desktop. Specifically here, you increase # of mouse clicks/movements quite a bit.

[kobelb]

I do agree that trying to adopt designs specifically from mobile and implement them on the desktop isn't always a good choice; however, I don't think that just because something was done in a mobile context it shouldn't be considered for use on the desktop.

I was trying to suggest that we retain the multi-action mode, but allow the user to toggle it (like clicking the Edit button in the above example) and this would enable the checkboxes to be displayed along with all of the multi-actions. This suggestion was based on the assumption that it would be more common for a user to use the singular actions via the three-dotted action-menu on every row; as opposed to doing the more bulk style options.

Perhaps I'm doing a fairly poor job describing what I'm envisioning via words, and hastily taken screenshots of similar examples. If this is still something open for discussion, I don't mind throwing together a wireframe of what I was envisioning, but I don't want to be intruding on the design team's responsibilities or wasting time on an unimportant detail.

[uboness]

@kobelb While I understand the overall intention, I think showing a mockup for desktop (or refereeing other desktop like behaviour) is indeed better than showing a mobile UI as a reference. The reason for this is, as I described above, mobile is substantially different than desktop, and when looking at an interface like the one you referenced, it's very easy to think "yea... that can work", just because we all feel it a relatively natural interface we use daily on our phones... but it can be a misleading feeling.

I'm all for exploring new ideas... but it needs to clearly relate to the context (desktop UI in this case).

I did also mention this:

Specifically here, you increase # of mouse clicks/movements quite a bit.

which I think will bite us. To me it feels we're complicating something that shouldn't be complicated at all... and that's my fear. It's similar to having a "Done" button next to a "Save" button in dashboards...

[cjcenizal]

Closing this so we can move the discussion to EUI.