Jeffrey Veen

I agree with you 100% Jeff.

We work with a client who is using an Oracle Application Server to run their site, using tons of templates and "portlets", which all gets stuffed into columns with a nice big table wrapped around it.

In their entire site, the only thing they have forms for update are news releases and job openings. Other than that, all their content is static. Sure they have a few forms for requesting information or contacting this department head or that...but it is nothing that a nice little PHP or PERL script couldn't do.

I am of the impression that probably 70% of sites that use a big back-end CMS could do without it.

I was right in the midst of writing just such a rant on the open source CMS world when I saw this entry. Never in my life have I yelled "WHAT WERE YOU THINKING?!?!" at the screen so often as in the past few months, struggling with phpWS, Mambo, Plone, Drupal, Geeklog, Siteframe, and phpNuke, and rejecting each for utter unusability. I finally settled on Mambo, but now the struggle is teaching AOL-bound writers and editors how to leap through any number of hoops just to make categories and post articles.

I haven't seen a standards-compliant website CMS that isn't blog-based. I'd say it's time to start one.

I think the problem is that making a website is hard. Most people don't realize the complexity of the business.

Users just want to point and click to have a website and that is what we need now!

I think the flexability of CSS Zen Garden coupled with the dynamic loading and editing of content would be the best thing ever!

Textpattern is by far the closest to this list I have ever seen:

Make it easy to install. YES
Make it easy to get started. YES - default screen is "write"
Write task-based documentation first. NOPE - but they're working on it.
Separate the administration of the CMS from the editing and managing of content. YES
Users of a public web site should never be presented with a way to log into the CMS. YES
Stop it with the jargon already. 99% – I've argued the use of the term "forms" with Dean many times, and we agree to disagree... everything else is solid.
Why do you insist Web sites have "columns"? IT DOESN'T

Textpattern is very blog centric on first look, but it's structure is along the lines of section/category/article so each content object is an article, which lends itself to many things besides blogs... it's a highly powerful CMS.

It's downfall right now is the default styles and templates are very limited, but the upside of this is that none of the sites will look like other Txp sites.

It's real value is it's roles/permissions system, and it's logical separation of content and presentation, and the notion that content (and the process of writing content) is very important.

It requires very little of a writer, but it requires someone smart to set-up and sculpt the system to suit the sites needs -- but all systems with a wide scope really need this anyway.

Jeff, what you are describing is not a problem with Open Source CMSes but with Open Source Software - which is a information, that does not help you at all, sorry.

It's part of the Open Source Paradigma "Scratch an itch ...". Most Open Source Software is developed by nerds for nerds. If a nerd needs some software and does not want to pay for it, she writes it or gets together with a few friends and writes it. This is a bottom up, grassroots (sometimes) democratic process. But nowhere in the steering commitee you will find a representative of the users (if those are not identically to the nerds doing the development). Why should they invite one? They're scratching an itch (on their own asses). Other users are simply "not an issue" (no powerful stakeholder).

See also http://macartisan.typepad.com/ , http://daringfireball.net/2004/04/spray_on_usability or http://mpt.phrasewise.com/discuss/msgReader$173 (which you may know)

So, the Open Source process produces fine "tools" but end user software that sucks. Your one of the most outspoken and most pragmatic spokesman for User Centered Design I ever had the pleasure to meet. Don't you have an idea how UCD and Open Source can be brought together.

And no, I don't think commercial CMSes suck that way that Open Source ones do. The big ones, yes. They suffer from featuritis and the desrire to lock the user in, once theybought the six figure monster. But some of the smaller and cheaper CMSes already do quite a nice job usability-wise, because thats the only way - besides the price - they can compete with the biggies.

hmm...i'll agree with justin, textpattern is very streamlined for the end user although the documentation is still being worked on...

i've recently started to write my own cms, to learn php & xml so these recommendations come at a good time :)

Oh, finaly.
I've been waiting for this post. Most likely it should come from you. And there it is :)
I've tried a bunch of CMS systems myself - jus to pick up the good points. I had no illusion there is a system more or less doing that I want.
Mambo has nice install system.
Other have some nice features. All suck in templating - why developers feel a necessity to mix code into presentational template. Never got it.
And some people should read "Inmates are running the asylum".

Having been invovled in the development of two CMS's now (one of my own) and also having been involved in a few projects where they were implemented, I am still amazed that people believe that the CMS should do everything for them.

At least where creating content is concerned, if a person can learn to deal with all of MS Word's foibles then surely then can learn how to use a tool to insert an image (and perhaps add an attribute if needed).

Website templates, css, perhaps php functions and such, should all be relatively easy to access and either cut and paste from a document library or straight out edit for those who know how to do so.

In the end, every good site is custom so why not make tools that allow that to happen right up front?

Amen.

What do users want? Its hard for much of the open source community to think about this since many of the projects are written with a Developer to Developer mentality. Documentation is usually scarce, but thats not an excuse when you look at a tool like Outlook 2003, which I have never opened a manual for, but I can easily send out email and put events on my calendar.

Its simple really, make it easy to use, and people will use it. Part of the solution to making it easy to use is echoed in your comment Jeff about giving the user immediate rewards in the system. If I like a system I will explore what else it can do, but if I have to assign tons of permissions or switch around content blocks or create complex little modules just to get my home page up, forget it. I can code html faster then that system can make a page for me. Totally worthless.

A content management system should be just that. Not some crazy code behemoth with featuritis. A goofball from the marketing department should be able to log in, see where they can create content, paste it from Word (ugh) save and close. All the cool bells and whistles like creating Atom/RSS feeds, trackback features, archiving, etc should be done without having that same markteing goofball be responsible for executing those tools, because he WILL screw it up.

Thanks for your thoughts on the subject, Im definitley going to be taking close look at my home rolled CMS for my company and make any neccessary changes. Its hard to step away from a project sometimes and get a fresh perspective.

Nice points, Jeff, and well said.

I've been searching for a new platform myself and have come up very discouraged.

Another thing that really scares me about some of these Open Source CMS platforms is that they are one-person efforts. I know that I could take TextMangler and do whatever I want with it while the rest of the world waits for Xiu Xiu Barnhardt (the original author) to return from his tour of duty with the Peace Corps. But...if I wanted to do it all myself, I'd start over from scratch.

And my individual effort would be less useful to everyone else for pretty much the same reasons.

Anyway, I believe that a properly designed, well documented platform has to be a group effort. A strong leader is needed to encourage design and coding discipline, but there is far more work than one person can accomplish.

I've been looking for a project to put some effort behind, but haven't found it yet.

I'll keep an eye on the comments to this article in the hopes that you've sparked something here.

Your timing is great. I've actually begun the process of building a CMS to beat all CMS's! (okay, that's a pretty bold statement but you get the idea) I'm documenting my progress over at my site http://www.snook.ca/jonathan/. I've been inspired by apps like Basecamp which have shown that there's a viable market for user-centered design.

[blockquote]
Users of a public web site should never -- never -- be presented with a way to log into the CMS.
[/blockquote]

I agree the prominence systems like Drupal and so many of the /. clones give this feature is absurd.

However I think you're overstating your case. Unobtrusive edit/admin links can actually make a world of difference in dealing with unsophisticated users (not to mention providing handy shortcuts), and is a feature I've been asked for on numerous projects.

People are struggling with figuring out how to find their own website, and now they're supposed to learn how to find some hidden page on their site as well? Too much to ask of many folks.

I started to write a comment from my point of view as a developer of Bricolage, but it got too long. So I posted it in my own blog. Comments welcome.

"Unobtrusive edit/admin links can actually make a world of difference in dealing with unsophisticated users"

None of my clients would allow an "Edit this page" link on their sites. But you're right, I am reacting to the /. packages that lead with that feature.

As an alternative, I generally recommend that when someone logs into the organization's intranet, there be a way to access the pages they have permission to edit. And most employees I've worked with can find their intranet.

Another appealing option is to simply install an "Edit this page" bookmarklet in the content creator's browser. Have it bring up a log-in page, then place them directly in an editing interface.

I'm one of the devs of Drupal. To be honest, I think you're being a bit overzealous by saying Open Source CMSes suck. Every CMS out there is different. Drupal is oriented at communities.

The biggest different in CMSes, to me, is whether you manage content for the site or manage content on the site. This is really the same focus shift as public websites vs intranets. If you think CMSes should only do the first (which is the impression I get), then you are underestimating the demand.

Most Drupal installs out there are on cheap Apache/MySQL/PHP hosts. Making a CMS which installs and runs automatically on such systems is a lot trickier than it sounds. And yes, these people are a significant part of our audience. Is telling people to set their configuration directory permissions to 777 a good thing to do? How many people will forgot to turn that off after the install and end up with someone defacing their site (even if you told them so)?

"Users of a public web site should never -- never -- be presented with a way to log into the CMS. "
"But the only sites that really require this functionality seem to be open source projects; this is an indication that you're badly misinterpreting your audience."

Drupal has a log-in box by default, because Drupal has a public registration feature. If you don't want that, you can turn it off along with the log-in box. The registration system is identical for public users as for administrators, which makes it easy to add interactive features to your site. Not having the log-in box there would make 90-95% of all Drupal sites useless. Again, great for communities, bad for static sites.

"None of my clients would allow an "Edit this page" link on their sites. But you're right, I am reacting to the /. packages that lead with that feature."

Drupal has had this for a long time, and it improved usability tons. In 4.5 we switched to large, visible view/edit tabs at the top too.
With a separate editing interface, you force your users to reach a piece of content in a different way just to edit it. People usually know how to browse their own site, so the edit tabs/links on the page itself boost usability by giant leaps. Of course, these edit links are only visible to people with the right access in the first place: having that link there for non-priviledged users would be unacceptable. I suppose you're thinking of CMSes which spit out static HTML for the visitors.

"All suck in templating - why developers feel a necessity to mix code into presentational template. Never got it."

My answer would be: because a website template is not like a letterhead or stationary. A templating system expressive enough to let you put content exactly where you want in exactly the position and order you want IS a programming language, whether your like it or not. Tableless CSS is promising, but still requires that the HTML be carefully crafted and has enough wrapper divs so people can have their drop shadow picture frames, rounded corners and whatnot. And it will break horribly if you put a wide table or picture in it.
For templates, there's also the debate of push vs pull (does the program drive the template, or vice versa): for a small blog site, it's easy to define templates for every page, and simply pull the content from the system/database. For a large portal with different features and areas, it's inpractical and you're forced to go to push instead.

In Drupal, we allow you to use different templating engines (and in the upcoming release we made it easier to install them: just drop them in the right directory) ranging from a simple 'xtemplate' (only conditional logic) to 'phptemplate' (where you do anything you want through PHP). This seems to be the best solution when everyone insists that their templating approach is the best.

"Another thing that really scares me about some of these Open Source CMS platforms is that they are one-person efforts."

This is certainly not true for Drupal. We have 10-20 people actively contributing to the project. In fact, whenever I read a comment by people saying they made their own CMS, I worry about the result. Implementing a good, usable, pretty, secure and flexible CMS in a reasonable time is beyond the abilities of any single programmer, no matter how good he or she is.

I'm pretty sure you won't like Drupal, because it is not made to fit your needs. Maybe we need a taxonomy of CMSes, because obviously the term means different things to different people.

I think Markus Breuer hit the nail on the head when he said that this is not so much an opensourceCMS usability problem so much as it is an open source software problem. If I may be permitted to rant a little bit here about what gets my goat ( And I'm sure everyone else's ).

<rant >
The whole see a program that rocks, imitate its functionality, but not its usablity is one of the tragedies of Open source. I think I may be one of a few breed of Designer/Developers ( Web and Desktop) out there who actually consider how their softwares work in addtion to how usable it is and how good it looks. I say this because I've looked. I'm neurotic to the point of downloading tons and tons of software web and desktop, uninstalling and installing just to try and find one that matches up and then ending up having to settle.

Good software design should ALWAYS progress in parallel. From the perspective of the user and the perspective of the developer integrating features. I love open source, but until mainstream opensource software matches up to the parameters you specified above, it is always going to be lagging behind commercial software.
</rant >

On the aspect of doing something about it, I've been entertaining thoughts these days of creating a website that rates open source software (Web and Desktop ) on the criteria you mentioned above and applauding the authors of those that do match up, encouraging those that have worked hard to implement those features and giving other developers something to work towards. Suggestions are welcome

opensourceusability at yahoo dot com

Jeffrey, here is your chance to help make a better open source CMS:
http://drupal.org/node/11293#comment-17359.

Usability: do not include trailing punctuation in your URL auto-linker. ;)

http://drupal.org/node/11293#comment-17359

I believe you are the one "misinterpreting your audience".

Implementing a website is complex, technical matter. Never forget that. So implementing complex an dynamic websites is complex².

If you buy a house, you expect a finished, working product. That is because it is already developed (architects, engineers) implemented (engineers, builders). That is because developing a house is a complex matter. You pay for that, a lot, but it is the case.
No-one out there expects a house to build it self., or expects it to be easy to build one. If someone decides to build a house, then he or she should have enough technical knowledge and abilities to do so.

If someone builds a website, he or she expects it not only to fit exactly his or her needs, he or she even expects it to build itself.

If Joe User wants a complex site, he should hire people to build it for them. If he needs it to fit his exact needs, he should also hire developers.

A CMS is not a finished site. A CMS can be seen as the building material out of which a site can be build. Sometimes houses are build out of prefab roofs, four wall and some windows, and sometimes even the bricks are custom-made.
Same goes for CMSes. Some deliver sites in only one way, but are almost finished. Some need lots of knowledge, time and budget to be implemented.

Implementing a site requires knowledge, this is a simple fact, you see it I see it. You think it should require less knowledge to implement one. I think you are wrong at that point. There are enough solutions out there that require little to no engineering (blogger, tripod).
But if you are not happy with a pre-made house and want it to be exactly yours, you need technical knowledge, or hire the people who have it.

"Implementing a website is complex, technical matter. Never forget that. So implementing complex an dynamic websites is complex."

Complexity and usability are very different things, I'm arguing for the later in open source software. Let me explain through example.

Many years ago, before the Web, I worked in the newspaper business. We used a program called Quark XPress to produce our product. Quark made an incredibly powerful and complex product, filled with controls for things few people understand. You can set tolerances for trapping, and have your Postscript output modified for dot gain. There are templating and workflow features that blow away most of today's CMSs.

But you know what? Just about any computer user can sit down with Quark XPress, open a new document, and have an attractive newsletter designed and printed in about an hour. Features are intuitive and discoverable, and they have few dependencies. You aren't *required* to set the trapping for your newsletter; the app picks a workable default for you.

Applications like this adhere to a simple mantra -- one that I though most developers followed when designing their apps:

"Make simple things easy, and hard things possible."

That's all I'm arguing for.

The most widely used 'CMS' that I've seen is FrontPage. Granted, the results are not always pretty, and it really isn't a CMS, but it is very easy for people to use.

My take on that is that a really good client application is needed. Either that or the inline editing features on the web page need to be vastly improved.

veen, you are spot on. Seriously. I've researched endlessly to find an open-source CMS project that had what I was looking for and couldn't find one. (Actually, Lenya came close but c'mon, haven't they heard of a screenshot? Is all the configuration in text files?)

It's a truly confusing market for even technical people to find a product that meets the needs of their organization. MOST companes pushing open and closed source CMS projects do a tragically poor job of demonstrating and documenting what their product can do. Closed source projects are truly frustrating in pushing their marketing speak (which is the same rhetoric every other site about content management is pushing) and require you to CALL them just to get any information.

And THAT'S why I decided to build my own...

Jeff, good article.

http://opensourcecms.com, while being a really nice resource, only covers the low end of the market. To get a more complete picture, you'd want to take a look at Plone, Apache Lenya, OpenCMS and a couple others as well.

http://oscom.org/matrix/ is a good starting point.

I think to be fair, we should get a comparison of what you like in the non-OSS CMS packages on the market. At my company, we are evaluating Microsoft's Sharepoint Portal Server (for a very MS-centric environment) and Plone (for customers that either aren't MS-centric or want a cheaper solution). It seems to me that SPS suffers a lot of the same problems (which doesn't really surprise me, but that's another rant) What packages out there meet your criteria?

About your first point:

If your Web host has Fantastico installed, it takes a lot of the tech work out of installing your CMS.

--|PW|--

Veen wrote,

"But you know what? Just about any computer user can sit down with Quark XPress, open a new document, and have an attractive newsletter designed and printed in about an hour. Features are intuitive and discoverable, and they have few dependencies. You aren't *required* to set the trapping for your newsletter; the app picks a workable default for you."

I believe that for CMS's to work like that, they will have to move toward the distribution model, much like with Linux. I'm currently working on a project with CivicSpace Labs to introduce a better "out of the box" installation for the CivicSpace distribution of Drupal. The idea is for users to choose between three basic site profiles, and by answering a few questions, have a running site immediately after: http://civicspacelabs.org/book/view/683

By the way, plenty of people that use and work with Drupal would love to see you accept Dries's offer and turn this argument for increased usability into reality (FYI: Dries is the founder and lead developer of Drupal).

"The biggest different in CMSes, to me, is whether you manage content for the site or manage content on the site."

Bor? That kind of statement will leave everyone but programmers blinking their eyes in confusion.

Jeff, you probably shouldn't only limit your suggestions to open source CMS systems. Vignette and others manage to fail at least as impressivly as any of the examples you listed.

[quote] '"The biggest different in CMSes, to me, is whether you manage content for the site or manage content on the site."

Bor? That kind of statement will leave everyone but programmers blinking their eyes in confusion."' [/quote]

Let me clarify what I mean.

Some solutions exist to let you build websites. The content you manage are articles, images, downloadable files, etc., which are viewed by visitors. Visitors see a static website, and have no control. Typically, the administrators have access to tools which allow them to browse content differently, while users are forced to use a simple tree or navigation bar.
This is managing content /for/ the website. This seems to be what Jeffrey Veen is looking for.

On the other hand, you have systems where you manage content /on/ a website: visitors can post files, links, discussions, etc. Classifying and organising content takes a higher priorty here. The site would have browsing interfaces for files, image galleries, a search engine, etc. There is little or no distinction between visiting and editing: most people will do some of both. This is more like the typical intranet for example.

Firstly great article Jeff.

I'm one of the Mambo devs - was pointed to this article by another Mambo dev. Your comment on mambots cracked me up :)
We're guilty as charged, though I dont think the use of our application specific terminology was intentionally aimed at making it harder for new users. Inclusive and specific jargon is unfortunately something that predominates human nature and isnt limited to simply OS CMS's - it pervades life. Its a way that people like to seperate themselves from others and to identify themselves as belonging to a particular commmunity/group. In this particular case I think this was a community created jargon. However, I do agree that one should always attempt to reduce jargon and continually advocate the use of 'plain-english'.

Like anything a product must satisfy and meet the needs of its end-users. So it really depends on clearly identifying your market segment and your end user. So a blanket comparison of (in this case) all OS CMS's may not be all together fair, in that each may be targetted at slightly different users, who have slightly different requirements and abilities.

However, I agree usuability & simplicity should be the mantra we should all be adopting and that it is very easy to be mesmerized by the dazzle of new technology and functionality.

As a developer I think it is easy to become insular and loose touch with the 'common person'. The key I think is to keep yourself open to feedback and to listen to the community.

You have higlighted some important considerations and ideas that I know I and the other Mambo devs will be considering.

Cheers
Rey

I agree that there is no CMS out there that really does its job perfectly. The best CMS I have found is Drupal ( http://www.drupal.org ), which I currently use, but it needs to become a lot better.

Hi Jeff, very nice article.
I'm a CMS developer, alone in the company where I have follow the designers layout.
Designers > Programmers ( that's what happened here )

To me the fastest way to achieve what the designers want is, create the CMS yourself . The holy 3 column layout,2 culums, web page scroll to left and the latest one...design without table a.k.a CSS ZEN alike...you name it...sometimes they want seperate administration,if they're not happy...I've to embed it within the presentation layer.

For oepnsource CMS, I've tried some of them
- eZ Publish
- Nuke s
- Drupal ~ my favorite for the moment

As developer, we also need simplicity and easy to start with...so I ended with

Smarty
PEAR
Apache Bench
LAMP ( Linux Apache MySQL PHP )

All your points are well taken. I personally work on an OS CMS but can tell you from experience when you start bringing up these kinds of issues you tend to get ignored. The way it works is if you can update or make the changes great, if you make suggestions then more than likely they won't get implemented.

Reality, devs don't have to take into account the newbie users because the reasoning is they can use the system, i.e., it works for them and "scratches their itch" and that's what counts right?

Having said this, strides are being made in the project I'm working on and I'm sure projects will look at user centered design if they want to evolve/grow.

As you suggested though, the quickest fixes would be to streamline the terminology, use plain-English!

After reviewing most of CMS's on that site, I have to agree. None of the CMS's I saw had an intuitive, tree-like view of the categories and sub-categories you create (many of them didn't even have a way to nest multiple categories), and yes, I was frustrated to the fact that most of them are blog-centric.
I'm currently working on a CMS's for personal use that lets you create your own tree of categories, and then you can attach to each categorie texts, pictures, banners, news, etc. The idea is to have the navigation design in this category-tree (a category being a page inserted in a tree structure) and then information "elements" (text, images, other categories) "hang" from any category. Then I'm using pat Template to completely separate logic and content from presentation.
It's not ready, but looking pretty cool on my staging server (I implemented a prior version for a client and he was feeding his website within the first day).
If anyone is interested...

I love eZ Publish (www.ez.no).

But then, I work with it every day (www.FireBright.com).

However, it's got few of the drawabacks of plone (natively CSS/XHTML), scales, and doesn't look like open source software. Check out the new interface improvements coming out in eZ 3.5 (before Christmas).

In terms of rolling you own, you can do it, but it's a lot bigger task for most organizations than many people care to take on.

That said, I think Plone, EE, and Drupal represent the best choices in the market right now.

J

Oops. I mean that in an "in addition to eZ publish kind of way".

BTW, fantastic article, and great comments.

I'm pondering -- we really do need a better directory for open source CMS solutions. The difficulty is that categorizing them is just about impossible, as they vary tremendously in capabilities.

Has there been any work done to categorize open cms solutions, at least in terms of figuring out the basis by which they should be compared? I can't find squat!

J

May have a look at Lodel if you want something different. Lodelscript -- the template langage -- is really simple and has been designed for people who only knows HTML (and like to learn a little bit about SQL). Site look cannot be changed in the interface and provided templates are basic, because we don't want column sites, because users have to create their site, not to let this task to CMS developpers. Import of document direct from rtf, doc, sxw format make easy life to editors. French language at the moment :-( but we are working hard at the internationalization now.

There is a CMS that was developed in exactly that direction. It's called SPIP and is not well-known to the english-speaking world (so far) because up to recently it was only speaking French. But now it's got a whole English-speaking interface, too. (and Spanish, and German, etc).

The only great principle governing any decision in SPIP is this: how do you increase the quality of the publication system without making it a hassle on contributors? More specifically, the whole system was done with one user in mind for the primary focus: the user who doesn't know squat about computers.

It takes five minutes to install it at first, all the MySQL work is done by an installation script. Create a few categories, reorganisable ad nauseam every time you want to move them around.

Create an article. Click publish and bam!, you've got it working.

Where the trouble lays (yeah, everything couldn't be *that* perfect, could it) is that the templating system needs much work, although it's written in layman's terms (again, the templating system only speaks french at the moment, sorry for that).

Yet this CMS has an incredible advantage: everything can be turned around to fit your needs. A few websites that use it:
- http://www.uzine.net/ (tables)
- http://www.spip.net/ (tables and css)
- mine :) (all css)
- http://www.spip.net/en_article2009.html lists many sites done with spip. Again bear in mind that the engine is the same, only the system delivers such a polymorphic code that anyone can create very different templates.

In short: although templating *does* require work (and all your points are duly noted, Jeff, but after all it's a *job* for many people to code templates for CMS's, be they open-source or commercial), the sytem matches

hmmmm. Drupal is not really about content managment in my opinion. It's about having an online community. a job it does very well. I agree that it is very difficult to use for a non-geek.
I built http://wqb.villages.co.uk on drupal and I'm quite pleased with it. I did have to heavily modify it so that it worked with postgres better and so that a user could login if they really wan't to but it is not obligatory.

Miles (13)

I find it very difficult to regard to article as anything more than flamebait.

"10 minutes from download to running, never send a user to the command line, never force open a text editor."
Is this the way you should manage your *server*? Why should a server-side CMS be *more* easy to install than, let's say, a webserver, mailserver or a database? They are not apps for client side newbies.

"Make it easy to get started."
Most CMS's are easy to get started. You want to disable functionalities and start with wizards people have to run through? Please, one MS Office Paper Clip is more than enough.

"When I first log in, I want to create a Web page. Next, I'd like to add some styles to it. Then, I'd like to make links to some other Web pages."
Right, when *you* log in the first time. Let other people make their own decisions, ok?

"Stop it with the jargon already. I don't know what a portlet is. Or a component, module, block, or snippet."
This is only relevant for admins. So what is the problem? Apache has modules, Linux has modules. Something wrong with that? What else would you call it? A ... "thing"?

"Users of a public web site should never -- never -- be presented with a way to log into the CMS."
Created your own dogma? Most people only want *one* webpage, not a separate one to log in. Now, who is listening more to want people really want? Most login-boxes are non intrusive, anyway. And if you don't like the default, change it.

"Separate the administration of the CMS from the editing and managing of content."
A good CMS's does this, based on roles and permissions. Look around, there are enough.

"this is an indication that you're badly misinterpreting your audience.
No, it's not. The main audience for open source CMS's are not closed companies, but non-profit organisations or virtual organisations like internet communities. Creating an account and be to able to log in, is therefore a very good default. And if you don't want it, customize it. I fail to see your problem.

"Yet so many content management systems bake the 3-column layout so deeply into the code that it takes considerable hacking to get rid of it (I'm looking at you, Plone.). It may be a couple of years before everyone can start using table-free layout,"

Not clear what are you criticizing here: 3-Column layout (doable in CSS) or using tables for markup?

"I'm looking at you, Plone."
Simply choose the tableless skin, and all the markup gets spit out linearly, and styled with CSS, like you wanted. A lot of effort has gone into this from Plone 1 to Plone 2, but you fail to even acknowledge that effort.

"Where does this assumption come from?"
euh, because most websites only have one , two or three colums? Let's see, how many columns has this blog, or w3.org?

Plone doesn't have 3-columns "deeply into code", It's just a template with macro's that you van configure. If you want something more complex, use something like CompositePack. Or do you want end-users to write their own CSS?
then why not let them write static HTML, and get rid of the CMS altogether?

For people actually developing CMS's this article is pretty worthless. From this article, I have absolutely no iota of evidence the author has any real experience with CMS whatsoever. Almost none of the *real important* topics come up.

It just looks an article of a 16-year old frustrated newbie that got lost during installation and fainted when hearing the word "module". I guess the guy described in the bio must be referring to someone else. And if you really are an expert, please write something more researched, less trivial and more significant.

On 06 Oct 2004, at 9:50 AM, noneedto@nowhere.net wrote:

"I find it very difficult to regard to article as anything more than flamebait."

I wrote this to be provocative, and to spark debate. I stems from 10 years experience building Web sites, increasingly with sites developed with both commercial and open source content management systems.

"Why should a server-side CMS be *more* easy to install than, let's say, a webserver, mailserver or a database? "

It shouldn't. Those are way to difficult to install as well. I'm talking about the hard work it takes to translate powerful software to *everyone* and not just the technological elite who need convincing to trickle out capabilities to those they deem deserving. Guess what? You don't get to do that anymore. You work for your "users"; you serve them. Work that way.

"Most CMS's are easy to get started. You want to disable functionalities and start with wizards people have to run through?"

No. They're not easy. They're not usable. I have no interest in disabling any of the features of a software package, though I certainly advocate a simple way of making those features accessible and allowing people to feel as though they are making progress quickly. Why would you be against that?

"Right, when *you* log in the first time. Let other people make their own decisions, ok?"

Exactly! I couldn't agree with you more on this point. Let anyone do what they need or want to do intuitively and easily.

"This is only relevant for admins. So what is the problem? Apache has modules, Linux has modules. Something wrong with that? What else would you call it?"

I would ask users of a CMS what it should be called. Nomenclature is one of the most testable things in Web design. The bigger issue is that I'm advocating for removing Admins from this whole process. We don't need you. You just get in the way.

"if you don't like the default, change it. [...] And if you don't want it, customize it."

How? Almost all the systems I evaluated require me to get an Administrator to do this. Why?

"The main audience for open source CMS's are not closed companies, but non-profit organisations or virtual organisations like internet communities. "

Really? That's news to me and all of my clients. I'm working with a Fortune 100 company in the financial services space that is installing an open source CMS. Should I tell them not to?

"Where does this assumption come from?"
euh, because most websites only have one , two or three colums? Let's see, how many columns has this blog, or w3.org?

So open source systems are only for non-profit organizations based around communities that publish Web sites with columns? Wow, I guess I really have been misunderstanding the audience for this software.

Ah, flame wars. So much fun...

I have seen a content management system that does what you want. It's called WordPress. It is the best I have found so far.

http://wordpress.org/

I think comparing a DTP application and a CMS is like comparing apples to ... well ... elephants. Yes, they both are carbon based, but that's where it ends, doesn't it?

DTP app (Scribus, for instance) will let you drop together some stuff and create a page or two of semi-coherent text and images. However! You have to be a true master of impositioning to use the software to it's full potential and create highly coherent layouts that use styles etc... Not to mention, that you have to be a designer to make everything look good... And a writer to make it worth wile....

In an analogue way... you have to be a true web wizard to create coherent websites. No matter what size.

There is just no way(!) for a content management to be "easy enough" to use for 99% people that want to use it (note the word 'want' as opposed to 'need'). The remainig 1% is negligable and accounts for all others, who use some sort of content management already.

Face it. Complexity is exponentially proportional to flexibility. Have you noticed, how the most complex thing for most people is a white sheet of paper and a simple pencil?

Well, I'll own up to the Mambot :)

Jeffrey I now see what point you are making with nomenclature but I disagree as it makes it very difficult to then write documenation. If a module (developer's choice) is locally called a widget, addon, component (oops, now we have to rename the component)... The best Mambo does if at least provide a glossary in the doco's to explain what it means by it's particular 'jargon'.

> 3-column layout.
Many sites use them, many sites don't. Many CMS's are locked into a x-column layout, many are not. For those that are not you have to get on the case of the site designer for not being creative.

Jeffrey, to foster better debate can I ask you come into land on some of your generalities and sweeping statements. Take the best-of-the-worst (in your view) from the opensourcecms site and lead us (dev's particularly) by the hand and tell the developers' what their strenghts and weakness are (yes, all of them have both) from a non-dev point of view.

I'm particularly keen to know how we can make Mambo easier to install. I thought we had really got it down to an art.

However, I'll rightly take criticism of our Category management on the nose. This is a known issue and we are working on making the organisation of content and building a web site much better (lot's of legacy stuff to move out of the way first).

There are also a number of other considerations you need to make when choosing a CMS.

How big is the development team?
- Is it one person or a massive crew. Too big and too small can be issue however it's difficult to put a number to what is 'just right'.

Is the dev team healthy or is there dead wood?
- On sf.net you see many projects with 20 devs and yet only 2 are active. This usually spells out that the management of the project is adhoc or not healthy. If all are active and are diverse in their roles it usually makes for a better managed project.

Is development current?
- Nothing worse than finding the nirvana of the CMS world and find that last release was 2 years old.

Does the Dev Team listen?
- Are wish lists and support issues responded to promptly, politley, with due consideration, etc? Do the dev's have a take-it-or-leave-it attitude?

Is there a Roadmap?
- (ok, we've been guilty here for a long time) Is development adhoc or planned? Is scope creep a problem (not us, lol)? Are good ideas from the community balanced with code freezes to actually get some code out.

Is there a community?
- 3 users a good CMS does not necessarily make. Too small a community does not generate enough momentum for development. A larger community (while it can be problematic) usually has enough momentum to provide good feedback to the devs and take some of the more mundane support heat off the dev team.

Is the community healthy?
- A community of 10,000 zealots might seem great but if it's full of in-fighting then the dev's will spend more time going grey fighting spot fires = less development time.

Just some more thoughts for the melting pot.

There are also other issues. Do *you* the user know anything about publishing content to the web. Not the mechanics of the edit boxes and publishing but do you know how to pull a web site together. There are many styles to designing a web site and you will often find each CMS will look at site design with a different flavour.

A good designer can sometimes belt a bad CMS into submission (with severe limitations obviously). Conversely, a bad designer or user is never going to get any economy out of the best CMS.

>Face it. Complexity is exponentially proportional to flexibility. Have you noticed, how the most complex thing for most people is a white sheet of paper and a simple pencil?

So true, but the developer would return and say "Do you realise how much time, energy and resource went into providing you with that paper and pencil that you purchased off-the-shelf from the store" :)

> SPIP

Do they have a demo somewhere? Their own site is not what I consider to be a good advertisement for their product IMO.

> http://wordpress.org/

I like their category selection when editting an item. Very neat.

Now this is meat and potatoes stuff:
http://www.uie.com/events/uiconf/articles/veen_interview/index.php

"Most often, I find that businesses don't treat their web site as a publication... Instead, they view their site as a software project"

That is so true!

Jeff, I must apologise for my earlier tone. A bit of research shows that I should be listening a bit harder to what you say. Re-reading your article with that in mind I can concur with 99.9% of it (sorry, we've had some serious dev-knocking lately).

> I wrote this to be provocative, and to spark debate.

So what is a better virtual venue to continute the debate and promote better discussions on this issue (comments on a 2-column blogging system are probably not the most effective)?

Regards,
Andrew [who is sorry for spamming the comments]

Thanks for writing this, Jeff.

It's probably not suitable for your Fortune 100 clients, but in WordPress 1.3 we're introducing a "pages" feature which adds simple hierarchical content management. (Although after reading your article I think we should rename it "WordPageHyperlets.") The code actually comes from a fancy CMS I wrote earlier this year with advanced workflow and versioning and all that jazz, it's the best bits of that without all the crap no one used.

The motivation was that one of our number one requests is for multiple blogs. That's what people were saying but when ve looked at what they were actually doing it was something different, people who said they wanted "multiple blogs" fell into three camps. The first wanted to host blogs for a lot of people, Typepad in a box basically, so we did that with the new WordPress MU. The second camp genuinely wanted multiple blogs managed by a single person. The third and largest camp was using the paradigm of blogs which they understood to manage content in very convoluted and highly fragile ways. WordPress already had a solid API framework and metadata store with custom fields, so we expanded that system to include non-chronologically aligned data. What's nice is it can leverage the existing post infrastructure, so for example every page could be set up to recieve pingbacks.

Anyway now I'm rambling. Best of luck with your OS CMS search. I haven't found anything that hit the sweet spot either, for my projects these days I always end up using either my old CMS or WP.

What I guess it really comes down to is whether by "CMS" we mean "Personal Site Management", "Small-shop Site Management", or "Enterprise Content Management".

Even within these categories you have the distinction between "Code-hacker Site Management" vs. "Grandma Site Management".

The big beef I have is that, in my opinion, the two biggest audiences should/would/could be "Grandma" and "Enterprise". In both categories you have end-users who know 0% HTML, don't want to know, and should never have to know. They want to put content into the system and just have it work. But in reality, most systems target the much smaller "Code-hacker" audience.

I believe Jeffrey's main point is that the majority of existing "CMS" softwares fail on that key point. They are non-trivial to install, and/or are non-trivial to configure, and/or non-trivial to add content to. On top of that, many are rigidly coded allowing little more than colour and logo changes.

Couple of questions.... Droplets, Portlets, Snippets.... Could you give us coders some better names perhaps =)? I'm guilty of Snippets, but really, how could one better phrase "Little Bits of Editable Text"? Just curious.

Secondly, with the public login thing... Since it has to be web accessable, is just having the private login at a URL that is not directly linked OK in your opinion? i.e. anyone can go to it, but it's never listed.

On 07 Oct 2004, at 12:38 PM, tiger@kiwicore.org wrote:

"Couple of questions.... Droplets, Portlets, Snippets.... Could you give us coders some better names perhaps =)? I'm guilty of Snippets, but really, how could one better phrase "Little Bits of Editable Text"? Just curious."

On your system, "Snippets" means "Little Bits of Editable Text", on another system "Snippets" means "Little code objects that grab RSS files."

I've read documentation with sentences like, "You can use components to call modules that feed content streams into assignable page slots."

Um, what?

I don't have an alternative for individual names. Just be clear.

"Secondly, with the public login thing... Since it has to be web accessable, is just having the private login at a URL that is not directly linked OK in your opinion? i.e. anyone can go to it, but it's never listed."

Here's what I mean. Where do you login to edit content on these sites:

http://creativecommons.org/
http://economist.com/
http://www.ctb.com/
http://kcet.org/
http://thuleracks.com/

All of these sites have content management systems that they are unhappy with (they have been my clients in the last few years). All of them would benefit from Drupal, Midgard, Mamba, or Plone. They would never think of showing a login system for their CMS. In fact, I've honestly *never* had a client that would.

That's all I mean by that.

Re: login

Just to clarify, by login you are meaning a login to administer the site as opposed to a site where I login as a registered user to download my latest e-mag subscription (eg, www.phparch.com) or receive additional services.

In Mambo we distiguish between users that would log into the web site (say to gain download rights, be able to post comments, maybe edit your own content if you have that role, see secret stuff, etc) and users that can log into the administration client on a different url (manages users, templates, install things, etc).

Am I reading it right that this is the sort of model you are wanting to see??

Re: Jargon

"You can use components to call modules that feed content streams into assignable page slots."

When taken in context, as long as there is a glossary (and *hopefully* a pretty diagram) I don't see the issue with this. Of course, if that sentence is made without any qualification or explanation in the rest of the docs then the developer should rightly be shot.

Good article, good points.
Maybe you should not go to opensourcecms as they state clearly:
..."try out" some of the best php/mysql based free and open source software systems ...

Magnolia is Java based, and thus we cannot get a demo on that site.

While I am biased, please check it out ( http://www.magnolia.info ) and if you fell like it, write an article about how you fianlly found what you are looking for ;-)

And we do even have a glossary (and no mambots)

Cheers
Boris

Well I'm not as guilty as I thought with the jargon =) I was a little bit dismayed when THIS came up:

google-> define:snippet

A code Snippet is an object which acts like a little library with PHP code in it. Code Snippets can be used to store useful fragments of code that don't necessarily belong to styles: classes, utility functions, html templates, style sheets, etc... Code Snippets include documentation.

Sheesh. From a programmers point of view I can see why we end up with ridiculous names though.

class Little_Bit_of_Editable_Text { } just doesn't look as good...

Usability is not all about the UI. I agree with many of the comments in the original article and in the replies.

To me, it comes down to the simple reality that no one tool can possibly please everyone. That's never happened and the world of software is full of examples of similar tools with slight variations that appeal to different users.

I don't believe a CMS is any different. You can build your entire site using one tool (CMS) or you can use a combination that best meets your needs (eg. Drupal, phpBB, phpMyFAQ, gallery, the list goes on).

Each tool usually has some feature that makes it a better fit for solving a particular problem. Drupal and gallery both manage images, but the features of gallery (especially the desktop front ends) make it a far easier tool to share images.

When you build a website you're really building a system environment. Just like we don't expect a single application on our desktop to serve every need, we can't realistically expect to find one for building a website.

What we do expect of our desktop applications is that they stick to the principles of our system environment.

Do they share my identity seamlessly across the tools or does each one force me to create an account and log in before I use it?

Do they adhere to a common authorization model or does each tool have a different idea of which groups exist and what they are allowed to do?

Do they manipulate similar data objects and expose consistent interfaces to the objects enabling me to share data between tools or do they each have thier own concept of what a fundemental unit of data is and what it's interfaces are?

If you try to build a system using multiple tools that each posses unique, powerful features, you'll quickly realize that most web tools (CMS or other) fail terribly.

One solution to this problem is to use middleware that uses standardized interfaces/protocols to help share these abstractions across application and system boundaries. For example, build a system that enables people to communicate via email lists, have that list define the members of the community and provide a phpBB style forum interface for web-based participation on the list.

Getting the component applications to agree on user identities, authorizations, and to share data objects is quite a chore today.

I view CMSes as operating systems in their infancies. This "middleware enabling" of web applications is an area that I'm actively working on and is a large area of research on Internet2 (http://middleware.internet2.edu)

Making it possible to have web applications work together without requiring each application to give up its useful individual features is an important aspect of usablity.

I'd be very interested in comments about this. I'm targeting drupal as one of my applications so I've cross posted this comment to the thread on drupal.org discussing the better open source cms.

I read nothing particular to Opensource or Not opensource software

many commercial CMS are ugly and not convenient to use, many opensources ones too.

the point is not about opensource software (there are many perfectly "usable" opensource software, with people eager to improve : gnome, mozilla firefox, and others)

the point is about the lack of usability and serious in many web tools.

Usability is the most complex problem to solve in software, it's not simply technicals (can I say my daily job prooved me the windows world of software is not enough accessible and useable ? )
it's a mix of psychological knowledge, taste, good technical choices BEHIND, good interface, simplicity but not stupidity, and a very specific goal for the tool (not the kitchen sink).

Good points one and all...

I really like Expression Engine. It it's not open source unfortunately, but worth every red cent. And, unlike Movable Type, you can use to build as many domains as you'd like, and you only have to purchase one license. I've built two so far, and with my subscription only site, was able to integrate it nicely with a billing system, bulletin boards, and soon, PhotoPost.

I've been using and experimenting with different CMSs for a long time. While I generally agree with you, Jeff, on some points, I have to disagree specially on one.

There's a substantial number of CMSs which have greatly advanced in the installation process. Many of them simply require you to upload the files and then present you with some simple form or wizard which asks you some data.

You can't get simpler than that. You can't not ask for database configuration, an admin login/password and maybe a couple of details more. and yes, there's a couple of systems which don't ask you to do anything more than this to get a site running.

10 minutes from download to running, no tinkering, no file editing? Yep. They have already achieved that.

You may want to take a look at this report, which gives similar conclusions:

Open Source Content Management Systems: An Argumentative Approach

http://www.michelinakis.gr/Dimitris/cms/

On 09 Oct 2004, at 11:16 AM, ggbraschi@indra.es wrote:

"10 minutes from download to running, no tinkering, no file editing? Yep. They have already achieved that."

Which? Let's get a list of them together. In fact, wouldn't be great if we could build a chart that ranks packages based user-centered criteria rather than technology features?

Which under 10 minutes? Mambo for one.

I shall get some of out benchmarking zealots onto it :)

Try WordPress. http://www.wordpress.org/

Really, not only do open-source systems suck, but PHP sucks as WELL and makes them worse..

Has anyone here had experience with TYPO3? http://www.typo3.org .

Many of the CMS solutions mentioned here are Portal type (ie Drupal, phpNuke etc), or blog-CMS's like MT, Wordpress etc.

TYPO3, seems to be more of an enterprise CMS. I had a project where I started an evaluation of TYPO. But that project got shelved. I'd be interested to hear if anyone has experience with it, and what your impressions have been.

Typo3 is one of the CMS products evaluated in the report mentioned in comment #59 (a few comments above).

Its definetly one of the best open source CMS products and definetly better than many commercial solutions. Though the problem with Typo3 is: complexity. Just take a look at it and you'll realise that you need several months of learning before you can build a proper website.

-- Start Quote --
I think the flexability of CSS Zen Garden coupled with the dynamic loading and editing of content would be the best thing ever!
-- End Quote --

Funny you should mention that: the CMS I've just made (and am currently finishing up for release) is doing -just- that!

My CMS uses a clean, semantic set of templates (all database-driven) with virtually no presentational markup anywhere (a few BR and STRONG tags). The styling is done completely via CSS, and since we're going to start a service with this CMS soon where the templates are all set and can't be touched, we're going to create a CSS Zen Garden-like system so that they can choose their own style. Additionally, if they like a unique one or a more complex one, they can order one from us for a small, one-time fee, and it'll be most easy for us to add it as it involves only one thing: creating a new CSS sheet.

Also, every page on the site is dynamic, allowing for complete power in using the Permissions system, for instance to have Edit page links only to people who should see them (e.g. a site owner with a cookie set).

Downside for the interested people here is that it's not Open Source as it's made by me for the company that I work for. Additionally, since it uses PostgreSQL (because that's infinitely better than MySQL and its incredible lack of functionality) it's not really useful to distribute it to people to install on their own in the first place. Very few hosts have PostgreSQL at the moment, which is a shame.

-- Start Quote --

-- -- Start Sub-Quote --
"Unobtrusive edit/admin links can actually make a world of difference in dealing with unsophisticated users"
-- -- End Sub-Quote --

None of my clients would allow an "Edit this page" link on their sites. But you're right, I am reacting to the /. packages that lead with that feature.
-- End Quote --

Indeed, a big problem is that business don't want an "Edit page" link anywhere on their site, so what I've come to do is only display such links to people who are currently logged in and have permission to edit that particular page. In my CMS, I use 2 separate logins: one for the site, and one for the Admin panel. The site cookie doesn't time out for 3 weeks, but the Admin panel cookie can be set to work as a session-cookie (= gone when browser is closed), or time-based (15 minutes, for instance).
When an Admin panel cookie is expired, users who are still logged in on the site itself will still see the link, but once they click it they'll have to re-login on the Admin panel, for obvious security reasons.

We've found that this approach works very well for our customers.

-- Start Quote --
Most Drupal installs out there are on cheap Apache/MySQL/PHP hosts. Making a CMS which installs and runs automatically on such systems is a lot trickier than it sounds.
-- End Quote --

I disagree; yes, it's tricky, but not that much in my experience. Various versions of PHP and MySQL behave differently and all that, but with some testing and public beta testing, you'll get an awful lot of those issues worked out in absolutely no time at all. Most of them require only a tiny IF (versioncheck) conditional, really.

-- Start Quote --
On 06 Oct 2004, Noneedto said...

I find it very difficult to regard to article as anything more than flamebait.
-- End Quote --

And I find it incredibly difficult to take anyone serious who is afraid to use their own name. In all my life online (which, I can assure you, is pretty long) I've noticed that those who hide behind anonymity usually have little to show for themselves, nothing to prove, and even less to say.

More on the article in general:

The article points out a lot of serious issues with CMS's in general, not just Open Source ones. The use of jargon, the complexity, the amount of HTML in the code... these issues are found in most such systems. And where not, it's usually because the CMS is far too limited in what it can do _to be able to have_ such problems in the first place.

It's a good thing that there is more focus being put on CMS's and their usability, these days. Usability in particular is a giant problem on the current Web, something I bet everyone here is quite aware of.

To me, these are really the basic 'rules' that one should follow when creating a CMS:

- always focus on usability and let a clueless person test it out every time you finish a part of the CMS, right from the start.
- keep all HTML out of the code (PHP, whatever)
- never show more to a user than they really need, and use simple, descriptive names for everything (ie. no jargon whatsoever, anywhere!)
- stick to W3C standards for structure, styling and accessibility; they help immensely in making your end product be usable.

Okay, I didn't quite say everything I wanted to say, so maybe I should just write an article on the issue myself and put it up on my site. If or when I do, I'll inform people here if interested...

Typo3 really rules. I started working with it more than a year ago and it is indeed rather complex and asks for a certain learning periode.
But for me it was worth the investment. And I don't know any other open source cms with so much documentation material: two books, more than hundred online documentation tutorials and hours of video material.

The possibilities and functionalities are really overwhelming and it is for an editor very intuitive and user friendly. Ones you're able to update and enhance websites with Typo3, you wouldn't want another web building and site maintaining tool.

Reaction to #51:

http://creativecommons.org/
http://economist.com/
http://www.ctb.com/
http://kcet.org/
http://thuleracks.com/

4 out of 5 are 3-column-sites. :)

On 10 Oct 2004, at 5:05 PM, rvtol+veen.com@isolution.nl wrote:

"4 out of 5 are 3-column-sites."

Who's choice was that?

[quote]Who's choice was that?[/quote]
Jeff, from what angle are you wanting to come?

The answer could be:

1. The client, who maybe empolyed a marketing designer to come up with an unimaginative 3 col design and then gave it to a contractor.

2. The developer/vendor who presented the client with several designs and it's the one they picked (could it be that they indeed rejected a non-grid-like design, we don't know). Of course, we don't know if the vendor was locked into a x-column layout by the CMS.

However, I don't see this as a CMS issue but one of design. Look at a book, newspaper, magazine, tv screen. Except for some kids books they share a fairly common trait. They are rectangular. Most print media (there are exceptions) divide this rectangle into a grid of some sort. A paperback is a 1x1 cell. A user manual might be a 2 or 3 col layout. A newspaper may be an assymetric, heavily nested grid.

I don't see to many publications designed with content in bubbles or diamonds or random shapes (you do in advertisements I will concede). However, a car dash *would* be an example of a non-columnar user interface. Maybe there is something in that.

Whether it's right or wrong, we are conditioned to media being laid out in grid fashion. But web page design is really another issue and off-topic for this thread. However, if the CMS locks you into an inflexible layout it is an issue but it is quite unfair and wrong to infer that ALL Open Source CMS's (particularly those previewed at the site you mention - which runs [plug]Mambo[/plug]) force you into an 2 or 3 column layout.

Maybe part of the problem is that coders are willing to do the work for free. For the love of it. On the other hand, how many "usability experts" or "design experts" do you see who are willing to do the same? They're all too busy sucking down $75/hr or more to design goofy logos and button templates to be bothered with contributing to an open source project.

Word up, Veen!

I'm in charge of development at umbraco - a company developing an open source ASP.NET based CMS (GPL Licensed).

I think the problem with many open source cms' is that they're made as a tool for the developers who makes them :-/

We've spend tons of hours working on the UI and a lot of time listning to designers and IA's telling us what kind of system they need.

We've just released the beta version of our CMS, and you can download it here:
http://umbraco.org/download

However a lot of the UI still has parts of Danish UI, but we're working hard on translating it. Probably ready by the end of this week!

You can see screenshots here: http://umbraco.org/screenshots and read about features here: http://umbraco.org/features.

Please mail me of you wanna know more or I can help!

/n

I kept hoping there'd be a resolution to the original post! No such luck.

I so agree with Jeffrey's rant. My case is somewhat similar. I guess. I've installed (and uninstalled) - mostly successfully, I might add - some 10 or 12 various CMS packages. No problem with most of the installations. Sometimes no problem with the customization. But, without fail, the ones I liked were huge uploads to start with and, even after I selected and de-selected modules, I still had all this bloat on my server.

And conversely, the ones that were a more manageble (pun intended) size didn't really offer a full framework to build on.

What *I* want is a CMS system that lets me (really, just me) manage content! I don't have forums or multiple users. I prefer to write my own HTML or at least my own templates. My own look and feel. That would come under Jeffrey's separation of content and structure.

I want a gallery but I can add that on. I might want a blog but not yet. I do want a shopping cart for selling photos from the aforementioned galleries.

But my company (a one man show) also offers web design and selling my services as a writer. So I need an entry section that's not a gallery.

Now I know I can code my front section and then link into my gallery and/or shopping cart.

But I'd soooo like a package that would provide a framework for me to keep consistency and make updates and changes easy. The gallery doesn't/shouldn't be a silly browser based thing. I can FTP my photos up just fine. But I'd like the navigation of the galleries to be within my CMS framework. Maybe it's FTP that separates CMS from some other nomenclature. I don't much like the slowness of browser based upload systems. Does that take me out of the CMS picture?

I know just enough about all this to be pretty dangerous. I know that. Also don't know enough to roll my own.

And I'll keep trying to find the system that gives me something I can work with.

Bottom line is that I know I can make my website; I've done many of them. But I'd like to be able to offer the package concept as part of my web design services. To do that, I have to have one I'm comfortable with and that won't force my client to go out and buy 500 MB of hosted space. I figure if I can find this magical CMS, I can both use and offer it.

OK. That's my rantlet. I fully appreciate - really! - the wonder that OS brings to us. And I'm not carping that what's out there is great. For what it does. But it sure would be nice if someone would see the need for the small single user business in the mix.

O.

Amen to that, Veen.

I would add just one point to your list: please make your URLs nice and human readable! I mean, what is with the URLs like:
"www.example.com/component/option,com_user/task,UserDetails/Itemid,15/", or
"www.example.com/index.php?option=com_rsgallery&page=inline&id=1&catid=1&limitstart=0" ?

And this is with "nice/SE friendly URLs" turned ON! Imagine what it would look like on your business card or corporate broshure, or even worse try explaining it to someone over the phone.

Of all the CMSes I tried recently, I really like phpwcms (www.phpwcms.de) the most. It gets it right on most of your points (and mine). But it has several shortcomings, and biggest of all is: it is (almost) a one-man show, and development depends on his own free time :(

I have used Typo3. Typo3 sucks. The primary developer shoves baby jesus along with the product, makes insane architecture decisions, and the product itself is about as standards compliant as Hotmetal, though you can "make it work" if you want to hack your fingers bloody. Worst three months of my life completing projects with that thing.

Ugh.

Re human readable URL's. Is this one better:

http://www.devshed.com/c/a/Practices/Smart-Cards-An-Introduction/

It's using a different SEF (search engine friendly) engine for Mambo than the ones shown (for the record, I do NOT like the way this site is designed). Keep in mind, SEF and Human Readable to two different issues. One is about people finding your site, the other is about how pretty the url looks. Both present their own technical challenges.

Actually, that's something that has not been considered - user wants versus the effort the Developer has to put in to achieve it. At some point, a cost (time, money, effort, consultation, etc) has to be applied to a 'wish'.

For more on this check out an article in PHP Architect (www.phparch.com) called "Open != Free".

Pardon this method of inquiry. I'm new to the site.

I'm tryin to help a small, good organization get higher on the 'radar screen.'

Let's say that one were to be establishing an online news site. It would have major traffic (just for sake of discussion).

It would require easy editorial input by writers but ability for a layer or more of editors to edit and approve before final 'publishing.'

You would end up quickly with a very large database of news items that would be archived and searchable for potentially years.

The system would have to be rock-solid, scalable to big-time.

What Open Source (or other) platform would you consider?

Thanks!

jhale@mindwest.net

Good points. I'd like to add a point of view please: What all the Plone, phpNuke, WordPress, blogger, and others miss is that the system should promote in the *simplest* way various means for a writer to write, period! For u designers & coders out there: How about a paper bag full of refrigerator magnets coupled with a large magnetic whiteboard??? See what I mean? I don't want to know about XHTML, HTML, CSS, XYZ, ABC or any other coding language or scripting whatever. What I do need is a platform to hold my content and allow me to manage it like a tabloid-sized newspaper. Allow insertion of photos, sound files or whatever without first studying the format, history and whatever of the script or language. I don't want to know who invented the paper bag or how it is made. I'll be satisfied to experience the bag securing the contents up to the rated poundage without tearing or breaking. I want 1-column two-column or three, whatever. It must be WYSIWYG people!! Imagine you are tasked to teach me to use a rifle effectively to defend myself ----- but we don't speak the same language. I'm already running two careers ---neither of which allows for time to learn coding.....so, do you have, make or sell markers, magnets & whiteboards or not?? The largest market out there is of the population of *non-coders*, not the other way 'round.
Thank you for taking the time to read this.
Have A Healthy, Prosperous Day!!
---Robert H. Williams

@Andrew Eddie: The SPIP site is not a demo, it is a documentation site. They don't want to advertise, they just want to make it possible for people to use their product easily, that's all. (OK, OK, I'm simplifying an awful lot here, but you get the idea).

The page I pointed you to showed how much templates can vary from site to site. Here's the same in French: http://www.spip.net/fr_article884.html
(the product being originally in French, there are many more variations to be found there)

And as Jeff says, "they should run in ten minutes". SPIP does just that. I don't need a live demo, I just run a local virtual host and test.

Same goes for all the other CMSs I've tested thus far: I test them locally.

I've never felt online demos would respond neatly. The whole hierarchy of sections is always a mess (*when* the CMS provides a way to group things into a hierarchy, of course).

Anyway. Ten minutes. Simplicity. Evolvability when you want to do more complex tasks (newsfeed integration, anyone?). I found this SPIP and am going to be using it for a long time.

Robert, it took me a while to work it out but what a great analogy - fridge magnets.

Thanks for that.

ad 64, 65, 67. and especially 75.
It seems to me that Typo3 is really a paradigm case of what OS CMS typically do well and what they don't do so well at all. Typo3 is extremely powerful and flexible. It has some of the features that commercial CM software doesn't care to much about (Sorry, I don't have any examples at just now, see for yourselves at www.typo3.com) and they are all very well thought through. You can feel the commitment that Kasper and his fellow developers have and they use it for good.
But as so often all this comes at a price. Typo3's main fault is to be utterly inconspicuous – almost esoteric ;-). It has a declarative language of its own called - for no very good reason it seems – TypoScript. Its API seems to lack focus. I daresay Typo3 is made up out of one-offs; indeed, the architecture decisions are really odd.
I wouldn’t recommend using it. I wouldn’t recommend learning it – it will worsen your programming style. It is just too confused.
I do not mean to say that Kasper is confused (and btw. I do not condemn his religious views, although I do not share them.). But: He took too many wrong turns in developing the project and the worst thing is that he and his fellow developers still don’t realize this and are thus unwilling to remedy this. They live on their little Typo Island Utopia seemingly only concerned for their clientele.
This it seems to me is at the core of so many problems with so many OS CMS. This problem is also shared by the bad examples of commercial CMS – not so by, say Coremedia or Day.

check this out - bitflux cms: http://www.bitflux.ch

Andrew: better, but still not good enough. If we are talking about Mambo (and for the record, I'm Mambo, Drupal and phpwcms user myself), to get that kind of "friendly" URLs, you need to pay EUR 40 ($50) per site for that extension to the developer. And even his own site doesn't fully use it!

It's not just the money (after all, developers need to eat, too). Nice and clean design matters like this should be one of the first things to think of when developing a CMS, not an aftertought. This is one of the things that Plone, Midgard, Brickolage... got right.

Robert: do try phpwcms. It is closest to your metaphor (and that is what I *don't* like about it -- too many magnets, if you ask me), although you'll still need designer/programmer/admin to get you started.

p.s. I'm sorry to say, but I liked DevShed much better before it switched to Mambo.

'Ole 79 really hits the nail on the head for me. I have spent months of valuable time in the jungle of Open Source software trying to make it more accessible (www.techno.ridgewood.ca)and just when I think I have the path figured out... another site, or resource comes along and I feel silly because of all the work that I have done can be summarized in a single link.

I guess I am what one used to call a "power user", not a coder... skills born out of the revolution of the .ini file and then "drag and drop". Getting a workgroup to run on top of the university's Novell system etc. without being caught. Integrating faxing and database applications... macro power. Grew my business and a lot of others.

Technology is a tool and now it seems that we are in a period of divergence brought about by the wonderful abundance of skills and talents that allows for the creation of many, many variations...each with its inherent identity built in.

An individual "user" can no longer keep up with the change... learn some HTML and now its CSS... get a handle on MySQL...learn how to modify a config file and its Java platforms and Tomcat... there are just too many developers competing for attention, and with each other, not listening to the end users or assuming that all "enterprises" are corporate.

I am grateful that I had the time today to read all of this... it is rare treat... quite an education... what a great dialogue!

I would like to pose the question... Given all the talent and energy that has gone into the Open Source Content Management Systems, why can't someone create a desktop application with its own little Apache server and PHP library etc. that is WYSIWYG and as simple to use as FrontPage and creates true "Desktop Publishing for Content Managemant"?. Style, function and content...no hacking...no need to cut and paste... spell cheek is always welcome.

I mean, if that is "rocket science" that would be a cake walk for those that seem to be bent on making CMS just that :)

Correction.... url was misspelled...knew those spell checks came in handy. sorry.

"All suck in templating - why developers feel a necessity to mix code into presentational template. Never got it."

There's no reason to mix it these days: http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf

A worthy open source CMS can be found at www.obinary.com

I use this as part of a cruise ship interactive entertainment system that allows us to post articles via the CMS directly to the set top box in the cabin.

Worth a visit.

>>Andrew: better, but still not good enough. If we are talking about Mambo (and for the record, I'm Mambo, Drupal and phpwcms user myself), to get that kind of "friendly" URLs, you need to pay EUR 40 ($50) per site for that extension to the developer. And even his own site doesn't fully use it!>>

There are several other open source options, in addition to this commercial option. Also, for key pages, there is no reason you can't create a custom url. I mean, we are talking about web developers creating this sites still (when it comes to commercial sites), right?

There is never going to be a solution that is all things to all people. But, if you are a python expert, then you can do quite a bit with Zope/Plone. On the other hand, if you read one or two php books, you can do quite a lot with a php/mysql CMS. However, installing a CMS on a server, uploading a template and some add-ons, and handing over the logins to the client does not constitue web development.

Yes, I happen to know a system which enables a client to work immediately. I have posted screenshots a while ago on an other forum and the interface, and the way the system works were applauded :)

I strongly disagree with a _universal_ idea that content management links should not appear on public pages. If this were followed, WikiWiki would not exist. The essential idea of Wiki is that readers and authors are the same people, that the Wiki is enriched by "drive by" additions, random acts of authorship if you will. It is easy for an expert to take a minute to add or correct something in a Wiki. There is nothing wrong with Edit this page links as long as you accept this paradigm is useful to your purpose. A good example is the Wikipedia where you can watch or participate in history being written as it happens. For other kinds of CMS, it is probably best to hide them.

I use THIS... ->
I use THAT...

Jeezzzz...

All Jeff tries to do is see if there is a reason (or not) to use an Open Source in comparison to a paid version...
At work we use both (no I'm not going to mention names...) The paid for the Internet site and the open source for the Intranet site... I am slowly getting to like the open source better, but it has a large community working on it and there is a very large support group in various countries, a lot of plugins and a lot of themes...

And all the above mentioned and not-mentioned pitfalls...
Period.

Perhaps the way to do things easier is to look for CMS that are services. (all we do this for web pages hosting, email,,, ),

and to do things even easier, we should integrate the cms in the site while we are building it.

I've done this with Genb
No installs!
No templates!!
No waste of time!!

I'm happy with this solution.

Just a factual correction to an earlier post: ExpressionEngine, which i use and love, is ABSOLUTELY open-source. It's not FREE -- but that's not the same thing. One can hack, tweak, and modify the source code to one's heart's content once one has purchased it!

Recipe for CMS:

* apache webs server with webdav on
* apache or tomcat XSLT transformer
* openoffice

People write their documents with OpenOffice and edit them on the webdav server in OO's XML format.
Your XSLT transformer transforms the webdav XML responses and OpenOffice's documents to provide a nice view.

If you want fancy security roles then configure apache as required.

I've used WebGUI [http://www.plainblack.com] for several years now. It's not easy to install, but once you've installed it once you can use it for a many sites/domains as you like. I'm not going to get into all the features, but it is very different from the column based CMS's which are so prevalant. Some sites I've worked on (and am working on) that use it are http://www.riverpoolsandspas.com and http://www.buffelendoor.com.

Adrienne, just because you can read the source code does not make Expression Engine Open Source. The phrase has much broader meaning, which you can learn more about here:

http://opensource.org/

I don't think EE developers would claim their product is open source.

Been searching for the 'Holy Grail' myself for quite a while. Closest I've found is Etomite ( http://www.etomite.org/ ).

Add in a couple of snippets -- sorry for using their lingo ;) -- (DocVars + ListMenu) and it's a great way to manage Content for pretty much any design you want in full XHTML/CSS glory. It is NAPS (Not Another Portal System).

Its biggest drawback is you pretty much have to run IE Windows or Firefox to work with the Admin side, so no Safari to manage the system. But then again, we all LOVE Firefox, don't we? :)

Thank you for presenting the issues so well. It is very enlightening for beginners like my self.

On my weblog I've tried to explain how umbraco - the ASP.NET based content management system that I'm working for - solves the issues you state. I've included screenshot to make everything clearer. Hope you'll take a moment to read it: http://www.090978.org/2004/10/apparently-umbraco-doesnt-suck.html

Best,
Hartvig / umbraco.org

As usual, Jeff, you're spot on. (Sorry it took so long to get here.) I've looked at drupal, but never tried to install it. Tried and failed to install Xaraya (this despite over three decades of experience in programming; I'm sure I eventually could have made it work, but since there were more CMS options available than I had time to poke around in the code, I moved on). I have installed and used Mambo, PostNuke, Xoops, WordPress and others.

I currently use Mambo and WordPress regularly, depending upon the site, though I have to admit the best design samples I've seen for a CMS were out of Xaraya.

Mambo installs easily, divorces admin from user login, and doesn't insist on login boxes if you don't want to offer them. It also supports multiple page templates. Downside: it's a dickens of a learning curve and the docs are below par.

I think it was a drupal dev who claimed you needed to pre-wrap things in lots of divs to give designers the opportunity for drop shadows, rounded corners, etc. That's incorrect, but it highlights a problem with most CMS's.

As a site designer, I come from a hand-coding tradition. I develop "templates" (for lack of a better term) for the types of pages in the site, and when I'm coding a new page, I start from one of those templates and add content to it. Virtually no CMS behaves this way. Instead they insist on not only providing the content, they've already attached all the surrounding code they think I need (without having the first clue what I want to do) to it as well.

I'll lapse into Mambo jargon here, but I'll define as I go, to more fully illustrate the point. Every module (simply put, a module is a logical section of a webpage, such as a menu, a login box, a news item, etc.) is associated with a position code, which the designer uses when building the page template, telling the system to put modules with this position code here, those with that position code there, etc.

Now if that actually described what Mambo was doing this would be good. But, alas, Mambo (and every other CMS I've tried) is doing more, and that's what causes designers to tear out huge chunks of hair.

Specific example: there's a position code in Mambo called "inset." I tried to use this to position a small box, floated right and bordered like a sidebar, on a page, letting the page's "normal" content flow around it. Alas, the main content came pre-wrapped in a table by Mambo (note please the same problem derives from it being pre-wrapped in a div, so table-based design is not the issue here) which meant that it *didn't* wrap around the sidebar like it should, but instead left this big void below the sidebar.

If a piece of content needs to be wrapped in a table/div or three to achieve an effect I want to have, for pete's sake let *me* do the wrapping. I know how many divs I need and why, so get the bleeping bleep out of my way and let me do my job. After all, I'll only need to do it once in each template. How many divs and why is dependent upon the template, *not* upon the content, so don't marry it to the content!

But what about the casual user who may not know that you need an extra div to achieve some effect? First, every CMS ships with a few templates which can be used as is, modified, or learned from by this class of user. Second, if they truly don't know why the extra div is needed, what makes you think they'd know which div to style if you provided the div? Just move the code required by the design out of the content and into the supplied templates. That's not too much to ask, is it? To put design in the templates and keep the content items limited to content?

The job of the CMS is to manage content. Content *isn't* divs and design tables, it's words and pictures. (I can hear the standard programmer comeback, "*everything's* content" right now. If you truly believe that's a useful statement when made about web design, then you should stick to programming and stay away from web design.)

Another bad example from Mambo is the calendar. Rather than use the same CSS file as the rest of the site, or even allowing me to specifiy which one I want to use, it has its own, hard-coded file reference. Which means either I have to rewrite the included CSS file (which would then be subject to being overwritten if I ever update or reinstall the calendar module) or I have to override the included styles, which is made harder than it should be because the Calendar insists on loading *its* style sheet *after* the template's stylesheet, hence I have to work "uphill" (against the cascade).

Note that while I've been picking on Mambo here, I don't mean to say it's worse than the others. In fact, I think it's one of the better systems. The point I'm making is that it shouldn't be reckoned to be any sort of great achievement to be one of the best of that lot.

Arlen, can I ask you a couple of quick questions.

To what version of Mambo are you referring? If it's 4.5.1a then please contact me directly about what is deficient in the docs (we have spent hundreds of hours revamping them).

There are also built-in ways to get rid of the extra divs and tables from the modules. The biggest problem we have here (and every CMS experiences it) is that we are maintaining a balance between backward compatibility and breaking templates on every new release. We decided not to force the latter on users and so implement (sometimes subtle) workarounds. With many hundreds of templates in the wild (eg, see www.mambohut.com) it becomes a signigicant issue in your planning to change template rationalles.

Legacy support is the bane of the CMS designer and the bigger you get the worse it gets. Note that our current roadmap does have a version that will 'break' backward compatibility but it is a little way off.

Also, following the link to the paper on Templating and MVC (that has been like gold to me) we're testing systems to give 100% of the HTML control back to the web designer. We are also using the root node of this blog for reviewing how we can make Mambo better.

Now, to divert attention from CMS's, hehe, maybe we should also talk about what makes a good blog...

Wow Veen, you really opened a great discussion here. I have had a similar take on the whole OpenSource CMS thing myself, with many solutions being either WAY overbloated(php-puke, Xaraya, etc) or just too damned limited(Drupal, Text-Pattern)..what i was really looking for, was a system i could have complete control over every aspect of my site. By this, i mean from storyboard(sitemapping), layout(templating)right through to extensibility(modules)... and after countless mnths of installing and uninstalling (which can really suck, considering im still on dialup, and some cms's come in at 30+mb) I have found the perfect solution for my needs. The secret squirell of CSM solutions really: ETOMITE!
Put simply, Etomite( http://www.etomite.org ) is a system coded by ONE fellow, who has invested literally thousands of hrs into creating a tool that is continually becoming more an more powerful each day. Where etomite differs from the majority of CMS's, is in its pure extensibilty. The API allows the inclusion of Scripts, via a method now known as "Snippets", "Chunks" and "Templates"..
Snippets are simply php scripts, held in the dbase, and can be called by simply adding [[MySnippetName]] to the content area or the template. you can also add variable values to the mix(ie: [[MenuBuilder?id=8]] will grab the manu structure for a folder(yes, we can have folders!!!) with the id of 8 ).. Chunks work in a similar fashion, but are just HTML code nad can be called like so: {{ContactForm}} .. Finally, templates are what makes the site look pretty. simply code up a layout(xhtml strict, for compliance sounds good to me!)and add that code as a template. now you can simply select that template as your desired look when u create a new page, or edit an existing one. Please note, guys, that waht i have written above is only a VERY small part of Etomites features. Others include User control, internal messaging..damn, the list goes on... The etomite flagsite( www.etomite.org ) is COMPLETELY W3 compliant, which in the day of browser issue relevance is very important indeed.
So, if u havent yet given it a go, download etomite0.6 and give it a bash..what have u got to lose?.. a database, around 2mbs of server space, and possibly one or two hrs of your Halo2 time?...

Stephen Wittens of Drupal makes a good point at the end of his post (I haven't seen Drupal myself): "I'm pretty sure you won't like Drupal, because it is not made to fit your needs. Maybe we need a taxonomy of CMSes, because obviously the term means different things to different people."

The term "CMS" seems to encompass a variety of things. The problem to be solved is not even agreed upon, nor is the way to solve it properly.

Is it just a website creation tool? Even within this category, there are a variety of types of websites meant to serve different purposes and needs, with different creation processes, and different user communities.

Or is it a tool for managing 'content' for all sorts of 'publications', for a very abstract conceptual model of 'content' and 'publication'--or even managing content for purposes other than even an abstract sense of 'publication'? Just because you can fit all sorts of scenarios into your conceptual model doesn't mean that one piece of software can serve all those different needs---or at any rate, that we've yet figured out how to make software that does that well. We haven't neccesarily even figured out how to make software that works in some of those specific scenarios, let alone software that works in all of them!

So the whole thing is somewhat confusing, people don't neccesarily know what they want, the state of the art is not neccesarily at the point of doing everything people imagine it could, and the terminology isn't there to even always describe what you need or what you're doing. And a lot of the discussionis very market-driven in a way that doesn't serve to clarify things neccesarily.

And then there's the open source stuff, which might not be 'market driven' in the same way, but still has it's own driving forces, some of which indeed work the way Veen's essay describes.

>Arlen, can I ask you a couple of quick questions.

Sure. (BTW, we can move this discussion somewhere else if you or Jeff would prefer. I've put a copy of the comment on Theodicius, and I have a username at mamboportal as well.)

>To what version of Mambo are you referring?

4.5.1a

> If it's 4.5.1a then please contact me directly
>about what is deficient in the docs (we have
>spent hundreds of hours revamping them).

I wouldn't doubt that. I can pop on over and discuss it in more detail, but the basic point is it took far longer than it should have to figure out, even incompletely, what I was doing. Again, this is not a relative criticism; I've yet to see OSCMS docs that I'd give high marks to. Writing good docs is hard work, and is a skill most programmers have never cultivated (many more think they have than actually have, alas). Speaking to humans is a different skill than speaking to machines.

It might be that the good docs are just hiding the information. I remember having to do a lot of digging through various bits of code trying to figure out just what the arguments were for this or that call. I had a parameter name, but no idea of what that name actually was or where I could find it defined, for example. I usually found it eventually, but it's the "eventually" in that clause that was responsible for the low marks (the "usually" in that clause kept the low grade from becoming a failing one).

>There are also built-in ways to get rid of the extra divs and tables from the modules.

A good example of the doc problem, I guess, because I never ran across such a way. Dug through some of the core code to find ways of doing some of the things I wanted to do in my template, but never ran across a way to do that. Could be my lack of skill with PHP hindered me, there. I've only recently started to learn that. Been a perl guy for too long, I guess.

>...maintaining a balance between backward compatibility and breaking templates...

Understand the issue. But providing a way a template can directly access the content without the extra detritus doesn't break a template unless you make it the only way to access the content.

>Note that our current roadmap does have a
>version that will 'break' backward compatibility
>but it is a little way off.

Truth is, the roadmap is one reason I decided to put the work into figuring out Mambo. I like where you're headed. I've even stopped using the packaged installer my host provides (4.5) and gone to directly installing from the 4.5.1a tarball so I can be closer to version where you break the templates and not get used to something that will go away.