April 19, 2009

I think the problem with WordPress (and indeed all blog and cms platform) themes is that there is a little bit too much doing, and not enough talking. Recently we have had quite a number of theme frameworks, most of which are very good, we’ve had debates about how plugins should pass on styles to the content they add into a theme, and we’ve had discussions about replacing the default theme, with suggestions about what that replacement should be that are entirely contradictory. Ultimately I think what is needed is consistency, not evolution, or even revolution. Themes may be the one place where intelligent design is the answer.

When you sit down to do some serious programming you do several things. You plan your inputs and outputs, design tests to make sure that each function produces the results that are expected in the form they are expected, and plan the overall architecture. As you progress you solve problems and turn the solutions into patterns that can be reused or improved up.

In this way you produce schemes that produce solid and consistent code that is easily readable, understandable, modifiable, and extensible, and this must surely be the goal for themes, and for the way that themes and widgets interact.

If this all sounds a little abstract then don’t worry, it needn’t be. But, this is where conversation and communication come in. There is no benefit in everyone producing their own theme solutions if each solution requires widgets to behave in a different way, and every, and for someone extending that theme to do so in a different way. We need to stop acting and start talking.

Let me give you some more practical examples:

• (x)HTML 4/5 — There are many reasons for choosing one over the other. They don’t really matter. It is more important that a theme, plugin, or widget, can predict the environment it will insert into.
• Widget / plugin styling — It is fine to ask where the CSS should go, but a better question should be how to define what kind of output it is¹, and therefore how all outputs of that type will be structured so they can be pre-styled by the theme author².
• Child themes — Will they be used or not, and if so what do we do about modifying child themes themselves?
• Simplicity versus complexity — What level of knowledge should be required to make changes? Should you have to learn the theme first, or can all themes have a relatively standard HTML base.
• Modularity — How much functionality should be built into a theme in the first place? Should a theme be just the presentation with a lot of hooks, and all the functionality outsourced to plugins that can be easily switched out?.

These are just the points that occur to me on the spot, but I hope you can see that diversity, while good in some cases, can also be seriously detrimental. Consider how much better and easier theming could be for the end users if a little consistency was available.

If WordPress needs to stay balanced at the top of the pyramid then paradigm diversity in the theme space³ needs to be curtailed. I strongly believe that the early days of themeing, despite the fact that its multiple Kubrick rip-offs took a lot of wading through to find the gems, was massively enhanced by so many themes being based on the underlying Kubrick structure. We knew what to expect, how to change it, and more importantly it wasn’t a huge leap to produce our own themes. We need to replace Kubrick soon, but we need to replace it with a consensus, not with the pure weight of diversity.

Footnotes

1: For example, is it a menu element, a styled content block, an unstyled content block, a multiple-post navigation control.

2: It needn’t even be styled by the author, for example a standard set of styles for horizonal navigation should be available as part of a default stylesheet. Given this sort of thing some plugins wouldn’t even need their own CSS.

3: Yes, that is a horrible sentence that drips with the stench of marketing, but it says what I mean so it stays.

  every 1983s, 1s ago, in 0.03s.