Admin redesign: Settings

[jameskoster]

In the context of the wider admin redesign (#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 (#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

• 12-Column Grid: The design is based on a 12-column grid system, ensuring flexibility and consistency across various screen sizes.
• Responsive Design: The layout adapts to different screen sizes. When the container shrinks beyond a certain breakpoint, the columns stack vertically, and spacing values are adjusted for optimal readability and usability.
• Horizontal Rules: Sections are visually separated by horizontal rules, providing clear demarcation between different groups of settings.

Section Structure

Each section contains the following elements:

• Section Title: A clear and concise heading for the section.
• Description: A brief description of the section's purpose, including a link to relevant documentation for further guidance.
• Settings Fields: The main content of the section, containing various input elements like text inputs, select dropdowns, checkboxes, radio buttons, and textareas.

Responsive Behavior

• Stacking Columns: On smaller screens/containers, the left and right columns stack vertically to make efficient use of limited space.
• Adjusted Spacing: Padding and margin values are reduced to maintain a clean and functional layout.

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.

[oandregal]

@jameskoster how do we think of validation? In implementing parts of this #59745 I've started to add validation #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.)?

[jameskoster]

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.

[jeflopodev]

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.

[jameskoster]

@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.

[nikkivias]

I tested the layout with the PayPal plugin, incorporating some changes and add-ons for consideration:

• Added an image in the header to help identify the page. Since many plugins only exist as a settings page, this could be a useful (and possibly the only) place to include an identifier.
• Included a status badge
• Experimented with placing the 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.
• Considered sectioning within sections. For example, within Quick Settings (section 1), the settings on the right are separated by a divider, which could be a useful way to create distinction when it makes sense.

[jameskoster]

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.

[nikkivias]

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.

[jameskoster]

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.

[mirka]

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.

[tyxla]

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?

[psealock]

Do we have a direction we'd like to go for regarding saving? I'm seeing several iterations and I'm curious how we view each section from the perspective of DataForms. Will each one be its own form or will the page be a single form? We also have the opportunity to do an auto-save, although this doesn't feel very WordPressy.

Sticky footer with Save button

Header with Save Button

Save button with every section

[jasmussen]

What we end up recommending here can be informed by any experiences you encounter. Though I will say that a save button in the header can not work as the only save button, as that would require shift-tabbing backwards to save, where the logical keyboard flow would put the save button at the end.

[jameskoster]

I quite like the sticky footer approach. It puts the save button in easy thumbs reach on mobile too.

[ciampo]

The only downside of a sticky footer is that it can take up precious screen estate. Maybe we could show a sticky footer only for viewports above a given height?