This is worth the read. Check out Jeffrey Veen's critique of open source CMS's which makes some excellent points, some of which apply to Drupal. Note that he does give them credit for being better than their commercial counterparts:

"Open source content management software sucks. It sucks really badly. The only things worse is every commercial CMS I've used. But it really doesn't have to be that way."

For those that want the short version, here are the key points:

  • Make it easy to install
  • Make it easy to get started
  • Write task-based documentation first
  • Separate the administration of the CMS from the editing and managing of content
  • Users of a public web site should never -- never -- be presented with a way to log into the CMS
  • Stop it with the jargon already
  • Why do you insist Web sites have "columns"?

Update October 5: Dries offers Jeffrey Veen a deal:

For each hour you or your company Adaptive Path spend reviewing Drupal 4.5.0's usability (free of charge), I spend 4 hours implementing your suggestions (free of charge). The review should be public, and the Drupal community should be behind the proposed changes. If you don't feel like setting up a Drupal site yourself, I'll set one up for you.

Update October 7: Jeffrey Veen responds.

Comments

inteja’s picture

I noticed under "make it easy to install" he says:

Ask me a few questions, and then you [meaning the CMS] go set up the database tables and write the conf.php or whatever.

Sounds like Drupal to me :-)

Now that 4.5 is released, an easy installation framework/hook could do with some attention. I really liked XOOPS' method of core and module installation and upgrade. Very user friendly. No fiddling with SQL imports and table prefixes etc.

I think with the new Theme selection of 4.5 teamed with PHPTemplate, Drupal solves most of the issues he raises in the section "Why do you insist Web sites have columns?"

Regards,
Brian.

--
Brian.

robertdouglass’s picture

If all he wants to do with his CMS is make static pages available then it is easy to turn off the login block in Drupal. Otherwise he's missing the beauty of "community" software like Drupal. Lotta fun this site would be if you couldn't log in.

- Robert Douglass

-----
visit me at www.robshouse.net

chx’s picture

If you are making commercial showcase sites, you do not need the login block. True. Switch off that block, and tell admins to go to /user. Mission accomplished.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

njivy’s picture

It's not too hard to make arrangements other than "3 columns". For example, on my web site I have 3 regions for blocks in addition to the main content area: top, inline, and bottom.

Of course, I did hack my own theme from scratch.

bitman’s picture

Yeah, that's a pretty slick layout. I especially like the look of all the blocks at the bottom of the page. Very unusual.

toni’s picture

Have a look at this particular one:
http://sdb.rkc.si/

Notice the horizontal dropdown menu? That's a block.
Notice the search (top right)? That's a block.

All it takes is a little patience with CSS.
I still wonder, why are people obsessed with their markup in the first place? It rather seems to me, that most people are still in the "designing" the output. The output of a content management should be rigidly set. No templating is needed if a markup is properly designed. Everything can be done in CSS.

killes@www.drop.org’s picture

Nice site! But you should replace the Druplicon favicon. It looks too evil for a church site. ;)

--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

njivy’s picture

It looks good! I like the clean and crisp lines. My browser (Safari) has some trouble with the drop-down menus, though. The menus hide behind the center column.

It would be nice if everything could be done in CSS, but I no longer believe that.

Steven’s picture

Unfortunately CSS layouts are much more fragile than old-school table layouts. Yours is fixed width. Have you tried doing a fluid layout? Any time someone posts something wide, you get a float drop. Not to mention the various browser bugs you'll have to work around.

It can be done, but it's a huge hassle, and the result will be a carefully tuned layout which will break as soon as you do something unexpected.

gde’s picture

The menus drop down behind the church.

Steven’s picture

I replied there as well. He makes some interesting points, but the program he's looking for is obviously not Drupal. He wants a system where you manage content for the site. In Drupal, you manage content on the site.

For example, integrated edit links/tabs are unacceptable to him. I assume he is talking about static HTML sites where there is only one version of the page for everyone. Drupal's approach (integrated edit links for privileged users) is much better in terms of usability: if you want to edit an item, you go to it like your site visitors would.

As far as his columns-comment goes: tableless CSS is a nice dream, but it's inpractical to just spit out clean HTML and attempt to style it all with CSS. The 2/3-column approach works for most sites, and is easy enough to administrate.

Maybe what we need to do is make a Drupal distribution aimed at such brochure sites: instructions on how to turn off the log-in box, author/date information turned off by default, only page module enabled, etc.

inteja’s picture

I'm using Drupal 4.5.0 RC with the PHPTemplate cleanslate theme.

It is a tableless, 3 column layout, styled purely with CSS.

So it's not a dream, it's a reality!

Brian.

--
Brian.

Steven’s picture

I have a tableless theme too. However, it is still composed of 3 areas: main, left sidebar, right sidebar.

What the author of the article suggests is that the CMS just returns HTML for all the content, and that it can all be positioned and styled perfectly with CSS. That's a pipe dream. Even if you assume that everyone is using a browser which implements the standards perfectly, you'll still run into problems with fluidity and flexibility.

Have you noticed how Mozilla's XUL uses tons of custom CSS properties to get everything done? That's because plain CSS doesn't have enough power to do a typical desktop application interface with it.

inteja’s picture

I see what you mean.

Even in the absence of tables people are nesting divs to layout sites.

--
Brian.

heathen’s picture

"Make it easy to install
Make it easy to get started"
i think we don`t need "install wizard"
for now Drupal installation simple and "transparent" unlike other open source CMS... please don`t make that stupid "wizard" like mambo, xoops and nukes... same with the modules...
the only problem i see in drupal cms - compatibility with contributed modules... especially taxonomy context, banner and image :)
and another big problem in Drupal - its open source system, enyone can read and analyze code... hackers, for example :)
Good commercial CMS not opensource and usually zend-encoded - those facts increase their users safety :)

inteja’s picture

I think you're missing his valid point of "software written by geeks, for geeks" rather than end-users.

Easy installation contributes to a rewarding user experience and good first impression, thereby increasing uptake.

I also don't agree with your comment regarding open-source and security. You only have to look at Linux VS Windows.

Brian.

--
Brian.

cel4145’s picture

I've been working on a project to extend Adrian's install configuration wizard for CivicSpace (see info about it at CivicSpace Labs). Good thing about CivicSpace is that they include many of the contrib modules, making this sort of guided configuration possible.

So I think that projects like CivicSpace can take on this sort of involved install configuration wizards, but a GUI-based install for the basic setup would be nice for many people.

dries’s picture

I'd be happy to cut Jeffrey Veen a deal if Drupal is more or less what he is looking for.

Jeffrey, here is your chance to help make a better open source CMS:

For each hour you or your company Adaptive Path spend reviewing Drupal 4.5.0's usability (free of charge), I spend 4 hours implementing your suggestions (free of charge). The review should be public, and the Drupal community should be behind the proposed changes. If you don't feel like setting up a Drupal site yourself, I'll set one up for you.

I'm pretty sure we can't afford to hire Adaptive Path, but this is something we can do and something that can make a difference. Other Drupal developers might be willing to cut a similar deal to make this offer more interesting.

Update October 6: no response from Jeffrey (yet).
Update October 7: Jeffrey responded, see the comments bellow.

robertdouglass’s picture

This deal should be more visible on the site.

If Jeffrey accepts the deal you've got a 5 hour unit from me as well.

- Robert Douglass

-----
visit me at www.robshouse.net

boris mann’s picture

We'll definitely donate some time as well. And we'll setup/host a Drupal site for him to work on.

--
Boris Mann
Bryght Guy

drumm’s picture

I would definately like to help out. My time isn't ever especially measured in hours, but I'll see what tasks are doable and lead on at least one, if not more.

veen’s picture

Sorry for my delayed response; I've been at a conference for the last two days, and haven't had the chance to catch up on stuff.

I've had similar responses from the Mambo community, as well as the Midgard folks. Clearly, there is a need for more usable and intuitive user experiences for open source content management systems.

But the bigger issue is where to put resources towards solving the problems I was ranting about. In fact, it feels like part of the problem with this genre may be the diffusion of efforts. For example, if I coordinated a group of interface designers, ethnographic researchers, interaction designers, and usability experts, which system should they fix? Or should we put out recommendations, schematics, research reports, and interface schematics that are generic enough for any open source project to implement?

What would be the most effective use of people's time and talents?

Tarlbot’s picture

There is no way to compare peoples pledges of effort after you make suggestions - different people are more effiecient, different suggestions will require varying amounts of effort for different projects.

Reviewing the systems and saying they this one is 72% good and have 23% market share so that's the one I will help takes time out of actually doing the study - Possibly this is worthwhile time. That is something only you and your team can answer.

Generic suggestions can be difficult to make in a vaccum - maybe Drupal, mambo and Midgard should be used as examples to draw the generic from?

Something we can do on this end is to take Jeffrey's suggestions, check to see how well Drupal does, and if we fall down in a specific area submit a bug report and start working on it. He's already done a fair chunk of free work writing that article - maybe we should work on those comments before asking for more. Maybe fixing those things is all we need to do.

dries’s picture

There are already plenty of usability books/articles available. Even so, we often fail to see opportunities to improve usability. Often, all we need is a 'Drupal-specific eye-opener'. Once someone showed how things could be made better, we tend to research the problem, and fix it. We don't have problems with the research, neither with understanding why it would be better. We just don't always see how some things can be made better in our particular case (despite the fact we read usability books/articles).

In the past, annotated screenshots (example) have worked really well for us -- much better than written text/articles. Visualization and comparison are key.

So why not visually compare the usability of different CMS platforms based on certain (micro-) tasks (i.e. configuring user permissions, adding a user or setting your site's mission statement)? Direct comparisons using annotated screenshots often act as eye-openers. Finally, because different OSS CMS platforms would be compared, it would be beneficial for the OSS CMS community at large. We could learn from each other with you being a mentor/moderator.

Thanks for listening, Jeffrey.

maptheway’s picture

I sent Jeffrey an e-mail with Dries' offer.
Seems he's at a conference now but has been reading the notes here with interest. I've listed his note below. Guys like Jeffrey that respond back like this achieve a coolness factor that proves why they are a success. Plus as mentioned, Dries your offer was sheer brilliance. That's why I took the effort to contact Jeff today. Smart people use drupal...

Matthew,
thanks for the note. I've read the thread and am very impressed with
the openness of the community.

Would you do me a quick favor? I'm at a conference for the next two
days, and connectivity is spotty. I don't want to seem aloof, so I'd
appreciate if you'd let those developers know that I've seen
everything, and will respond when I can?

I totally appreciate it.
Jeffrey Veen

Tommy Sundstrom’s picture

To make a general CMS that works as its users would like out-of-the-box is probably not possible - there are too many different user needs and expectations.

But a possible strategy may be to pre-pack different distributions for different niche-markets. Drupal has the technical foundation for being tailored for different target groups in it’s module system.

Aside from the usability advantage (a system with just the things that you need, not a ton of features to be confused by) it also has a marketing advantage. A system tailored for a specific group is likely to get more attention from that group than a general system (even if it has the same features). In this case less is more. Especially when it also promises an development potential when the needs grows.

I believe CivicSpace is an example of this strategy.

Other pre-packed versions of Drupal I would like to see:

  • The systematic blogger – blogging software for those that care for categories
  • Forums - strip everything else and make a out of the box forum handler (an alternative to PHPbb)
  • Project manager – use the projects module to make an basic project management/issue tracking CMS
  • Personal website – a blog, some static pages, an image gallery
Yasha@spreadfirefox.com’s picture

Pre-Packs are an outstanding idea. They would allow Drupal to compete with blogs, forums, personal site managers, and community cms's right out of the box.

Other than that usability fix, I think themes are the most important improvement needed. Getting the SFX theme as an included standard would be one major step forward.

gábor hojtsy’s picture

There are quite a few existing prepacks (Drupal 4 bloggers, DrupalBlog, DrupalCOM, CivicSpace), so we are not short of these. If an installer could get into Drupal, it could help users to install a preconfiguration.

About including third party site themes, I am quite sceptical. The spreadfirefox site identity is not something I would like to see elsewhere. It is their property. Graphics identity and source code are very different things...

PaulEbert’s picture

As a potential user of Drupal, or an alternative CMS package, it would be great if I could go to a site and see how to download and install a base package in no more than 30 minutes. I dabble in XHTML, CSS and PHP and I have installed a number of software packages using the command line. While I am addmittedly a novice, I am not completely clueless. As an educator, I would like to be able to see what is available and play with it on my laptop. That way I could evaluate systems and then make recommendations to others in charge of IT at the University. Terrific open source software that has a greater entry barrier than I mention above is missing its target audience. I would like to strongly support Goba's comment above that an installer would be greatly appreciated.

I would disagree that there are adequate prepacks. Education is not listed above and education prepacks that I have found are not intuitive to set up.

I also think themes tailored to a specific audience could be extremely useful if they improve the ability to use an interface intuitively. Great code is much less useful without an intuitive interface - even if it is very powerful and overflowing with features.

A low entry barrier and an intuitive interface will do wonders for market share.

killes@www.drop.org’s picture

Somebody with your knowledge should have Drupal up and running in far less than 30 minutes assuming he uses a machine where mysql and apache with php are already installed.

If you are an educator you should watch this space
http://cvs.drupal.org/viewcvs/contributions/modules/evaluation/
over the next few days.

--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

joel_guesclin’s picture

... to go to OpenSourceCMS to see a selection of just about everything available that is PHP/MySql based. These guys have done a great job.

cel4145’s picture

I started addressing the issue of a Drupal prepack with version 4.4 by preparing DrupalEd. So I'd be curious to see what you'd like to see an education prepack.

javanaut’s picture

Maybe the Drupal Handbook should include some recipes for mixing and matching modules to achieve certain goals. Someone new to Drupal can become overwhelmed just reading through the module descriptions and how to effectively use them together. When 4.4.2 came out, I found that some modules had overlapping functionality and actually didn't really work together.

One problem with such recipes would be the subjective nature of the recipe author. I do know, however, that there are some combinations of modules that just work well together, even though neither lists the other as a requirement.

Alternatively, drupal.org could have a pre-pack module that automatically assembles a tar.gz file containing the prepack using the current specified version of each module. This could be in the form of a wizard that asks you what you want to do with your site and automatically configures a set of modules for you.

Great Idea!

freyquency’s picture

The documentation for drupal installation is really obtuse. There wasn't any information on third party hosts, which I think is what most people have , not running their own server. It took me hours, hours, to 'decrypt' the instructions and through trial and error get the user/password settings right, get the cron setup correctly, and realize that when presented with mysql stuff to login to phpmyadmin and paste it in. It took two or three installations before I got to the point where I knew all the ins and outs of the setup. I think that there is a huge barrier to any users that are new to cms's there. Auto-config pacakages aside the documentation should reflect what are essentially two different methods of installation.

javanaut’s picture

I think that 3rd party hosting is often overlooked (myself included) when considering a "Howto" document or answering support questions.

killes@www.drop.org’s picture

I mostly use third party hosting and it is absolutely no problem to set up Drupal in such an environment (if the php settings aren't too weird).

--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

javanaut’s picture

I've responded to support requests where the user was only familiar with PHPMyAdmin, and not the mysql command line tool. I responded in terms of using the command line tool, even giving command line options, and was met with the online version of a blank stare. I don't doubt that someone familiar with Drupal and Mysql could easily have translated my command line options into PHPMyAdmin procedures, but some people just can't.

I've only used PHPMyAdmin a couple of times and am not very familiar with the user interface or it's features, though I understand it allows users to do just about anything the command line tools do. There is a very wide body of users who are limited to using this tool instead of the command line one, so it would just seem appropriate to consider them more when writing documentation. Additionally, I know Postgres has a Webmin interface that might warrant being considered as well.

Maybe there needs to be a mysql-to-PHPMyAdmin translation guide that covers basic Drupal installation tasks as a quick reference for these people?

killes@www.drop.org’s picture

PHPMyAdmin is very intuitive to use. You just upload or copy and paste the database definition file and your db is set up for you. Reading some phpmyadmin docs doesn't hurt of course. And if that leaves open some questions there is a phpmyadmin help forum, too.

But I of course would welcome installation instructions for more than just the command line approach. I believe some suggestions have been made. Maybe you can add to the appropriate book page.

--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

javanaut’s picture

"Maybe you can add to the appropriate book page."

Well, that means that I'd have to install PHPMyAdmin and figure it out first ;)

Tommy Sundstrom’s picture

Some suggestions for this has been made. See http://drupal.org/node/11355 and http://drupal.org/node/11350

freyquency’s picture

I agree. Once you get started it's easy. It's that first step of "wait, where is this command line they keep talking about?" that took me hours to get.

I created a few pointers (aww it's node/2!) here: http://coacalina.org/node/2 for myself and others that are critical to wading through your first third party installation of drupal. There's also notes on cron here: http://coacalina.org/node/73 ... the way I see it that's pretty much all one would need to configure, aside from initially creating the database and editing .htaccess (especially if they have subdomains unrelated to drupal).

Hope that helps someone in the future, esp. regarding updating the documentation

axel’s picture

> Make it easy to install
> Make it easy to get started

CMS for housekeepers? We already have one operating system projected "for housekeepers" ;) Dead-and way.

* Why do you insist Web sites have "columns"?

Reasonable question. Really, why?

--
Axel,
Russian Drupal Community

sepeck’s picture

One of the comments he makes is very valid.

Write task-based documentation first. Most systems have installation instructions that are quite good: "First do this, then do this, this, and this." But when it comes to actually using the CMS, they revert to feature-based docs, carefully outlining what each feature does, and typically from a back-end perspective. Remember, I want to get started quickly, so give me the basics in sequential order for doing that. Do I have to create users first? Can I make a template right now?

I am not a web developer and this is the problem I first encountered. It didn't help that I had this 'vague' idea of what I wanted to accomplish and put up against the 'features' of Drupal, it was a perfect match. Accomplishing that goal however has proven to be a learning experiance.

Now that I finally 'know' what I want to do, I can start actually making my site what I wanted to in the first place. I intend to keep a journal about it and write it up as a guide (step by step) so others can perhaps avoid some of my confusion.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

Bèr Kessels’s picture

A few days ago I posted something similar to the Mailinglist in a thread to make Drupal Documentatiuon better [1]

For a flatter structure, one person needs to sit down a few hours, and move stuff aound in the book, creating about ten chapters (I looked on my bookshelf and found that most technical books have about that amount) with maximum of three levels deep structure (idem) might be the first step towards a better handbook.
An example could be to not follow the "roles" chapters (users, admins etc) but functional structure. Adminstering, configuring, expanding, personalising, developing,
content editing, content moderation etc.

Anyone with some spare time who can think of a proposal for this?
[1] http://lists.drupal.org/archives/drupal-devel/2004-10/msg00046.html

[Ber | Drupal Services webschuur.com]

sepeck’s picture

I saw your post and missed some of it evidently. I like your inital idea but I will try and send out suggestions based on your post tomorrow on the layout structure.

There is a lot of information in the current handbook, it's just that a lot of it doesn't make sense to non-devlopers until they get the underlying concept. hmmmmmm............

The one section that is missing is a 'Getting Started Guides' section which could reside under Configurations.
Setting up a single blog site. (ala Drupal for Bloggers)
Setting up a blog site for multiple users (I realize that there is not much difference, but there is some)
Setting up a Community site (ala Slashdot).

Would this be 'optimized' for the individual users needs? No, but at least the new people would then have a working site and a starting point for any further changes/modifications they might wish to have.

-sp

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

mrshark’s picture

even better if these settings could be made at installation time! Gimme your mysql host, user, pass, email, than select a ready2go starting point for your site (that can be blogging, forum, community, or DEFAULT!). Every of these settings have only to set some modules to be active for that specific task (one can always go to admin-section and completely convert an installation-time-blogging-selected site to a new slashdottish one!). Not so many pre-built installation configurations (about 5 different styles is good). The default option must of course be default...

sepeck’s picture

umm, not quite :). I am not for a completely automated inital install yet. There are to many different site setups to account for.

I was picturing more of a section that started off with Drupal default base install. Then maybe 3-5 'Guides' for common configuration.
1. Blogging site -single (ala James Seng's site)
2. Blogging site -multiple (ala Family Times)
3. Community -ala Drupal main or Civic Space
4. Corporate site -hmmmm....
5. And last a slightly more complex style http://urlgreyhot.com/
-which I am taking as an organizational model for mine
-seperate 'professional' section from 'personal'

These would not be 'be all end all' guides. Merely a training how to.
Download X modules, set Y settings for a custom block on a given page and you will achieve Z site.(x+y=z)

After that 'training' intro people could then go and read the remaining documentation with a better understanding of 'how' Drupal works. They would also hopefully have a acquired a 'standard' Drupal vocabulary so that when they ask questions in the forums, people have a better chance of understanding the question.

I already knew some of what I wanted to accomplish with my site, now I finally know how I want to organize it. I also finally think I understand how to accomplish it. So I intend to document it as I build it and add it to the site documentation. (Also, I intend to try and get my instructor to accept it as the basis for my class project which would be a nice bonus in time savings).

In retrospect, the documentation for How to do it is in the manual, I just didn't understand it when I read it the first time and it;s not presented in a way I understood. I will throw out a suggestion for a table of contents structure in a day or two. Someone may also beat me to it with a better one.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

Tommy Sundstrom’s picture

To make Drupal easier to install for users with phpMyAdmin I've written an instruction.

jibbajabba’s picture

Usability for a specific end user is what Jeffrey Veen appears to be talking about. The reason OS CMSes like Drupal are not as focussed on non-technical users seems obvious to me. Open source projects -- projects democratically designed by communities of people rather than by individually controlled projects -- are created by groups of programmers to fill programmers' needs. They're almost always started this way, aren't they? They're created by programmers so that they can use the end-product. Maybe they have customers/clients in mind. Maybe those clients consist of non-technical people with publishing needs. Maybe they don't. But I'm sure the act of thining about a non-technical user persona and designing the software for that type of person is probably lacking in OS projects. The result is that they are programmers' tools -- platforms for creating software -- and not necessarily tools for non-techie consumption. So this is why you see such resistance by non-technical people (those who don't touch MySQL, PHP, Perl, etc.) to using many of these tools.

I have more to say about the topic on my blog if you're interested.

PaulEbert’s picture

The lack of adoption by non-techies has nothing to do with "resistance" to adopting the technology. On the contrary, there is a great deal of interest. The communication gulf is the barrier that prevents wider adoption of very useful software.

jibbajabba’s picture

I said resistance to use not lack of interest. What I've observed, and this is not to say that this is universal, is that people are very interested in the features of Drupal. But what many are not interested in is a steep learning curve. So when it comes to using a CMS that requires too much cognitive overhead, the investment of effort might be too much and the use of a CMS that isn't user friendly (i.e. enables efficient *use*) may be abandoned.

killes@www.drop.org’s picture

Yep, people do want a CMS with all bells and whistles but do not want to spend some time setting it up or configuring it (or pay somebody to do it for them).

A CMS (especially one that has as many features as Drupal has) is by nature a bit complicated. Developers can try to to hide a bit of the complexity, but that isn't easy and is naturally not on the top of the list for a developer. I personally do not mind if people find Drupal too complicated and go looking for other solutions.

--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

Bèr Kessels’s picture

...exactly. If people wish a site with with bells and whistles and also want to have that without any hassle they should hire someone.
If people want a site, with bells and whistles and want it for free too, these people should get out of wonderland and step into the real world.

A Mercedes costs more money than an old ragged opel kadett. And in IT its the same: A big complex website will cost. If not money then at least time and effort. There is no such thing as free beer :)

[Ber | Drupal Services webschuur.com]

jpr@lab.ac.uab.edu’s picture

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.

djhomeless’s picture

Hi everyone,
I agree with everyone on this thread, out of all the Open Source CMS's I do believe Drupal has the best chance of being crowned 'the best', mainly because the technology is good, but also the community is strong and willing.

If I could offer two suggestions that Mr. Veen touched on is the focus of the product. He is correct that Drupal, like others is focused on the blog/slashdot model centered around community. But Drupal can be so much more than that! Consider:

1. Provide a staging environment. I'll go one further than the comments that admin links should not appear in the primary interface. The admin interface should allow users to make changes to code and content without affecting the 'live' site. Once the admin is happy with the changes, he or she can commit the changes and update the live site. Why do this? By implementing a staging model you can start to push Drupal into more traditional CMS propositions.

2. Allow for structured information architectures. This is a standard functional structure used by all major CMS's, from Vignette, to Broadvision, to Documentum. Granted, I've posted recently about my inability to get my head round the taxonomy model, but I would recommend thinking about building a structure like so, which is not far from where we are now.

A user can should be able to create several object types:

a. blog - same as now
b. forum - same as now
c. external link
d. page - Page would fit within the overall information architecture tree. In other words, you could create a 'Contact Us' page which would feed into the menu dynamically.
e. article - Same as above but you get the additional option of defining a root parent, which instead of taxonomy term would just simply be either a page or the root node.

This way, you could easily create a CMS structure in minutes using Drupal. The one major difference would be creating content would auto-generate two menu types, the top-level site menu (e.g. About Us, Contact Us, News), and section-specific sub menu's (e.g. Sport News, Finance News, World News).

To my knowledge, no Open Source CMS does both out of the box today. While Mr. Veen is correct that the intuitiveness and usability of OS CMS's have a long way to go, it also must be said that with just a few tweaks and added features Drupal could seriously challenge not only the O.S. CMS market, but Mid-Tier CMS's as well (such as Percussion, and RedDot).

My 2 cents,

Geoffrey

jcwinnie’s picture

If you read the comments to Veen's article, you will notice that several of the commenters mention the need for updating to work.

As a "usability" test, I tried to update my Drupal mysql database. The 4.5.0 upgrade script failed, as when I have tried to upgrade previous versions. Nothing new there.

No matter for those who like working under the hood. I, for one, stopped hoping that Drupal would be a useful CMS a while ago, after being abused for mistakenly asking for help via IRC.

I will have to give Dries credit for the chutzpah -- the best defense is a good offense -- and so it goes.

Steven’s picture

Changes in the way locales are handled and the way sessions work required 2 manual table creations. Did you do this, as per update.php's instructions?

As far as IRC help goes: we put it in the topic of #drupal that it is not a support channel, with a link to the support forums. People ignore it and ask their questions anyway. We have now setup a #drupal-support channel for this purpose. However, as expected, few people have the time to provide real-time, personal support: it is an inefficient way of doing so because the help has to be repeated every time. Putting IRC logs online is no solution (people aren't going to read IRC logs to find a solution to a problem).

The result? People still come into #drupal saying "I didn't get a reply in #drupal-support". Often the problem is caused by not reading the instructions properly or something which has nothing to do with Drupal at all, yet they expect us to immediately drop everything and help them with their problem.

Open-source software is volunteer based: we don't have time to help out everyone immediately. I personally try to help out on the forums as much as I can, but I will not provide help on IRC.

jcwinnie’s picture

Did you do this, as per update.php's instructions?

You mean the instructions further down the page than where it said click here only once? Yes, I manually created the tables before clicking the link to run the upgrade script.

Steven’s picture

Indeed.

Update your Drupal sources, check the notes below and run the database upgrade script

Yeah I know, annoying users will click before reading. That's the sort of people who need installers. Maybe we'll have one for 4.6.

i100yanov’s picture

I updated my Drupal-driven intranet site with a few clicks:) Usability pure!!!

takacst@drupal.org’s picture

It is quite easy to take pot-shots at applications and user interfaces. It is quite another matter to offer constructive criticism backed up by concrete examples or specific suggestions relating to design alterations. While I agree that the generic Drupal user interfaces suck, I must point out that the level of effort necessary to implement a "usable" user interface is not unreasonable. The tough part is designing a good user interface. The development of a good interface invariably involves iterative design going through rigorous use cases.

Drupal is a damned powerful CMS platform. The module-based approach to obtaining a CMS with a disciplined means of achieving scalable functionality is downright elegant in my eyes. If one filters through the module development "noise", one finds that a very disciplined collaborative community is working quite effectively to ensure that it is possible to build a highly stable production CMS system which it is very easy and safe to upgrade with field-proven modules.