I agree with Patrick, it's a vague term. Think about it this way: CMS 
stands for "Content Management System": the first term is quite general 
and the 2nd and 3rd are even more so. "Content" encompasses a vast 
range of things. Imagine a similar acronym for other sorts of vague 
things that need to be Managed by a System. What would a Data 
Management System do? Or a Customer Management System? Or a Profit 
Management System?

This is one of those buzzwords that, when I hear it, makes me think 
"the customer hasn't thought very much about the requirements." In 
fact, often these buzzwords mean "the customer is saying he wants to 
acquire software to help with a well-defined process, but instead he 
hasn't done a lot of work to figure out the process and is 
subconsciously hoping that the software will come with the process 
already fixed."

When it comes to "content", there are a million considerations that 
could come into consideration:

- Who's responsible for writing and editing content, and determining 
the ideal volume of that content? Does a copy editor need to vet the 
content before it goes into the world? Business manager? Lawyer?
- Who gets to see the content? Paid subscribers? Company employees? 
Everybody?
- We probably care about getting to view this on MSIE Windows, but what 
about other ways of viewing it? How important is it for Firefox viewers 
to be able to read it? How about blind readers using specialized 
browsers for the blind? How about Google?
- What forms will the content take, ultimately? Sure, there's HTML, but 
what about Flash, RSS, CSV files, Excel spreadsheets, PDF, movies, 
images, and sound clips?
- What sort of resources are we willing to devote to producing content? 
Is this going to be a weekly text-only blog, or a full-blown online 
magazine with paid writers, photo shoots, and video interviews?
- What purpose does this content serve, anyway? Is it supposed to raise 
our profile in the world of bloggers and hackers? To give the 
mainstream news media a way to keep track of what we're doing? To 
foster a sense of community among our customers? To help us strengthen 
support for our products? To speed up internal project-based 
communications? To boost company morale? All of the above?
- How important is it that this "content" be preserved into the future? 
Is it archival stuff that you might want to put in a library? Is it 
mission-critical content that needs to be up at all times?
- How are we organizing it, anyway? Do we want to throw together simple 
categories? Is it worthwhile for us to look into 
Technorati/del.icio.us-style folksonomies? Are there any 
industry-standard ontologies that apply in our domain, whether we're in 
the field of fine arts or aeronautics?

I'm dumping all of this out because in fact I've spent much of the past 
few months asking these sorts of questions about the company where I 
work. It's interesting, but also fairly tiring, and it requires you to 
have an extremely precise sense of your organizational strategy ... and 
guess what? We barely mention implementation technology, though we're 
at the stage where I'm going to have to start costing it out, so 
obviously it's going to come into play soon.

So, to get back to the original post, I'd ask first: What is it that 
the web site's supposed to do, anyway?




On Jan 15, 2005, at 6:22 PM, James Britt wrote:

> Patrick May wrote:
>> I think the definition of CMS software is pretty blurry.  To me, CMS 
>> is a fancy way of saying, a development environment for building 
>> websites.  I think Rails, Seaside, IOWA, are the ruby equivalent of 
>> CMS's.  I think of these as a "standard libs" for doing web 
>> development.
>
> Interesting.  CMS makes me think of an application that allows folks 
> with little knowledge of (and no desire to learn) Web stuff to add, 
> edit, and otherwise manage content.  CMS systems typically, I think, 
> allow for assorted type of editing access, change notifications, and 
> comments from readers/reviewers.
>
> Often a CMS is used to produce a  Web site, but I think they tend to 
> be corporate intranets.
>
> So, I would see Rails, Seaside, etc as possibilities to use as 
> groundwork for building a CMS.
>
>
> James
>
>

Francis Hwang
http://fhwang.net/