The Customizer is great. I’ve been working in and around it to offer site customization features to our WordPress.com users since it launched with 3.41, coinciding with when I joined Automattic on Team Custom. We’ve especially used it to build great tools as part of the Custom Design upgrade, but as we’ve pushed the boundaries of what awesomeness we can unlock for our users, certain aspects of the Customizer have started to create roadblocks for us. Some of these are addressable, and some probably aren’t.
The Customizer doesn’t work on a phone/small screen. Anyone who thinks this isn’t a dealbreaker is just wrong. The UI was designed for the desktop web. This could possibly be addressed in core, but it will require a pretty fundamental rethinking of the interface.
The Customizer can get really slow. This is partly because of its two-requests-to-load model: one for the
customize.php app, and one for the frontend XHR that gets injected into a preview iframe. Any slowness on your server is multiplied x2 since there are two requests that happen serially.2 We’ve seen this hit up to 60 seconds on WP.com sometimes3, with similar reports from WP.org users on underpowered hosts like GoDaddy. Some performance work could probably be done here to start fetching the frontend sooner in the
customize.php load process.
Speed could possibly be better served by a more fundamental rethink: what if the user wants to start customizing from the frontend of their site and clicking Customize just transitioned you seamlessly into a customization mode via an already bootstrapped, frontend customizer app? This actually has some serious UX considerations I’ll touch on later, but the big advantage for performance is that you’re not throwing away a perfectly good DOM to get the Customizer up and running.
Speed will also be hampered as more things are put in the Customizer. Putting Widgets in there in 3.9 is a great example of this: it’s made Widgets better, but the Customizer worse. As more things are added, speed will suffer, not to mention the UX cost of dumping so much in there.
Uncanny Valley UX
You can enter the Customizer through wp-admin or the frontend of your site via a Customize link in the adminbar. In both cases, the transition begs the question: am I still where I started? Is this admin, or my site? I believe that we should optimize for the frontend flow, where the app is bootstrapped and the Customizer becomes an editing mode you can seamlessly enter. Frontend editing for appearance.
WP Tunnel Vision
One thing we’ve seen in our user testing is that users (especially new ones) don’t care about or really understand the distinction between themes and the things you can do to customize them. They just want to get their site looking the way they want it to look. Therefore, the best customizer UX would blur the line between themes and customize-able options, freely allowing you to preview different “designs” (themes) while then tweaking that theme’s options. The Customizer’s current architecture would make this impossible, as the Customizer “app” itself must do a full refresh for each theme previewed, kicking off the slow 2-request cycle.
The Customizer is the first true JS-driven feature in core.4 It reimplements a bunch of Backbone internally, since this was a release before Backbone made it into core. It’s also a JS-driven app wrapped around a PHP-only public API,5 which is I guess about what you’d expect from an early WP foray into something JS-driven. But this fundamental PHP dependency makes it basically impossible to account for a seamless switching of state while changing a previewed theme: a full page reload has to happen. If the Customizer is going to be awesome, it needs to a seamless way to customize how your site looks – themes vs theme options are just implementation details.
Also, looking forward, the Customizer itself should be a client app of WP-API. Everything related to site appearance should be an API call away, rather than the tightly coupled thing that is the Customizer. This will open the door for, say, a native Customizer on Android or iOS or some other platform that doesn’t exist yet but will be important.6
Some folks might be reading this and wondering why I’m not trying to contribute this vision to core. ‘dI love to, but I don’t think it’s possible architecturally, and particularly not in a backwards compatible manner. This is certainly a case where the optimal use-case on WP.com (new user signup, pre-picked list of themes) may not line up with the best user experience for core users. I might be wrong about this, thus this post. I would genuinely love to be wrong, but I’ve worked with the Customizer extensively over the past two years and I’m pretty sure I’m not.
- Actually, 3.4 dropped on June 13, 2012, but we launched the Customizer for WP.com users on May 17. ↩
- Also, since the preview iframe just gets the frontend request injected upon XHR completion, any browsers’ optimizations to do things like prefetch resources like images or DNS entries before the page has even started rendering are nullified. The frontend also tends to be the more resource-intensive side of things, which compounds the problem since it’s loaded last. ↩
- Obviously there are issues for us to address here, but the previous footnote contains some gotchas that can’t be addressed in the current architecture. ↩
- As in, without JS, it just doesn’t work. Until then, everything else in core admin worked with JS disabled. ↩
- Many aspects of the JS API are “public” in the sense that they’re not hidden inside a closure, but they are not documented anywhere on the Codex that I’ve seen. I’ve even spoken about this. ↩
- Maybe I will customize my blog from my fridge. ↩