[Sigia-l] Notes from IA/UX discussion on CMS

[Samantha Bailey]

Hi,

The Charlotte IA/UX group met last week with a guest speaker to discuss
content management. I found the session very instructive, so I'm sharing my
notes below. If you live in the Charlotte NC area and would like to be added
to our mailing list and informed of upcoming meetings (we meet monthly)
please email me off list. Thanks.

Samantha Bailey
samantha at baileysorts.com | http://baileysorts.com


IA Cocktail Hour: Content Management Systems
Guest: Carter Hansen, Wachovia Corp User Centered Design Director

An expert on content management system design, Carter Hansen gave a
presentation and answered questions relating to content management issues
and concerns from an information architecture perspective.

Here are my notes from the evening:

· Prior to 1997 there wasn't a great need for content management on the web
as there wasn't that much content, most of it was brochureware. Very
shortly: content explosion "content is king" led to content providers being
overwhelmed by demands of delivering & managing content
· Vignette story server derived from Cnet's efforts to manage content; 1998
handful of users: cnet, zdnet, playboy, bankone, Chicago tribune. Carter
began working with it during launch of Omaha.com (city portal)
· Efforts associated with real-world publishing didn't want to have to
introduce editorial and workflow separate from existing efforts (unclear how
successful this has been)
· Carter's background gives him unique perspective: technical know-how
coupled with UCD and UI principles, strong advocate for user
experience--encourages us to look for (nurture) such people in our
organizations

 CORE elements of ANY CMS:
o Access control: who has access to content, nature of that access
o Revision control: how has the content been modified. (Can be a defacto
archive-we're actually able to resurrect any version of the Wachovia.com
website from start of using the CMS
o Workflow: systematic routing, updated through review and approval
o Release management: controls deployment (must be approved, bars accidental
release of content; esp important in a highly regulated industry like fin
services)
o Template engine: environment for building layout templates to support the
separation of church and state (just seeing if you're reading) content &
presentation. Enables multiple views of same content: text only for
accessibility and low bandwidth, versions for different environments
(wireless, PDA)
o Database: Schema to support structured content. Database modeling is a
semantic exercise: break language and concepts down to fundamental elements:
objects, types, relationships, children, etc.
o Application server: executes programs in template engine and matches to
content in database to generate the pages of the site
o Webserver: receives the generated pages and serves them

A note about programming: don't assume that all programmers/developers have
the same aptitude. In terms of CMS there are often application designers and
programmers (coders/developers). An application designer is going to tend to
be more of a big picture person with database modeling experience. They will
think conceptually and understand the capabilities of the system but may not
be able to code as efficiently/elegantly as a true coder. Programmers will
be more literal and linear in focus-will be able to make anything but may
not be user centered, UI focused. More likely to want to solve a problem
efficiently from a code perspective than to focus on end users. Good to have
both: application designer for the conceptual/design and coders for the
build and maintain.

A note about database modeling: thinks that more IAs could/should do
database modeling; have aptitude for it, can expand influence

Two sides of a CMS:
CMA: content management application: update content, manage workflow, make
releases
CDA: content display application: presents the pages to the server

Database publishing: gave overview of tables, records, fields (i.e.,
databases are made up of tables which consist of records. Records contain
fields)

Pros & Cons of CMS-based web design
Plus:
Efficiency: keep everything centralized (yet work decentralized),
versioning, leverage database
Ease of maintenance
Repurpose/reusability of content
Consistency
Simplicity for users of system (e.g. distribute entry and maintenance, don't
have to learn HTML)

Minus:
Consistency: it's a double edged sword; will always be something that doesn'
t fit, exceptions desired. People who are used to static HTML will be used
to making elaborate tables to accommodate the exceptions.
Inflexibility: no exceptions or very $$$ exceptions
Rules: will always be people who chafe

Example of the degree of complexity that can be present: one page on the
Wachovia.com site draws from 30 templates (objects on a page) and 100
database records.

What's in a CMS for me as an IA?
Prototyping assistance: rapidly develop both low fi and hi fi test
environmentsà get near immediate feedback to see how ideas on paper actually
play out when applied; less labor in creating a fully navigable prototype
means you could test alternative schemes, test earlier in dev. [example:
created a 600 page test site with 3 days of effort; future test sites then
created in a couple hours]

Version control: docs associated with the IA of the site can be kept current
and show what the site actually looks like-removes the situation of having
site maps that are long out of date. CMS serves as a system of record. Can
also be used to release diff designs at diff times (does require more
sophisticated CMS)

Workflow: partition access by role. IA group can be added as a required
approval step in content development or alerted as the IA changes. Limits
the "postage stamp" effect of "minor" changes being added here and there all
over the site

Recommendations on working well with techies:
-Understand the diff between application developers and programmers and know
who is who on your team.
-Involve developers as early as possible.
-Build trust and respect
-database design is fun-maybe you as an IA should consider becoming this
"kind" of techie
-describe the elements in the UI in terms of RULES that will be consistent
-classify UI elements into types/families (often groups of pages with
similar characteristics can be generated from one flexible template, cutting
down on the number of overall templates required)
-decompose each page type into discrete objects with presentation and
inclusion rules for each
-Agree together on deliverables: some developers will be comfortable with a
rough narrative, others with a flow chart
-Approach the work as a dialog: explain what you're thinking, allow
developer to ask questions, bounce back and forth as rules emerge

CMS resources:
Bob Boiko's Content Management Bible:
http://www.amazon.com/exec/obidos/tg/detail/-/076454862X/qid=1043185303/sr=8
-1/ref=sr_8_1/002-4913614-5416801?v=glance&s=books&n=507846

CMS watch:
http://www.camworld.com/cms/

CMS listserv:
http://www.camworld.com/cms/

EVOLT article:
http://www.evolt.org/article/MartinB/20/5127/

Intranet Journal tools list:
http://www.intranetjournal.com/tools/cm/