Design system - Page layout #53617
Comments
|
The proposed design is a single view of a page? |
|
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.
|
jorgefilipecosta
added
[Type] Enhancement
|
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! |
|
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? |
|
@SaxonF thank you for your preliminary analysis and proposal. I'd like to add some initial thoughts from my side. Screen Options and Help PanelsI'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 I'd recommend to go through that Trac ticket, keeping in mind a couple key points:
Filters and hooksOne 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. TablesPages 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 Pinging @joedolson and @alexstine for any further accessibility consideration, feedback, and possible improvements. |
|
@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:
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! |
|
@acdotme I am thinking something like this.
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. |
|
@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:
|
|
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). |
As long as it is accessible. The notices currently in Gutenberg are read to screen readers but really hard to discover. |
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. |
I'd second what @alexstine pointed out:
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. |
|
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 |
|
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'. 
|
|
I conducted an audit of existing section headers to identify common features and areas of opportunity for refinement. I've included section headers in this review because they share conceptual similarities with page headers and arguably should have similar characteristics. This effort largely recaps the existing discussion, but I figured it was worth sharing anyway. As a next step I’d like to explore some design concepts that account for the identified feature requirements, plus any details that warrant refinement. With consensus on these designs we can document examples on Storybook and over time, apply conventions consistently across the various use cases. The sooner we do this, the sooner we can equip folks in the ecosystem with the tools they need to create UIs consistent with WP. Data Views
Each data view in the site editor includes a section header that provides context for the displayed content, often accompanied by a primary action button. Occasionally secondary actions are present in an ellipsis menu. Inspector / Global Styles
The Inspector offers information and editing capabilities for specific entities or concepts like 'Typography' in Global Styles. Differentiators here include:
Site Editor Sidebar
Each 'page' in the site editor has an associated sidebar. The sidebar primarily serves as a navigational tool, with its header providing context for the links within. A 'Back' button is utilised here too. wp-admin Pages
Admin pages in wp-admin generally share a consistent appearance. While there are exceptions, such as the 'Site Health' page, these differences are largely superficial. Common FeaturesThe following features are commonly found across section headers:
I’ve excluded sub-navigation as a feature of the header, as horizontal tab interfaces can be limiting in some scenarios. Instead, I suggest placing navigation within the 'content' area of the section for greater flexibility. Also excluded are Notices—I agree with the sentiment above that global notices should live outside of the section/page container. Opportunities for ImprovementActionsWe should agree upon best practices for employing actions, addressing questions like:
To promote consistency, we might start by suggesting the use of just one primary action, applied only in the ‘page header’ context, with all secondary actions consolidated into an ellipsis menu. This promotes clarity and ensures the primary action follows the section title, identified in the discussion above as an a11y win. It also aligns very closely with what is already shipping. Streamlined Navigation for Drill-Down LevelsNavigating deeply nested levels, such as editing a font size preset in Global Styles, can be cumbersome (e.g., requiring three clicks to drill out). How might we make this process more efficient? Title and Back Button DifferentiationThe relationship between the back button and the title is often unclear:
Users sometimes assume the title describes the back button’s destination. However, the title isn’t clickable or even part of the back button. This issue is most prevalent in the site editor sidebar, but it’s perhaps more confusing in the block inspector, where the back button is sometimes adjacent to a decorative icon with no clear indication of interactivity. Responsive behaviorHow do headers adapt to different container widths? |
|
@jameskoster thank you for your thorough analysis.
From an accessibility perspective, I'd very welcome this pattern as any section of content should be clearly identified by the means of a visible title (a heading). I'd strongly recommend to include this pattern as an accessibility requirement documented in the guidelines. |
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. This expanded further with the addition of Data Views in 6.6.
As we pursue the admin design project, we need to form a consistent way of structuring pages. This includes how we handle page headers, sub navigation, page actions, and content areas with different container sizes. This important not only internally, but for third-party plugin authors too.
What is your proposed solution?
Generally there exists the following main 'types' of admin page:
Amongst these page we find some common elements such as a title, description, primary/secondary action(s), sub-navigation, screen options, pagination, and of course the main content area.
We should design and implement reusable patterns that support these features (plus any other features deemed necessary), also accounting for responsive behavior.
It's worth noting that rudimentary, private page components already exist, and are used in DataViews. These can potentially form a base for any new components.
The text was updated successfully, but these errors were encountered: