It’s no secret that one of the things that I love most about the most recent versions of WordPress is the Theme Customizer (which is soon to be called the Customizer). I’ve talked about it in a number of different articles, some of which include:
- A Guide To The WordPress Theme Customizer
- Modular Procedural Programming The WordPress Theme Customizer
- Writing JavaScript Helpers for the WordPress Theme Customizer
Further, I’ve been clear in stating that I think that as much as I like the Customizer, we’re beginning to see the same problems, but in a different place.
Simply put, I think that we’re disrespecting our customers and damaging the WordPress customizer.
And over the past few weeks, I’ve seen this manifesting itself more and more through various themes I’ve seen, various screenshots I’ve seen, and various other discussions I’ve seen.
Granted, I’m not really one in a position to say what a person opts to do with their own projects, and I’m not particularly interested in getting up on a soapbox (but this is probably going to read like that, so there’s that, I guess) and telling everyone how or why to do something, but I do have strong opinions on the WordPress philosophy and how it directly contributes to developing themes.
As it stands now right now, I think that we’re doing a terrible job of respecting the WordPress philosophy, putting it to work for us, creating happy customers, and leveraging the WordPress customizer for the betterment of the WordPress economy.
Damaging the WordPress Customizer
Since I’ve written my first post on the topic of the Customizer, I’ve also done a number of posts all about the pillars that make up the WordPress Philosophy.
I’ve covered:
- Out of the Box
- Design for the Majority
- Decisions, Not Options
- Clean, Lean, and Mean
- Striving for Simplicity
- Deadlines Are Not Arbitrary
- The Vocal Minority
- The Bill of Rights
I’m not going to summarize everything here because its available both as a page on WordPress.org, and in the linked posts above, but I can distill my point into the following:
The WordPress Philosophy values simplicity, designing for the majority, having features work out of the box, and making decisions over creating options, but implementations of the Customizer are giving users the ability to tweak everything from the font used throughout the theme to the colors of the text and the links that make up the text.
I find this to be in contradiction to the philosophy that WordPress provides, and I think that it actually makes for less opinionated, more complex products than not. And for those who genuinely care about creating better products, improving the state of the WordPress economy (so that it’s not a race to the bottom for pricing), and so on, this works in direct contrast to that.
And we have no one to blame but our own kind.
On Settings Pages
Before the Theme Customizer, there were settings pages. Initially, these were relatively easy to work with (not necessarily because of the API), but because developers were able to add a few options into an area of the dashboard that allowed users to toggle a few options and set a few values.
Then WordPress began to mature and introduced controls that allowed for things such as custom header images, background, and so on. It put more control in the hands of the user – what used to be done via file uploads and CSS was now possible via the Dashboard.
But then developers and those who were working within WordPress for the money more so than the value of creating philosophically solid products began to leverage APIs and features.
The Rise of Options Pages
Shortly thereafter, we then saw the rise of theme frameworks (a phrase that is used in so many different ways that I’m not sure anyone has the same conceptual model than the next person, but I’ll cover that later) that introduced options pages full of tabs, panels, and so on all of which allowed the end user to customize basically every single thing about their site.
If you’ve ever watched the average end user attempt to navigate one of these, you’ve what a usability nightmare this is, and the sheer disappointment that comes over a customer’s face when they see how much work is required to configure a WordPress site.
Just this week, I happened to hear:
I bought this theme thinking I’d be able to change the header text and add some widgets and have it look like the demo.
Instead, the user was faced with a tabbed interface full of image upload panels, dropdowns, input fields, radio buttons, and checkboxes, and so on.
The learning curve was steep, there was a disconnect between what she had seen and what she had purchased, and after spending time trying to make the thing work the way it should’ve worked out of the box, she opted to come back to it later.
But what incentive does a person have to go back to something that frustrates and intimidates them?
I felt bad for her because she had paid good money for something that worked completely differently than expected, and I felt a big angry because it’s stuff like this that’s harming the WordPress economy – it frustrates the user, it gives themes a bad name, and thus it reflects poorly on those who are working within the industry to do the opposite of exactly that.
Here We Go Again
When the Theme Customizer was first released, I thought it was fantastic. “Finally,” I thought “we’re closing the gap between the options that are available to the user and the impact it has on their site.”
That is to say, they are able to see a direct result of their changes.
Unfortunately, we’re circling back to where we started: We’re doing the same exact thing that we’ve been doing with settings pages, but now we’re doing it with the Customizer.
Rather than having a number of tabs and a number of input elements, we’re now creating a vertical, accordion-style menu full of every option possible, and then selling it to customers who are going to be just as frustrated with this new approach as they were with complex settings pages.
Frankly, that sucks. We should be doing a better than that. We have these amazing features and APIs that make it incredibly easy for users to add a header image and change the location of their sidebar, for example, but instead we’re creating designs – some far more elaborate than others – and then giving users the ability to change it to whatever they think looks best.
But if you’ve got a solid team of designers working on your themes, wouldn’t it stand to reason that they know the industry trends, best practices, and have an expert opinion on similar topics (granted, not all – but most)?
If we really want to give customers an experience of “what you see is what you get” when they buy a theme, and stop the disappointment that comes when they first open a theme and see how much they have to do in order to get the theme to look how they thought it was going to look all along, then we need to stop throwing options into the settings pages and into the customizer.
We Are Shooting Ourselves
Ultimately, themes are for presentation and it’s absolutely ridiculous that a person sees a theme that they’d like to purchase because of how it looks only to install it and find that they have to do a significant amount of work to get it to look like what they thought they were purchasing.
That is so backwards.
And the more that we continue down the road we’re on of giving users multiple options over making decisions on their behalf, and the more than we show demos that do not map to the product that the user is purchasing, the more frustrated customers are going to become.
Rather than turning the WordPress economy around with an upwards tick in pricing and quality of products, we’re going to have price the work inexpensively to compensate for the amount of time a customer loses when they’re sitting at their computer navigating the labyrinth of options, pulling their hair out, twisting knobs, cussing at every feature that’s available, and toggling options trying to figure out how to make the product they purchase look like the demo of the very thing they thought they were getting.
We’ve got to do better than what we’re doing right now.
Leave a Reply
You must be logged in to post a comment.