Notes from “Patterns in Theming”, Richard Carter’s talk at Front Row Conference
Here are the notes from my talk at Front Row Conference, with a title of something between ‘Design/CMS integration‘ and the slightly catchier ‘Patterns in Theming‘. Please do contact me with feedback and ideas, and I’ll try and reply to every email I get, and post any relevant annotations here.
Introduction
The above are hopefully fairly self-explanatory: my Twitter username is @RichardCarter, and I changed my mind on the title.
What is theming?
- Integration of (X)HTML/CSS design in to a particular software
- WP
- Drupal
- Magento
- OpenCart
- PrestaShop
- Inhouse CMS
- A ‘theme’ is a package that allows the software to function with a given look and feel
- Themes are also called Skins, Views, Templates
- So, we’re going to cover a few patterns – repeated ideas – I’ve come across in my time as a themer, and what I’ve found works, and doesn’t work
Pattern 1: ‘Base Themes’
- A ‘theme that covers all the bases’
- What is a base theme?
- Encapsulates all of the style and markup, etc, that the software needs to function in its entirely
- Idea is that you over-write the base theme with changes you want to make
- Each aspect of functionality is styled. E.g., shopping cart, checkout process, category pages, product pages
Base Themes are ‘convenience vs overhead’
- Having to effectively load 2 themes is (very probably) more computationally hard
- That’s a problem for developers, not themers ;)
‘Base theme’ implementations in the wild
| Software | Base theme implementation |
|---|---|
| MediaWiki | Common.css; a stylesheet which provides style for common elements across all wikis – userbars, toolboxes, etc. MediaWiki also has common JavaScript files. Not really a true ‘base theme’ as |
| WordPress | Starkers (see starkerstheme.com) ‘base theme’; there are others available. Heavily stripped back WordPress theme you can create sub themes upon. |
| Magento | Base themes the ‘truist’ base theme implementation I’ve seen; mark-up, style and behaviour can all be overwritten by another theme, in part or whole. |
Abstraction: ‘as little logic as possible’
- In the context of theming, we want as little direct code, and logic as possible. Why?
- Helps keep themes ‘upgrade-proof’
- A step towards making themes ‘portable’ between other software types
- Good for sanity: don’t want to think about logic the majority of time I’m theming!
- But, do we really want as little logic as possible?
Some examples: the <title> element
Example from WordPress
- WordPress: too much logic at theme level
Example from MediaWiki
MediaWiki’s implementation is simpler than WordPress’, but still uses raw PHP. Doesn’t offend my designer sensibilities too much though!
Example from MODx CMS
Much nicer. Well-abstracted – it’s clear what these ‘placeholder’ values are for, but.
Example from Joomla and Magento
Joomla (top snippet), Magento (bottom snippet). So, is this too abstracted? The <title> element is abstracted/obscured to a point we as themers no longer see it.
Is it up to us as themers to decide this, or the software – i.e., the end user through their content management access?
But we do want logic choice
“But we do want choice”. I don’t want to see the ‘hard’ logic of software, but I want to be able to chose the variables, and the FORMAT of variables, that are presented.
What is granularity?. It’s “control where it matters”. We need abstracted control over content but not direct logic. The next examples are from various OS CMS/etc for how navigation is implemented within a theme.
MediaWiki example
Argh, logic! But, it does provide us as themers with some choices with the output HTML:
So, by default, MediaWiki provides a unique ID for each list-item in the navigation list, which is pretty handy, but I’m having to use the PHP print function to wrap it in<nav> elements, which is annoying, and exactly the type of thing I want to avoid in themes to keep them ‘clean’.
An example from MODx CMS, which uses sensible defaults (top snippet), but allows you to overwrite the output mark-up and append classes, etc (as in the bottom snippet).
Similar to MODx example above; fairly sensible defaults for the output mark-up are added, but you can overwrite the mark-up through templates if you need to.
Where do we draw the line?
Where do we draw the line between what the software/user controls and what we control as a themer? It’s blurry.
Does software control?
Example from Drupal 6. List items in menus are automatically given relevant classes (.first, .last), but…
Or do themers control?
…we can target those elements with CSS. A trivial example, but doing it this way means better portability of the theme – no find-and-replacing class/id names!
Class-tastic
Another example from Drupal 6, with panel module installed, courtesy of @philsherry. 22 nested <div>s. I think the problem here is that software/web developers aim for ‘robust’ (a good thing), and end up with ‘overkill’.
The CMS problem, or WYSIWTF
As designers/themers, we spend a lot of time making websites look nice for our clients. Then we install a RTE (Rich Text Editor), and clients can ruin the design all by themselves, without even really trying.
Jeremy Keith summed this up nicely at the DIBI conference in Newcastle this year as ‘WYSIWTF’ (or ‘What You See Is What The Fuck’).
This example is from an older website that runs on our inhouse CMS. The Rich Text Editor is TinyMCE. Within one paragraph element there are:
- 9
<span>s - 4
<font>elements (WTF?) - Another
<p>element?!
Other than restricting the options available to clients in RTEs, there’s not much we can do about this.
Portability of themes
Very much theoretical; portability is about the ability to utilise themes between different versions of software…or even different software entirely (e.g., WordPress to Drupal). Nice to have, but very difficult to fully automate! Abstraction in templates/themes is one thing that could help towards this.
Questions
As I said at the top, feel free to email me with your thoughts and ideas, and I’ll try and respond to all of them, and post any relevant annotations on this page.