Creating User Interfaces to Work Within a CMS

17 Feb 2010 - 2:49pm

Last reply:
5 years ago

4 replies

487 reads

Yvonnia Martin

2009

I hear ya, Jennifer. I work with a coldfusion-based content management
system and I don't think the community is as big and those of PHP and
.Net. We have 1 developer on staff who for some reason or another,
does not know the CMS at all (go figure). Anyway, we are totally
locked into basically 4 template styles. Each of the template styles
have "elements" of the page that you can edit in either the wysiwyg
mode or the html mode. I basically resorted to exploiting the html
editing portion of the thing! The template is still the template, but
in the end I am able to add in niceities without throwing off the
design or architecture too much. I find that people are happy that I
was just able to do something different with the thing (however
small)

Comments

17 Feb 2010 - 9:30pm

Anonymous

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.

> 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 ....... discuss at ixda.org> Unsubscribe ................ http://www.ixda.org/unsubscribe> List Guidelines ............ http://www.ixda.org/guidelines> List Help .................. http://www.ixda.org/help>

17 Feb 2010 - 12:15pm

Adam Williams

2010

How much control do you for the styling? I would make important action
links look button like, without over doing it. Also, be creative with
wording if you can't control the layout much.

I am working in a similar situation where we have limited page
templates built in a CMS and limited developers to help create more
custom pages.

My biggest suggestion is to do some analysis of what your needs are,
in regards to modules and templates. Use what you find to come up
with 2 or 3 page templates that you believe will be flexible enough
to meet your needs. Currently the site I work on has about 6
different page templates that have been created over the last year.

So be strategic about when you request new templates and sometimes
you will just need to make what you currently have work.

Over the past 4 years I've been working with CMS tools in
maintaining site templating and content management. I've worked in
Stellent but mostly in Percussion. Over the years I've actually
taken control of doing the actual implementation and development both
the CMS tools I've worked with.

I'm also the interface designer for the project so that allows me a
good bit of freedom to figure what can and can not be done, or more
how it can be done but with what difficulties. I think that in
working with a CMS there are a few factors that would help improve
our overall partnership with the tool: content chunking, modular
templating, and scripted interactions.

Since the primary goal of a CMS is content management, reuse of
content and that content's data is quite important. As a UX person I
normally approach how I would be using these various chunks of
content. How would the display title be presented, where would it be,
could it vary, how would it vary, and what would trigger it? One
content item's title and description could be used in various
sections of the site. It could potentially look different from one
section to another. It could serve completely different purposes from
one section of a page to another. So figuring out the purpose, the
how's, why's, where's, and when's would help in determining how
your interface changes but also how a developer would go about
implementing it. Is it based on content type, folder, a data field
selection in the content type, content id, name, etc..?

This would allow for modular templating. A CMS at the basic assigns
something to one particular template. It could be an assignment on
the folder level or the content type level. It's mostly a one-to-one
relationship, a primary template for a content type in the case for
Percussion. What I normally allow for are buckets of information to
be used in a page. Percussion uses something called "related
content".

I created a content type called "Bucket". Anyone can put any type
of content in this bucket. Depending on what page is calling for this
bucket or even where on that page it's being called, the rendering of
that bucket of information changes. The content item created can be
filtered through various templates depending on the situation that I
define.

Depending on how robust the CMS is, I guess, you can have one global
template but it presents multiple menu systems, logos, and masthead
titles depending on which directory the content is being called from.
I scripted my "global template", which in Percussion is the wrapper
(header, footer, main global nav), to recognize what's what content
is calling it and changing accordingly.

Essentially it all boils down to you seeing the many uses of the
content that's being stored, what those content types do, how it'll
change, and their triggers.

If you're not the one implementing then you'll need to provide that
level of information to the developers to implement. Try to find a
reasonable pattern so that the coding doesn't have to be specific.
Does content type A's data field XX present in template 1a
everywhere but except when it's a content item is in folder FF, then
it'lll use template 2b?

Developing for a patterned behavior is more efficient that a bunch of
one offs as that would take more time and then there would be a lot of
code bloat in the templates.