Organizing content in a meaningful way is nothing new. We have been doing it for centuries in our libraries—the Dewey decimal system being a perfect example. So, why can’t we take known approaches and apply them to the Web? The main reason is that a web page has more than two dimensions. A page on a book might have footnotes or refer to other pages, but the content only appears in one place. On a web page, content can directly link to other content and even show a summary of it. It goes way beyond just the content that appears on the page—links, related content, reviews, ratings, etc. All of this brings extra dimensions to the core content of the page and how it is displayed. This is why it’s so important to ensure your content model is sound. However, there is no such thing as the “right” content model. Each content model can only be judged on how well it achieves the goals of the website now and in the future.

The Purpose of a Content Model

The idea of a content model is new, but it has similarities to both a database design and an object model. The purpose of both of these is to provide a foundation for the logic of the operation. With a database design, we want to structure the data in a meaningful way to make storage and retrieval effective. With an object model, we define the objects and how they relate to each other so that accessing and managing objects is efficient and effective. The same applies to a content model. It’s about structuring the content and the relationships between the classes to allow the content to be accessed and displayed easily.

The following diagram is a simple content model that shows the key content classes and how they relate to each other. In this diagram, we see that resources belong to a collection which in turn belongs to a context. Also, a particular resource can belong to more than one collection.

As stated before, there is no such thing as the “right” model. What we are trying to achieve is the most “effective” model for the project at hand. This means coming up with a model that will provide the most effective way of organizing content so that it can be easily displayed in the manner defined in the functional specification. The way a content model is defined will have an impact on how easy it is to code templates, how quickly the code will run, how easy it is for the editors to input content, and also how easy it is to change down the track. From experience, rarely is a project completed and then never touched again. Usually, there are changes, modifications, updates, etc. down the track. If the model is well structured, these changes will be easy, if not, they can require a significant amount of work to implement. In some cases, the project has to be rebuilt entirely and content re-entered to achieve the goals of the client. This is why the model is so important. If done well, it means the client pays less and has a better-running solution. A poor model will take longer to implement and changes will be more difficult to implement.

What Makes a Good Model?

It’s not easy to define exactly what makes a good model. Like any form of design, simplicity is the key. The more the elements, the more complex it gets. Ideally, a model should be technology independent, but there are certain ways in which eZ publish operates that can influence how we structure the content model.

Do we always need a content model? No, it depends on the scale of the project. Smaller projects don’t really need a formal model. It’s only when there are specific relationships between content classes that we need to go to the effort of creating a model. For example, a basic website that has a number of sections, e.g., About Us, Services, Articles, Contact, etc., doesn’t need a model. There’s no need for an underlying structure. It’s just content added to sections. The in-built content classes in eZ publish will be enough to cater for that type of site. It’s when the content itself has specific relationships e.g., a book belongs to a category or a product belongs to a product group, which belongs to a division of the business—this is when you need to create a model to capture the objects and the relationships between them.

T o start with, we need to understand the content we are dealing with. The broad categories are existing/known content and new content. If we know the structure of the content we are dealing with and it already exists, this can help to shape the model. If we are dealing with content that doesn’t exist yet (i.e. is to be written or created for this project) it’s harder to know if we are on the right track. For example, when dealing with products, generally the product data will already exist in a database or ERP system. This gives us a basis from which to work. We can establish the structure of the content and the relationships from the existing data. That doesn’t mean that we simply copy what’s there, but it can guide us in the right direction. Sometimes the structure of the data isn’t effective for the way it’s to be displayed on the Web or it’s missing elements. (As a typical example, in a recent project, the product data was stored in three places—the core details were in the Point of Sale system, product details and categorization were in a spreadsheet, and the images were stored on a file system.)

So, the first step is to get an understanding of all the content we are dealing with. If the content doesn’t exist as yet, at least get some examples of what it is likely to be. Without knowing what you are dealing with, you can’t be sure your model will accommodate everything.

T his means you’ll need to allow for modifications down the track. Of course we want to minimize this but it’s not always possible. Clients change their minds so the best we can do is hope that our model will accommodate what we think are the likely changes. This really can only be done through experience. There are patterns in content as well as how it’s displayed. Through these patterns e.g., a related-content box on each page, we can try to foresee the way things might alter and build room for this into the model. A good example was that on a recent project, for each object, there was the main content but there were also a number of related objects (widgets) that were to be displayed in the right-hand column of the page. Initially, the content class defined the specific widgets to be associated with the object. The table below contains the details of a particular resource (as shown in the previous content model). It captures the details of the “research report” resource content class.

This would mean that when the editor added content, they would pick the free-form widgets and then the multimedia widget to be associated with the research report. Displaying the content would be straightforward as from the parent object we would have the object IDs for each widget.

The idea is sound but lacks flexibility. It would mean that the order in which the object was added would dictate the order in which it was displayed. It also means that if the editor wants to choose to add a different type of widget, they couldn’t unless the model was changed, i.e., another attribute was added to the content class.

We updated the content class as follows:

This approach is less strict and provides more flexibility. The editor can choose any widget and also select the order. In terms of programming the template, there’s the same amount of work. But, if we decide to add another widget type down the track, there’s no need to update the content class to accommodate it.

Does this mean that anytime we have a related object we should use the latter approach? No, the reason we did it in this situation is that the content was still being written as we were creating the model, and there was a good chance that once the content was entered and we saw the end result, the client was going to say something like “can we add widget x” to the right-hand column of a context object? In a different project, in which a particular widget should only be related to a particular content class, it’s better to enforce the rule by only allowing that widget to be associated with that content class.

Defining a Content Model

The process of creating a content model requires a number of steps. It’s not just a matter of analyzing the content; the modeler also needs to take into consideration the domain, users, groups, and the relationships between different classes within the model. To do this, we start with a walkthrough of the domain.

Step 1: Domain Walkthrough

The client and domain experts walk us through the entire project. This is a vital part of the process. We need to get an understanding of the entire system, not just the part that is captured in the final solution. The model that we end up creating may need to interact with other systems and knowing what they are and how they work will inform the shape of the model. A good example is with e-commerce systems, any information captured on a sale will eventually need to be entered into the existing financial system (whether is it automated or manual).

Without an understanding of the bigger picture, we lack the understanding of how the solution we are creating will fit in with what the business does. That’s when there is an existing business process. Sometimes there is no business process and the client is making things up as they go along, e.g. they have decided to do online shopping but they have never dealt with overseas orders so don’t know how that will work and have no idea how they would deal with shipping costs.

One of the typical problems that will surface during the domain walkthrough is that the client will try to tell you how they want the solution to work. By doing this, they are actually defining the model and interactions. This is something to be wary of. It is unlikely that they would be aware of how best to structure a solution; what you want to be asking is what they currently do, what’s their current business process.

You want to deal with facts that are in existence so that you can decide how best to model the solution. To get the client back on track ask questions like: How do you currently do “it” (i.e. the business process)?

• What information to you currently capture?
• How do you capture that information?
• What format is that information in?
• How often is the information updated?
• Who updates it?

This gives you a picture of what is currently happening. Then you can start to shape the model to ensure that you are dealing with the real world, not what the client thinks they want. Sometimes they won’t be able to answer the question and you’ll have to get the right person from the business involved to get the answers you want. Sometimes you discover that what the client thought was happening is not really what happens.

Another benefit of this process is gaining a common understanding. If both you and the client are in the room when the process for calculating shipping costs is being explained by the Shipping Manager, you’ll both appreciate how complex the process is. If the client thinks it’s easy, they won’t expect it to cost much. If they are in the room when the shipping manager explains there are five different shipping methods and each has its own way of calculating the costs for a shipment based on their own set of international zones, you know modeling that part of the system is not going to be straightforward unlike what the client initially thought.

What this means is that the domain walkthrough gives you a sense of what’s real, not what people think the situation is. It’s the most important part of the process. Assumptions that “shipping costs” are straightforward, so you don’t need to worry about that, can be a disaster later down the track when you find out it’s not the case. Also, don’t necessarily rely on requirements documents (unless you have written them yourself). A statement in a requirements document may not reflect what really happens; that’s why you want to make sure you go through everything to confirm that you have all the facts. Sometimes, a particular requirement can be stated in the document but when you go through it in more detail, ask a few questions, pose a few scenarios, the client changes their mind on what it is that they really want as they realize what they thought they wanted is going to be difficult or expensive to implement. Or, you put an alternative approach to them and they are happy to achieve the same result in a different manner that is easier to implement. This is a valuable way to work out what’s real and what really matters.