In 6.0 I am hopeful that we’ll be able to provide users with access to post and page editing directly in the Site Editor. There have also been suggestions of adding media management, menu management, and more.
In order for this to be a success we need to design quick and easy pathways for users to access these key site management areas.
The current menu system is sub-optimal because a click is required to open it. This means that to go from editing one template to another involves three clicks:
A permanently-visible navigation might work better.
Enter the Dock 🚢
Anyone who has used macOS (and most mobile OS’s) will be familiar with the concept of the Dock – a row of icons that provide quick access to applications.
Thinking about WordPress as an operating system, it may make sense to introduce a similar concept to the Site Editor. Our dock would feature applications for managing content, media, templates, styles, settings, and so on.
The interface for core apps should reuse shared componentry, and moving between them should be a fluid experience. Plugins might have more freedom.
Here’s an example of how a dock would enable me to move quickly from editing my site home page, to my index template and back again, all in just a few clicks.
Much like the macOS dock, it might be fun to allow folks to control the dock position and style:
Building such a system in to the Site Editor seems preferable, but perhaps it would need to be implemented in wp-admin first. There are likely trade-offs to both approaches. Luckily I think that each would work work well from the design perspective.
It goes without saying that these are very early explorations, and no doubt 6.0 will ship with something entirely different. Nevertheless it’s fun to explore and share in the hope to inspire bigger and better ideas.
Last month I shared some concepts where “global” site elements could be managed in a dedicated area of the UI. In this post I’m expanding and refining those ideas a bit in an effort to explore the broader viability.
If global entities like styles, templates, and navigation menus can be edited in the Site Editor, then it seems feasible that folks may want to manage other parts of their site there as well.
The Site Editor was designed mostly to handle presentational things like posts, styles, and templates, but non-visual entities like users or settings need further consideration. Along with general content management, these are the kinds of things that I concentrated on here.
During these explorations two key UX requirements emerged:
When a management view corresponds with something that could be edited visually, a direct and intuitive pathway between editing and managing should exist
Since the lines between managing and editing can sometimes blur in the site editing context, a distinct visual language should help users orient themselves in the experience.
As is often the case with these things, pictures speak louder than words, so here’s a quick demonstration of how I envisaged a user zooming out of the editing experience to find access to management areas:
The (W) button in the Editor acts as a pathway to the relevant management view. The dark colorisation of the button creates a visual hint towards the nature of the destination and helps to conceptually separate management and editing. Clicking the preview window takes you back into the Editor.
This pattern and design language satisfy the two points outlined above.
Is it a template? Is it a category? No, it… doesn’t matter
As yet we’ve not come up with any elegant pathways to edit entities where content and template overlap.
For example the “Posts page” in WordPress is presented (somewhat misleadingly) as a “page” in the backend, but always redirects to a specific template (not the page template, notably) when viewed on the frontend.
Similarly things like post categories have a content element – you can add a custom description – but right now you can only edit the archive template agnostically. It should be possible for folks to edit and create templates for specific categories without having to understand the technical cruft going on beneath the surface.
We can use the pattern above to contextually surface previews (and therefore editing access) on the relevant screens. As an example, here’s how I might edit a post category:
From this management view it is possible to invoke an instance of the Editor where you can customise the relevant content and template simultaneously. In this environment you might also be able to create a new dedicated template for this particular category.
The Finder-inspired columnar navigation creates the hierarchy of the drilldown pattern we explored in the past, while still providing direct access to the top levels of navigation – something the original drilldown lacked. If this feels like too manycolumns, tabs could be used for filtering instead, and the primary navigation could collapse down to icons as you navigate deeper in to a section:
But this doesn’t scale down quite as well to mobile devices. At this point it’s worth repeating that these are all very rough concepts…
Still, they hold up quite well in other areas of site management, and feel aligned with the idea of WordPress being an operating system for the web.
Making quick edits to media meta is easy to imagine, and this pattern would translate well to other management areas. I can see a lot of value in being able to update things like publish dates, authors, titles, and so on, without launching the “full” editor.
This hybrid management / preview screen is extremely useful when working with particularly complex menus that include lots of nesting.
Such menus get very tricky to directly manipulate on the canvas, but you can always click the preview to zoom in and do so if desired.
Templates, Styles, and settings
The template management above view is simply a dark-styled interpretation of the one we’ve already implemented for 5.9. A toggle to view the templates in a mosaic configuration (using the preview component) would be a nice enhancement that continues to build on the zooming metaphor.
Likewise, Styles use the same panel that is shipping in 5.9. A mosaic of curated templates in the preview area could provide holistic feedback on style adjustments.
Visual settings like the site icon need to live in the Site editor. Options such as front page settings are also integral to the site editing experience. Folks shouldn’t have to go all the way back to wp-admin to do this. Once again the preview area adds value by clarifying the visual component of these options.
I’m not sure what the next step is here, but I’m hopeful to see some of these items worked on for 6.0. #36667 and #37001 seem like good candidates to explore further.
Today I begun exploring ways to refine the contents of the template inspector for #36951 and stumbled across the idea of visual revisions. I’m thinking it might be neat to have a way to browse through past versions of a document in a more visual manner, similar to Figma.
Since revisions are just stored HTML, it doesn’t feel like a huge leap would be required to achieve something like this.
In addition to features like Reusable Blocks a number of other global concepts emerge in the Site Editor:
And yet we lack a centralised area in the UI in which to manage these things. Consequently there is a lack of clarity with regards to whether a setting is local or not. For example Global Styles appears on the same plane as block settings.
As a part of #36667 I’ve been ideating on high level design options to improve this. In particular I’m drawn to a left-hand panel with an inverted color scheme as a home for features that are global in scope. The icon column is a common design pattern for adding layers of navigation that we see in software like Slack and VSCode.
One reason I’m particularly excited about this concept is that it provides an intuitive way to navigate to (and edit) your posts / pages in the site editor, something that as yet has proven tricky to get right.
A subsequent idea emerges that in the far future it could be possible to manage posts and all manner of other WordPress functionality here:
Until then, this feels like a promising idea for the Site Editor. Follow along in #36667.