The Gilbane Report: Volume 10, Number 2

The Many [Inter]Faces of Content Management

Download a PDF version of this article

Read the news for this issue.

User interface design has always been a bit of a black art. There was criticism of the browser interface when it first became popular. UI experts had developed very well thought-out and sophisticated interfaces for viewing electronic documents and data, and some were puzzled at the appeal of browsers. They perhaps felt reassured that such a primitive approach could not ultimately succeed. In hindsight it is easy to see it was the simplicity of Web browsers that allowed it to monopolize content presentation on the Internet - everybody can use a Web browser, and everybody was the audience the browser was (not entirely intentionally) designed for.

In the case of content management systems there are many audiences, and each of these may have specialized needs that go well beyond those of the content consumer. The success of a content management implementation depends on its acceptance by authors, developers of different types, managers, and administrators. Today's requirements for integration with other enterprise applications mean additional types of users. User acceptance requires an interface designed for each constituency that is easy to use and enhances productivity. In the early days of content management many of these interface issues were given short shrift. This is understandable, but is no longer acceptable. This month Rita Warren, an expert content management and information design consultant, takes us a tour through the evolution of the different interfaces to a content management system to help you think about how evolved your own system is.

The Many [Inter]Faces of Content Management Systems

Back in the good old days (circa 1994-1995), we called them "database publishing systems." I get nostalgic thinking back to when the company I was working for developed systems that wrangled large bodies of content (then hundreds of files) into databases, and then spit them out into a host of pub-lication formats.

At that time, the idea of an "interface" for one of these systems was an afterthought. We cobbled together a bunch of tools that only a couple of specialized folks (a developer and a well-trained content processor) were able to use. Nowadays, having watched the evolution from homegrown database publishing system to modern commercial content management system (CMS), I marvel at the progress that has been made-particularly in the UI.

From its humble and crude beginnings, the CMS has become a living, breathing entity with several distinct functions. Out of each of these functions grew roles, and for each role a unique interface: one for creating content, one for keeping track it, one for customizing and developing functionality, and one for running the system itself.

While there has been remarkable progress in CMS user interface design, from my experience with numerous Web content management packages, It's clear that there is yet another level of sophistication to be reached. In the next phases of the evolutionary path, expect to see a "survival of the fittest" competition where the winners are those who offer the most familiar interfaces, the most reusable objects, and the best integration with other systems.

Why UI Matters

Coming from a user interface design background, I would assert the following:

"User acceptance is probably the single most important aspect that contributes to success of a system."

Or, from an equally valid perspective:

"Lack of user acceptance is probably the single most frequent reason for failure of a system implementation."

This premise is backed up by a 1994 study called the "Chaos Report" (by The Standish Group), which concluded that the highest-ranking factor contribut-ing to failed system implementations is lack of user involvement. And what do users tend to care about most? The user interface. In any type of system implementation, teams tend to put sufficient energy into the mechanics of the deliverable. But, it is rare to put the same energy into making sure the system works for the users.

A content management system is a complex beast, to be sure. It has not just one user type, but many. Each of these user groups has different skill sets, expectations, and requirements.

Weighing the strengths of a CMS' user interfaces comes into play under very specific circumstances, namely when you are:

• Deciding which commercial CMS product to implement
  
• Customizing a commercial CMS product that you've purchased
• Designing a homegrown (or commercial) CMS

Whether buying or building a system (or parts of a system), it pays to put the time and energy into selecting or designing a system with user interfaces that work for all of your different users.

Breeds of CMS User Interfaces

When we talk about CMS user interfaces, we're not talking about the interface of the publications they produce (the Web site, for example). We're talking about the user experience of those creating, contributing to, and managing the content, and those administering the system. I define these "breeds" of UI as:

• Content Creation Interfaces-the means by which content (both text and graphical) is brought into the system. This interface might involve content contribution forms, links to common authoring tools, direct integration with those authoring tools, and newer types of authoring tools (e.g., XML editors). They also encompass the editing and approval interfaces, which are typically very similar to those used by the content creators.
• Development Interfaces-the environments for customizing the system or adding functionality to the Web pages it produces. These interfaces could range from links to common development tools, to template-building tools, to a centralized location for storing and writing scripts, to a complete IDE (integrated development environment).
• Management Interfaces-the ways for different contributors and managers to keep track of and distribute content in the system. Managers need interfaces for finding and viewing content, assigning content, running status reports, organizing hierarchies, and viewing task lists and audit trails, to name just a few.
• Administrative Interfaces-the tools for configuring and maintaining the system. Interfaces are needed for adding, editing, and deleting users, defining user roles, setting permissions, configuring workflows, setting publishing and backup schedules, and so on.

The descriptions above are not exhaustive, but they give you an idea of the typical CMS tasks. Where there is a task, there needs to be a UI. Note, though, that there is not always a strict line between these different "breeds." In some products you may find that administrative and manage-ment interfaces, for example, are treated as one in the same.

Let's take a look at the evolution of these different CMS user interfaces over the past decade or so. In our archeological dig, you'll see how some remnant features of ancient UI species are still prevalent in our current generation of CMS products.

The Evolutionary Patterns of CMS User Interfaces

Some of the foundational concepts of content management were formed early on, back in the days of SGML and document management. As the nature of electronic content began to evolve with the advent of the Web, so did the need for different and more complex tools to manage growing amounts of electronic content. Enter, the CMS.

Prehistoric: Command-lines and proprietary tagging schemes rule

In software terms, the most basic interface is the command line. You type a string of text onto a dark screen with only a prompt and a cursor to light the way. In early CMS development, the command line often came into play in running scripts or "compiling" content, so it mainly reared its head in the territory of the management/administrative interface.

Being the least expensive interface to implement, as recently as 1997, several commercial CMS packages (including significant players like Inso, and Vignette) defaulted to this interface for many of their more technical features-presumably to get the functionality to market faster. A business manager evaluating a CMS would certainly balk at prospect of paying hundreds of thousands of dollars for a system that relies on a command-line interface. But the users of that particular interface, the administrators and developers, are used to it. And, while annoying, it's better than not having the feature at all.

Figure 1. Example of a command-line syntax. This primitive form of interface can still be found within many modern-day commercial CMS products.

The other prehistoric interface that was prevalent came from proprietary tagging systems. These systems applied equally to the content creation and development interfaces. Authors would add "tags" right into their content using some kind of "made up" syntax that program code could recognize. Modern-day XML and HTML find their roots in this base mechanism for coping with document structure and formatting.

On the development side, similar proprietary languages formed the basis for publication templates. Both authors and developers had to learn a set of tags, creating a barrier-to-entry to anyone wanting to use a CMS.

Neolithic: Getting to GUI

Following in the footsteps of software evolution in general, it was not long before the graphical user interface (GUI) started creeping into the mix. It was the idea of creating a visually pleasing and more intuitive way to interface with the content management system. This event was not novel at all in software terms, but a huge step in the evolution of a CMS.

For authors, GUI meant friendly "forms" in which to enter the content destined for the CMS. The better ones also provided a means of previewing the content the way it would look in the publication - a definite plus.

Figure 2. An example of a basic GUI interface for content creation. A very good start.

For the most part, developers continued to use their tried-and-true tools and languages. Administrators started to get a better view into the system through graphical tools for tasks such as adding users, setting security permissions, and structuring and maintaining the repository.

New management needs started to surface, such as the need to see how the content was stored, to be able to organize it, generate reports, and track content status as it moved through workflows. A management GUI began to emerge - one oftentimes modeled after the traditional "Windows Explorer" interface. Leveraging interfaces that people are already know certainly lends itself to better usability.

Figure 3. Designing management and administrative interfaces to mimic already-familiar interfaces makes the learning curve less steep.

Neanderthal: For the not so swift

Following the GUI revolution, the evolutionary path seemed to split along two lines. One path many of the CMS vendors followed was to design their system around the "least common denominator" user, the businessperson as content contributor. Probably the most "demo-ed" feature today, the easy-to-use "in-place" authoring and editing interface became the most attractive feature of many CMS products.

The "ease-of-use" traits of these systems also carried over into the development and management/administrative interfaces where a few of the products started to introduce object-based GUIs for template development. A few product vendors (most recently Percussion in their Rhythmyx product) have gone so far as to develop graphical tools for configuring workflows.

Homo Sapien: For the brainy types

On a separate but parallel path, other CMS vendors were appealing to the growing sophistication among the developer and IS community, building tools that enabled those players to optimize the system performance, get at the underlying code, and customize and integrate to their hearts' content. Particularly true of Interwoven up until few years ago, the emphasis was not on the pretty interface, but the "robustness" of the underlying infrastructure. No doubt this backend sophistication was needed, but it left the user-centric among us feeling like there was something missing, like maybe the notion of an audience other than IT.

Bronze Age: The best of both worlds (sort of)

Convergence is a typical phenomenon in evolution. In this next age, the concept of what a complete CMS should be, do, and look like, was finally starting to coalesce.

We began to see systems that all had common feature sets and interfaces. Major CMS contenders had easy-to-use content creation interfaces (typically forms-based, but also integrated with existing tools), and decent management interfaces that allowed Web site producers to keep a handle on their workflows, content hierarchy, and publishing structures.

The systems provided an administrative console with a fairly common set of features to enable the administrator to do the typical tasks of managing users, reviewing and modifying content, and sometimes even workflows. And many had at least some level of an IDE (integrated development environment).

Figure 4. An example of an early effort to integrate the development environment (in this case a tool for managing scripts) with the rest of the CMS management interface.

It wouldn't be entirely accurate to say that the CMS interfaces in this era were highly user-friendly. But, they were certainly a huge improvement over the cobbled-together tools of previous generations.

Iron Age: No more reinventing the wheel

It seems a common pattern that distant societies will come up with different solutions to the same problem. Over time, as they gain exposure to what others have done, the light bulb goes on, and they realize they don't have to create tools that already exist; they can borrow, steal, or adapt them.

Such is the case with environments for content creation. Some CMS vendors, like Documentum; Intranet Solutions (now Stellant), and NCompass (now Microsoft CMS), recognized early on that a tool called a "word processor" already existed. Others made busy building their own rudimentary content creation tools to handle common tasks, like adding bold or italic formatting to text. Still others started along the path of authoring in XML. While the jury is still out on the most effective authoring interface, many CMS vendors understand that most users like to work in environments they already know-mainstream desktop applications. (See Volume 9, Number 7 for more on this topic.)

Thus, rather than a wholly new creature, the CMS started to become an aggregation of commonly used tools. Integration with Microsoft Word, for example, allowed users to create content in an environment they were familiar with and submit their content using a custom command added to the standard Word menus. Still other CMS vendors were adding this level of in-tegration into graphical design tools (Photoshop, Illustrator, Freehand, and QuarkXPress) and commonly used HTML editors (HomeSite, Dreamweaver, and FrontPage).

Modern Era: At last, integration between civilizations

In the new millennium, the melding of worlds continues. Content management gurus and CMS product vendors alike are beginning to see the bigger picture of where and how a CMS fits it an organization. In doing so, they're realizing that many existing tools and systems come into play when managing and publishing content.

CMS products that are designed to produce e-commerce Web sites need to share a common language with other systems, like customer relationship management (CRM), e-commerce, enterprise resource planning (ERP), personalization, and other custom database applications. This drive towards integration has put increasing requirements on the sophistication of user interfaces. CMS designers and developers are recognizing this.

More than ever, efforts are being put into ways to seamlessly connect the CMS with other business systems. Today the goal of a CMS is not just to help create and publish content; the goal is to enable e-business.

It's not easy for a CMS vendor to anticipate and build in the UI needed to integrate with all of the ancillary systems. But this is the world we live in today. To make the CMS do what users want and need it to do, you've got to do lot of custom coding. Fortunately, in most CMS products, user interfaces are highly customizable. But I also subscribe to the theory of "conservation of workload" as presented by Bob Boiko in his book the Content Management Bible, which basically states "any effort to make the work easy for the user will create proportionately more work for the designers and developers." You can't have your cake and eat it, too.

What to Look for Now and in the Future

A company's Web site is fast becoming the "core" media outlet for its business. The Web is creating more than an evolution of the tools and user interfaces; it is starting a revolution in the way that people think about and value content. Consequently, people are changing the way they think about content management systems. In the "information age" creating content to communicate with others is not something some isolated group does. It's what most people in technologically advanced countries do for a living. The CMS is moving to center stage.

"Best of breed" interfaces

We are now in an age where terms like usability and user-centered design no longer need to be explained. Going into the future, it would be great to see CMS products and homegrown systems built based on already existing best practices of software and Web UI design.

• For Content Creation, the ideal is an interface that can find that delicate balance between constraint and flexibility. This would be an easy way to access all of the most common formatting and document structuring that users are familiar with in desktop tools, but validated against a standard (e.g., an XML schema) to ensure consistency.
• For Management, continuing along the lines of leveraging commonly used interfaces (Windows Explorer-like), but also building in key ways that people work, like automatic e-mail alerts, and easy-to-use tools for building custom reports.
• For Development, it's time to put an end to the days of complex proprietary scripting languages and take advantage of modern-day Web development languages by wrapping the most common development tasks into reusable programming objects. The other move would be to integrate the CMS develop-ment environment with other commonly used tools like source code version control systems
• For Administration, the ideal would be to build consoles along the lines of today's integration with directory services, but for integration with other systems. For example, the ability to schedule back-ups of the repository not through the SQL Server or Oracle interface, but rather directly from the CMS ad-ministrative interface.

The value of crossbreeding and mutation

The long predicted shakeout of vendors in the CMS marketplace has begun in earnest-although partially through extinction rather than crossbreeding. Inevitably, as the industry matures, there will be more mergers of CMS companies. The outcome will be the evolution of a much stronger, more clearly defined idea of what a CMS is, and better interfaces for each of the user groups.

At the same time, there is an undercurrent of "open source" CMS development lurking in our midst in the form of Zope, OpenCms, PHP-based systems, and others. At the risk of implying that these rogue CMS developers are mutants, I would venture to say that these open source solutions are catalysts for beneficial mutation. It is often the independent thinkers who contribute the most logical and practical traits to the gene pool.

Another strain of variants that is emerging is hosted CMS services, or the ASP (Application Service Provider) model. Rather than buying your own server, you "lease" the application from a host. Because of the lower upfront costs, this model will expose many more organizations to content management systems, thus fueling the competitive forces that lead to better interface design.

Survival of the fittest

The system with the most user acceptance will ultimately win (presuming its backed with sufficient marketing dollars). Given that premise, UI is key. Whether you are a CMS product vendor or a manager in charge of a corporate CMS initiative, you have a lot of UI considerations. You need to understand that there are many interfaces, not just one. You need to know that there are UI best practices out there that are already working. And, you have to weigh the trade-offs between built-in versus custom interfaces. It's a lot to think about, but failing to consider these issues can make or break a project or a product.

Facing the Future

At this point in the evolution of most organizations, content management is a still a difficult concept to comprehend. A really good CMS solution is extremely difficult to design. And the idea of a smooth and highly successful CMS implementation is just a glimmer in a few people's eyes. But if you have that glimmer - and a passion for making systems work - go out and demand or create better interfaces, and help the evolving CMS species put on its best face.

Rita Warren
rita@ziacontent.com