RE: More users = simpler CMS

James,

>From what I understand from your article - and the clarification on the
mailinglist - your main point is: when decentralising authoring, the focus
should be more on usability than on "enterprise needs"; therefore,
simplifying, there are two main options: getting an "enterprise strength"
CMS and developing it to be more usable, or getting a "simple CMS" with a
focus on usability (it can always be upgraded, customised or replaced later
on).

While I do agree on that important point (usability is key when
decentralising to many users, and you give an excellent summary of the
reasons why in this article and the related article on decentralising), I'd
like to comment on those two options. -Reading back, I notice I must learn
to keep things short and clear. Hope you still have the time and energy to
read through all of it. The management abstract would be "Go for option 1,
because it doesn't have to be what James described it to be" ;)

* Option 2 - A "simpler CMS", or at least, "simple to use" (high focus on
usability) has got many organisations into trouble. My own organisation is a
prime example - our current CMS is relatively easy to understand and use and
has enabled to get tens of thousands of pages online with highly
decentralised authoring. Unfortunately, step two after deploying a simple
CMS - extending or replacing it - is extremely cumbersome, very expensive
and will take us at least two years in total. 

Likewise, in many other organisations where the CMS was selected based on
usability criteria ultimately caused either huge infrastructural problems
(the CMS wasn't up to the task anymore, causing the website to be
inaccesible, slow, hard to navigate) or management problems (a
content-jungle, where both visitors and authors can't find their way
anymore). Yes, it's made the organisation ready for a "more complex CMS",
and made it easy to get a quick start, but at a price I'd rather not see
anyone else pay.

When I heard another Dutch university was planning to get a simple CMS to be
deployed in multiple instances decentrally, thinking, "oh, it'll only be a
couple of sites in the beginning anyway", my thought immediately was "yes,
and you'll be exactly where we are now in three years from now" - we thought
the same a couple of years ago. When I heard about a governmental
organisation getting a particular CMS (known to insiders for its stone-age
technical architecture) on the basis of its usability, I thought "hm, lets
see how usable it'll turn out to be when it starts bogging down and then
crashing after the first few hundred pages have been added".

* Option 1 - On the other hand, your option 1 focusses on getting a
"complex" CMS and then tailoring it to your need. Your description of that
option, however, suggests that tailoring a CMS would effectively mean
redesigning parts of it or adding on to it, i.e., actually programming new
stuff. While one of my qualms with many "enterprise" systems is that they'd
actually need to have that kind of work done, it isn't necessarily so. It
just takes a different focus during the phase of selecting a CMS.

When I was going through demo's with vendors last year, I wanted to see all
possible features. My first response would always be "That's very nice. Now,
how do we turn it off?" :) What I mean by that is we were looking for a CMS
that had all the features we could possibly ever want - and then turn almost
everything off for 95% of our users (leaving those features only to the
power-users). Most of the customisation we're now doing is taking a nice and
usable interface and stripping most of the features that are too complex for
a "standard" user (and in that way making it more usable to them). That
gives us a great saving compared to doing it the other way round (having to
add everything we needed to a system) and we still got a system with
"enterprise strength" qualities in managing a huge amount of content.

So I'd say be very very wary of option 2 - go for option 1 and select a
system that still has to have at least good usability, but can be
selectively and easily stripped down to fit the large group of authors you
want to be able to work with it with minimal training and then be higly
usable. To be fair, to my knowledge there isn't an ideal fit to this utopia
yet - but several close enough to be viable. Selecting a CMS based on
usability alone can be as disastrous as selecting a CMS based on its great
architecture or feature-richness alone.

Adriaan M. Bloem
__

Project Leader Implementation CMS, ICS Webcommunication,
& Internet Coordinator, Faculty of Law

Leiden University
Visiting address: Steenschuur 25, room C0.13
Postal address: P.O. Box 9520, 2300 RA Leiden, The Netherlands
Telephone: +31 71 527 7897

> -----Oorspronkelijk bericht-----
> Van: [email protected] 
> [mailto:[email protected]] Namens James Robertson
> Verzonden: maandag 8 augustus 2005 7:00
> Aan: [email protected]
> Onderwerp: Re: [CMS] More users = simpler CMS
> 
> Hi Rickard,
> 
> I agree 100% with your points, so clearly my article didn't 
> convey the argument very well.
> 
> To therefore paraphrase:
> 
> If you have a lot of users, then you should get a CMS that is 
> suited to being used by large numbers of non-technical users.
> 
> The inherent usability/simplicity of the CMS should therefore 
> be a *key selection criteria* when choosing a CMS...
> 
> Cheers,
> James
> 
> 
> -------------------------
> James Robertson
> Step Two Designs Pty Ltd
> Knowledge Management / Content Management / Intranets
> 
> http://www.steptwo.com.au/
> [email protected]