Batch Actions in Live Data

[amilica]

Hello everyone! I’m here to discuss with you batch selection & batch actions in live data.

Current situation

---

Currently, we don’t have an UI for batch actions for Live Data, nor for Live Table.

New Live Data Property - Enable batch selection

---

The user may not want all tables to have batch actions available, so we should add to Live Data a property to enable or disable batch actions.

Enabling batch actions would add a column of checkboxes at the beginning of the table.

Design

---

Initial state (non-selected)

The column of checkboxes is empty at first.

It will have as a header a 3-state checkbox.

This column cannot be searched, filtered or sorted through.

Selection state

Behavior of selection

---

The header checkbox and all the items checkboxes function exactly how the Gmail checkboxes work, to keep a familiar UX pattern.

The selection of items is made at page level and filter/sort level. This means that if the user changes the page or inputs a search filter or adds a new sorting rule in any way, the checks made by the user are NOT kept after the query change.

This is pretty similar to how Gmail does it, except they preserve checkboxes state when going to another page, even though they allow batch actions only on the current page.

UI changes when selecting items

---

When selecting at least 1 item, the batch actions row gets visible below the row of pagination.

The table actions button (for filtering, sorting, etc.) gets hidden to keep the UI cleaner and the attention on the left side.

The number of selected items is signaled first, and then it’s followed immediately by the possible batch actions. We keep everything aligned to the left.

If the user navigates to another page after selection, the row of batch actions disappears and all checkboxes get reset to state 0 (unchecked).

We should also recolor the selected item’s row. See benefits in the proposal page.

This means:

• changing the background color to the one of an info box
• changing the text color to the info box’s text color, to ensure accessibility
• preserve original border color

Design

---

Batch Deletion screen

---

After selecting a number of items in a Live Data table, the user chooses Delete and is led to the following screen.

We need a separate screen and not just a confirmation modal because we should let the user select a new target for the deleted pages.

The screen mainly consists of a new live data table made with only the selected pages from the previous screen, with one action column.

That action column, Set new target, can have one of 2 actions available:

• Configure - setting the actual new target, clicking it opens a modal you’ll see next
• Edit - this action will appear only if the user already set the new target, enabling him to edit it. Clicking it leads to the same modal for Configure, just with fields filled in.

The live data table doesn’t need to be filterable, sortable, searchable and shouldn’t have pages.

Set new target modal

Batch Move Screen

---

After selecting a number of items in a Live Data table, the user chooses Move and is led to the following screen.

In the Items to be moved section, if the user chooses to expand it, he will see all the selected items in a live data. This live data table doesn’t need to be filterable, sortable, searchable and shouldn’t have pages. There are no actions available for these items.

What do you think?

• Proposal page
• JIRA issue

[surli]

Hi Adina,

thanks for working on this!

@amilica

The user may not want all tables to have batch actions available, so we should add to Live Data a property to enable or disable batch actions.

Enabling batch actions would add a column of checkboxes at the beginning of the table.

+1

@amilica

The column of checkboxes is empty at first.

It will have as a header a 3-state checkbox.

This column cannot be searched, filtered or sorted through.

I’m wondering if it would make sense to be able to sort it? e.g. to put every check items on top of the table for some reason?

@amilica

The selection of items is made at page level and filter/sort level. This means that if the user changes the page or inputs a search filter or adds a new sorting rule in any way, the checks made by the user are NOT kept after the query change.

I generally agree with this but IMO we should be careful to allow users to keep the selection when using the navigation back browsing capability: e.g. if a user forgot to select something and already selected an action, they should be able to browse back and select the missing page and then perform the action again.

@amilica

When selecting at least 1 item, the batch actions row gets visible below the row of pagination.

Question: I guess the checkbox of the column should allow to immediately select/unselect every rows displayed in the table right? Do you think we should also have same mechanism than in Gmail to allow also selecting the rows once we clicked to select everything?

Also I’m a bit mixed about displaying the actions only when selecting a row, I’m wondering if the actions shouldn’t be visible but disabled by default? So that users don’t have to select something to know which actions are available?

Last comment also seeing your screenshots: IMO the rows that are not visible to current users because of lack of rights (N/A lines in the screenshots) shouldn’t be selectable at all for batch actions.

@amilica

The live data table doesn’t need to be filterable, sortable, searchable and shouldn’t have pages.

So this is not a live data, but a static table then. I’m ok with that, just wondering how it would work if we allow selecting all lines of the LD as I suggested above.

@amilica

That action column, Set new target, can have one of 2 actions available:

• Configure - setting the actual new target, clicking it opens a modal you’ll see next
• Edit - this action will appear only if the user already set the new target, enabling him to edit it. Clicking it leads to the same modal for Configure, just with fields filled in.

Since this table is also a summary of what has been selected IMO it would make sense to allow removing a line: e.g. a user made a mistake in a big selection and wants to delete the batch except a page, would be handy to be able to remove a line there and I don’t think it’s technically complex.

Also I would probably display in this table the number of incoming links for each page: it’s an interesting information to know if the new target should be configured.

@amilica

In the Items to be moved section, if the user chooses to expand it, he will see all the selected items in a live data. This live data table doesn’t need to be filterable, sortable, searchable and shouldn’t have pages. There are no actions available for these items.

I’m not sure why it’s not displayed by default? This UI is a confirmation UI so for me it makes sense that the user can quickly ensure they didn’t make a mistake. Also in this UI it’s not quite clear to me why the child pages links and incoming links would display since the count should be a total count about what’s been selected? Also “Rename as terminal page” is probably an option that should be independently selected for each page of the batch no? Doesn’t really make sense to have that globally? Same for auto redirect probably. Not quite clear to me why all those settings are not individual like you did for the delete UI with configure.

[CharpentierLucas]

@amilica

The user may not want all tables to have batch actions available, so we should add to Live Data a property to enable or disable batch actions.

+1, we should assume the default use case is the simplest possible, which is a Live Data with only a few entries. In this use case, batch actions are unnecessary and would only bloat the UI.

@amilica

When selecting at least 1 item, the batch actions row gets visible below the row of pagination.

Regarding the design of each action, shouldn’t we make them look like standard buttons? I think at least a border would help here. IMO it’s not immediately clear what is an action and what is not. The first icon+text “ 2 Selected” looks very much like an action.

@surli

@amilica

The selection of items is made at page level and filter/sort level. This means that if the user changes the page or inputs a search filter or adds a new sorting rule in any way, the checks made by the user are NOT kept after the query change.

I generally agree with this but IMO we should be careful to allow users to keep the selection when using the navigation back browsing capability: e.g. if a user forgot to select something and already selected an action, they should be able to browse back and select the missing page and then perform the action again.

+1

@amilica

Design

---

Note for implementation: those checkboxes are custom styled. In order to do this correctly, one should hide the native checkbox and customize the style of their labels to make them look like what we want the checkbox to look like.

@amilica

We need a separate screen and not just a confirmation modal because we should let the user select a new target for the deleted pages.

I don’t think it’s a NEED, it’s probably a SHOULD. I didn’t check but I doubt it wouldn’t be possible to open one dialog from another dialog (nesting them). But I agree that it’s a bad practice and it would be confusing to have this whole complex process into dialogs.

@amilica

In the Items to be moved section, if the user chooses to expand it, he will see all the selected items in a live data. This live data table doesn’t need to be filterable, sortable, searchable and shouldn’t have pages. There are no actions available for these items.

Shouldn’t we show at least some items by default to the user? It feels weird to me to have an empty expandable section at the top of the page. Maybe we should move this section somewhere else or make it less prominent in some other way?

---

@surli

Also I’m a bit mixed about displaying the actions only when selecting a row, I’m wondering if the actions shouldn’t be visible but disabled by default? So that users don’t have to select something to know which actions are available?

From what I remember, disabled controls are a real headscratcher when it comes to usability/accessibility. One important thing is to make sure it’s easy to understand “How to enable the control” (and if the control, cannot be enabled, ofc it means it should have been hidden in the first place). AFAIK in order to do that we’d need an explicit label around the controls, something like: “Batch actions: These actions are currently disabled because no entry is selected.”
Here is one source that explains this in more detail: Disabled buttons don’t have to suck | by Justine Win | Justine Win Stories | Medium . Disabled buttons aren’t bad for accessibility per se, but IMO we should be careful adding any.

Sidenote: We should probably use the same pattern for the action column, when no item is selected. It looks very complicated and I am wondering why we couldn’t remove it altogether and just use the batch action on one selected item (one more click, but less clutter and UI appearing/disappearing).

@surli

Since this table is also a summary of what has been selected IMO it would make sense to allow removing a line: e.g. a user made a mistake in a big selection and wants to delete the batch except a page, would be handy to be able to remove a line there and I don’t think it’s technically complex.

+1

---

Thanks for advancing on this topic!
Lucas C.

[vmassol]

@amilica

Hello everyone! I’m here to discuss with you batch selection & batch actions in live data.

thx for working on this!

I have a general question regarding how this proposal overlaps or complements the one at LiveData for Cristal . The later also tackles batch updates and since we want the LiveData component to be the same for Cristal and XS, we need proposals that are compatible and work the same.

Could you check this out with @tkrieck ?

@amilica

The user may not want all tables to have batch actions available, so we should add to Live Data a property to enable or disable batch actions.

Enabling batch actions would add a column of checkboxes at the beginning of the table.

I think we need consistency in term of L&F between a LD with an Action column (as we have now) and this batch action proposal. To reconcile both, I’m proposing that:

• We allow a config option for LDs, to say that a LD has actions for it (like Edit, Delete, etc)
• We have another config option for LDs, to say whether multiple selections are allowed or not.

If we have actions = true but multiple = false, we still display checkboxes on the left (but not the global checkbox to select all), and only allow the user to select a single row.

Technically we could imagine preserving backward compatibility, when an _actions column is defined, don’t display a new column but display the actions in the L&F defined in this proposal, for consistency.

@amilica

The header checkbox and all the items checkboxes function exactly how the Gmail checkboxes work, to keep a familiar UX pattern.

So this means a single click on it selects ONLY the visible LD rows, and there’s some text displayed with a link to allow selecting ALL rows:

@amilica

After selecting a number of items in a Live Data table, the user chooses Delete and is led to the following screen.

The table needs to be a LD for scalability.

General important remark re the move and delete proposed UIs: I’d like to have consistency between the single item delete or move UI and the batch deleteor move UI. Basically they need to be the same UI for me (with possibly some inir differences but at 90+% the same).

Could you update the proposal to have this consistency?

Thanks a lot!

[tkrieck]

@vmassol

I have a general question regarding how this proposal overlaps or complements the one at LiveData for Cristal . The later also tackles batch updates and since we want the LiveData component to be the same for Cristal and XS, we need proposals that are compatible and work the same.

Could you check this out with @tkrieck ?

This proposal complements mine. The one about LD in Cristal is more about the generic mechanisms that I am proposing LD to have. This one deals more with what happens after someone selected multiple entries, move and delete.

When talking to @amilica we made sure that both proposals have the same way of selecting multiple objects (but I still need to update mine to get the correct L&F of the selected row, as proposed here).

[vmassol]

@tkrieck

This proposal complements mine. The one about LD in Cristal is more about the generic mechanisms that I am proposing LD to have. This one deals more with what happens after someone selected multiple entries, move and delete.

When talking to @amilica we made sure that both proposals have the same way of selecting multiple objects (but I still need to update mine to get the correct L&F of the selected row, as proposed here).

ok cool but I remember discussions there that I don’t see mentioned here. For example:

@tkrieck

The Action button

This button appears at the beginning of each line and serves to group all actions that affect the item being highlighted

So does this mean we would have both the chexkbox + the kebab in front of each row for tables that allow batch actions? Seems a bit weird to me. Hence my comment and proposal above to merge the 2 concepts.

Also another question: I dont feel that tables that support batch actions should display checkboxes in front of each row, as this makes the tables heavy. As I mentioned in your proposal, we need to be able to have very lightweight UI for LD (similar to a normal static table). So I believe we need a mechanism to activate the selection of rows (and thus the appearance of the checkboxes). This could be located in the toolbar or appear when hovering over the table.

Thx