CMS Template Development and Developer Tendencies

We’ve had enough cases of this situation to constitute a pattern that I should articulate it and share it with everyone. One of the major challenges when creating a CMS is how granular the templating and authoring should go. On one end of the spectrum, the entire page is one big blob of text and users can do whatever they want, on the other end, each piece of text can be a separate managed component. Neither of these is desirable.

Typically, my recommendation is to go less granular. The reason is: it gives the authors more flexibility which is sort of the point of a CMS; take the control away from IT and give it to the authors. Although the IT department you are working for might not like this and of course, you have to consider how this impacts adherence to the Style Guide and Branding elements, it is generally the right side to err on.

What I wanted to write about today is the need to recognize and adjust some our fundamental developer tendencies ...

Over-Granularization for Content Management’s sake:

A CMS gives us a way to easily create templates and manage content within those templates. We are over-granularizing, though, if we have more than 3 managed pieces of content within the same 4 inches of content. That should either be powered from a list or be one single blob of text.

Over-Granularization for Flexibility and Re-use’s Sake

An OO (Object Oriented) Developer’s tendency will be to create modular, more flexible templates to minimize the maintenance for developers and maximize the re-use of the templates.  This typically results in templates that have very generic names and have multiple uses. I once built a set of templates (about 3 of them (Table, Row, Cell) that allowed the user to generate <table><tr><td></td></table> tags. This is a great tendency to have when we are doing OO development, but not when we are creating templates for a CMS.

Creating Templates for the wrong Reasons

I know it’s tempting to create a new template when we have a unique UI scenario, but this isn’t the best use of new templates. Most CMS's let you conditionally output different HTML based on a content attribute so it shouldn't be hard to use the same template and use some basic conditional logic to get the result you want. It’s worth it to reduce the number of templates. More templates means more to maintain and also clutters things up for Content Authors (Sally Author says: “I can never remember which template I want, is it 'Text Box and Image' or 'Text Box and Summary Text' ” )

These tendencies usually result in too many templates because we are making the templates TOO flexible and TOO granular and not using the tools appropriately.

WHAT’S THE POINT??

While most of these tendencies are excellent habits for building Web Applications, too much observance of these principles contributes to the overall failure of a CMS implementation. The biggest factor to consider this when creating templates is HOW WILL IT IMPACT THE CONTENT AUTHORS. Is it going to be more difficult for them to achieve their business objectives for the sake of template flexibility? If so, they won't use it or they'll complain and the system will fail. It doesn't matter how maintainable, re-usable or flexible the template code is when the users don't use the system or decide to implement something else (possibly using someONE else) when the system is too hard for them to use. SOO, denormalize if we have to, collapse layers if we have to. These will all result in less clicks for Content Authors, less cluttered template list, more obvious naming, and ultimately higher likelihood of adoption.

The bottom line is, our decisions when building templates aren't just decisions for how to maintain code, they also are directly related to how users will interact and manage the content. This is what makes developing CMS templates a little different than developing HTML and OO code.