The Planned Obsolescence of WordPress Themes

Last week, I shared a few thoughts on how I think that major updates to an existing WordPress theme are actually more analogous to a new product rather than an update of the existing product.

That is, if a theme is identified by the way it presents the content of the blog, then it stands to reason updating the look and feel of the theme is changing the very thing that gives the theme its identity.

So, from there, it’s reasonable to ask the question: Once a theme’s design is locked in, should it ever change?

Planned Obsolescence of WordPress Themes

Planned obsolescence

In general terms, the lifecycle of a theme is relatively predictable:

  • The theme is launched and there’s usually a level of excitement around it
  • People try it and [hopefully] buy it
  • Some may customize it through child themes or through customizations made available on WordPress.com
  • Time passes and the interest in the theme wains

So how do we keep others interested in using our themes without having them get bored with the way the theme looks?

1. Update Code

Since themes are built on top of WordPress and WordPress is built on top of server-side and client-side technology, it stands to reason that whatever we’re working with right now will likely change within a year or two.

As such, one thing that we can do in order to make sure our themes stay current is to make sure that the underlying code is updated to keep up with the updated WordPress APIs and browser technologies.

2. Maintain It

This is similar to the previous point in that nothing really changes about the way a theme looks, only the way that it’s put together. So in addition to updating the code from, say, previous versions of HTML to HTML5 and from using deprecated APIs to current APIs, there are addition things that can be done such as improved internationalization, accessibility, and minor changes to, say, the typography in order to improve the readers’ experience.

This can be seen in theme’s like Twentytwelve where the overall look and feel of the theme hasn’t changed over time, but the theme has remained updated, consistent, and compatible with current trends.

3. Fork It

All themes are eventually going to hit an end of life. When this happens can be influenced by a number of factors, but the general ideas behind the theme don’t have to change.

That is, let’s say that you have a theme specifically designed to showcase photos taken from a mobile phone while on the go – that is, you have a theme that’s primarily meant to be used via the WordPress mobile app and to be viewed by those on their mobile browser.

Then assume that perhaps the standard screen size becomes larger, design moves from skeuomorphic to flat, and/or general color trends change as well. We want to make sure a given theme continues to exist but with a look that remains consistent with current trends.

This can be achieved by forking the existing theme, maintaining the previous version, and carrying the new version into the major updates.

There Could Be More

Even though I think the above three points can go a long way in helping others want to continue using a theme, there’s ultimately nothing that can prevent people from changing their tastes. It’s part of the reason we buy new clothes, new devices, new cars, and so on – sometimes, we just need to mix up the way something looks.

To be clear, I’m certainly not implying that we need to try to lock users into themes through the use of advanced features (that really belong in plugins) nor am I saying that we need to introduce more and more functionality into a theme in order to keep the users’ attention.

Instead, I think it’s more important to lock in a relevant design, modern code, and WordPress compatibility and then plan on continuing to release more relevant, updated themes in the future recognizing that themes can’t last forever while simultaneously keeping the same design that it had when it was first released.

This is essentially planned obsolescence of WordPress themes and the more comfortable we are with admitting that – as is true with so many other products – the less restrictive it feels to think about maintaining a theme forever.

9 Replies to “The Planned Obsolescence of WordPress Themes”

  1. I think one point that could be added that might be relevant is the design of the theme. Web design trends tend to drive the theme industry. People don’t care about the code or what it does, they want shiny and pretty. So updating or re-skinning a theme might also be helpful.

    1. I think one point that could be added that might be relevant is the design of the theme. Web design trends tend to drive the theme industry.

      This is true. I think it’d be easy to be a bit more dismissive and say “why couldn’t it be the other way around,” but the truth is that I can’t think of a good reason why it couldn’t, you know?

      Themes could drive newer features. Look at what’s happened with some of the other new blogging platforms that have come out, and then see how they’ve impacted some of the larger journalistic sites.

      For now, though, it’s the exception rather than the rule, I guess.

      So updating or re-skinning a theme might also be helpful.

      Oh I definitely think it does – I just don’t think giving it the same name as its predecessor is the right thing to do.

  2. I think planned obsolesce or “theme retirement” is a really good option for theme shops. Big updates (like converting a theme to be responsive, or using new development techniques like icon fonts) is sometimes really difficult to do in a way that won’t break child themes.

    We’re using a mix of the “Fork It” and “Retire It” options at DevPress. The “Cascade” theme will become “Cascadia” (for example) and we’ll make the new theme available free to all customers who purchased the free version. Less popular themes will just be retired as we add new themes to take their place.

    This is a lot harder to do in the wordpress.org repo since you’re not able to retire and old theme and set up redirects to the new one. You also can’t push out any critical updates for an old version if it does get retired. I’ve generally used the “Update Code” option there, but it’s not an ideal solution.

    A lot of other theme shops also use the “retirement” approach. WooThemes and Array.is are two in particular I know of.

    1. I think planned obsolesce or “theme retirement” is a really good option for theme shops. Big updates (like converting a theme to be responsive, or using new development techniques like icon fonts) is sometimes really difficult to do in a way that won’t break child themes.

      Bingo. I think that if you wanted to have a, say, responsive theme for a theme that already exists, either use a child theme to introduce the functionality, a plugin to handle it, or just an ‘amped up’ (eh, though I’m not a fan of that word, really) version of the theme in order to maintain compatibility and adoption with existing and new customers.

      we’ll make the new theme available free to all customers who purchased the free version. Less popular themes will just be retired as we add new themes to take their place.

      I love this.

      This is a lot harder to do in the wordpress.org repo since you’re not able to retire and old theme and set up redirects to the new one.

      Agreed. This is something that I haven’t thought of in terms of .org – I don’t have anything there – just have one in .com with plans to eventually release more.

      And you’re right – Woo and Array are two others that do a good job of this.

  3. Themes will always reflect the current trends in web design, so they will sooner or later be obsolete from a design point of view.

    Certain types of themes, like for example those with a two column blog layout, remain popular. So forking the original theme and creating a theme with the same vision, while having a refreshed design, updated code and maybe a couple of new features makes sense.

    Other themes have designs that were popular, but that are now out of date. An example would be themes that use images and textures heavily. For those it makes sense to retire them without creating a follow up theme.

    Once a theme is launched, it is important to fix bugs and make sure that it uses no deprecated WordPress functions. But it is important to keep the HTML and CSS largely the same, so that users’ customizations are maintained. This is why Twenty Twelve still uses the hgroup tag, although it is obsolete.

    But I would be hesitant to add new features to existing themes. It makes for example little sense to migrate the options from an options page into the Customizer for an older theme. There is little to benefit from this and it will only confuse users (where did my options go?). Updates should not be a surprise to users, so there shouldn’t be too many surprises when they do update.

    This prudence should also apply to theme names. If the initial theme is called Awesome, and the fork is called Awesome 2, this indicates a kind of continuity. So unless you ensure some kind of migration plan from the old version to the new one, choose a new name.

    Certain developers are really attached to names, and want to benefit from the success of the old theme and use the name to “migrate” some of that success to the new theme. I’m of the opinion that names largely don’t matter. Choose a name you like, if the theme is good and your marketing is adequate, the theme will be successful no matter what you name it.

  4. I believe Themes “retire”, no matter the intentions from the developer, it has a lifecycle of its own.
    And the proof is in the WordPress Theme Repo, there’s a wast amount of Themes no one has downloaded for years.

    1. And the proof is in the WordPress Theme Repo, there’s a wast amount of Themes no one has downloaded for years.

      Agreed and it’s a shame that they just sit collecting dust, too =T.

  5. I think you can achieve a balance that allows you to keep a theme relevant with minor cosmetic updates without losing it’s identity in the process. In fact, I would contribute subtle iteration on older themes to the longevity of several themes in the Array collection. Slate and Pocket, for example, are both over 2 years old and have received many updates over their lifespan. Some of those updates have been cosmetic treatments (tweaking typography, padding, details) to keep them in line with not just the code quality but also the overall aesthetic quality of our collection. I’ve found that the Array user base has always been excited about getting relevant aesthetic treatments here and there and rarely do we see any kickback.

    Another thing to consider here is user feedback. Once a theme has been around a year, two years, almost three years, you gather a lot of useful feedback about it via support questions and general inquiries, and I think it’s prudent to iterate upon this feedback. In some instances it may be more beneficial to you and your users to iterate instead of retiring or forking.

    Surely you hit that point where a theme simply isn’t worth updating, structurally or cosmetically. Sometimes it just doesn’t serve the purpose you initially created it for, and that’s ok. As Tom suggested, tastes change, just like styles, trends, preferences and needs. In the past when we’ve retired themes, we still try to make the final version available to users who still might be using it. This allows them to take over where we left off.

    1. I think you can achieve a balance that allows you to keep a theme relevant with minor cosmetic updates without losing it’s identity in the process.

      Definitely. You’re someone that’s able to pull it off. There are others, too, but they’re more rare than not, imho.

      In some instances it may be more beneficial to you and your users to iterate instead of retiring or forking.

      Agreed.

Leave a Reply

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