Already a customer? Please sign in.

Don’t steal my WordPress theme options

by Andy Adams on December 20, 2011 / 19 comments

Here at The Theme Foundry we take the craft of WordPress theming seriously. We’re constantly scrutinizing everything: how we code the themes, what features we want to add, and ultimately what features we need to leave out. While developing our latest theme Duet, we had some passionate discussion about WordPress theme options.

There are some themes that are designed to serve nearly any purpose under the sun – and they contain a vast amount of configurable options on the backend to help you get your site “just like you want it”.

On the other hand, there are those who say themes should have zero (or as close to it as possible) options – the idea being that a theme should “just work”.

At The Theme Foundry, we tend to lean toward the “zero configuration” side. We think requiring extensive backend setup is a turn-off for the average user, so we gear our themes to work “out of the zip”.

With that in mind, I’d like to share a story with you about some lessons I learned while building Duet.

Developing a philosophy

Personally, I’m relatively new to the WordPress theme space. As I’ve read over various WordPress development blogs and news sources, I’ve found that there seems to be a general outcry against too many options. Some of the best WordPress themes take a more minimal approach to theme options. Andrew Nacin wrote recently about “learning to decide” instead of just adding another option.

Death to options!

Such a compelling rallying cry – the thought of a theme that “just works” without a single configuration option seemed like a crystal-clear light to guide the way! I loved the principle so dearly, that during a company discussion, I suggested that we gear our efforts towards eliminating all options:

Reduce all the WordPress theme options!

Talk is cheap…

The team rallied around the idea – we’d take a hatchet to options! At the time, we were working on our most recent release, Duet. Scott’s design was focused on typography and a beautiful reading experience, and it had a number of options to tweak the appearance. Duet’s options page looked like this, fully expanded:

The original

We talked it over, and decided we’d go one-by-one through the options and scrutinize like madmen. Anticipating massive option slaying, we pictured the “after” screenshot to look something like this:

Duet's ideal options screen.

The Ethos of the Logos

Energized behind our new philosophy, we started with some substantial victories in the Logo Options section.

Logo options

We asked: Do our users have any need to modify the alt text of their logo image?

The answer: No. Of course not – the site title works wonderfully as the alt text (this is for their logo, after all). Chopped.

We asked: Do we need an option to toggle the tagline display?

The answer: No. The tagline is only used in the header, and if the user wants to remove it they can simply remove their tagline in their settings. Any more complicated tagline requirements they have can be handled through template modification and/or CSS changes. Consider it chopped.

Boom! Two options down right out of the gate. We were feeling pretty good at this point, and our strategy looked promising. But (you knew this was coming), as we started trying to chop some of our other options, we found ourselves at a bit of a crossroads.

Color me unconvinced

Color options

The headings in Duet were a nifty orange color by default. Knowing that orange doesn’t suit everyone’s taste, we originally included an option for toggling the color of these headings to a color of your choosing, using a hex value and a color picker.

Then, we asked: Is choosing the heading color something a user should have to deal with?

The answer: No – but they need to be able to switch from orange. As theme designers, instead of leaving the user to try to find something that looks nice, we should be be providing some awesome choices that are stunning out of the box. It’s all about making the best decisions for the user, not adding options.

We decided to come up with some color schemes to choose from, which offered a few big advantages:

  • Users didn’t have to mess around with hex color codes, trying to find a good fit.
  • We could add additional colors to compliment the main.
  • We could change the featured banner color (which uses image CSS pseudo-elements to get the banner effect) to compliment the color scheme.

Our slash-and-burn philosophy was starting to hit reality – and believe it or not, I started to feel a little anxiety. I wanted desperately to chop our options down to the bare minimum, and I suggested ways to get rid of the option:

  • Provide tutorials on editing CSS that would show users how to modify their color schemes and select good colors.
  • Include the banner elements as PNG and PSD files so users could make their own.

Drew and Scott quickly reminded me that requiring users to make modifications to their theme is a less than ideal experience. They weren’t buying it, so we kept the option.

So, after our changes we still had an option – but we felt it provided a better experience and prevented the user from having to make a nuanced design decision (that’s our job, after all) – instead, they had 3 lovely choices. I wasn’t thrilled, but I was overruled and we moved on to the next option for review.

The great reversal

Post display options

Scott had included an option to control whether or not the tags would display on a post. If the user checked it, all tags would be hidden from all posts – aha! Something that could be easily controlled using CSS or a small template modification – victory was mine!

We asked: Do our users really need to be able to hide the tags on their posts?

The answer: No. Except that this is one of the most-requested modifications on any of our themes. Some people use tags, some people use categories, some use neither, and some use both. Hiding one or the other is useful to many of our users, and that’s something we’ve learned only through experience. It could be omitted, but we would then have to instruct users on how to modify the templates to remove tags or categories (not easy for the average user).

So, the real answer: Maybe…?

This was a toss-up. The option wasn’t necessary, but experience told us that a toggle option would probably improve the user experience. At this point, I was actually going through a bit of cognitive dissonance.

On one hand, I wanted options to die. On the other hand, I realized that these options were born out of real use cases. I knew this because I handle requests for removing categories, tags and authors on a daily basis in support. Modifying template files is difficult for many of our users, and hiding via CSS is not a very clean solution.

In addition, we sell our themes on WordPress.com – where users are unable to modify their template files, and CSS changes cost extra.

We left it in, and actually added a toggle for hiding the author and categories as well. It was sorta painful, but I was beginning to realize the flaw in my philosophy: It’s not about eliminating options, it’s about having the right options. I know, I know – hardly groundbreaking. It’s been said before by many wiser people than myself. But it’s very easy to get caught up in a philosophy without considering the real goal, which is making a pleasant experience for your users.

Don’t steal my WordPress theme options

And this is why I wanted to write this post – to counter-balance the anti-options, anti-configuration sentiment. It’s too easy to get caught up in a cargo cult – I know I did, briefly. Instead of making a theme either fully-customizable or configuration-free, I’ve realized that the ultimate goal is to add “just the right options” to make the user experience more pleasant. I think everybody would agree with that sentiment – but it’s easier said than done.

We continued through our options page, scrutinizing each one and considering ways to improve. We ended up reorganizing many options and adding a few (crazy reversal, huh?). Here’s what we ended up with, final (left) vs. original (right):

The final result

We actually ended up with more options (19 vs. the original 16). Many of our original options remained, though some were tweaked to be clearer. We added an option to control the drop cap styling on posts, since Duet is all about beautiful typography and we anticipated not everyone liking this aspect. Finally, we added some slider options that are commonly requested on our other themes.

And that brings me to the end of my story, a tale of a developer (and a team) who went from loving, to hating, to having a mutually beneficial relationship with options, all in a matter of weeks. It was a tremendous and rapid learning experience for all of us. We still have a lot to learn, but we’re making strides in providing top-notch experiences with each of our themes.

Enjoy this post? Read more like it in From the workshop.

19 Comments

  1. Isaac Keyet

    Thanks for writing this up. It sheds some light on the thought process that goes into these things.

    I think premium themes are special in the sense that you’re not just buying the theme itself, as it looks out of the box – purchasing a premium theme means you do have a set of requirements out of the box, and customizing the theme is a big part of that. It’s just like buying a shiny new gadget, let’s say an iPad: you unwrap it, marvel over all the accessories, wonder why a dock wasn’t included, then proceed to peruse the tablet itself, giving it a name, changing the wallpaper, re-arranging the home icons and download a few new ones that you know you’ll want.

    But – I still think you can make some options invisible to the users, and just have it “work”. Take, for example, the problem you mention with the use of Tags and Categories. If a user is truly not going to use one or the other, or neither, they’re probably not tagging/categorizing their posts to begin with. It’d be interesting to have the theme detect this, and simply not display that post meta if it doesn’t exist. If their WP install doesn’t contain any tagged posts, why not just hide tags for the whole site?

    Another example would be the Footer section, as depicted above. I get the simplicity of it, and it’s easy to understand – but if no external accounts are added, it should just not show the section altogether. The fields could be compressed into a text box, asking you to enter any accounts you want associated with the blog, all on a new line. The theme could take care of distinguishing which ones should use a dedicated icon, and which ones should have a more generic one (default, included icons could be the ones listed, plus maybe e-mail).

  2. Andy Adams

    Thanks, Issac.

    I completely agree with everything you said – the theme SHOULD work the moment it’s installed. In fact, the Tag/Category/Footer behavior you mentioned is exactly what Duet does (any field that isn’t set is hidden by default). Your analogy to an iPad is good – themes should come functioning on install, but should also be configurable to your liking, since there is seldom a theme that is “perfect” for any given scenario. The difficulty is deciding what options are necessary – some can be cut, but options by themselves aren’t as evil as I used to think.

  3. Drew Strojny

    Thanks Isaac! Some really great stuff in there, thanks for jumping in.

    Just to clarify some more of the thinking behind the Tag/Category options:

    One scenario we were thinking about with those options was the user switching themes, with already established Tags / Categories, that doesn’t necessarily want to show them in the post itself. Manually removing all the Tags / Categories would be tedious.

    The other scenario is a new or existing user that might want to use Tags / Categories in other parts of their site (Sidebar, etc.), but not show them in the post itself.

  4. Kevin

    The first half of your article scared me, but I’m glad you decided to keep the “right” options. Having a few options for commonly changed things is so much easier than messing around with the code.

    Keep up the good work.

  5. johanlm

    I think you are “right on the money” as they saying goes. I do not know how many times, friends, familly and friends friends contact me about basic WP setups and then various theme settings I never heard of.
    The whole “out of the box” concept I think is the right way to go for the “user friendliness” ala “click and go”. Just as long as it’s done right from the start. More advanced stuff they can learn and add later.
    By the way … Duet = 10 of 10

  6. Erik Ford

    Excellent post and I am happy you have added another perspective to the ongoing debate.

    As a premium theme provider, we, too, have been gradually moving our products away from option heavy themes. In fact, we try to “educate” our users to the benefits of creating a child theme, if you truly want to match your the theme to your specific color palette. It’s a bit more work than adding a color picker, but I think the user walks away with knowledge they can apply to another product, whether it is ours or yours.

    On a final note, did you think about using the if ( has_tag() ) to check if the post has tags assigned to them? This is what we do to avoid adding an option to hide the tags.

  7. Drew Strojny

    @Kevin: Thanks, we appreciate it :)

    @johanlm: Thanks for the support! Glad you like Duet :)

    @Erik: Thanks! Yep, we’re using has_tag, but the option is for those people who might still want to hide tags even when they have them (see my comments above).

  8. Andreas Nurbo

    One thing to think about is how much certain options are changed. Do the user need to see all options up front or can some options be “hidden” as not to overwhelm the user.
    This is something I’m thinking about for my plugins.

    I know some use tabs etc to divide the options between different panels but its still a lot of options. Especially if majority of users only change a few on each page, and the edge cases modify most of them.
    I’m thinking of adding a simplify toggle button for my option pages.

  9. Michael Chacon

    Absolutely right. A lot of the options that we see in premium themes are more suited for plugins than the core of the theme anyway. Having too many options/ post types/ functionality in a theme starts to destroy the separation of design and functionality, leaving people stuck with a theme because they added so much information in to the themes custom post types or options fields, that they aren’t able to easily switch to a new sight design without some coding.

  10. Kevinjohn Gallagher

    An adult, thats read the best practices, and made up their own mind on the exact Return on Investment to both You and your Users, regardless of whether that completely comply with what the community have been brought up to believe is unquestioningly the “Truth” that should not be deviated from???

    That won’t go down well at all, but I for one salute you in making something that works for you and your users!

  11. Andy Adams

    @Andreas: I think this is somewhere we need to improve. For example, under the “footer” section, having text inputs for each social site is too much – they can be hidden until the user selects that they want to use each one individually. That’s something we’ll be working on going forward.

    @Michael: Here’s my issue with that: Any functionality beyond the design of the theme is “plugin territory”. But for every plugin you make the user go install, you decrease the ease of use and the overall “experience”. And that’s what a theme should be – a pleasant “experience”, from purchase to installation to completion. Moving essential functionality out of a theme and into a plugin, even when it philosophically makes sense, ends up being less than ideal for the end user.

    @Kevinjohn: Thanks for the support :). I don’t think the community has gone off the deep end of “options are evil”, but I sense the trend is in that direction. And maybe it’s better to trend that way than the other?

  12. Mike Schinkel

    @Andy: Excellent analysis, and I love the reference to cargo-cultism!

    Moderation in all things. Options are bad, of course, until the user actually needs them. Then if they are not there, you’ve just made the user’s like 10x or 100x more difficult.

    It’s unfortunate that the pendulums always have to swing so wide in order to eventually settle in the middle.

  13. Ryan Imel

    Thanks for posting about the thought process you guys went through, it’s very interesting. As long as developers are really thinking about the weight of each added option, the pros/cons of having them around, I think we’re on the right track.

    So much worth chatting about in this post and the comments. Let’s see…

    @Andreas: I really like the idea of a “simplify” toggle button. Particularly with plugins I find myself sometimes thinking, when looking over the options, that I would like to just trust the developer with the best (general) settings for my site.

    @Andy: I wonder if there’s a way to take options which could apply for many themes — in this case, social links that show up in the footer — and integrate with a plugin for them. So if the plugin’s in place the theme will default to those settings and display what’s set, and not even display the theme’s specific settings. I think I’m drawn to liking the theme options plugin because it allows for the saving of that sort of information, particularly when changing themes.

    Also, regarding introducing complexity to users by requiring plugins to work with themes, is it just a matter of user interface and workflow? By that I mean, could something like the footer social links section just have a link that says “Enable social links” that installs and activates that plugin, enabling that section of the options? It’s just an example, but I have to think there’s a way to make that user interaction simple and easy.

    By the way, I should preface all of my opinions by saying I’m just a doofus with zero themes and just as many customers who gets to sit back and be nit-picky about the products that theme developers spend hours and days and weeks building. Despite my various opinions on theme/plugin ideals, I respect the hell out of what you guys do.

    Kudos for the candid thoughts on this discussion, I love it.

  14. Andy Adams

    @Ryan: Thanks for the kind words – I enjoy reading WPCandy daily!

    Something like the theme options plugin is interesting, but the advantage of using common code is only an advantage when the plugin is ubiquitous. And to me a plugin that’s ubiquitous should probably be in core, anyways.

    If we could easily integrate certain plugins to the point of it being a 1-click install from the options page, I think we’d consider it. However, up to this point we haven’t found any functionality that was so important that we felt like investing in this kind of solution. Features are generally important enough to integrate tightly (and seamlessly) into the theme, or not important at all and left to the individual users who want to add the functionality.

  15. Clare Swindlehurst

    Thanks for this Andy – I have a theme for sale at the moment that requires a User guide to talk people through how to set it up, so I’m going back to the drawing board to try and aim for something “out of the zip” as you say. This article has come at just the right time for me as I determine what options are really required, and when I should actually be creating another theme. At the moment I’m trying to have something that is one size fits all!

  16. Mario Peshev

    Pretty entertaining material, I have to admit.

    For your logo edit feature – why don’t you go with the default header option from WordPress core – http://codex.wordpress.org/Function_Reference/add_custom_image_header ? We have implemented it in several themes as a logo editor and have more advanced stuff for body backgrounds and more.

    For the CSS tutoring – I have designed several videos for this but about 30% of our customers group is with little to zero technical experience and this makes it pretty tough. On the other hand, another bright idea you might consider is adding “Additional CSS” box in your theme options so you can create few pages with code snippets for frequently asked questions – some things that few people tend to ask but don’t seem like option worthy. Also, this field could be persisted in the database therefore no updates/file changes would override them.

  17. Japh

    This is a really fantastic break-down of the process you guys went through, Andy. Thanks heaps for sharing.

    It’s so important to have a good rationale behind what you do, and if you’re aiming for the fewest best options, you have to be able to rationalise each one.

  18. JCG

    I would prefer a splitting into “basic theme options” and “advanced theme options” in the backend. So the user would be able to decide whether there are only a few or many adjustment possibilities.

    IMO, that would be the ideal way for serving both unexperienced and advanced users.

  19. Andy Adams

    @Clare: You’re on the right track. If your users are anything like ours, they want something specific and you’ll spend more time supporting and instructing them on how to set things up than you need to if you distill your offering down.

    @Mario: We’ve considered using the built-in header page, but our decision to abstain comes down to 2 things:

    1. 1.) On most of our themes, we’re designing for a logo instead of a header.
    2. 2.) Having a separate page for something essentially under the control of the theme felt unintuitive.

    We’d always prefer to use built-in WordPress functionality, but not at the expense of usability. It’s a tough call in this case.

    @Japh: Glad you liked it. Thanks for reading!

    @JCG: On this theme, I’m not sure where I would make the distinction between basic and advanced. We design our themes to be pretty simple, so if we start wandering into “advanced options” territory, I’d say we’d need to rethink our approach.

    I know that doesn’t apply to everyone, but that’s just coming from our philosophy of theme design: themes that are simple, serve a target audience, and just work.

Comments are closed.