graphitefriction / useful-content

Curated resources and references about content. Categories include: story arcs, bias, chunking, etc.
0 stars 0 forks source link

Content Modelling: A Master Skill #28

Open WhiteShark5 opened 9 years ago

WhiteShark5 commented 9 years ago

http://alistapart.com/article/content-modelling-a-master-skill

WhiteShark5 commented 9 years ago

Author: Rachel Lovinger Blog Post 04/24/2012

"...content model is one of the most important content strategy tools at my disposal. A content model documents all the different types of content you will have for a given project. It contains detailed definitions of each content type’s elements and their relationships to each other. The content model both influences and is influenced by the work of several other disciplines. A content model helps clarify requirements and encourages collaboration between the designers, the developers creating the CMS, and the content creators.

For information architects and designers — The content model helps information architects and designers make sure that the page designs accommodate all the content types for the site and provides guidance on the bits of text and media that will be available for the page. At the same time, the content model needs to support the content, layout, and functionality portrayed in the designs.

For developers — The content model helps developers understand content needs and requirements as they configure the CMS. Given the many types of CMS, there are many ways to accomplish the same effect. If the content model indicates something that isn’t easily accomplished by a given CMS, it helps the developers adjust their approach to create the desired result in a way that’s compatible with the way the CMS works. Developers will need a greater level of detail in the content model.

For content authors and producers — The content model gives content authors and producers guidelines on what content to write or create and how to enter it into the CMS.

How do you create a content model? There are three main things to consider:

  1. The assembly model: The way content creators will put individual content items together to make webpages, campaigns, documents, or other content products. It’s important to understand that most CMSs have a bias. They’re often designed around a certain “unit” of content and that’s what they’re optimized to create. For blog applications, the unit is a post. For Sharepoint, a unit is a document. For most web content management tools a unit is a webpage, even though we’re more likely to be making dynamic sites that use (and reuse) content in a variety of configurations. To make these decisions, you need to consider how modular your content needs to be. Some types of content, such as a press release, may be fairly self-contained. Each instance of Press Release will create one page. In other cases, you’ll have pages made up of many different reusable content modules collected to create the whole.

Some other things to consider when thinking about the assembly model:

-How structured does the content need to be? Do you need to capture specific, uniquely identifiable data that can be used to sort or filter the content (for example, date, price, rating, author, or location)?

-How flexible does the content need to be? Can you predict what the elements of a page will be, how many and in what order? Or do you need to support an open structure with the ability to add varying numbers of various content elements to any part of the page?

-How reusable does the content need to be? Can you make the reusable parts separate so that they can be shared across different pages of the site?

-How tolerant are your content creators of laborious processes? If you ask them to take a lot of unstructured content and break it into dozens of distinct data fields, are they going to have the time to do it? If you’re lucky, maybe they’re already used to doing that kind of work, but try to avoid asking them to break up the content if it serves no functional purpose, because this can be very time-consuming.

  1. The content types: The various configurations of content that are distinct enough to be unique types in the system. Questions about how structured the content needs to be will help you determine what constitutes a distinct content type. If the content doesn’t need to be structured, you can have one basic content type and put whatever you need to in it. This is the premise behind a blog post. Very flexible but very unstructured. There are other reasons to make something a separate type of content:

-Distinct, reusable elements. You might decide to create an Author content type that contains the name, bio and photo of each author. These can then be associated with any piece of content that person writes.

-Functional requirements. A Video might be a different type of content because the presentation layer needs to be prepared to invoke the video player.

-Organizational requirements. A Press Release may be very similar to a general Content Page, but only the Press Release is going to appear in an automatically aggregated Newsroom. It’s easier for these to be filtered out if they’re a unique type of content.

  1. The content attributes: The content and metadata elements that make up each type, including how they relate to each other. In the last step, you’ll identify each different element of each content type. This includes both the content that you can see on the page, and the metadata, which you don’t see. It also includes relationships to other content types. For example, if you create a separate Author content type, you will need to indicate that a Review can have an Author associated with it.

Some elements will be obvious—your press release has a title, maybe a subtitle, an optional image, and body text. But determining which pieces of information need to be captured in separate fields can be a challenge in some cases. Consider the following:

-Layout: Do some things need to be displayed in a completely different style, or on varying places on the page? You should avoid having markup and styling stored with the content, so ideally each element that needs to be displayed differently should be in its own field. For example, you could just make the subtitle part of the body text and ask your editors to bold it, but how well is that going to work with the RSS feed or on a mobile device?

-Reuse: Again, a separate field of data can be pulled out and used independently of the rest of the page, but not if it’s all part of one big body text.

-Sorting and filtering: If you want to be able to sort content by date, or filter content that pertains to a particular city, then these pieces of information have to be in a field by themselves so that they can be used to sort and filter.

CONTENT MODEL DOCUMENTATION Since the content model serves different audiences, at several different stages of the project, treat it as a living document. It’s never really complete—you just stop updating it when the project is over. If you must also create CMS training or content production guidelines, the content model will serve as a useful starting point. You can easily excerpt information as needed and reformat it into a more user-friendly document. Though we might strive for a well-configured CMS that’s intuitive and easy to use, the reality of the implementation is almost always more complicated than that. Providing proper guidance to the CMS users could make the difference between the project being perceived as a success or as a serious mess.

Conclusion A content model is a powerful tool for fostering communication and aligning efforts between UX design, editorial, and technical resources on a project. By clearly defining the assembly model, the content types, and the content attributes, we can help make sure that the envisioned content strategy becomes a reality for the content creators. In my recent projects, I find that content modeling is more and more in demand. It’s a valuable skill for any content strategist, especially those that strive for mastery.