Alex around the World

At last, I will be attending a major web development event. I’m going to spend a week at the User Experience 2006 Conference organized by the Nielsen Norman Group (5 - 11 November, London, UK). Out of the 29 full-day tutorials available, I took 4 of them:

• Getting from User Data to Design. Speakers: Tamara Adlin, Adlin, Inc. & John Pruitt, Microsoft
• Content Usability 1. Speaker: John Morkes, Expero Inc.
• Content Usability 2. Speaker: John Morkes, Expero Inc.
• Making Search Work. Speaker: Martin White, Intranet Focus

I don’t really know what to expect from this training, but from what I’ve seen on web experts’ blogs, it’s a very useful experience, not only because you learn a lot from people who know their subject, but also because you can become part of a network of people who have the same questions, fears and ideas about the web.

I’m going there with 4 of my colleagues, with different backgrounds and experience in web development and web content management. We’re not attending the same sessions, but the idea was to share what we would learn in each of our sessions and start to create a real community of web experts within our organization.

International organizations such as the UN are not known to be very reactive at changes about the web, but I guess it’s partly because people who give directions, plan a web presence strategy or make key decisions don’t really know what to expect from these changes and how they can/will affect the organization. As web designers, content managers, information architects, etc., it’s our role to help educate these people, and I’m sure participating in these conferences and sharing this new knowledge with our colleagues is the first step of this education process.

Has anyone participated in previous editions of the User Experience Conference? What’s the reputation of the speakers? Let me know.

There’s a discussion going on concerning our CMS in the organization I work for. Specially these last few months, since more and more people outside of the web team seem (finally!!) to realize the usefulness of a knowledge dissemination tool.In fact, since we implemented our content management system in late 2002, daily web operations have considerably improved, but the CMS did not solve all our problems. Rather, it seems that it has created or at least put a finger on new issues we did not have before.I have been reading a lot about content management issues lately and more specifically about why the implementation of a cms is not (always) a success (and apparently, most of the time it is not …). Here are some ideas that I’ve collected around the web:

• Content management is a process, not a technology. Focusing on the software rather than how you process your content doesn’t serve your needs. In most cases, the setting up an efficient and effective editorial process will do the trick. Choosing the software is secondary. See Jeffrey Veen’s article “Why content management fails“, John Zeratsky’s “Strategic content management“.
• Moving to a CMS is not always the best option. Content management softwares are usually expensive and include a lot of features that you’re never going to use. Some organizations just need a way to put their content on the web with a few simple steps (workflow). See an interview with Jeffrey Veen: “Making Your Content Management System Work for You“
• People don’t like to change the way they work. Human factor is the most important element in the adoption of a CMS. “A CMS installation is an editorial project, not a technical project” says Veen.
• You need a professional team to handle your CMS. A few years ago, it was ok to have only a few people dealing with daily web operations. Basically, they only had to post static web pages. Nowadays, more and more content is made available through a website. Information goes faster too. With a CMS, and to some extend, with any web technology you use, you need to have distinct competencies involved in a web team. See Jesse James Garrett’s “Nine pillars of successful web teams” (Here’s the PDF of the Garrett’s diagram).

Another interesting article listing some Do’s and Don’ts about CMS is posted on Alttags blog.

Content management systems are behind more and more corporate websites. It does certainly help manage thousands of gigabytes of content, but we are also more aware of the limitations of some systems. Here’s the weekly definition from wikipedia:

A content management system (CMS) is a computer software system for organizing and facilitating collaborative creation of documents and other content. A content management system is frequently a web application used for managing websites and web content, though in many cases, content management systems require special client software for editing and constructing articles. The market for content management systems remains fragmented, with many open-source and proprietary solutions available.

Read also my discussion about workflows.

I am talking about my own experience.In November 2002, our organization moved from a static HTML website to a taylor-made Content Management System (cms). At that time, the basic idea was simply to help the Web Unit speed up the web content publishing process, by allowing them to focus on the content of a page, the system taking care of the design through templates. The new cms also had other purposes, such as:

• Use a common, corporate look and feel for all sub-sites of our organization (more than 30) in addition to the main website;
• Ensure that the content of the website has been cleared (in terms of internal policy), edited in English and translated into French and Spanish (we have a multilingual website) through an internal workflow.

Technically, the cms is in fact a web content management system and a document management system. It is used to create and publish web pages and also as the main repository of official publications and meeting documents. It is important to say that our organization is active in three areas:

1. Intergovernmental meetings (output: meeting documents);
2. Research and Analysis (output: publications and reports);
3. Technical assistance (output: webpages and reports).

At the beginning, we all thought the cms was going to make everyone’s life easier, not only for the Web Unit, the main user of the system, but also for all staff involved in web content creation and updates.In the facts, it’s another story.After a bit more than 3 years of use, we are still facing some major problems in terms of workflow. We did not manage to implement a fully working and thus open the system to the web authors. In other words, the web pages are still being maintained and updated by the 5 staff Web Unit, which is not only creating a bottleneck but also frustrating the users that have been excluded from the process: the web authors.There are many reasons to that:

• lack of web culture within our organization: not everyone understands how the web can help you disseminate your information;
• system not adapted to our current needs: we need a simple and working workflow;
• some internal conflicts concering major issues: to what administrative entity should the Web Unit belong to? How many people should be working for the web? do we have a clear web strategy?

Although these reasons are crucial when you implement a cms, I will not discuss them here for the moment. Instead, my intention was to ask the following question: when we talk about implementing a tool that helps users to publish web content that needs to go through different steps, do you think that “workflow is the wrong metaphor?”A few weeks ago, I read a a paper entitled “Is workflow the wrong metaphor?“, by James Robertson, of Step Two Design. His main argument was that while workflow is an central component of cms, they often fail in most organizations. The main purpose of a workflow is to help organizations publish information that went through a precise review and approval process.The problem is that usually these workflows fail to reflect the complexity of an organization, leading to a “considerable gap between the vision communicated in cms tenders, and the reality of implementation. Eventually, the organization will only use basic, linear workflows, instead of complex ones. Robertson’s idea is the following: instead of seing the web publishing problem as a content management, with workflows, a solution might be to see this issue as a task management, where instead of having rules as in workflows, a user could “assign a task related to a specific piece of content to another staff member”. Examples of requests are:

• review the content
• update the content
• add additional details

Depending on the task, it will trigger either a direct publishing or a longer linear workflow. In other words, steps to be performed on the content will depend on what needs to be done on it. This would allow a wider range of options / workflows, instead of providing only long, non-flexible workflows.I found Robertson’s idea quite new, and it also shows that there’s a new paradigm being built around the issue of actual use of content management systems. A necessary paradigm, because my experienc taught me that, even if you have a perfect system or tool, it’s not guarantee for your system to be 100% efficient. Human factor and existing working habits are also to be taken into consideration when adopting a cms. I might be even more important than the technical side.