‘CMS design/integration’ – notes from my SuperMondays talk

1 August 2011

Home — Web Design & Ecommerce Blog — Magento — ‘CMS design/integration’ – notes from my SuperMondays talk

I’ve included my (hastily written-up) notes from the SuperMondays talk I did last week (Slideshare link), entitled ‘CMS design/integration’ (original, I know!).

  1. Introduction
    1. Creative Director at Peacock Carter Ltd, a Newcastle-based web design agency
    2. Author of 4 books in theming:
      1. Magento 1.3 and Magento 1.4
      2. MediaWiki
      3. Joomla! 1.5
    3. Technical reviewer on more:
      1. Drupal 7 (x2)
      2. MediaWiki
      3. Inkscape
    4. Experience with below too:
      1. ModxCMS
      2. Drupal
      3. WordPress
  2. What is theming?
    1. Taking a static template – (X)HTML/CSS, possibly JavaScript – and integrating that in to a specific software package – a CMS, ecommerce package
    2. To me, it bridges the gap between web designer, frontend developer and, sometimes, a little towards backend developer too
  3. Topics to promote discussion throughout the rest of this talk. Base themes:
    1. Concept, as seen in Magento
      1. Base theme encapsulates everything needed for the software (e.g., ecommerce) to ‘run’ visually
      2. Then create an overwrite theme which overwrites specific elements you want to customise
      3. Good for upgrades – you can upgrade the core components of the software – base themes included, probably – and in the worse case scenario only have to rewrite your changes to the base theme
  4. Base themes II
    1. Examples of ‘base theme’ implementations
      1. MediaWiki: common.css – single stylesheet you import you defines style for common elements – e.g., user bar, page tools
      2. WordPress – ‘base’ themes such as ‘Starkers’ by Elliot Jay Stocks – but these are more for copying and pasting than overwriting
      3. Magento – the ‘truist’ base theme implementation I’ve seen
  5. Abstraction
    1. I want to see as little logic as possible in  template files (sort of). Why? It helps themers focus on mark-up rather than the intricacies of where a particular block of content is coming from
    2. What follows are examples of how various open source CMS/ecommerce/etc platforms implement something as simple as populating the <title> element
  6. WordPress example
    1. No! Just nasty
  7. MediaWiki example
    1. Getting better – my designer sensibilities aren’t too offended by this
  8. ModxCMS example
    1. A good balance?
    2. Separated parameters for the site name and the title of the page – you can reorder them as required
    3. But, is this our choice as themers, or the end users’ choice?
  9. Joomla!example
    1. Navigation is in this block, somewhere
    2. Gives the user more control
  10. Magento
    1. Similar to the Joomla! example, defined elsewhere.
    2. Can overwrite through XML layout files – and remove/add stylesheets/scripts
  11. So, I said as little logic as possible, but I’m also awkward.
  12. Whilst I don’t want logic as a themer, I do want choice: the ability to change how data is formatted if a particular element of the theme is better suited to it
  13. Granularity in theming can provide abstracted control to themers for this very purpose, and it can be done without resorting to huge amounts of logic
    1. How many people have themed/tried theming? How many people have got 95% complete with a theme, only to find that the last 5% they need to change is nearly impossible? E.g., to add your own custom id to an element within a predefined element which can be hardcoded in a block of output HTML
    2. (Of the people who put their hands up for the first question, all hands remained up for the latter)
    3. As an example, let’s look at how various systems implement populating the navigation
  14. MediaWiki example
    1. (For those wondering, the Sky Sports style pint glass meant we were halfway to beer at the Trent House)
    2. This doesn’t give us enough control
  15. MediaWiki example (II)
    1. But luckily, MediaWiki outputs the list items with (semi)unique ids assigned to them
  16. ModxCMS example
    1. A contained block, with little control here…
    2. …but the bottom code block can be used in a template to overwrite the predefined output and append a unique class/id to the list item
    3. A good balance – sensible defaults with the option to overwrite them if required?
  17. Drupal example
    1. Similar to Modx; can be overwritten in a template file
  18. So, where do we draw the line in what a themer should define, and what a user should be able to define? The simple answer: who knows? It depends on the:
    1. project itself
    2. the technical ability of the end-users of the CMS/ecommerce system/etc
    3. the client’s budget (doesn’t it always!)
  19. Drupal 6 example:
    1. Generated output from Drupal 6 module ‘panels’, courtesy of @philsherry
      1. 22 nested <div>s! Possibly to make it ‘robust’ to theme…but it’s <div> overload
      2. Duplicated classes within nested <div>s (e.g., .inner)
  20. Drupal 6 example (II)
    1. Software automatically adds a class of .first, .last for the relevant list item in the navigation block
    2. There’s also overlap in how we as designers can control things.
  21. …because we can control the style here through CSS such as this
  22. The CMS problem
    1. We create nice mark-up for our clients’ sites, only to have it destroyed by output from Rich Text Editors (RTE)
    2. Jeremy Keith at DIBI 2011 (Design It Build It conference) summed this up nicely as WYSIWTF (What You See Is What The Fuck)
  23. Here’s an example from a website using TinyMCE: nested <span>s, <font> (!) and even nested <p>s?!
  24. And they overwrite our style inline, too. Is this too much choice for the client? I would say yes!
  25. Portability
    1. Ability to port theme/template/skin from one software to another (e.g. Joomla! to Drupal), or even between software versions (e.g., Drupal 6 to Drupal 7)
    2. Magento 1.3 to 1.4 – forum post which says ‘start again’!
    3. An ideal that’s unlikely to ever be reached. Plus, it’d put themers out of a job!
  26. Documentation
    1. Problem in open- and closed-source systems
    2. This is an example from Magento’s website. Very long page…and nowhere does it say it’s largely irrelevant to the most recent version of Magento!
    3. But then they are starting to sell guides on everything Magento
  27. Documentation II
    1. Example from the WordPress Codex; well integrated wiki – you can correct mistakes, add to it from your experience.
    2. Magento has a wiki, but it’s poorly integrated
  28. Few things I could have gone in to more detail about:
    1. Layout control
      1. What’s the best way to define and control different page layouts? Again, is it the themer’s or end-user’s choice?
      2. What’s the best way to control widgets and changing where they appear on different pages, if required?
      3. I think the answer is it depends who the client is (and their budget, of course)
    2. Scalability
      1. ‘Future proof’ themes
      2. What happens if your client decides to install a module; is at least the basic styling for that covered by your theme?
        1. Base themes come in here, to some extent
        2. Some systems (e.g., Drupal), simply import another stylesheet with a module, if required
  29. Plug for Drupal North East