Draft: Use DataViews for post-meta and custom sources block bindings.

[cbravobernal]

What?

Experiment checking how could DataViews work for post-meta and custom sources.
Right now it is hard-coded on block bindings, but I'll think about how to make it extensible. We could:

• Have a DataView per source, separated by tabs.
  

• Have a big DataView with all sources.
  

Demo:

dataviews_demo_mp4.mp4

[jasmussen]

Interesting. Using a modal for adding inputs might work, data views if there are many pages would certainly also be a good component to use. However there seems to be an ItemGroup thrown into the mix, is that right? If we're going to use DataViews it should be the vanilla component, recognizable. I think there's a question, however, of whether DataViews is meant to be used in a modal, in a context such as this. CC: @jameskoster in case you have thoughts.

[gziolo]

Tagging also @oandregal and @youknowriad for general awareness in case they have any thoughts to share.

[youknowriad]

For me DataViews are meant to be used anywhere we want to render a list of structured data. So having it in a modal or not is not really a problem for me.

That said, for now, dataviews is a bit optimized for switching layouts, configuration... So I think if we want to absorb more use-cases, we should look into pushing this issue to resolution #63646

[jarekmorawski]

I think there's a question, however, of whether DataViews is meant to be used in a modal, in a context such as this

I'd say yes. We're building a similar flow for Remote Data Blocks and VIP and we'll use DataViews because it's a complete package that offers UIs that large site managers will surely use, like sorting and filtering. DataViews will enable users to:

• Filter spreadsheet data by column
• Filter products by inventory status
• Identify products by images
• Switch layouts to view large product thumbnails
• Select multiple items at once
• Search by column ID or data source
• Show and hide columns

In the future, we will also want to provide custom views, like recently added products or custom data collections. No other UI I explored checked all the boxes. Popovers and dropdowns are okay for choosing from a limited number of options, but won't work just as well for picking 10-20 items out of 1000.

DataViews are perfect for that and showing the tables in a modal seems like a good balance between flexibility and simplicity.

Perhaps we could consider a more 'compact' variant where some UI options like filtering are hidden by default? That could help reduce the component's visual footprint and reduce complexity for those who don't need the extra tools.

[oandregal]

I see the dataSet is an array of objects that have the following keys: id, label, value. Is the id unique among the items? It seems so. If my understanding is correct, getItemId could be removed here.

[cbravobernal]

Done

[oandregal]

I'd like to make the type required soon. There're some fallbacks for things such as sorting to work in most common cases (text, number, date), but it'd be great to be more explicit here by providing type: text.

[jameskoster]

Agree that conceptually this is fine, but looking at the video in the OP my reaction is that DataViews feels like overkill for this particular use case? If it's just a list of options a user can choose from, would a Menu or ComboBox (#66173) work better?

[jarekmorawski]

The demo shows a small number of items, but in some cases, there may be 1000s of them (context). Perhaps we'd let consumers choose to use a simple picker or a more advanced data view?

[gziolo]

We're building a similar flow for Remote Data Blocks and VIP and we'll use DataViews because it's a complete package that offers UIs that large site managers will surely use, like sorting and filtering.

I see a lot of similarities between these two ideas. I agree that DataViews fit perfectly where you have a large set of data, you need to search for items, filter them, select multiple of them. This is precisely why the mockup attached for Remote Data Blocks looks so good. I would like to point out that the block editor's "Attributes" panel's role is currently limited to associate one of the options exposed by the block bindings source with any available block attribute. In effect, it isn't concerned yet with editing the value.

I would like to understand better how that flow looks like in Remove Data Blocks as to me, it seems oriented towards selecting then a source (Remote Data), then an option (Conference Events or ClothingStore.co), then the DataView is used to select the value (Product: Powder Blue Jacket or Event: 11 items).

In contrast, what @cbravobernal has explored so far was selecting an attribute (content), selecting a source (Post Meta), and opening DataViews to select one of the post meta fields exposed.

[artemiomorales]

Agree that conceptually this is fine, but looking at the video in the OP my reaction is that DataViews feels like overkill for this particular use case? If it's just a list of options a user can choose from, would a Menu or ComboBox (#66173) work better?

The demo shows a small number of items, but in some cases, there may be 1000s of them (#67012 (comment)).

I'm torn. My first impression on opening the modal was, "This is a lot of information." I imagine many users could have a similar reaction.

At the same time, the modal isn't too bad once you get used to it, and the benefits of the modal and DataViews for advanced use cases is clear.

Going either way — with or without the modal — may lead to a less-than-optimal user experience for a large number of WordPress users.

Perhaps we'd let consumers choose to use a simple picker or a more advanced data view?

Can we get feedback from users on this? I left a message on WordPress Slack and tagged a couple of folks who I know have some familiarity with Block Bindings (I can't tag them directly on this PR for some reason EDIT: It turns out you can, it just won't autcomplete).

Here I'll directly ping @carstingaxion @mauteri @afercia @kraftner — any thoughts appreciated! Please feel free to tag anyone else who may have thoughts.

[bph]

Pinging @WordPress/outreach for feedback.

[SantosGuillamot]

I personally lean towards reusing DataViews and, if something doesn't fit the UI, it might require an improvement in DataViews API. I think if we hit limitations in block bindings, other extenders using DataViews might hit them as well, so it could be a good way of informing those.

Some of the immediate benefits I see from using DataViews:

• As shared by Riad, DataViews are meant to be used anywhere we want to render a list of structured data. Using it in block bindings provides consistency across Gutenberg and extenders.
• It comes with built-in functionalities like searching, filtering, pagination...
• It could act as the validation system for bindings. DataViews already use a fields property that helps with that and will potentially be improved in the future. I feel reusing it for block bindings is highly beneficial. See related conversation.

[cbravobernal]

I agree with @SantosGuillamot that provinding the Dataviews package would save a lot of development time and would add a default method of dealing with big amounts of data.

Most sites using custom fields use at least between 5 and 10, and I consider block binding users as "advanced" developers or site builders, rather than DIYers.

I may limit the the Dataviews verision to only table, and hide some sorting a rearranging options to make it simpler, but IMHO the advantages are far superior than the caveats.

I've updated the branch with the last updates from DataViews team.

[afercia]

@artemiomorales Thank you for the ping, otherwise I would never have known about this important ongoing experiment and conversation, and would not have been able to participate as a contributor.

As mentioned a few times before, I'd kindly suggest everyone to put more focus on the established contributing guidelines of this project, otherwise this PR may look like an internal conversation between a restricted group of contributors. WordPress is supposed to be a collaborative open source project where gathering feedback from the community of contributors is essential for the health of the project.

That said,
I share the feeling that getting more feedback from users would be good.
To me, the DataViews has been designed to manage large sets of data. It boils down to how many sources will be available in the UI. To my understanding, there are ongoing explorations to restrict the list of data sources to their specific usage for an attribute, as in, for example:

• When I click the url attribute, I would like to get a list of sources that provide URL values.
• Instead, right now I get any value that is a string even values that aren't URLs.
• Same for other cases, for example when clicking the alt attribute, I would expect to get a list of strings with values that are meant to be used for an alt attribute, etc.

I'd tend to think making the UI show only the sources with values that are appropriate for a specific attribute should happen before any experiment about what kind of UI to use. The reason for that is that the amount of sources in the list would be greatly reduced. Would it make sense to use a big modal dialog to show, for example, only 2 sources?

One more thing to consider: so far, the only available action is 'Select binding'.
Aside: the term 'binding should be avoided because it's too technical and the rest of the UI refers to 'connections'.
As @gziolo pointed out, the UI isn't concerned yet with editing the value. Are more actions like 'editing' going to be added in the future? In that case, a larger modal dialog would make more sense because an editing flow would require a larger UI.

I'd also agree with @cbravobernal that block binding users are likely "advanced" users or site builders. For this kind of users a more complex UI shoud be manageable. But we shouldn't assume that's always true.

Overall, I'd think there should be a more clear idea of how many sources will be typically listed in the UI. So far, to my understanding, the answer is that they could be a few or many, even hundreds. Would it make sense to consider two UIs?

• A simpler 'quick connect' to select a source that doesn't use a modal dialog.
• A more advanced 'manage and select' that does use a modal dialog.

Last considerations:

• All modal dialogs should have a visible title.
• I would like to see in the editor an established design convention for all buttons that open a big 'manage' modal dialog.
• I'm not sure I like modal dialogs that contain highly dynamic content. Things like pagination, filtering, etc. inside a modal dialog feel an unexpected and potentially confusing experience to me because they update the content of the modal dialog. The same problem occurs, for example, in the Manage fonts modal dialog where depending on the flow it's not always clear what is going on and how to 'navigate' the UI within the modal dialog. Such highly dynamic content within modal dialogs should be designed with great care to make sure to provide the est user experience and to make sure it's accessible.

[oandregal]

I personally lean towards reusing DataViews and, if something doesn't fit the UI, it might require an improvement in DataViews API. I think if we hit limitations in block bindings, other extenders using DataViews might hit them as well, so it could be a good way of informing those.

This has already been the case :)

For example, we had identified that the actions menu could be simplified when the consumer only registered a single action and it was primary. This PR was the 2nd consumer where we saw that need, so that work was prioritized and it's now shipped.

[afercia]

For example, we had identified that the actions menu could be simplified when the consumer only registered a single action and it was primary.

I appreciate that change ❤️ I would like to see that implemented for all the ellipsis menus in the editor that contain only one action.

[afercia]

P.S.
One of the advantages with using a modal dialog + DataViews is that it allows to show the value of the source, which is a useful pieace of inromation to check before selecting the source. Screenshot:

However, in some cases the value could be a very long string or maybe just a number. The UI should try to display these values in the most appropriate way.

[cbravobernal]

For example, we had identified that the actions menu could be simplified when the consumer only registered a single action and it was primary.

I appreciate that change ❤️ I would like to see that implemented for all the ellipsis menus in the editor that contain only one action.

I updated this PR with that update recently.

Would it make sense to consider two UIs?

Two UIs implies more maintenance costs, but could be an option (right now we could divide between UI with getFieldsList and UI without.

To my understanding, there are ongoing explorations to restrict the list of data sources to their specific usage for an attribute..

What about if a source can be used for different attributes? Should the source definition have a list of compatible attributes?

Are more actions like 'editing' going to be added in the future?

I would love to explore that possibility.

[cbravobernal]

I also explored the combobox posibility in this PR:

#67447

[afercia]

What about if a source can be used for different attributes? Should the source definition have a list of compatible attributes?

I'm not sure what would be needed from a technical side to make it work, but I'd think any source should declare what its value is intended to be used for. Also for the case of a value that can be used for more than one attribute. Still, looking at it from an UI perspective, for example displaying any string value for a paragraph content isn't great. In the list below, there are values that are meant to be used for other purposes and not for a paragraph content:

[jarekmorawski]

I'd think any source should declare what its value is intended to be used for

I couldn't agree more. Some value types, like images, videos, and variables, require different approaches. When the user attempts to connect an Image block to a source, the UI should adjust and let them choose from a grid of images instead of file names.

Similarly, the user should see a small preview in addition to the URL when they select a link. The concept of binding block content to external sources is pretty complex; if we can find ways to make it feel less technical, we definitely should.

We may need to maintain two different UIs to get there, but it's a small price to pay for a better user experience and more flexible dev UX. Besides, if we figure out how to inject the source data into DataViews and other UI components without importing and bundling them with Bindings, the maintenance effort wouldn't be as high because we'd just consume what's already part of the core component library (which will be true when DataViews and the new admin design system matures).

One unrelated thing that has bugged me from the early days is the visual hierarchy of information presented in the picker. The way I see it, the value type is less important than the value itself, but it's the other way around in the UI right now. I'd expect the actual value to be displayed more prominently than the source.

Not sure if we need another issue for that, but I'm flagging it in case anyone has thoughts.

[jameskoster]

The way I see it, the value type is less important than the value itself, but it's the other way around in the UI right now.

I agree that giving greater prominence to the value makes it easier to identify and select the piece of data you're looking for. The type is mostly useful for clarification where values can be similar (e.g. image alt text / description / caption).

Probably worth opening an issue for that as it may get lost here.

[cbravobernal]

Now custom sources without getFieldsListAPI are also shown in the first dropdown, so the user can select them.