Matt Wiebe on WordPress, design, and tech stuff

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.

Mobile

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.

Performance

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.

Architecture

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

Patches Welcome

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. ↩

Like this:

We are entering a new era for independent writers and publishers to embrace depth and quality, and WordPress.com is committed to empowering these creators — not just through tools and services that make the most of these evolving formats, but through community, distribution, and new ways to have your best work seen by millions of people across a wide range of diverse tastes and topics.

I’m really excited to have the Longreads team at Automattic. WordPress.com has been steadily getting better at showcasing fantastic writing from the millions of blogs we host, but this is going turn up the heat.

Like this:

Although I slung some HTML back in the early Netscape 1 days1, I really got going as a web designer/developer2 back in 2005. These were the heady days of early web standards, with Doug Bowman and Co.’s spiffy Blogger redesign and new, standards-based templates pushing forward the state of web design.

In 2005, Internet Explorer 6 was already four years old. To put that into perspective, Chrome has only existed for just over five years, and Mobile Safari for nearly seven. And today, IE6 is finally dead, at least in terms of being supported by Microsoft. I was longing for this day nine years ago, little would I have ever guessed that it would still be hanging on in some parts of the world.3

In 2005, IE6 was the bane of my existence. People today sometimes joke that Firefox is the new IE, but they probably weren’t around for the old IE.4 The funny thing is that IE6 was a really good browser when it was released, but Microsoft abandoned it after crushing all other browsers, finally releasing the only-marginally-better IE7 a staggering seven years after IE6 was released and an entire generation had been scarred by IE6’s quirks, bugs, and outright non-support.5

So, pouring one out for IE6. It defined a few generations of web design, from great initial release, to domination and stagnation, to its refusal to just go away. Probably nothing else has ever united the web design community like a hatred of IE6, and let's just hope we never have something with that kind of a stranglehold on the web's progress again.

Like this:

Like this:

Writing every day is hard. You have to carve out the space for it. You can’t just try to fit in some writing when time’s available–you have to dedicate time to it and structure everything else around that.