Re-aligning where we are actually heading (Questions about "the great unification")

[fabiankaegy]

Over the past few WordPress release cycles, we have spent tremendous effort moving the site editor forward and shipped an impressive number of features/enhancements. The site editor feels much more polished and is really coming along nicely.

I think this would be a perfect time to come together and re-align ourselves on what our goals actually are / where we are going.

@mtias shared some wonderful thoughts about a possible future for the WordPress admin experience and in the Phase 3: Collaboration posts on the make core blog. There also is The great unification tracking issue, which aims to track some of these efforts.

What I feel is not covered in these overviews, is how we will actually get there. Is our goal for the site editor to eventually become the new admin experience of WordPress, replacing all of the other areas (starting with the other editors?)? Or what do we envision the future of those other areas to look like?

In a lot of recent conversations (like this example), it seems like that is the unspoken goal we are moving towards. And at the same time, the edit-post package seems to be getting far less attention currently, which also points towards that conclusion.

I want to be clear here. I don't have an agenda here. I don't think if we choose for the site editor to replace the rest of the WordPress admin that has to be a bad thing. In the end, these are technical details that don't really matter as long as the UX is clear, understandable, and extensible.

I just think we are all better off and more focused on the right thing when we know which approach we are taking to get to that end state 🙂 And if that is the goal we can all focus on enhancing the site editor with all the things it would still need to get to that state instead of focussing on other means such as introducing template previews in the post editor etc.

I for one know I feel I'm lacking clarity on what the current long-term vision for the great unification actually looks like. Which is why I wanted to start this conversation :) I hope it resonates with others. (This discussion was inspired by a twitter thread with @ndiego and conversations with @aurooba)

[mtias]

For many technical reasons, the site editor package as is today won't be the way to approach the general admin redesign, at least not without modifications. So far the site editor has been a good place to develop some of the main concepts and design primitives (interface skeleton, navigation, frame, etc) while introducing features like the wayfinder/commands to jump to different areas without reloading sessions, but all of this within a confined use case in mind around design and content editing.

There's no further outline on end state because we need to approach it comprehensively from the scope of phase 3, which has not been developer further yet. In broad terms, we would need to identify how to lift the UI shell and its packages globally, define the frame area purpose for sections without preview and with backwards compatibility considerations, approach the mechanics of the main menu IA and user personalization, and so on. Given the nature of the post and site editors, SSR concerns have not been relevant so far, but for the entire admin those considerations need to be addressed in some capacity.

Workflows will also give us a tangible anchor to start mapping these better.

[fabiankaegy]

Thank you for sharing that insight :)

The area where I currently still have the largest open question is what approach should be taken for the other user roles besides administrators. They have not yet been exposed to any of these new updates that were made in the site editor for the last few releases because it is for admins only at this point. At the same time their experience has gotten more confusing when it comes to WYSIWYG editing because the post editor doesn't put their content into perspective with the actual template used. And every time this topic gets brought up like in #27847 and #50857 the great unification is mentioned as a reason for not introducing such a mode in the post editor because it will get absorbed in the site editor at some point.

And if that is not actually going to be the case, I worry that even in the interim we shouldn't focus on bringing those other user roles into the site editor when in the end that won't be the long term solution. Because that kind of back and fourth will lead to more confusion.

(I might also be missing a lot of nuance here and be oversimplifying it. Just sharing my thoughts and worries :))

[mtias]

It's possible to visualize the template from the post editor flow already. The work on #50857 should help us improve how that works. The next steps are to leverage the template structure to convey in the normal editor the relevant elements that an author can modify (for example, title, featured image, content) and show them in the canvas.

[SaxonF]

@fabiankaegy replying here instead of the post template issue.

I see two parts to this discussion which intertwine somewhat.

Is our goal for the site editor to eventually become the new admin experience of WordPress

This is the first which @mtias answered above.

The area where I currently still have the largest open question is what approach should be taken for the other user roles besides administrators. They have not yet been exposed to any of these new updates that were made in the site editor for the last few releases because it is for admins only at this point. At the same time their experience has gotten more confusing when it comes to WYSIWYG editing because the post editor doesn't put their content into perspective with the actual template used.

This is the second which is whether site editor and post editor can/should co-exist or whether we should unify which I can talk a little bit about.

The main goal of the great unification post and the work it outlines is to reduce the number of concepts and environments a user has to learn when picking up WordPress (aka simplifying our system). As I mentioned in the post, I see two major points of confusion/complexity right now. The first is around overlapping block types which we are beginning to address in 6.3 patterns/library work. The second is around overlapping and diverging editor experiences which you touch on.

I see a future where there is one "WordPress editor" that can adapt to different contexts and roles and set the right default settings. For example, if your entry point into the editor was via the posts list, we hide the surrounding template by default, allowing you to toggle it on when needed, for pages the opposite is true (template toggle is listed as milestone 3 in unification post and you can see an outdated video below).

template-toggle.mp4

I don't think this would be a particularly controversial opinion, it benefits the user as they only have one editing experience to learn, and it benefits core from a maintenance/velocity perspective. What is more challenging is the pathway towards that point. As Matias mentioned above, building out the site editor as a separate package has given us a space to explore these concepts in isolation. We're now at a point where we can think more deeply about how to unify. Introducing the ability to create, modify and publish pages from within the site editor coming in 6.3 is a good start, even though it comes with some added duplication, but for that to be useful to more people we need the editor to be accessible to different roles. Greater permissions control is something that would fit nicely into phase 3, and that should include who can access the site editor and in what state. There are plenty of other gaps between editors we would also need to close which we can do over time.

Based on the above, my response to the template issue is that I would personally prefer to focus on opening up the site editor to more people vs introducing more template features to the post editor.

The site editor is really starting to take shape, and I'm excited about all the upcoming technical, design and strategic discussions we need to have to unify editing experiences.