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.
Photo courtesy of
.faramarz on Flickr
What I wanted to write about today is the need to recognize and adjust some our fundamental developer tendencies ...
OverGranularization for Content Management's sake:
A CMS gives us a way to easily create templates and manage content within
those templates. We are overgranularizing, 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.
OverGranularization 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.