MultiSelect UI & UX

[kuserich]

As we're currently working on the MultiSelect component I would like to discuss the UI and UX that will be added to blocks and extensions that need to pull posts from the database.

Currently, we are providing a sort parameter, a sort order (e.g. ascending by creation date, descending by name, etc.), a filter (taxonomies, e.g. category) and a limit option in the Inspector panel for the content editor to construct the post query from.

With MultiSelect, the content editor is hand-picking a set of posts to be included in the block and may freely rearrange the order in which these posts should be included. This is incompatible with the current implementation. That is, these two configurations are mutually exclusive and cannot be used collectively.

For blocks like FAQ and Slider, selecting and ordering by hand offers the better user experience as well as necessary functionality that couldn't be achieved with simple filtering without creating a complicated set of hierarchical taxonomies (e.g. in Kettler). Other blocks like Recent Posts, Portfolio, and Team however, benefit massively from the simplified query configurations and do not necessarily require hand-picking posts. For these blocks, though, there are still some use cases where it is useful.

Thus, ideally, we would be able to offer both types of query configurations in each of these blocks and make sure that they are not both used at the same time. Similarly, enabling the simple sort + filter method might have implications for the MultiSelect component (i.e. disable ordering).

What are your thoughts, @mahdiyazdani @AdrianFiroiu @gooklani @kalibir ? Would you be able to come up with a UI design in Figma for the inspector panel @gooklani ?

[gooklani]

Would you be able to come up with a UI design in Figma for the inspector panel @gooklani ?

I will be happy to provide a design for it, however, I need to make sure I have understood what you need. At this time you need to select the items after inserting a block. But if we want to keep both conditions, we should add a toggle to the sidebar to enabling handpick selection, and once toggled we need to disable the sorting and display a multi-select box with a frame below to display selected item with sorting ability. @kuserich Could you please confirm this theory is ideal for what you need?

[kuserich]

Yes, I believe a structure like this could work. Also, in the initial view in the editor, perhaps we can show a selection of these two querying types similar to how variations are rendered? The idea here is merely to provide the best, easiest, and most intuitive way of configuring the query for content editors working with our blocks.

Do you happen to know any similar examples from WordPress or WooCommerce that we could get some inspiration from, @gooklani ?

[mahdiyazdani]

I would want to suggest and take inspiration from what WooCommerce originally published as part of their UI components package for selecting multiple items/options using list item and checkboxes in conjunction with a mini API for doing a phrase-based search functionality.

In a similar approach, previously, when I was working on the wp-block-icons repository I have ended up creating a small method to do a quick search among the list icons based on what is being typed into the textbox and display results when and if the term that has been entered is a match with any of the keywords associated with icons.

To me, the ideal solution to implement would be a drag and drop interface that wraps these (tag) items that are being represented as selected items from the list with a higher-order component to allow sorting and returning an array as a callback.

The screenshot above has been taken from the "Hand-picked Products" block provided by WooCommerce out of the box.

As a closing note, it might be worth mentioning that there are already a number of great drag & drop libraries out there which we might definitely give them a try first. However, most of those libraries rely on the HTML5 drag & drop API, which has some strict limitations. For example, things could rapidly become tricky when it comes to adding support for touch devices, or in some instances like repeatable field elements created for the Forms block, we needed to lock dragging to a vertical axis only. Ultimately, the solution that we are seeking is a React Sortable HOC (higher-order component) that aims to provide a simple implementation by wrapping our selected items in a similar fashion that we used to implement in our projects in the past.

[gooklani]

@mahdiyazdani The Hand-picked Products block idea is great and @kuserich we have two options to add custom sorting one add sorting to the sidebar two add sorting to the products selected section above product search. However, to add a new product we need to click on the edit button that I don’t like.

[gooklani]

Do you happen to know any similar examples from WordPress or WooCommerce that we could get some inspiration from, @gooklani ?

I can’t recall any examples. I have shared my imagination 😁

[mahdiyazdani]

However, to add a new product we need to click on the edit button that I don’t like.

WooCommerce currently renders the same UI component within the Inspector panel to allow modifying the already selected items from the list of available options. However, it has one flaw which is that it establishes a connection to the database and initiates an XHR request every time that you are toggling the PanelBody component that this element has been placed in.

[gooklani]

Thank you I didn’t notice it before 😁

[kuserich]

This same panel could be used to edit the selected posts without entering the isSelecting state of the block (although this is an optional feature IMO).
I assume it should be possible to keep post data persistent when the panel body is closed and remove the additional XHR request (although one could make the argument that this could be considered a feature as it will allow you to add newly created products without refreshing the page).

[kuserich]

It will be tricky to allow sorting as well as selecting in the inspector component unless we strictly display selected posts above unselected (i.e. group by selected and then sort by sort order)

[kuserich]

or we could restrict sorting to the list of selected items entirely (i.e. only the top part).

[kuserich]

In addition to these selection elements in the editor block and the inspector panel, we will need something that enables and disables hand-picking. I believe a toggle, as suggested by @gooklani , could be a good solution. What do you think, @mahdiyazdani ?