Graduate data view options out of a menu to allow more design expression

[jameskoster]

#63367 introduced a useful feature that allows users to adjust density in data views Grid layout.

Future enhancements, such as those proposed in issue #60891, may add even more view options.

However, adding more controls could make the UI feel overcrowded:

Ideally, all view options should be consolidated into a single UI. The current menu isn't suitable because it can't accommodate elements like the RangeControl used for adjusting grid density ergonomically.

Let's explore alternative solutions in this issue.

[jameskoster]

This could be an opportunity to implement the Settings pattern design (#63624).

That way the view options could easily live in a popover, panel, or modal. It may make sense for views to utilise different methods, based on how extensive the set of options are. For very few options the popover can work, but as the form gets more elaborate (for instance when there are many fields) switching to a panel or modal might work better.

The modal is also a UI that could be invoked from outside the view, e.g. to edit a custom view from the sidebar:

What do you think @youknowriad?

[youknowriad]

I like both the dropdown and the modal, less the panel because it introduces some complexity for us. :)

[youknowriad]

I like that the proposed UI also could allow drag and drop of fields (and potentially later, combining fields)

[jameskoster]

In the short term I think the popover could work.

The main point was that if we systematise the settings layout then (theoretically) it becomes much easier to swap between popovers, modals, or panels down the road. Or for different views to specify different UIs.

(and potentially later, combining fields)

Also adding/removing custom fields.

An more existential question I have is whether this UI should contain all view configuration options. For instance should it also be possible to edit filters here? It's not something to handle immediately but a detail to think about. A popover would not work well for such a complex edit UI.

[youknowriad]

The other thing that I think I'm coming to, is that the "fields" part should be different from "layout" to another.

• In table, you can reorder columns, you can combine fields but you can also set the primary field.
• In grid, you can set primary field, media field and badge/columns fields (and reorder the latter)
• In list, you can set the primary field, media field and add/remove/reorder additional fields.

If feels like the design of this section should adapt to the layout.

[jameskoster]

If feels like the design of this section should adapt to the layout.

Agreed. Besides fields there will be options that are only relevant to one layout or another, e.g. the Grid density slider.

[jameskoster]

@youknowriad do you think those aspects of field configuration (combining, setting preview / primary, etc.) are a requirement of this work? Or would it make sense to start simple; toggling visibility and re-ordering?

[jameskoster]

I suppose setting the preview field, primary field, and display (badge/row) are reasonably straight forward.

But a UI for combining fields is probably going to be quite complex.

[jorgefilipecosta]

I suppose setting the preview field, primary field, and display (badge/row) are reasonably straight forward.

But a UI for combining fields is probably going to be quite complex.

Hi @jameskoster, @youknowriad, I'm working on implementing this mockup.

[jameskoster]

Should we implement a Settings pattern as a component first (#63624)? It's going to have many practical applications.

It would also allow us to easily switch between using a modal or a popover, without having to redesign the form. I'm still a bit concerned about how much we're cramming into the popover here.

[jorgefilipecosta]

Should we implement a Settings pattern as a component first (#63624)? It's going to have many practical applications.

It would also allow us to easily switch between using a modal or a popover, without having to redesign the form. I'm still a bit concerned about how much we're cramming into the popover here.
I believe we could use a DataForm for the view settings. However, it will be challenging. For example, how do we specify that "sort by" and "order" take up 50% of the space and are on the same line, while "Items per page" takes up 100%?

I think in the future, the DataForm component may have a feature to group a set of fields under a section with a title and description such as the section titled "Appearance" and section description "Customize the display of data." However, providing this flexibility is difficult, and we need to avoid creating something that is more complex than simply writing the equivalent JSX calling our components.

For an initial version, we can add ToggleGroupControl and SelectControl as field types to DataForm. This will allow us to implement "Layout," "Sort by," "Order," and "Items per page" directly as a DataForm. We could set aside the grid density for now (there will be a Dataform field for range-control later), and sections would also be outside of Dataforms. We can also implement something for field visibility outside the Dataform, as that UI is very custom and I don't expect Dataform to absorb it ever.

I will try to make things declarative as a base for what was described at #63624.

I imagine something like this:

<Popover>
	<Settings>
		<SettingsSection title="Appearance" description="Customize the display of data">
			<Dataform ... />
		</SettingsSection>
		<SettingsSection title="Properties" description="Manage property order and display">
			<PropertyManager />
		</SettingsSection>
	</Settings>
</Popover>

Please remember the following information:

The SettingsSection should have the responsive behavior described at #63624, wherein the title and description are displayed on top of the section content on small viewports and at the side on larger viewports.

The steps to achieve this are as follows:

1. Create a short-lived experiment called "Use new view configuration UI". If the experiment is enaled. We add a second view settings button that opens a popover instead of a menu. Initially, the popover will be mostly empty to allow for iteration on the dataforms expansion and properties manager in different PR's. It will serve as a place where we can test the new UI's while we develop them.
2. Create the SettingSection component with the specific responsive behavior detailed at Admin redesign: Settings #63624.
3. Expand Dataforms with the ToggleGroupControl and SelectControl types, including a declarative mechanism to pass the possible options, etc., and use them to control appearance settings.
4. Implement a properties manager component with the UI to control visible fields, etc.

Once everything is merged, the short-lived experiment and the current view settings menu should be removed, and the popover should be the only mechanism for customizing the views.

cc: @oandregal, @youknowriad, @jameskoster

Is the plan ok?

[youknowriad]

Personally, I think we should avoid using a DataForm here, it's still too early and I would just go with what we already have, adapt its design a bit and that's it.

[jorgefilipecosta]

I would just go with what we already have, adapt its design a bit and that's it.

Hi @youknowriad, So do you think we don't need yet to implement yet the responsive sections proposed at #63624? And that is something that can come later? Or we avoid the DataForm but keep the rest of the plan?

[youknowriad]

@jorgefilipecosta I'm not sure, if we can easily squeeze in some container queries to do that adhoc, that would be fine, but overall I think it's way too early for the DataForms abstraction to be used here. I think we should go step by step there, I don't see what using DataForm would bring UX or DevX wise at the moment for this particular form.

[youknowriad]

I don't think that prevent us from exploring adding the "sections" and the responsiveness to DataForms but it feels like an ambitious but separate task and we should do one thing at a time.

[jorgefilipecosta]

So I guess I will try to have things declarative in JSX something like:

<Popover>
		<SettingsSection title="Appearance" description="Customize the display of data">
			<AppearanceForm />
		</SettingsSection>
		<SettingsSection title="Properties" description="Manage property order and display">
			<PropertyManager />
		</SettingsSection>
</Popover>

Include some simple container queries in SettingsSection to get the pattern in #63624.
AppearanceForm just uses our components ToggleGroupControl, SelectControl etc. One day we may consider using the DataForm.

I will try to have this in a single PR that replaces the current menu, it will be a big PR but I think it is still manageable.

[jameskoster]

My thinking was that while DataForms would be a frequent consumer of the settings design pattern (#63624), there may be uses for it outside of DataForms too.

So hopefully it can be built as a function that we can easily extract and componentise in the future.

how do we specify that "sort by" and "order" take up 50% of the space and are on the same line, while "Items per page" takes up 100%?

Could this part be handled by a <FormRow /> (or similar) inside <AppearanceForm />? I think we could write CSS to handle the layout based on how many fields are in the row.

Your suggestion seems good to me @jorgefilipecosta :)

[jorgefilipecosta]

Closing the issue as the PR #64175 was merged. Thank you all for the insights shared.