Musings on Customizer as Future Admin Interface

Authored by

There has been a lot of (well-deserved) excitement over Automattic’s Calypso project which largely re-implements the WP admin on WordPress.com as a JavaScript-driven REST API-powered single page application. (Reminder: WordPress.com is a service of Automattic that is built on the WordPress project, which I’ll call “WordPress.org” to differentiate here.) It is great to see what is possible when JavaScript leveraged in this way with the REST API. The improvements to speed and overall user experience are much improved in the new WordPress.com admin interface.

Calypso does not yet have a plugin architecture for extensions, but even when it does, it will be completely incompatible with all existing WordPress plugins that integrate with the WP admin. This works for WordPress.com because it doesn’t support arbitrary plugins and so they have a fixed feature set that they have to account for. This is not the case for WordPress.org, so unfortunately there is no easy path toward adopting Calypso as the next-generation admin interface for WordPress.org.

How can we bring WordPress.org forward to feature a next-generation JavaScript-driven REST API-powered single page application (SPA) admin interface like Calypso, but also support existing themes and plugins in the WordPress ecosystem?

Well, it turns out that WordPress already has an SPA admin interface that plugins and themes already widely support: the Customizer. There is a roadmap for improving the Customizer over the next few releases, but this roadmap does not currently include scope for re-implementing all of the WP admin in JavaScript. Should it? Is this the right avenue for bridging this transformation from PHP to JavaScript? Obviously there would need to be a lot of design changes to the Customizer, including adding more space for controls.

I personally think the Customizer provides a good foundation for bringing us forward. But I don’t know what the community thinks, and obviously implementing this would require buy-in from the entire community. Should we use the Customizer as the foundation, or should we start from scratch like Calypso? I favor the Customizer (obviously) because it is something we have today as a foundation and we have existing themes and plugins already supporting it, and so we can better continue our commitment to backwards compatibility.

4 thoughts on “Musings on Customizer as Future Admin Interface”

  1. I think this makes a lot of sense as a first step forward. As you’ve said, the Customizer has laid a strong foundation and already offers interoperability with themes and plugins.

    Even if the Customizer isn’t the final step (and I really don’t think it will be, I believe we’ll see a greater transformation still beyond this), it makes a lot of sense to approach this as the first step because of the existing foundation, because of the contributors already involved, because of the roadmap that already exists.

    This sounds like an effort worth making, and I look forward to seeing where we can go next.

  2. The customizer is a great tool and the improvements made over the last few releases have been really valuable. I thought I’d hate having menus in there but they’re actually pretty nice.

    I still feel that the customizer excels at its original purpose for tweaking design components. I could see it working it’s way towards functionality like page builders, but it really depends on the nature of the content that’s being edited. It might be too cluttered for blogging or Longform writing, where things like editus or distracrion-free writing are great. And the traditional post editing screen is probably still best for content types with lots of post meta or content that isn’t visually represented.

    For that reason, it would be great if there was some kind of global api – maybe the fields api – which provided a common way to manage content across different editing views, so that plugin and theme developers could build one control and see it work in a few different contexts. That would give us the benefits of the ecosystem without necessarily forcing us down a single path.

    I don’t suppose that’s a simple task though, and wouldn’t know where to begin.

    (sorry for typos, written on my phone)

  3. I’d echo what Nate says above:

    I still feel that the customizer excels at its original purpose for tweaking design components.

    I think that the same could mostly be said for all front-end editing which has always raised two major issues for me that I don’t see a way around:

    1. It encourages editors to focus on how their text looks rather than what it says. It’s essentially antithetical to Distraction-Free Writing. This can lead to things like editors manually adding line breaks and trying to control the text-flow in ways that interfere with responsive layouts. A properly implemented editor-style.css gets nearly all the benefits of front-end editing of body text with none of the drawbacks.

    2. It interferes with people’s mental models of their website and completely falls apart for pages with dynamic content that may appear in different places and different formats (think Archive pages, complex meta-data, etc.)

    There’s a parallel discuss of inline *access* that I’m a huge proponent of and wrote about here: https://mrwweb.com/wp-inline-access/. The customizer actually sneakily has this built-in a little bit with the ability to SHIFT + Click widgets.

    My favorite thing I quote in that piece comes from an article called “The Cost of Leaky Abstractions”:

    If the primary editing interface we present is also the visual design seen by site visitors, we are saying: “This page is what you manage! The things you see on it are the true form of your content.”

    I link to a bunch of articles in my piece that include lots of really smart thoughts on that topic.

    So this is all to say that front-end editing may be great for a five page business brochure site, but I think it fails for long-form and complex structured content.

    Having used a few tools with inline editing, I’ve never really enjoyed them. I worry that for WordPress, inline editing is the greener grass on the other side of the fence.

    I’m really into allowing people to access the ability to edit a certain piece of text from the front-end, but keeping them there worries me. I even think opening a modal text-editor would be preferred.

    Finally, I like the suggestion from Nate to make it easier to create alternate editing interfaces, BUT I worry that this could potentially fragment the WordPress community. At least some of WordPress’s success certainly comes from the transferability of editing skills lower-level users have. Since it’s so common, people choose to use it again. The popularity feeds itself. If logging into WordPress becomes more of an unknown, does that hurt the project long term?

Leave a Reply to Nate Wright Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.