Over the last 18 months I worked on three default themes, Twenty Twelve, Twenty Thirteen, and Twenty Fourteen. Each project was a little different from the other, and on each project my role differed too.
Twenty Twelve was initially designed by Drew Strojny, with Lance Willett creating the templates, leading the project and herding volunteers. It wasn’t ready for WordPress 3.4, but was released with 3.5. I joined them in the 3.5 cycle I started helping out with testing and bug fixes.
For Twenty Thirteen, I was the main developer. Joen Asmussen designed the theme, and it was my job to take his mockups and make them work. Lance was again leading the project, reviewing and committing fixes after the theme was initially introduced to Core.
We took a different approach for Twenty Fourteen, where we ported over an existing theme, Further, designed and developed by Takashi Irie. Lance’s role stayed the same, while Takashi took on a more active role in bringing in fixes, and I reverted back in a more supporting role like in Twenty Twelve.
When we look at how the five Twenty themes were created, we can roughly categorize them in two approaches, “start from scratch” or “use an existing theme”:
- Twenty Ten was ported over from Kirby.
- Twenty Eleven was ported over from Duster.
- Twenty Twelve was designed as a default theme.
- Twenty Thirteen was designed as a default theme.
- Twenty Fourteen was ported over from Further.
Time consuming development
When I started working on Twenty Thirteen, I was asked to use Twenty Twelve’s code as a starting point. It had been thoroughly tested, vetted by the Core team, and was supposed to keep development time short. Except it didn’t. Twenty Twelve was developed to be Twenty Twelve — not Twenty Thirteen. I had to spend a significant amount of time rebuilding it to fit Twenty Thirteen’s design requirements.
We had an ambitious schedule with Twenty Thirteen to make sure it was releasable with 3.6, and I was so excited about the opportunity to work on it, that I actually started working on it, before all the mockups were in. In hindsight, I’m glad I did, because I am not sure we would have been able to introduce it to Core in the robust state that it was in, otherwise.
Twenty Fourteen presented a different set of challenges. Using a pre-existing theme promised to be more time saving than creating a design from scratch. After all, we had a finished design, and the theme was already working on thousands of sites. But it didn’t save us time.
Further was based on a (by then) outdated version of
_s, that didn’t see a lot of the improvements of Twenty Thirteen that we’ve been bringing back. We had to put in a lot of time and effort to bring Twenty Fourteen’s code up to Core standards, while not breaking the existing design. A balancing act that cost us a lot of time.
When we look at the ticket graph of the Bundled Theme component in Core Trac for the relevant time, we see how the majority of development for Twenty Thirteen happened within the first six weeks after the initial Core introduction. We released it on WordPress.com towards the end of April, and just ended up having to fix edge cases as we went along. With Twenty Fourteen we were not able to do that. Since we were busy remodeling it under the hood, the majority of testing and breaking happened towards the end of the cycle. We also didn’t release it on WordPress.com for “beta testing” until two weeks before code freeze.
Code-heavy and feature-rich
Another trend that can be seen over the last five default themes, is an increasing complexity on the code level to make the designs work. This is problematic in a variety of ways:
- It makes Core look bad, if a default theme has to filter Core output, or define its own template tags to make it work.
- It might serve as a bad example for beginning theme developers, if as a reult they learn it is okay to have ten files of compatibility code.
- Users who’re looking to make a small tweak in their theme might have a very hard time doing so.
- Twenty Fourteen consists of 8 folders and 62 files – not easy to grasp, even for some experienced theme developers.
Andrew Nacin has been a big advocate for simplicity in default themes. He helped us make Twenty Thirteen slimmer and better, even though it meant making some hard cuts on features that were dear to us. Unfortunately that didn’t really happen for Twenty Fourteen.
And I do agree with him. Default themes have become too complex, and we should try to make them easier to understand again. Yes, this comes from the guy who made Twenty Thirteen complex and hard to understand. :)
A simple Twenty Fifteen
I think it would be great if we could combine the two approaches, start from scratch and use an existing theme, for Twenty Fifteen. Let’s create a theme design from scratch, much like Twenty Twelve and Twenty Thirteen, and have it be based on
_s, as the pre-existing theme.
But most importantly: Let changes only be in
style.css. That’s it! No additional functionality or bloat. If anything, we take unneeded code out. This doesn’t mean it can’t look good. It doesn’t mean it will be less awesome than its predecessors. CSS is a powerful tool, if in the right hands.
We have plenty of time until we have to deal with Twenty Fifteen development. Enough time to start a competition, for example, and ask theme designers to send in their
style.css files with what they think the new default theme should look like. Enough time, to come up with a great design. Enough time to do it right.
Working on Twenty Thirteen, I wish I would have been able to use
_s. Unlike Twenty Twelve, which was a finished theme, a starter theme is meant to provide enough of a foundation to not completely start from scratch, but not too much of an opinion, that would force developers to tear down before building back up. I’m sure it would have saved me a lot of time.
Now I know that
_s is not a WordPress.org project, but consider this: Four of the top six contributors to
_s have had major contributions across the five Twenty themes.
_s is closest to what has been vetted for default themes previously, and the leading starter theme for WordPress.
In the spirit of iteration and continually improving, I really think a default theme based on
_s with very minimal changes is worth trying out.