Call for advanced bulk / row actions for object-to-object relationships

During last week’s multisite meeting the need for a new design pattern related to list tables was expressed. The intended functionality would require some kind of advanced bulk actions and row actions that would provide a second step to choose one or more related objects from a dropdown.

Before describing the requirements in more detail, the actual use-cases from the discussion are outlined:

  • Network Admin > Plugins list table: It should be possible to bulk-select plugins, then choose a new bulk action “Activate on site/s…” and then select one or more sites from a dropdown/autocomplete field on which to activate the initially selected plugins. In the same manner a row action “Activate on site/s…” should exist with a similar way of then selecting the site/s to activate the plugin on.
  • Network Admin > Themes list table: This would need a similar functionality like what has been described for plugins above, with both a bulk and a row action called “Enable for site/s…”.
  • Network Admin > Users list table: It should be possible to bulk-select users, then choose a new bulk action “Add to site/s…” and then select one or more sites from a dropdown/autocomplete field to which to add the initially selected users. A similar row action should be added as well.

While all these use-cases are about selecting related sites, the new design pattern should by no means be restricted to that. Such a pattern could benefit many other list tables in WP Admin as well. Some of the use-cases could be (without any intention to actually implement them though):

  • Posts list table: It could be possible to bulk-select posts, then choose a new bulk action “Set taxonomies…” and then select one or more taxonomies from a dropdown/autocomplete field to set these taxonomies for the initially selected posts. A similar row action could exist too. The functionality is technically already available through QuickEdit, so this example would not be useful in Core, but in general it still makes a valid use-case.
  • Posts list table: It could be possible to bulk-select posts, then choose a new bulk action “Set post format…” and then select the post format from a dropdown/autocomplete field to set the initially selected posts to. A similar row action could exist too.
  • Users list table: It could be possible to bulk-select users, then choose a new bulk action “Assign role…” and then select the role from a dropdown to assign this role to the initially selected users. A similar row action could exist too.

The initial thought during the multisite discussion was to have some kind of popover open when an advanced bulk action is selected or an advanced row action is clicked. This popover would contain the dropdown/autocomplete field to select the context for the action to perform. However, this is likely not to be the optimal approach here. Another approach would be to dynamically include the dropdown/autocomplete field on the right side of the actual bulk actions selection, which is what Advanced Bulk Actions does, a plugin that was recently created. This plugin could possibly serve as inspiration, however it does not currently provide an autocomplete functionality which would be required due to the possibly high amount of items selectable. Furthermore the autocomplete does make for a good example of REST API usage in WP Admin.

The three images below indicate the desired functionality in three steps, here following the second approach described, for the third example mentioned above (Network Admin > Users list table):

Bulk Actions Context Flow 1

1. A bulk action that requires context (indicated by three dots) is selected.

Bulk Actions Context Flow 2

2. A contextual autocomplete field appears.

Bulk Actions Context Flow 3

3. One or more sites can be selected before hitting the Apply button.

The goal for this new design pattern should be to be able to define any kind of object-to-object relationship (whether one-to-one, one-to-many, many-to-one or many-to-many) from a list table, by assigning one or more objects from the list table to one or more related objects of any type, which would be defined per individual bulk / row action.

While functionality like this could be included in an interface similar to QuickEdit for posts, it appears that having dedicated bulk and row actions might be more specific and fitting for such a use-case. This will still need to be discussed in detail though.

We would like to ask the design team for their feedback so that we can implement advanced contextual bulk actions in a proper way with the best possible user experience.

#core, #design

I’ve just posted a potential CSS roadmap for…

I’ve just posted a potential CSS roadmap for core over on Make/Core. For those of you who don’t follow along there, I’d love your eyes and thoughts.

#core, #css

Made a ticket for something that has bee…

Made a ticket for something that has been on our radar since 2.7 was in development, but just never got any kind of prioritization because it was minor compared to more serious UI things. That said, since it’s kind of minor, would be a nice thing to whip out.

Ticket #17028 – Move the “last edited at” text and saved/updated/published notices in post/page editor
1. The timestamp of the last save is currently displayed at the bottom right of the editor box. It would make more sense for this information to be tied to the Publish box instead.
2. The yellow alert boxes that appear at the top of the page are weird. a) They should appear closer to the button that caused the action (general usability/accessibility best practice), so probably by the Publish box. b) Once you edit anything on the screen, the “post updated” (or saved, etc) text should go away, because it is no longer current.
Am thinking we could combine these two things into one flexible status message that’s located in or adjacent to the Publish box.

#alerts, #core, #trac