Block Bindings: Add ability to add/remove bindings in attributes panel

[artemiomorales]

What problem does this address?

Currently, the attributes panel indicated when attributes are connected via block bindings like so:

However, connecting the bindings in this way requires copying and pasting JSON into the code editor — it is not currently possible to add or remove bindings from within the panel UI.

What is your proposed solution?

We should include buttons to add and remove bindings within the panel similar to the following:

[artemiomorales]

@jasmussen Would it be possible to get a new design for the most recent attributes panel that includes buttons to add/remove the bindings? It seems the caret interferes with the plus icon and so the original design from https://github.com/WordPress/gutenberg/issues/61404 may need to be revised.

[afercia]

We should include buttons to add and remove bindings

Question: should users be able to also edit an existing binding? For example, I want to connect a paragraph content to another meta. With the current design, I should first remove the current binding, then add a new one.

Also, as mentioned in https://github.com/WordPress/gutenberg/issues/61404#issuecomment-2112547326, considering this UI will need to provide the ability to add, remove, edit, I'd think it will need more space. I'm not sure the editing UI should be in the inspector panel and I'd consider a modal dialog.

[SantosGuillamot]

should users be able to also edit an existing binding?

I totally agree users should be able to edit the existing binding. I believe it would be expected.

There have been a few explorations like the following one to add something like a modal:

https://github.com/WordPress/gutenberg/assets/34552881/de5bf62f-1452-432d-b129-9e3a86a0f3b3

(I stole the demo from this comment containing other videos)

Do you think something like that could work? It feels like moving to the left of the inspector controls could give us the necessary space. What do you think?

[afercia]

What do you think?

Honestly, I don't know 😅 I'd probably start from some questions first:

• What kind of users it is epexcted to use this feature the most? Low tech-savvy users? Professionals who manage their customers' websites? Agencies? Developers?
• How often it is expected users will add/edit/remove connected attributes? Is it a 'set once and forget' action or it is expected they will edit often?
• Should the changes be immediately reflected and visible in the editor? If yes, this would not allow to use a big modal dialog.
• Should the UI be unique for all the actions of maybe it could be split in two flows? Similarly to the Fonts management where:
  • A big modal dialog is used to add / edit / remove.
  • Another UI is used to actually set the font.

I'm just brainstorming ideas but maybe a big modal dialog to 'Manage connected attributes' and a separate UI like the filtering popover in the video above to actually set a source would be worth exploring.

[seifeldinio]

I explored this potential solution as a starting point. Here's the prototype for it:

https://github.com/WordPress/gutenberg/assets/76487753/e04df4c0-2007-41db-bfda-1edc38746d37

And here's a brief breakdown:

1. Adding an Attribute:

   • The user begins the process by clicking the plus icon (+) located under the "Attributes" section.
   • This action opens a modal labeled "ADD ATTRIBUTE."

2. Selecting the Attribute and Source:

   • In the "ADD ATTRIBUTE" modal, the user sees two SelectControls:
     • The first select control labeled "ATTRIBUTE" allows the user to select the specific attribute they want to bind (e.g., alt).
     • The second select control labeled "SOURCE" lets the user choose the data source for the selected attribute (e.g., Post title).
   • The available options in these select controls are dynamically displayed based on the current context and available data sources.

3. Confirming the Addition:

   • After selecting the desired attribute and source, the user clicks the "Add" button to confirm and add the attribute to the block.

4. Managing Attributes:

   • Once an attribute is added, it appears in the "Attributes" section, showing the binding between the attribute and the source.
   • When the user hovers over an added attribute, a trash icon is displayed, allowing the user to delete the attribute if needed.

If the user wants to edit an existing attribute, they can click on the attribute, which opens the "EDIT ATTRIBUTE" modal, allowing them to modify the attribute and source selections.

I'd love to hear your thoughts or feedback on this!

[jasmussen]

@seifeldinio this looks very promising, thank you for exploring. This is good use of the ItemGroup system, and seems intuitive to use. Nitpick I'd replace the red trash shortcut with a black minus symbol for "reset", as that's a pattern explored for other cases too:

Otherwise, this could work. What do you think, @artemiomorales @SantosGuillamot? CC: @WordPress/gutenberg-design

[jameskoster]

Nice work. I had a couple of quick thoughts, feel free to disregard.

1. With two select controls, how do we ensure compatibility between attribute and source, IE stop users setting post title for an image src?
2. Do we absolutely need to use the popover? Wondering if we can make source editing a single-click exercise rather than two-click.
3. Would it make sense to use the Tools Panel UI for adding attributes? This would provide a reset affordance (thinking about attributes that might be set globally).

Here's a quick mockup exploring the points above:

https://github.com/WordPress/gutenberg/assets/846565/85b4f0f3-2903-4696-ba54-7a7f06d2997c

[jarekmorawski]

I like that approach, but it could get unwieldy when we throw custom fields into the mix. Additionally, the side-by-side layout in both explorations may break on languages like German, Icelandic, or Polish where the words tend to be longer.

Can we simplify and use two separate dropdowns instead?

For editing connections, we'd use a UI similar to Bits.

Some sources may have additional settings, like a fallback for images or format and a locale for date or text, so it may make sense to surface that in the popover panel.

Then, users could click the pencil button to open a list of sources and custom fields to change the source. If they wanted to change the attribute, they'd remove the current one and add it again.

[jameskoster]

Additional settings is a good argument for the popover. Further obfuscating edit-ability behind the pencil icon inside the popover seems to be unnecessarily adding extra clicks though. I wonder if we could present that UI immediately.

I'm leaning more towards using the toolspanel UI for managing attributes,

1. It already exists and is familiar.
2. It circumvents the need to check for compatibility when presenting the two selects.
3. Provides a way to reset to the globally-specific default.

[jarekmorawski]

I see your point, but I'm still concerned about scalability. An image block may only have two attributes, but there may be blocks with a dozen or more. As far as I know, the toolspanel UI doesn't support search and may not handle such a long list well.

We'd also have to figure out the default source for each attribute because otherwise, users would create an "empty" option and would have to click it to select a value. In other instances where the toolspanel UI is used, settings usually have default values, e.g., font size or style.

[jarekmorawski]

The accordion may make the popover grow awkwardly long for some attributes.

I wonder if we could use tabs instead?

[jameskoster]

but there may be blocks with a dozen or more

Do you have some examples? The toolspanel scales reasonably well, but can always be improved for benefits across.

Will all attribute sources have settings? IF not maybe they could be a separate UI.

[seifeldinio]

I wonder if we could use tabs instead?

I like the tabs approach as it doesn’t overwhelm users with too many options at once (progressive disclosure).

To maintain consistency, we can implement the same tabs in the add functionality. And to prevent errors and empty selections, the source value should default to the first available option in the select menu.

This approach ensures consistency with the edit functionality as well.

If an attribute doesn’t have settings, we can disable the settings tab or remove the tabs altogether for that specific attribute.

For scalability, in cases where there are many attributes (a dozen or more), we can group them into chunks of up to 7 items and provide options to show all or show fewer items.

Alternatively, the "show all" button can open a modal to search and manage all attributes.

[afercia]

replace the red trash shortcut with a black minus symbol for "reset", as that's a pattern explored for other cases too:

I'm not sure I understand this pattern. When a a control deletes an object, most applications around use the trash icon to visually represent the delete action. It's so popular at the point it's basically an industry standard. Why using a minus symbol instead? How that helps users in any way?

[jasmussen]

It's added using the plus, so the minus removes it.

[cbravobernal]

Updated https://github.com/WordPress/gutenberg/pull/62880 with a POC. It is using toolspanel.

https://github.com/WordPress/gutenberg/assets/37012961/e8034e55-91f6-4ade-b8a9-2796f1b318d7

[jarekmorawski]

Do you have some examples? The toolspanel scales reasonably well, but can always be improved for benefits across.

I can't think of anything that'd have more than 4 or 5 attributes, so the tools panel may work well indeed. Here's the updated design.

Will all attribute sources have settings? IF not maybe they could be a separate UI.

I guess so. We should let users specify a fallback for every attribute. For text-based attributes, it'd be plain text or another source. For images and other media, it'd be a file picked from the library. This would enable WooCommerce theme builders to set up a product grid that defaults to a product's Featured Image but displays a customizable placeholder image if a product doesn't have any pics yet.

In case of custom fields or attributes that may not have a fallback for some reason, we could hide the tabs and display just the form.