I am sure we have all had it – that feeling of excitement of a crisp blank piece of paper and a set of freshly sharpened coloured pencils. You are about to start implementing Tridion templates for a greenfield website implementation. No legacy VBScript scribbles already on your canvas to worry about, your favourite .NET TBBs and Custom Functions at hand to boost productivity. You will be knocking out Component and Page Templates by the hour and feel the buzz of seeing that sexy new site start to form on staging before the end of the day! Then you check the source of the html files in the zip provided by the design agency and your heart starts to sink…
At first glance it may look like nice, clean HTML, but when you actually start chopping it up into templates things start to niggle. The CSS class on the <body> tag changes on each different page, depending on what content is shown in the main content area… Component presentations in a column layout need to have specific styling depending on which column they are in… Images within HTML that would be part of an RTF field use tables or divs to provide alignment… Images are used for editorially managed content text such as navigation and headings. And so on…
Each of these challenges requires a workaround and leaves you with an increasing feeling that your implementation is becoming more complex than it needs to be. Your templates fill up with more and more noise from all the conditionals and custom function calls until your nice clean HTML is hardly visible any more, and your Default Finish Actions TBB contains 27 different sub-TBBs to do various pieces of sorcery to warp and bend the output to match what was provided by the design agency and signed off by the customer.
So what’s the best way to deal with this? Like any ailment, prevention is the best cure. You need to get in there early, before anyone signs off the HTML. When the agency (or whoever) starts cutting HTML from their Photoshop design concepts make sure someone who knows Tridion templates can review the output. Give them a little training (SDL has a Design Principles training which covers such stuff), especially on how a page is broken down into Page Template and Component Presentations, and what you can and can’t do with a Rich Text field. Help them understand content reuse, and the impact of this on the separation of content and design.
There are a lot of things to look out for to make and HTML Design play nice with Tridion, but here are some of my top ones (based on how often I have seen them, and how much pain they cause).
#1 Apply content styling at Component Presentation (CP) level
Often I have seen styling applied at too high or low a level. An extreme example of this is the <body> tag having a different class depending on what content is displayed in the main content area (news, events, products etc.). Usually this is not necessary, as simply moving the class down to the container for the content (ie CP level) will have the same effect. Without this you have pain as you have to put logic in your Page Template, or worse still Master Page or equivalent. If the Design Agency understands what a CP is, they should start to understand why this is important. It will also help your CPs work in different combinations on different pages, should that be required in the future (an event summary CP could be shown within a product type page without styling issues and so on…).
At the other end of the scale, you will also have problems if your styling is too embedded in with the content. If our news articles have a specific style for bullets, and this is specified in the HTML on the <ol> element itself, editors will have to select this style when entering content (or we will need to write a TBB to add this in). Better to specify this in CSS for the whole news article CP block.
#2 For a list of items, use a list!
If I had a euro for every time I have seen a page with a list of component presentations shown using a table, or divs with classes like col1, col2, I would be able to have a decent night out in Amsterdam. The problem is presented here (along with my solution in the comments) and John has a great solution for dealing with this but wouldn’t it be nice if a list, was represented as… a list? People bang on about the importance of semantics, but in this case, it also makes template logic so much easier, and indeed your output much more cross-device friendly (if the screen width cannot handle 3 columns, a list flows much more gracefully than a table or proprietary div structure into a layout with fewer columns)
#3 Will that content block work as a Rich Text Field?
Although you may not have yet done a full schema design, there will be some content areas which look good candidates for implementation as an RTF field. Bullet lists, hyperlinks, images and other formatting features are in the content text, but take a look at the source. Does this map well to simple XHTML? Some styling is perhaps inevitable, but preferably styling should be applied on a higher level element (see point #1) so editors do not need to worry about selecting CSS styles on the content in the RTF field. Image alignment and captioning is a common problem. Editors are not going to want to add a table and/or div in order to align their images and add a caption.
#4 Do elements containing editorial content scale well?
This is a classic. When we cut up the design into HTML, we create some test pages, and because we are lazy, we just use the example content already provided in the HTML design. We publish, and hurray – it looks great! Then testing starts, real content is used and disaster! It looks a mess – they added another footer link and the whole footer became misaligned, one of the product summary boxes has a bit of a longer description than the others and it screws up the look of the whole list, when translated into Finnish, the top navigation doesn’t fit on one line and makes the main content area mis-aligned with the other elements.
While you will never be able to catch all problems, it is quite easy while viewing the HTML design using Chrome or Firebug in Firefox to jiggy the content in the HTML source around a bit , and check that the main elements scale well with different content.
#5 Avoid images for text
There are so so so many reasons not to use images to display heading or navigation text on your website, and only one reason to do it (the company brand uses a font that is non-standard). You want to know them? Well think about SEO, accessibility, font-scaling and inability to globally change the style first, before moving on to Tridion specifics like having to write code to generate the damn things and integration with SiteEdit/New UI. Its 2012! Most browsers have a pretty extensive set of fonts, and most screens are pretty good at rendering them nice and smoothly.
As I said, that is just a few of the things to look out for. I am sure you have your own personal bugbears – so let us know in the comments. My final word on this is do not be afraid to be stubborn. Any time you invest in HTML review will be saved 3-fold further down the line*, and if this agency continues to work for Tridion projects, they should understand that they need to develop a competency for producing Tridion (or indeed any CMS) friendly HTML.
*Time is saved not just in development and maintenance effort, but also in testing. In my experience, the effort taken to discover and fix an HTML bug during UAT can be totally disproportionate to its complexity. The bug is first discovered and logged by the tester, then processed by a test manager and probably assigned to a template developer who will then analyse it and discover its a problem with the HTML. This then needs to be explained to the design agency (who often do not have access to the issue tracking system), who will issue new HTML/CSS which then needs to be updated in the the dev CMS by the developer, re-tested and deployed onto the test environment. The issue needs to be updated, retested by the UAT tester and then closed. HTML review cannot prevent all such bugs, but will certainly help.