-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Graduate data view options out of a menu to allow more design expression #63872
Comments
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? |
I like both the dropdown and the modal, less the panel because it introduces some complexity for us. :) |
I like that the proposed UI also could allow drag and drop of fields (and potentially later, combining fields) |
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.
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. |
The other thing that I think I'm coming to, is that the "fields" part should be different from "layout" to another.
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. |
@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? |
Hi @jameskoster, @youknowriad, I'm working on implementing this mockup. |
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 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:
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:
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? |
Personally, I think we should avoid using a |
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? |
@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 |
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. |
So I guess I will try to have things declarative in JSX something like:
Include some simple container queries in SettingsSection to get the pattern in #63624. 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. |
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.
Could this part be handled by a Your suggestion seems good to me @jorgefilipecosta :) |
Closing the issue as the PR #64175 was merged. Thank you all for the insights shared. |
#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.
The text was updated successfully, but these errors were encountered: