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.com>wrote:

> 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, where the CMS company is located). Yet, we are a
> large global company. It's just weird. :)
>
> Thus I'm curious: is this a common issue for UX designers? That is, are
> there things I need to learn about working with a CMS, static or otherwise,
> that will help me fulfill my role better?
>
> Thanks,
> Jennifer
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... disc...@ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... disc...@ixda.org
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

Reply via email to