Design system - Page layout

[SaxonF]

Part of #53322

What problem does this address?

6.3 brought in several new pages to the site editor, including pattern management, browsing pages and different detail views. As the site editor expands, and as we kick off the admin design project, we need to form a consistent way of structuring pages. Inconsistency between how pages are structured This includes how we handle page headers, sub navigation, page actions, and content areas with different container sizes.

What is your proposed solution?

We need to a full audit across different core pages and plugins. Please share common layouts you've come across that we need to handle.

To kick off discussions though here's some early thoughts

Current generic layout

Proposed

• title
• actions (primary, secondary)
• more menu
• content area (full and centred). The structure of the content area depends on the type of page and will be discussed elsewhere.

[hanneslsm]

The proposed design is a single view of a page?
I think a table view is essential, especially filtering and for bulk editing.

[Ren2049]

I hope there's also a pages view that works similar to the generic table view, but maybe as collapsible and nestable accordion like components.

This would enable a way to create page groups for easier page sequences (funnel flows, ecommmerce checkout flows etc.). Currently all power users I know use some kind of admin enhancement plugin to add organization features like nesting, drag 'n drop, folders for grouping etc.

[acdotme]

I've spent some time auditing a few dev and live sites looking for common admin layouts we may need to account for, but as the main scope for this seems to be requirements for the page header area, I think @SaxonF's list covers most needs. Everything else that's common, such as search / filtering etc., would be part of the page content scope to be discussed elsewhere.

Some other things we might want to consider as part of the standard admin page layout are the "Screen Options" and "Help" sections which should maybe be visible at all times for accessibility and usability. Given that these are contextual to the page you are currently viewing in Admin, it makes sense for them to always be available in the page area header. To make the best use of space, these could be included as icon buttons similar to the following:

The screen options and help sections would probably be modals when triggered.

In terms of how to lay this out, I'd suggest a sidebar type layout where the action buttons group stacks under the page title on smaller screens. This would provide a flexible, more intrinsic layout that would work well in many situations, such as longer titles that may collide with buttons if they were fixed at the top right.

While likely obvious to most, there should probably also be a standard slot offered in the page layout component for system notices to ensure consistency of positioning.

@SaxonF, I'm very interested in contributing to the design system. I'll keep checking back for tickets, but if there's anything specific I can help with, please DM me and I'm happy to pitch in!

[acdotme]

Another layout concern for smaller screens occurred to me after my last post. Admin screens with lots of tabs currently stack the tabs, which I'm guessing is not what we're going for with the new aesthetic. It's also pretty common to have both tabs and a list of links like this:

I'm thinking the guideline should be that lists of links like this should always be part of the page content area rather than in the header, reserving tabs for navigation between screens.

To handle many or longer tabs on smaller screens (or even large screens when there's more than space allows), we could have the tabs as a side scrolling track which is a common pattern for mobile site views and apps.

This could either just overflow the side of the viewport, which is common and fairly widely understood as scrollable, or if we feel like there should be more affordance for the user, there could be some sort of cap at the end to indicate there's more - also fairly common.

Finally, as you can see in my first screenshot, it's not unusual for plugins to use tall notice banners that take up a lot of vertical space. Should notices be collapsed to a specific height by default with a "Read more" control to expand them if the user wishes? This might encourage plugins to not overdo admin notices. Or do we say that only system notices are allowed in the header and any other notices, i.e. by plugins, should go in the page content area?

[afercia]

@SaxonF thank you for your preliminary analysis and proposal.

I'd like to add some initial thoughts from my side.

Screen Options and Help Panels

I'd agree with @acdotme that one of the most notable things missing in this issue description is the Screen Options and Help Panels.

In the past, the accessibility team discussed a few times how to improve the placement and discoverability of these Screen Options and Help panels but never found time or an opportunity to make actual improvements. The main concern for classic core was backwards compatibility. Most of the discussion happaned on this Core Trac ticket (see also the links to the related discussions on Slack on the ticket):

Improve discoverability and visual design of Screen Options and Help Panels
https://core.trac.wordpress.org/ticket/21583

I'd recommend to go through that Trac ticket, keeping in mind a couple key points:

• For many users, content navigation is a linearised process. Ideally, the content order in the source should follow a logical flow.
• The first thing in the page content should be the main H1 heading.
• All other content, including Screen Options and Help, should come after the main H1.
• All main sections of the page should be identified by headings, with a correct headings hierarchy.
• Please observe that the classic admin pages have a few visually hidden headings to identify sections. These headings must be taken into account and preferably be visible.
• All perceivable content should be within ARIA landmarks. No content should live outside landmarks.

Filters and hooks

One more very important consideration is that in the classic admin pages there are lots of filter and hooks.

I think it is essential running an anaysis of what filters and hooks are there and make them availabls in some way also in the new pages, or provide compatible alternatives.

In the more than 6 years of development of the editor I've seen that sometimes filter hand hooks have been a bit neglected and no equivalent features have been always provided in the editor, compared to classic pages. I think it is essential to make sure plugin authors are provided with equivalent features.

I do realize this is not a task for designers but we really need to know what all the hooks and filters that run on a typical classic page are. Often, these filters and hooks provide authors witht the ability to modify and add content. As such, the new design should provide areas and spots where the modified added content integrates nicely with the default content. Therefore, I think it is key to have a clear picture of all lthe filters and hooks in place before proceeding with the final design.

Tables

Pages with collection of objects (posts, pages, comments, and the likes) are better implemented with tables, from a semantic and accessibility perspectice. Also in this case there 's a lot of filters and hooks to take into account.

Tables should be used properlyu and, ideally, each column should only contain one specific data taype. The current tables are in a way very familiar to users but still not ideal. Thinking for example that the Title colum should only contein the title. Insteead, it contains many ohter things that are extraneous to the 'title' data taype: action links, status, post format and the liks. These are data of different type and ideally they should live in their dedicated table column.

One more thing is these tables in WordPress Core have always had problems related to the limited horizontal space. Plugin may add colcumns, and in some cases they add several columns. On a screen with limited width space, many additional column typically make the table almost unreadanle, as the content is stretched to fit into the columns. We should find a way to make these tablss more redable and still accessible.

On mobile: right now, these tables transform via CSS and JS in a stacked view with exapndable panels. To achieve these effect, the CSS property display: block is set on the tables. It is very important to consider that setting display: block on a table element alters the semantic of a table. The table is not a table any longer: assistive technologies would perceive them as normal content, npt providing the any logical relationship between table headers and celss, and screen readers will not provide tabular navigation any longer. I'd warn against re-implementing this table-to-block transformation on mobile view, as it is far from ideal for accessibility. We should think to some other kind of layout instead.

Pinging @joedolson and @alexstine for any further accessibility consideration, feedback, and possible improvements.

[acdotme]

@afercia thanks for your feedback. From an accessibility point of view, should system notices appear after the h1? It was my (limited) understanding that these kind of notices are best placed first in the document. They could always be moved below the h1 if that is more accessible.

I believe the scope of this ticket is for a reusable header and content wrapper layout only, with page content and tables being explored elsewhere. With that in mind, I think (?) the design I proposed follows your accessibility guidance. The order of header content would be:

• System notice banner(s) (assuming that is the correct place for them)
• h1
• Primary action button (optional)
• Secondary action buttons including help and screen options
• Page description (optional)
• Tabbed navigation (optional)
• Content area (details of which to be explored elsewhere)

I'm not sure what the equivalent of hooks and filters is within the Gutenberg interface, but my thought process was to offer only the above list of elements within the standard page layout component for developers to hook into. This would hopefully provide a consistent and uncluttered navigational experience for users.

I'm also thinking that it may be best to only allow system notices in the header, with any other notices (e.g., plugin banners) being placed within the page content area under the tabbed navigation. Again, this helps to reduce abuse of the header area and keeps it easier for users to navigate admin pages.

Thanks again. Any and all feedback welcome!

[alexstine]

@acdotme I am thinking something like this.

• h1
• System notice banner(s) (assuming that is the correct place for them)
• Primary action button (optional)
• Secondary action buttons including help and screen options
• Page description (optional)
• Tabbed navigation (optional)
• Content area (details of which to be explored elsewhere)

When users jump to the first heading, they would never think about checking for notices above it. Given the admin menu would still be in the previous landmark, it makes sense to make the heading the first item in the main landmark, followed by notices, etc.

[acdotme]

@alexstine thanks for your feedback. Upon further reflection, I'm inclined to agree that system notice banners probably aren't appropriate at all in the context of the admin page layout at all. They're probably more appropriate as some sort of overlay and not limited to the page surface of the new admin design. Maybe something like a snackbar / toast component overlay - and outside the scope of this component.

So my suggestion is that we'd be looking at something like this for the page layout component:

• h1
• Primary action button (optional)
• Secondary action buttons including help and screen options
• Page description (optional)
• Tabbed navigation (optional)
• Content area (details of which to be explored elsewhere)

[carolinan]

I am finding it difficult to picture the end result based on this design since it is not complete (the content in the grey area is missing).
I do not understand what the tabs are for. Can you describe in more detail what the different elements do? The only thing that is clear to me is the page title and the primary action (I am assuming this is "Add new page")

[alexstine]

@acdotme

They're probably more appropriate as some sort of overlay and not limited to the page surface of the new admin design. Maybe something like a snackbar / toast component overlay - and outside the scope of this component.

As long as it is accessible. The notices currently in Gutenberg are read to screen readers but really hard to discover.

[acdotme]

I am finding it difficult to picture the end result based on this design since it is not complete (the content in the grey area is missing).
I do not understand what the tabs are for. Can you describe in more detail what the different elements do? The only thing that is clear to me is the page title and the primary action (I am assuming this is "Add new page")

Hi @carolinan. Apologies for not being clear. The intention with this layout component is to standardise admin page layouts to provide a consistent experience. This is mainly focused on planning the structure of the page header content, with the content area effectively providing a wrapper in a couple of different widths. The actual page content structure is to be explored elsewhere - I'm aware that the table component has already had quite a bit of exploration.

The tabs are the navigation for admin pages under the same section, like in the Updraft Plus plugin example. Yes, the primary action button would be for things like adding a new post or page.

Most of the elements in the page header are optional depending on the context of use, with the h1 being the only one required. The page layout needs to account for any combination of these elements.

If it's helpful, I can create some visuals of various combinations and include some simple examples of the page content area.

[afercia]

From an accessibility point of view, should system notices appear after the h1? It was my (limited) understanding that these kind of notices are best placed first in the document. They could always be moved below the h1 if that is more accessible.

I'd second what @alexstine pointed out:

When users jump to the first heading, they would never think about checking for notices above it.

Quick aside for technical and historical context: in the classic admin, the PHP notices are actually printed out before the main H1 and then moved via JavaScript after the main H1. In fact, you can see this by disabling JavaScript in your browser settings and by triggering a notice, for example by updating the General Settings page. Screenshot:

As far as I can recall, that is because for backward compatibility reasons it was not safe to change the PHP part. Later on it was decided to move the notices with JavaScript after the heading because that's better for all users.

[jarekmorawski]

Coming from WooCommerce, I can see a need for a slightly more complex layout. WooCommerce pages are packed with data that isn't always linear and it makes sense to emphasize more than others. I put together an exploration for a sample data-packed screen (very high-level) where I mixed the two-column layout from the current wp-admin UI and the elements of the inspector sidebar in Gutenberg.

This could be a way to strike a balance between focus and information density. The left half is the main page area, which contains the most important information, like item details or settings. The right half consists of collapsible sections, all of which are secondary and not essential to a task at hand. Just like in Gutenberg, users could show and hide the settings and tools they need at the moment.

This layout could be optional and available in certain use cases, like item creation flow, data editing, etc. There could even be a toggle to enable it from within a single screen—a shorthand for more advanced users who know what they're looking for and can handle denser interfaces.

advanced2.mp4

[jameskoster]

As the container shrinks, instead of wrapping the buttons beneath the title, one option could be to move the secondary and tertiary buttons into the 'more' menu next to the primary action button. By reducing the button width as well we can keep the vertical height of the header more compact. This will be beneficial given it's likely the header will be 'sticky'.