Hi Jennifer,
I've been working with two different CMS tools for the past 4 years.
Stellent initially but more heavily these days with Percussion. They're both
relatively robust systems so my opinions only from those experiences.
CMS tools are mostly a one-to-one mapping for the primary template to a
primary content type or folder. But for with the projects I've been on, I've
been both the interface designer for the websites as well as the CMS
implementer. This gives me a good bit of say as to how many content types
and primary templates should be created. I've found that there are two main
ways to make a CMS and UX person work well together, and that's through
content chunking and modular templating.
Content chunking for a CMS focuses on breaking down a content type into it's
atomic data parts. Things like: display title, description, intro, body,
callout, url maybe, keywords, etc. The focus of content chunking is to
figure out how to reuse pieces of information. Percussion is a baking CMS
and produces static pages, so the best way is to leverage the use of that
one piece of data and reuse it in multiple instances. That way if that piece
of data is updated it's updated everywhere it's used. For a designer, you
can also figure out how to use those chunks of data, where to use it, when,
why, and what triggers would cause the usage of it. A display title could in
an page title tag in one instance but only has the title for an item in a
list of links in another. We would have to come up with the rules on how to
use these chunks of content so that we or the developers can implement them
in the templates.
Percussion assigns a type-specific template (the primary template) to a
single content type. But you can also have shared templates which can be
called by anything. So chunks of content can be filtered through a multitude
of templates depending on the needs of that page and the purpose and use of
that particular piece of content.
What I've implemented in my current project is a content type called
Buckets. The content authors can create buckets and put prose in them,
lists, images, etc. Depending on what page is calling the bucket, depending
on where on the page the bucket is being called, the content of that Bucket
content item can serve various purposes. It can also be assigned to various
pages.
The visual look and feel I define purely by the CSS. One template can have
the datafield displaytitle show up as an H1 tag looking one particular way
while another template can have that same displaytitle show up as bolded
text styled by a class in a div tag. Even on content type specific templates
I provide my content authors the ability to choose between one column, two
column, or three column layouts. Depending on the layout, different related
content can be pulled from different buckets.
So with modular templating you can also have templates that change their
elements based on what's calling it, where it's being called, or maybe as
specific as a singular piece of item. For example, I have a global template
(basically the wrapper consisting of the header, footer, and global nav) but
based on what folder and what content type is being called, logos change,
header titles change, and even global navigation change. But it's all still
one template.
So it's our responsibility to define the purpose of what's going to happen,
why it's going to happen, where it'll happen, how it should happen, and what
triggers it. So even if you're stuck with 2 or 4 templates, those templates
can still do various things.
Hope that helps,
Thai
On Wed, Feb 17, 2010 at 12:35 PM, Jennifer Wolfgang chicgee...@gmail.comwrote:
Hi all,
I'll be honest, though I've worked in web design and development for almost
13 years, I've never - until now - had to work with a CMS on a static site.
I've implemented an early version of eMPower (Ektron), but that was years
ago and it was pretty basic: no 'templates' or 'modules' to be concerned
about.
For the past year, I've worked at a company that uses a Perl-based CMS; the
majority of our site uses this CMS, and the site is static because it is
decoupled. We have templates, and modules that those templates use, that
were crudely built (no planning, just a dump when the CMS was implemented).
All that to say that I'm having the darndest time figuring out how to
design
/ structure new pages because of the limitations of the templates and
modules. I'm used to being able to create an interface that is custom to
the
content and structural needs of the page/path (as needed) - not to mention
for a dynamic site - that I'm struggling for how to do my job well while
working under such constraints. Another huge element, at least for us, is
that we are extremely limited on resources. So, if it's a matter of have
your developers work with you to build what you need, I'm sorry to say
that's not an option. We have 2 full time developers, and would need to
hire
contractors (in Germany,
