Tony Byrne’s CMSWatch: Featured Opinion: Open-Source CMS: Prohibitively Fractured? provides an excellent analysis of the state of open-source content management systems. Tony feels that the efforts are currently so fractured between competing projects that no one open-source CMS can compete with the commercial products. An excerpt:

I would like to see development and support resources coalesce around winning projects. Open-source CMS efforts would benefit from a selective merger of efforts, especially among packages using the same language. We could celebrate that a thousand flowers have bloomed, but let’s also acknowledge that too few of them give off a sufficiently pleasant fragrance today.

Bloug Entry (May 22, 2003) has some interesting and fun ideas on how to create really large whiteboards on the cheap and other brainstorming tools.

Fog Creek Software has released a beta version of CityDesk 2.0.

I use CD 1.0 to manage the non-blog portions of High Context. At work I have a couple of project sites set up with it and have deployed it in HR so they can maintain our employee handbook on the intranet. Very easy to train non-technical staff on how to use the software.

What’s new in this version? Go here to find out.

CMS Watch reports that the General Services Administration is licesensing Vignette, which they will use to offer CMS services to other federal agencies. Here is the award notice (over half a million $US).

It will be interesting to see how the internal service model will work for them. I think it is the right way to go but it’s hard to create change in the government, which this will require.

Chris Dent shared a link with me that discusses unique vs. descriptive identifiers:

Information-Free Identifiers: A Key to Flexible Information Systems
Part I, Part II

Despite the importance of getting it right and the consequences of getting it wrong, identifiers are, in fact, got wrong most of the time. The requirement for uniqueness in identifiers is so basic, and so universally appreciated, that it is usually taken as a sufficient as well as a necessary condition. The general idea seems to be that as long as the basic requirement for uniqueness is satisfied; an identifier is a convenient vehicle for conveying other information about the thing identified. This destabilizes the identifier and gives rise to the problems discussed in this article. Part 1 examines in detail the problems associated with altering the properties of a thing?s identifier and describes the basic principle of identifier stabilization through the use of information-free identifiers. Part 2 focuses on implementation considerations.

The big question about URL construction, based on the articles linked to in the previous post, seems to be this:

Should URLs convey meaning in and of themselves?

Everyone agrees that they should be short, human readable, and permanent. (Although very few make that hat trick.)

However, the content-neutral approach seems to be at odds with user behavior in decifering URLs to guess page location, primarily by going to the directory level.

Users should win that debate, shouldn’t they?

From *Pixelcharmer: Field Notes: Cool URI’s:

I have a list of resources that argue for and suggest best practices in URI construction.

Great list. A few choice excerpts:

Tim Berners-Lee:

It the the duty of a Webmaster to allocate URIs which you will be able to stand by in 2 years, in 20 years, in 200 years. This needs thought, and organization, and commitment.

Paul E. Hoffman:

It is common for Internet users to glean information from URLs in order to help them hunt on the Internet for additional information. Of course, this practice often leads to unsuccessful searches, but modifying parts of a URL and submitting the changed URL to a server is a common search technique. The creator of a URL can help foster this kind of search with the names they choose.

Bill Humphries:

The trick is to tell the outside world that your interface is one thing: /content/YYYY/MM/DD, but when you fetch the page, you’re accessing /content.cgi?date=YYYY-MM-DD. Web servers such as Apache and content management systems such as Userland’s Manila and the open source Zope support this abstraction.

Peter Seebach:

The structure of a URL is a powerful and informative tool. It provides a way out of your navigational structure. If you’re trying to force users into a certain view of your site, this won’t help you — but why would you try to do such a silly thing? URLs allow users to get around inconveniences or flaws in your design, without requiring you to redesign your site.

Here are four simple rules for naming files that will let users navigate your site more comfortably:

1. Make sure your site has a meaningful layout. Organize files into directories and give the directories informative names. Remember that the layout must be consistent and rational: Having seen one part of it, a user should not be surprised by the rest.
2. Make sure each file’s name is useful and informative. Favor descriptive words, and definitely avoid serial numbers. Don’t have documents named “d1827.html”; how is a user supposed to learn anything from that?
3. Make sure each directory’s default “index” page exists, and allows users to easily navigate to every page in that directory. A user who gets to nearly-the-right page will often clip the file name from the URL and try again (although many report frustration with how often this yields nothing but error messages).
4. Finally, do not reorganize all the time! News sites, search engines, and users will have linked to pages on your site. If all I get when I follow a link to the “product page at the vendor’s Web site” is an error message or a redirect to your front page, I’m likely to go look at the next product I was thinking about in the hopes that I’ll get the correct page right away. Try to keep old URLs valid.

Jesse James Garrett:

Some might argue that, in a perfect world, URLs would be used only by machines, hidden entirely from users. But in our imperfect world, users have come to depend on URLs to communicate key information as they navigate through the Web. Systems that don’t take this user behavior into account pull the rug out from under users who have come to rely on readable URLs. Recognizing that people really do read URLs ? and, in turn, making those URLs easy for people to read ? is really just an extension of the user-centered philosophy of design. It’s all about creating systems that work the way people work, rather than the way technology works.

W3C

Do not put too much meaning in a URI. as Berners-Lee writes, Designing mostly means leaving information out. If you put too much meaning, too much semantics in your URI, chances are your resource will evolve outside of the semantic frame, resulting in an unnecessary division of the resource or change of URI.

…

In order to make URIs easy to type, write down, spell, or remember, they should be short enough.

This checkpoint is not easy to quantify. However, we can take into account the fact that e-mail will be used to send URIs, and e-mail clients (sender or receiver) are supposed to wrap at 70-80 characters : even though they are not supposed to wrap long URIs, some do. As a result 80 characters is a reasonable total length for URIs (including URI scheme, e.g “http://”, and host name).

Please note, however, that this length limit is by no mean a technical limitation, but rather, a practical goal to pursue.

Creating a Usable Electronic Newsletter In House:

An onslaught of unsolicited commercial e-mail (spam) has made readers wary of marketing attempts. To reach these wary readers, companies need to create e-newsletters that respond to their audience?s specific needs?namely usability and trust. By following a few guidelines, you can launch a usable and successful e-newsletter.

Amy Lawless, one of my coworkers, wrote this article for the Usability SIG of the Society for Technical Communication. The article is based on efforts that she led to create style and quality guidelines for electronic newsletters published at our organization. Recommended reading if you manage e-newsletters or are considering launching one.

StepTwo has published the results of the consumer survey of CMS vendor websites that they conducted back in March.

A couple of excerpts:

It is interesting to note that the methods traditionally relied on by vendors, such as sales visits, are the lowest ranked by consumers.

Instead, consumers are looking for impartial and realistic sources of information to help them select between the possible solutions.

This strongly calls into question the typical practice of providing only limited information on vendor websites, and instead directing queries to sales staff.

The strong desire for demo software is borne out in the free-text survey responses.

…

Important information is delivered poorly, with the majority of survey comments focusing on the lack of pricing information. Clearly there are serious website issues to be addressed by vendors if consumer expectations are to be met.

Raw survey results are available here.

Not unexpected results given my own experience. Hopefully some CMS vendors will take this to heart and be more open about their products on their web sites. Luckily for them, StepTwo has also just published a for-sale web site benchmarking report for CMS vendors.