In order to manage something, it's important to understand it. Without understanding, there is no context for decision making. Rather than launching into using eZ Publish, it's important to understand why we use content management systems and how they differ from other types of projects. Content management is unique; I've heard some Content Management professionals go so far as to say content management is not an IT project. That debate doesn't really matter, what matters is understanding what makes content management different from other development projects, in order to be able to manage them effectively.
This book is primarily aimed at managers and business analysts who are given the task of implementing a content management system using eZ Publish, although it is also useful for developers and designers who will be involved in the project. It aims to provide an overall framework for defining and implementing an eZ publish-based project.
This chapter examines the differences between traditional software development and content management, and how that affects the way we approach content management as a discipline. To begin with, we look at content management projects as opposed to software development projects and identify the key differences between them. Then, we look at some of the myths that exist when it comes to web development and content management as well as the types of solutions implemented using content management systems. Finally, we look at the different types of websites and web applications, to gain an understanding of the common types of websites and applications that have emerged over the past 10 years.
There are a number of reasons why content management systems have become a specific type of solution, and have business advantages to be gained from their use. Initially, websites were simply static HTML pages that linked to each other. Maintaining these sites required an understanding of HTML and the ability to create web graphics. This meant that anyone wanting to keep their website up-to-date would either have to learn HTML or pay someone who understood HTML to make the changes for them. Given that keeping a website current is an important factor in its success, the ability to manage the content on the website becomes increasingly important. Over time, custom-built applications emerged that allowed people to update content without needing technical skills; also, clients wanted to save costs by having content managed in-house rather than having to outsource it to web professionals.
The end result is that a market emerged for web-based applications that allowed clients to control the content on their websites without having to be technically proficient in HTML: i.e., content management systems. There were other advantages as well: the separation of presentation from content, the ability for the client to enter the content and be sure that it would be presented using the correct look and feel, the ability to easily re-use content, the ability to have all content searchable, the ability to schedule the release and removal of content on the site, the ability to dynamically create related content to keep the reader interested, the ability to have multiple content creators working on the system at the same time, etc.
The key to content management is allowing non-technical people to keep websites up to date. It means that the people who create content can focus on what they do best, create content. The system provides them with a way to easily present that content on the Web, and that's why content management systems have become so popular. But what has emerged is that there is a lot more to content management than simply cutting and pasting content into the system; there is a range of other factors to consider.
A content management system is only a tool that helps achieve a business goal. It's a web publishing system and, like any printed publication, there are numerous decisions to be made: e.g., the purpose of the publication, the audience, the nature, source and structure of the content, the way content is to be presented, etc. The additional dimension that content management systems bring into play is that they are dynamic. The content can be re-shaped and represented in many different ways; it can also change depending on who is viewing it, e.g., members of a site might see more than the general public. A CMS can also contain interactivity that requires business logic and rules.
In summary, a content management system is far more than just software that allows people to easily update websites; it's a publishing and communication system that allows people to communicate and interact via the Web.
Software development, as an industry, has been around for over 40 years. Web development has been around for a little over 10 years, content management has really only emerged in the last 5 years as an industry in its own right. The question is, how does that affect the way we manage CM projects? The best way to understand this is to look at the differences between traditional development and content management. Through the differences, we will be able to see how best to approach content management projects as a discipline in their own right.
In traditional development, there are many established methods to choose from. There are dozens of books that you can read and courses you can attend to learn how to manage projects. In the early days of web development, the prevailing mindset was that the rules of traditional development didn't apply; it was a new world and needed a new way of doing things. This was akin to throwing the baby out with the bath water. Sure, web development was different from traditional development, but not so much that the rule book needed to be re written. It did need to be adapted to the new environment but not totally ignored. The result was that many people in web development simply made it up as they went along. Now that content management has emerged, there's a chance that a similar mindset could emerge and the lessons still being learned in web development and long since learned in traditional development will be once again be ignored. This would be a big mistake. That's not to say you can copy an approach from traditional or web development to content management, but there is much that can be adapted.
So, what makes content management different? Why can't we simply pick a known and documented process for software development and use that? The main reason is that there are elements to a content management project that aren't covered in existing processes. Therefore, we need to be aware of the differences, so that when we select a process, we know what it covers and what we have to adjust for a content management project.
To start with, let's look at example of a traditional project versus a content management project. To do this, I'm going to use cricket as an example. For those of you not familiar with cricket, you can substitute football or any sport you like.
A game of test cricket is played over a period of five days on an oval. Each team gets two opportunities to score as many runs as they can. A team is made up of 11 players, each with their speciality. Most players are either a batter or bowler. One player is the wicket keeper (for football fans, substitute strikers, defenders, and goalie). The positions each player takes on the ground and the role they play is well established. There are traditional game plans. The rules are well known (and debated at times) with official adjudication by professional referees (who still manage to make bad decisions!).
Test cricket is a well known, accepted, and understood game. The rules and strategies have been established over time and although they have evolved, the basics are the same.
20–20 cricket is a new version of cricket. It's played on the same ground, but each team only gets 20 overs each to score as many runs as they can. The game takes less than half a day and has a far quicker and more intensive pace than test cricket. The strategies for 20–20 are different from test cricket even though it's based on the same game. Similarly, we are used to traditional software projects lasting years but content management projects are expected to be completed in as little as a month (depending on the scale of the project).
So, what we have here are sports based on the same game. But each has its elements that are unique and require a specific approach. The same goes with traditional projects and content management projects. Both are projects and the basic principles apply, but the approach taken will differ depending on the type of project. Test cricketers won't necessarily make good 20–20 cricket players and vice versa. Assuming a project manager used to traditional development will be suitable for content management is being short sighted. What is important is to understand the role being played and having the right person to play that role.
If we look into the key differences between traditional projects and content management projects, it's easier to see why we need to be careful about how we approach content management projects.
As mentioned previously, the approach to implementing a content management system is not the same as a traditional software development process. Unfortunately, there are no defined methodologies for content management, because the industry is still taking form. In essence, we are working it out along the way through trial and error. The reason that no methodologies exist is that content management brings together a range of disciplines that have never been combined before. Therefore, we have to look at existing methodologies for each discipline and adapt them to content management project, and where there are no existing practices, form new ones.
So, we can't rely on a tried and trusted approach because there simply aren't any. Part of what this book is trying to achieve is to define a set of practices that will help Project Managers to deal with content management projects until the industry matures enough and methodologies emerge.
One of the major challenges in content management projects is the wide range of stakeholders that are involved. For a traditional application, you would expect the business owner/manager to be the key stakeholder, as well as including other people or departments that are to use the application or will be affected by it. The application may never need to involve marketing, public relations, communications departments, etc. In content management projects that are public facing, the number of stakeholders can be far greater as the end result will affect many departments in a company.
For example, a car parts manufacturer might build an application that allows its suppliers to look up information on the parts that it sells. This could be a simple database that is provided to the suppliers on a CD-ROM. Chances are that the marketing department and public relations would have little involvement as this is a business-to-business style solution and is a tool to help the supplier. The public would be unlikely to get access to such an application. However, if the same functionality was to be supplied via a website, it's highly likely that the look and feel of the information would have to fall within corporate style guides. If the information was highly technical, it could require restricted access so that only suppliers would be able to access that information. This would require the establishment of user accounts and management of those accounts that would not be required for the CD-ROM distributed once every 12 months. There would also be considerations regarding the upkeep of the information, which would impact on who manages that content internally. Suddenly, what was a straightforward task of supplying product information via CD-ROM becomes a more complex process when done via a content management system as more stakeholders are involved in websites than traditional applications, especially when the information is public facing.
This is a major problem when it comes to content management projects. It's not hard to find people who have been working on software or web projects for 10 or more years. When it comes to content management, it's hard to find someone with more than a few years experience. When it comes to eZ publish, it's only been around since 1999, so the most experienced people are likely to have a maximum of seven years working with it. The reality is, finding experienced eZ publish developers is difficult and most will need to be trained. Becoming proficient in eZ publish takes at least three months of development work after having been trained. Doing sophisticated work with extensions and integration is something that should be left to developers with over a year's experience.
In terms of the other roles played on eZ publish projects, experience with the technology is less important, but experience with content management is very important. Once again, these people are hard to find. Because of this, the people that end up working on content management projects rarely have the right experience. It's not a question of ability, it's simply one of training. There are no established training courses or methodologies for content management. We are making things up as we go along.
The people that are drawn to content management tend to have varied backgrounds. Some with experience in web development, some with information management, some with writing and documentation; but very few have an understanding of all elements. There are very few courses dedicated to content management. It's a new field and we are finding our way in what works and what doesn't. It's going to take time for the industry to become better established and the necessary skills better understood. Until that point, all we can do is cut our teeth on projects, learn from our mistakes, and hopefully, make fewer mistakes on the next project.
The other difference between content management and traditional projects is the breadth of skills required. Content itself is something that web developers have had to deal with, but not to the same level as required in content management. It works in a different way. It also combines workflow, business processes, and data manipulation. These elements are well understood in traditional development, so getting people with that sort of experience can help. But chances are, they won't be used to the limitations of a web browser as the client interface.
No matter how you look at it, staffing content management projects will continue to be a challenge until the industry has matured enough to have established practices and people, able to study what's involved before working on their first project. In the meanwhile, projects will continue to suffer from inexperienced or inappropriate staff.
Web projects can be quite small, lasting a week or two. Content management projects tend to be larger but still can vary in size quite significantly. A simple installation of eZ publish with minimal customization can be done in under a week. Larger jobs can take over a year from start to finish. It stands to reason, then, that the approach taken for smaller jobs would be different from larger jobs. As a rule of thumb, the bigger the project, the more rigour and discipline required. Basically, there is no one-size-fits all approach. For each project, the approach needs to be tailored to fit the particular needs of that project.
Having a client that understands what they are truly asking for is a blessing. It's also extremely rare. But we can't simply blame the client. As professionals, it's our job to explain things to the client, so that they do have an understanding. In the early days of the Web, it felt like half of the time was spent explaining to clients how a website worked. Nowadays, most people get the basics. Not so with content management, however. There is still a poor understanding of how these systems work and how best to implement them to achieve business objectives.
Another problem is that the use of the Web as a business tool is also changing at a rapid rate. The way we interact with websites is changing, the expectations of the users are increasing, and how things will pan out, no one knows—although if you are willing to part with significant amounts of cash, I'm sure there are plenty of research companies out there that are willing to take a guess at what will happen!
But mostly, it comes down to the client knowing what they want. I can't tell you how many times I'm asked, "Tell me what it can do and I'll tell you what I want". My standard response is "Tell me what you hope to achieve and I'll tell you how we can make it happen". It's too easy to focus on the features and ignore the business objectives. If a project doesn't have clear objectives, how can we tell if the solution implemented has succeeded?
In eZ publish projects, we are mostly dealing with web browsers. But one of the key benefits of eZ publish is its separation of presentation from content so that you can output to other formats and devices, e.g. XML, RSS, RFT, wireless devices, etc. Not only that, there are new devices emerging and we don't know what the future will hold.
As any industry develops, statements are made that become well known and accepted. The problem is they are not always true. Picking the facts from fiction can be difficult. This is particularly true in web development and now, content management development. Most of these myths are based on ignorance; that's why it's important to understand the nature of what we are dealing with so we can see through the lies.
Content management can ignore the rules of traditional project management.
This was the mistake that the cowboys of the early web era made, and it was a costly mistake paid for by clients who didn't know any better, many of whom paid ridiculous amounts of money for very little. Unfortunately, the same has happened in content management for similar reasons. The basic principles of understanding the project objective, properly capturing requirements, scoping the project, and establishing clear roles and responsibilities were too easily forgotten simply because it wasn't a normal project. Regardless of the fact that content management projects have a number of differences, the basics still apply. The question is how to apply them appropriately.
Content managed sites are just like a static website.
I have to admit, I only discovered this myth by believing it myself and then learning the hard way. There is a linear mindset in most websites; a page is a page, that's it. It might be linked to and from different pages, but a website is made up of a series of pages and functions. Content managed sites are different; pages are constructed dynamically from content elements, which can appear on many parts of the sites in different ways. It's a different mindset altogether that takes time to appreciate and understand. A content managed site is not just another website; it's a web publishing system, an application in its own right.
It's easy, it's only a website, it can't be THAT expensive!
This is the hardest myth of all to convince people is wrong. Websites appear simple, a site created using a content management system should appear simple to the user, but that doesn't mean that it's simple to achieve. The best designs are often simple, but making them that simple takes great skill. That's what many people fail to appreciate when it comes to content management, it looks and sounds easy. Just install the software and away we go. That's like saying, just install Word and you can write a book. The system is just the tool, a means to an end.
In the case of content management systems, the end can be the automation of a business process that used to be handled manually. A static website just presented information; a content management system can be a business tool that allows a business to interact with its customers in a more effective and efficient manner. Whenever business processes are involved, great care and attention needs to be taken in defining exactly how that business process will be automated via a website. Getting this wrong can mean the business could end up loosing revenue and customers rather than increasing revenue and gaining more customers.
It takes a lot of thought and planning to deliver a solution that works well and looks simple.
Software developers are great at implementing content management systems.
It's a bit like asking a fighter pilot to fly a helicopter, sure, he might know how to fly but a helicopter isn't quite the same as a jet fighter. It also doesn't mean that a fighter pilot couldn't learn and adapt to flying helicopters but it would require training and understanding as to how helicopters work as opposed to jet fighters. The point is making sure the right people are playing the right roles on the project. Just because a content management system is a piece of software, it doesn't mean it isn't specialized and therefore needs a specialized approach.
Content management systems combine content-focused and task-focused websites into one solution. It's important to understand the different natures of content-versus task-focused solutions so that we can be sure to cover the different needs of each solution. The following definitions are based on Jesse James Garrett's work on user-centered design in his book The Elements of User Experience. Later, we'll examine common types of solutions that combine hypertext and web applications.
A static website is actually a "hypertext system", i.e. a series of hypertext files connected to each other with links. Hypertext systems are content-focused and are about providing access to that information in an efficient manner via a web browser. If you break down a hypertext system into its different layers, you can see what's required to create one.
These will be derived from business needs to present information to meet specific objectives. Commonly, the objectives are marketing or communication goals. A good example is to promote a business through a corporate website.
This defines the content elements required to build the hypertext system in order to meet the business objectives. For example, a corporate site may wish to present case studies to illustrate what the company is capable of. The content requirements would outline the structure of the case studies and what information will be needed.
This defines how the site will be structured at a high level. How the content is to be organized in a logical fashion so that the users of the system will understand. It provides a context for the content elements.
This defines how the content is to be presented on each page and how users will navigate throughout the system. It's often missed or mixed in with the information architecture and visual design, but should be considered in its own right.
The visual design defines the visual treatment of the content, e.g., the text, graphics, and navigation. It's hard to separate information design from visual design and there is, in fact, some overlap between these elements of a hypertext system. Ideally, the visual design is the last element defined; but far too often, a design mock-up is done that actually mixes the information architecture, information and navigation design with the visual design and it's hard to then make changes without affecting all of these elements. It can be very confusing if there is not a clear understanding of the different elements and the role they play in a hypertext system.
There are only two things you can do with a website; communicate or interact. Web applications are about interacting with users, e.g., making a booking or submitting a request. A web application is no different to a traditional application except that it uses a web browser as the interface and the Internet for connectivity.
The objectives for a web application can be quite diverse, ranging from providing a simple feedback form through to automating business processes such as bank loan applications. The nature of the application will depend on the business needs but will either be focused on generating revenue e.g. online sales, or improving efficiency e.g. online business processes.
A functional specification defines the features that the application will deliver. The features may be grouped into feature sets. The specification will define how the application will deliver these features to the user. It will contain details of how business processes will be implemented. It is not a technical document as such—it doesn't contain database schemas and object models. It describes the functionality that the application will deliver.
The interaction design will most likely be captured in the functional specification but should be considered an element in its own right. Interaction design shows how the user will interact with the application, the flow of screens, and the options at each stage of the application.
Applications have interactions that follow a series of defined steps. Navigation is limited to the tasks the user can perform and is mostly defined by the interaction design. Basically, you don't want people to be jumping around a web application when they are in the middle of a task such as filling out a loan application. What is important is how the screen is laid out, how the buttons and form elements are arranged, what parts of the screen are dynamic, what changes when an action is performed. All of this is captured in the information and interface design.
As with hypertext systems, the visual design defines the appearance of text, graphics, and navigation. It is clearer with web applications to understand the role of the visual design. It is applied to the interface design to make it attractive and useable. By starting with the visual design, it's obvious that you are making decisions about the interface and interaction design, which may or may not be appropriate. Although the visual design is what we first notice, and is important, it should be the last element to be addressed in a web application.
If we compare the elements in hypertext systems and web applications, we can see there are some elements in common but the core elements differ.
Information & Navigation Design
Information & Interface Design
Given that the elements differ, it's obvious that, when building a web application, we need to take a different approach to building a hypertext system. The challenge with content management systems is that they are almost always a combination of the two, which means all the elements have to be considered. For some parts of the given solution, you'll be drafting interaction designs; for other parts you'll need navigation design. And then you'll have to work out what to do with navigation when the user is the middle of an interaction. This is why content management solutions have a greater level of complexity than a static website. There are more elements to consider and also how those elements interact in one solution.
Over time, a number of well defined categories of web solutions have emerged that combine hypertext systems and web applications into particular categories of solutions. Knowing there are patterns for these solutions can help make decisions for solutions that you may be asked to implement. It's about not re-inventing the wheel. If the website you are working on falls into one of the categories defined below, you can leverage an existing approach and reduce the risk in your project.
The categories below are based on a presentation from G. Kappel, "Web Engineering: Old Wine New Bottles" ICWE, 2004, Munich.
This is good example of a content-focused web application. The content of a website is dynamically generated in response to a user request. Form-based input, e.g. Search forms, is the primary mechanism for communication between client and server.
Public transport schedules
A transactional solution contains complex user interactions with many levels. Interactions often result in database queries and transactions. Well defined business logic is required and implemented strictly.
Workflow-based solutions are similar to transaction sites but are based on existing business processes and provide a more complex service to the user. They can be internal, business to business, or business to consumer. A prerequisite for a workflow system is an established business process.
Patient workflows in health care systems
Multi-level approval systems
These are solutions that unstructured and adaptive. Their focus is to support communication, e.g. groupware. They support shared information and workspaces. They assist people to work together through sharing information.
Forums & chatrooms
This is access to information via the Web or web-based systems. It is similar to a hypertext system but is more dynamic in that information can be presented in different ways on different pages. These solutions support knowledge management and derivation of new knowledge via re-use.
We are in a young industry with inexperienced people and clients that often lack an understanding of what they want. There are no established processes and procedures. And expectations from users are increasing as the Internet is used more and more as a business tool.
According to Alistair Cockburn (an internationally renowned project manager and IT strategist), developing solutions is actually making ideas concrete in an economic context. With website solutions, we are crossing even more boundaries than software development. eZ publish solutions bring marketing, communication, interaction, information, and business processes together.
If we fail to improve the way we manage projects, we will keep making the same mistakes. The reason for this book is to help provide a framework for eZ publish projects that deals with the most important aspects and will hopefully lead to better results.
In short, the better we understand the situation, the better we can deal with it. This book is not about a silver bullet; there is no such thing. There is no single approach to make all projects work. What this book does is define a framework that helps us deal with a complex and changing environment. From this, we are better placed to create quality solutions.
Content management as a discipline combines the practices of building a static website with building a web application. Because of this, we need to be aware of the requirements of content-focused and task-focused solutions. Given that there are no methodologies in place that cover both aspects of content management systems we need to adapt existing approaches.
Underlying this is the importance of understanding the specific needs of each part of the solution and taking the appropriate approach so that the end solution works together. This means having a clear understanding of the roles required and having the right people on the team to fill those roles.