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”:

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.

Like this:

Related

Post navigation

50 thoughts on “Twenty Fifteen”

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.

As a counterpoint — from someone who unceasingly pushes back on requests to make _s complex and hard to understand 😛 — perhaps core WordPress hasn’t become complex enough for default themes. By which I mean to say, if the simplest, most intuitive magazine theme some really awesome themers could come up with had “8 folders and 62 files” maybe some really common theme design patterns need more support from core? (back-compat.php, featured-content.php, template-tags.php, widgets.php, and some of functions.php jump out.)

Absolutely! My argument has always been this — let’s make WordPress core better and thus helping all themes, rather than make the default theme too complex for many to understand, help only that theme, and make WordPress (core) look bad in the process. 🙂

I absolutely love the idea of a simple blogging theme with a beautiful design for Twenty Fifteen. It’s like every 5 years we clean house and go simple again. A conscious push to make the default theme simple and easy to read again.

However, I think your idea of taking the latest _s as the start of Twenty Fifteen and adding only CSS is only half the battle.

During that same cycle, there needs to be work done on all the complex, code-heavy things that are in Eleven, Twelve, Thirteen, and Fourteen that should’ve been in core instead of the theme. We did a bunch of work with Twenty Thirteen, building HTML5 and comment/search loops improvements in core, but didn’t get much in with Fourteen and 3.8 unfortunately.

I think the second bit — moving more into core, like pagination as an example — will allow for a simpler theme for Fifteen and really, simpler WordPress themes altogether.

Twenty Fourteen does a few new stuff that all predecessors don’t – the featured contents, the slider, the paginations, the sticky header etc. But none of them is a revolutionary idea or anything that no one hasn’t seen before. Why did Twenty Fourteen need such many files and the complexity to do such common features we see on a magazine site everyday? I would love to see the core making it easier for default themes to implement common features and design patterns.

Like how we use and publish on web sites changes all the time, what people want with WordPress also changes all the time. I love the idea of the next default theme being dead simple but I’m more eager to see the core allowing default themes to have easily common functionalities that Twenty Fourteen required that complexity for.

I love Twenty Twelve and I use it heavily everyday on several test installations on live and local environments. My primary job is to write tutorials about using WordPress, installing plugins, and doing cool things with WordPress. I have found Twenty Twelve to be the best ever theme to work with. I use it to test all plugins, writing code snippets, debugging and what not. Sometimes I would switch to Twenty Thirteen or Something Fishy by Caroline Moore (which is also based on _s) for screenshots.

How I use Twenty Twelve does not represent how other people in the community use and see it, obviously my development environment is not for public viewing so I can afford to be careless about the visual appearance and lack of features in the default theme. But I just wanted to say that as a default theme it acts like a default theme. It compliments the core and even provides examples of how other themes should do things. I think it would be great to see Twenty Fifteen doing the same.

On the outside all the Twenty* default themes are not that complex in my opinion – but under the hood, yeah, so many files and functions…

I personally never use those Twenty* default themes as they are “too simple” for me, but that’s another topic.

What I am suggesting, is to go a different route with Twenty Fifteen. “_s” would bring much of the same complexity under the hood and the “too simple” approach for many users on the outside. I won’t go that way.

Let’s look what we have in WordPress:
– Child Themes
– Plugins

And there we have all we need! Take a strong parent theme – I am suggesting “Stargazer” by Justin Tadlock – and use a Child Theme for that (there are already 6 available for this, at least…!). Include both, parent and child theme as the “default package” but make it impossible (or really hard) to activate the parent – let users use the child theme. Period.
If you don’t want THAT parent theme, just take another one. That easy 🙂 However, I am really suggesting to use an existing community parent theme to show some more community love!

And for the “extra functionality” like we’ve seen in Twenty Fourteen (featured content, slider, etc.): JUST USE PLUGINS for that! This way we only need to maintain one codebase and not duplicate the stuff for every new default theme. We alrady have doubled functionality for the “featured content” stuff in Jetpack and Twenty Fourteen now. That’s not good!

The idea of a CSS Zen Garden-like approach using _s (as suggested by Brian K) is a really neat one. Confining everything to one css file would be an excellent experiment, and could quickly lead to some great default theme inspiration.

That said, part of me really thinks the default theme should be somewhat more feature-rich, not less. Note: I said ‘feature-rich’, not ‘complex’. As I browse around the WP theme ecosystem, I still see wide use of 2010, 2011, 2012, but they almost always look the same — header, sidebar and main content area. I can’t recall ever seeing a site implement 2012 the way it looks in the official demo, for example.

IMO, it really feels like the time to start pushing at a more CMS-centric theme like Basis from the Theme Foundry (http://thethemefoundry.com/wordpress-themes/basis/ ). In order for this to be successful, we’d have to leverage some of the development initiatives already underway with meta fields and CEUX. This probably won’t be possible for 2015, but this really feels like a missing area to me for sometime soon down the road.

Oh, _sis stable! The reason we recommend to not use it as a parent theme is that _s should only be a starting point for the theme you want to develop. Once it is styled and published as a theme, it certainly can be used as a parent theme like any other.

I have to echo @Noumaan’s thoughts. When I teach child theming I normally use Twenty Twelve. I find it invaluable to teach best practice, commenting, file organization, etc… The number of files is a bit daunting though and so when I teach custom theming, I prefer to use a bare bones theme.

The majority of students are there to learn how to make custom themes for clients and thus don’t need all the functionality that one would need in a theme that’s meant for public distribution. Having said that, the “complexity” of the default themes is great for demonstrating to them what can be achieved and also helps them see that building themes is a serious undertaking.

Agreed, part of the purpose of default themes is to be a teaching tool. That won’t change though – _s is filled with best practices! And then there are still previous default themes to look things up, like options pages in Twenty Eleven, or an extended Customizer support in Twenty Fourteen.

We very explicitly removed “teaching tool” as a goal of any of the default themes since 2010. Why? It’s a bonus if it happens, but as a design constraint it created too much disagreement (smart people can have different ideas of the best way to learn WP theming) and made it difficult to show off the state of the art in what a WP theme could do. The only way that we got through analysis paralysis post-Kubrick was to say aesthetically it would be something that I liked, it would be different than the one that came before it, and there’d be a new one each year (so as people didn’t like a given year, it’s not around forever so not as big a deal).

I think someone can, and should, make a theme designed explicitly for teaching, and it’d be a lot easier to do without the added burden of being the default theme that ships with WP for a year.

I love the idea of using a base set of template files (_s, or otherwise), and soliciting style.css submissions from the community. Very CSS Zen Garden-esque. It plays to the power of community that WordPress has embraced better than any other organization out there.

I disagree with Terry that Twenty Fifteen should be more feature-rich. I’m a believer that features belong in plugins, not themes. Themes are styles. They are layouts. White space. Icons. Fonts. They are not features. (And all of those things can be accomplished with pure CSS)

I definitely was’t suggesting that themes implement all of this ‘richness’. Core projects like CEUX and the recent meta fields work should. A Default theme could then leverage all of this and make for a rich site building experience for users.

I like that there are enough default themes now to have a “set,” and I like that they’re at least a little bit diverse. I think Twenty Fourteen pushed the boundaries of the twenties—a good thing. Balancing out that diversity with simplicity and teachability is a good challenge.

Miriam Schwab mentioned Kubrick in her tweet regarding this post. The youngsters among us will remember. 😉 Just like Miriam, I learned theming with Kubrick, and more importantly: without any knowledge of PHP at that time I still learned to trust WordPress to be simple and lightweight enough for me to continue learning and working with it.

TL;DR: A simple, lightweight default theme, preferably built upon _s = way to go.

For the point #2, name it with full name “underscores” a versioned version of _s that the same _s team manage to keep it updated and not afraid to make necessary changes even in the markups, but for each update the changelog will be provided.

Nothing fancy, just something along the line of “Hey if you update from this version to this version, here is what to do, or to be aware of.”

Changelog is what we need. Provide it, and users will know what to do. (Don’t tell them to use git or subversion to figure out — if they were capable of doing that, the reason for this CSS zen thing wouldn’t come up.)

Changelog is something that had been ignored in WP theme community. Look at Twenty-* for example, there are questions in support forum that users hesitate to update just because there is no real changelog provided, they don’t know what’d been changes.

I agree that Twenty Fifteen should be simpler, but let’s make sure that that simplicity extends to style.css, which has also suffered from complexity in recent default themes. Modifying only (or mostly) CSS could easily lead to complicated code, and users are more likely to need to understand the theme’s CSS than anything else if they want to make simple changes.

The plugin-extension model works well; Fourteen Colors is getting a lot of interest by users wanting to customize the look of their site. Perhaps we could take a hint from core and develop a few Twenty Fifteen features in plugins (adding theme hooks where needed). Then, we could look at more modular ways to package features within the theme (while also retaining features that don’t make the cut as user-oriented plugins). If incorporated features are organized well they would be out-of-the-way of new themers or users wanting to make minor tweaks, because it would be easy to find the code related to a particular component.

However, I think the most important point is to improve core support for theme features. This can take the form of adding things we want for the new theme as well as adding things we’ve developed in previous themes. There are a few obvious things that overlap between Twenty Thirteen and Twenty Fourteen that could easily be used in Twenty Fifteen as well. The gallery styles and the use of Genericons come to mind, as well as many back-end things. The Genericons discussion has already come and gone, but updating the default gallery styles (and adding html5 gallery output) would be a user-facing improvement we’ve developed in previous themes that could come into core.

I really like the idea of opening up the design phase via a competition to select the theme designer, and starting with only css. There are a lot of good designers in the WordPress community, what better way to encourage new ideas than a competition. I think that’s the best way to end up with a simple theme, but one that still pushes the boundaries visually, like Twenty Thirteen and Twenty Fourteen.

I’m liking the idea of simplicity + css enhancement route and would definitely like to see the CSS Zen Garden for WordPress take shape.

I would like to add that the default theme should incorporate plenty of hooks and filters for plugins to be employed for adding more features. Twenty Fourteen lacks on enough hooks/filters and its proving a little frustrating to try and get plugins to do what needs to be done to achieve certain enhancements/add-ons.

I totally agree that as default theme the code in the “twenty” series had become too complex.
They are great themes but aren’t anymore something from which the average user can start to customize it’s site or to be taken as an example or a starting point to buili your own theme.

I suggest to leverage the already wonderful template hierarchy: one of the most powerful features WP has and one of the less know and used by the theme developers.
Really I can’t understand why so many themes (often the default ones too) are using so many conditionals in index.php or archive.php when they could use the specific template files.
More template files also mean esier development of child themes since you can override just some of the (easy to read) templates.

Keeping TwentyFifteen simple and based primarily on _S is not a bad idea, but there are a few things that I would like to see added.

I think a widgetized footer is essential, such as from TwentyEleven

I think including the widgetized home page from TwentyTwelve is a good idea

I also look forward to the Twenty* themes implementing some of the key new features from the corresponding WordPress core release. Eg) the theme customizer.

From a design standpoint, it might be nice to build TwentyFifteen in the modern style of “almost flat” with support for full-width headers, footers, and pages. I’d use a color palette that is popular with this style, such as shades of blues and greens.

I do think that the underlying HTML and CSS classes in the theme should be designed to work with the theme design. There are some things that are hard to do with CSS alone when the underlying structure wasn’t designed to support it. Otherwise, I think you are going to need to add lots of extra divs… more than what is in _S today.

For example, most themes have a wrapper that contains the whole page. With the design style I described here, its very difficult to have various sections of that page have different colored backgrounds that fill the full width of the browser. Sure its easy to use CSS to break the whole container to fill the full width, but then it can be very difficult to try to put a max-width on every possible div that has content that should be contained. Factor in that whatever CSS techniques you use should be supported by a majority of browsers and you’ve got a whole lot of work on your hands and some really complicated CSS that can easily break.

In fact, I couldn’t find any themes that were conducive to full-width designs (although I limited my search to bootstrap themes), so I’ve built my own based on _S. As I start to build child themes for it, I find I’m constantly going back and making more changes to the parent to make it easier to style with simple CSS.

I think setting up a WP Zen Garden with the css files being open to the public to use would be a great contribution. If you were to go with the _s as the base theme, then each css submission could be done as an available child theme, with possibly a link back to the developers site. This would perhaps encourage commercial developers to also join in the fun and showcase their unique abilities.

I really like the idea of mostly limiting development to the css, though some appropriate php modifications should not be strictly forbidden. Using _s would be a great way to “show what WordPress can do” as best practice and simple. _s is really polished and combed through. I can’t think of a better way to start.