Open jameskoster opened 3 months ago
@jameskoster how do we think of validation? In implementing parts of this https://github.com/WordPress/gutenberg/issues/59745 I've started to add validation https://github.com/WordPress/gutenberg/pull/63895. I wonder how do we surface this to users (e.g.: when a user enters an invalid value for a field or needs to fill a required one, etc.)?
Good question. I think changing the input outline and including an inline error message could work:
The error appears before the help text because I think it's beneficial to give immediate feedback to folks using assistive technologies.
If a choice between them has yet to be made. I would vote for a full page design. I really like how this looks like.
@jeflopodev Thanks for the feedback. One of the main objectives of the design work here is to make the choice of container inconsequential. In other words a settings form could be rendered in a page (like the example you shared), a wide or narrow modal, a sidebar/panel, or even a popover, and just work.
I tested the layout with the PayPal plugin, incorporating some changes and add-ons for consideration:
Save
button in the header, aligning it with the design of other new pages. Although on smaller screens, it will have to move to the bottom.Thanks @nikkivias, it's really great to see the concepts tested outside of core. To be successful these patterns will need to adequately serve a wide range of use cases; IE plugins 💪
While closely related I'd say that your first three points relate to the page header; a separate component that we need to spec as a part of the parent Page
component. Good thoughts there though.
Sub-dividing sections seems reasonable. I wonder if it would make sense to use headings here rather than horizontal rules. In your example the toggles could live inside a fieldset
with a legend
, which I suspect would be more useful from an a11y perspective.
I noticed your section descriptions included a 'Learn more' link—I think that's a nice idea that would be good to standardise / codify.
While closely related I'd say that your first three points relate to the page header; a separate component that we need to spec as a part of the parent Page component. Good thoughts there though.
Ah thanks @jameskoster ! ~Does that mean we open a new issue like this one?~ Never mind I found the relevant discussion :D
Sub-dividing sections seems reasonable. I wonder if it would make sense to use headings here rather than horizontal rules. In your example the toggles could live inside a fieldset with a legend, which I suspect would be more useful from an a11y perspective.
It's a good idea, and I explored it at one point, but it doesn’t always cleanly separate sections and can sometimes add more visual noise. In cases where you just need to separate one setting, a subheading may not be necessary. Line separators provide a clean and easy way to distinguish settings without the challenge of crafting the right subheading, which many people may find challenging. That said, I think field setting can still be used where it makes sense.
Does that mean we open a new issue like this one?
I'd be curious to get @WordPress/gutenberg-components thoughts on a Page
component. I could see it being structured a bit like Card
with sub-components for header/body/footer. In any case it probably would make sense to open a new issue with a full spec.
thoughts on a
Page
component
That makes sense to me, especially since it seems we want to handle not just static layout but responsive styling as well. I am assuming that this Page
component (naming TBD) will be part of a higher-level package though (dataviews
? admin
?), not @wordpress/components
.
I am assuming that this
Page
component (naming TBD) will be part of a higher-level package though (dataviews
?admin
?), not@wordpress/components
.
@wordpress/interface
perhaps?
In the context of the wider admin redesign (https://github.com/WordPress/gutenberg/issues/53322), a scalable, portable, and responsive design pattern for settings pages is crucial. This issue outlines some foundational principles and design conventions for such a pattern.
General Structure
The layout is defined by a consistent header and footer (dictated by the Layout (https://github.com/WordPress/gutenberg/issues/53617)), framing the main content area where settings are organized into sections. Each section comprises a left column for title and description, and a right column for the actual settings. The left column makes it easy to scan the page at a high level and locate a specific setting.
Layout Conventions
Section Structure
Each section contains the following elements:
Responsive Behavior
By adhering to these guidelines, we ensure a consistent, user-friendly, and responsive design for settings pages.
Contextual examples
To test the spec we can try applying it to some existing interfaces.
Editor preferences
In this example we see how the Editor preferences would adapt to different environments; the existing modal, a hypothetical page in site settings, and on mobile.
Page settings
This mockup shows the settings for a page in the Inspector (in the full-screen editor, and as a quick-edit interface in data views), in a hypothetical full-screen page / modal, and on mobile.