Section 12.6. Content Models


12.6. Content Models

Content models are "micro" information architectures made up of small chunks of interconnected content. Content models support the critical missing piece in so many sites: contextual navigation that works deep within the site. Why a missing piece? Because it's easymaybe too easyfor an organization to accumulate blobs of content, but extremely difficult to link those blobs together in a useful way.

12.6.1. Why Do They Matter?

We encounter content models all the time on the Web and in more traditional media. A recipe is a great example. Its objects are a list of ingredients, directions, a title, and so on. If you "greek up" a recipe, it'll still be recognizable. But change the logicby putting the steps before the ingredients or leaving out an important objectand the model collapses. Content models rely on consistent sets of objects and logical connections between them to work.

12.6.1.1. Supporting contextual navigation

Imagine that, by hook or by crook, you found your way deep into a clothing retailer's web site in your quest for a snazzy new blue oxford shirt. As a user, you've just clearly stated an incredibly specific information need. Such a need is far more precise than that of a user who has reached a site's main page. Wouldn't it be silly for the retailer not to apply this knowledge to your benefit (not to mention to its advantage)?

That's why most online retailers will, at this point, introduce you to some matching pants or other accessories. "You might also be interested in...." This is far more reasonable than the retailers hoping and expecting you to 1) guess that they sell these related items, and 2) actually find those items using the site's top-down organization and navigation systems. Horizontal hopping across the hierarchy is a form of contextual navigation, where your movement is based more on your needs as a user, rather than the site's structure. And content models exist primarily to support such navigation, whether for cross-selling retail products, connecting baseball fans to the story behind the boxscore, or introducing potential customers to a product's specs.

12.6.1.2. Coping with large amounts of content

Content models also help us deal with scale. When inventorying content, it's not uncommon to stumble upon large bodies of homogenous information buried in our content management systems and databases. For example, after a content inventory, a company that provides information on cellular phone products might find that it owns dozens of content chunks for each model's basic product information, thousands of reader reviews, and many more for information on related accessories. The phone product pages look, work, and behave the same. So do the review pages and the accessory pages.

If each type of content chunk works the same, why not take advantage of this predictability by linking them? Allow those users to move naturally from a specific cell phone's page to its product reviews and accessories. Better yet, do this in an automated fashion so the links can be generated instantly, rather than having an army of HTML coders deciding what should be linked to what. Automating the creation of links between content chunks means your users benefit from more and better ways to navigate contextually, and your organization derives greater value from its investment in the content.

So content models can be especially helpful when we've got a lot of high-value homogeneous content chunks that aren't well linked and some technology on hand to automate those links. You can certainly create content models for smaller numbers of content chunksfor example, information associated with the dozen or so people that serve on your company's boardbut it's pretty easy to manually connect these objects. You could also create content models for all of your content, but the process is a bit involved, so we recommend doing so for only your most valuable content (with value defined as a judicious combination of both user and organizational needs, of course).

12.6.2. An Example

Let's say you work for a media organization that has invested lots of resources in assembling information on popular music. Certain content chunkssuch as artist descriptions and album pagesnumber in the thousands, and they all look and work in the same way. You might sense that there is potential here for a content model that serves fans of popular music. Instead of having those fans rely on the site's hierarchy to find content relevant to a particular artist or album, why not create a content model?

Based on content inventory and analysis, there are a few music-related content objects that may emerge as good candidates for a content model, shown in Figure 12-21.

Figure 12-21. Content objects that might be the basis of a content model for album information


How should these objects be linked? We can certainly decide that an album page ought to link to its corresponding review, artist bios and descriptions should link to each other, and so on. But it won't always be so easy to come up with the most obvious links; even if it is fairly obvious, you may need to produce some user research to validate your work.

In such cases, consider a variation of the card sort exercise. Print out a sample of each content object and cut out the navigation options (to prevent biasing users with the current information architecture). Then ask subjects to look at each content object and consider where they'd want to go next. Then have them cluster the objects and draw lines between them that indicate navigation (they can do this with string, or they can tape the content object samples to a whiteboard and use dry-erase markers to draw their lines). Arrows indicate whether users wish to navigate in both directions or prefer a one-way link.

To perform a simple gap analysis, ask subjects which missing content objects would be nice to include in the mix. By doing so, you'll get a sense of what should be added to your content model. If you're fortunate, the missing objects might already exist somewhere else in your site. Otherwise, you'll at least have some guidance in deciding which content to create or license.

At the end of the processwhether based on user research or your own hunchyou'll have an idea of how your content model ought to work. The result might look like Figure 12-22.

Figure 12-22. An ideal content model, showing navigation and missing content objects


So you've identified new content objects, like a discography, that you might need to create. And you've linked to other content, like TV listings for televised concerts and events in a concert calendar, that is a logical extension of the content model (and possibly, a connection to candidates for future content models). You've also identified logical "tops" or common points of entry to this content. And ultimately, you have a sense of how users might want to navigate an area deep in the guts of your site.

Unfortunately, you're not quite done. How do these links between content objects get made?

If you're Amazon, you've got reams of usage data to draw from. Amazon employs customer-behavior data to make connections between related products in its content model; familiar examples are the products listed under "Customers who bought this item also bought" and "What do customers ultimately buy after viewing this item?" But not every organization has the traffic volume from which to cull this kind of useful data.

So the rest of us typically rely on metadata as the basis of the logic that connects our content chunks. Shared metadata does the work of linking a pair of content chunks. For example, if we want to link an album page and an album review, the logic might look like this:

IF ALBUM PAGE'S ALBUM NAME = ALBUM REVIEW'S ALBUM NAME THEN LINK ALBUM PAGE AND ALBUM REVIEW

Now, this rule might suffice for albums with unique titles, like "Sergeant Pepper's Lonely Hearts Club Band." But what if the title is the ubiquitous "Greatest Hits"? If you're lucky, the object has a unique identifier, like an ISBN, that can be used as connecting metadata (many classical albums do have unique IDs; unfortunately, pop albums don't):

IF ALBUM PAGE'S UNIQUE ID = ALBUM REVIEW'S UNIQUE ID THEN LINK ALBUM PAGE AND ALBUM REVIEW

But as that's often not the case, your linking logic will need to get a little more complicated, and additional metadata attributes will be necessary:

IF ALBUM PAGE'S ALBUM NAME = ALBUM REVIEW'S ALBUM NAME AND ALBUM PAGE'S ARTIST NAME = ALBUM REVIEW'S ARTIST NAME THEN LINK ALBUM PAGE AND ALBUM REVIEW

As you can see, these rules rely on metadata. Do the required metadata attributes exist? The bad news is that you'll probably need to invest in creating new metadata from scratch or acquiring it.

Of course, metadata availability is a consideration with just about any information architecture project of any size. And the good news is that the content modeling process will help you decide which metadata attributes to invest in by helping you select the most useful from the wide range of possibilities.

Consider our arrows in Figure 12-22. Which metadata will be necessary to drive the logic behind each link? Make a simple table listing each content object, which other objects it should link to, and the metadata attributes required to make those connections. It might look something like this:

Content objects......link to other content objects......by leveraging common metadata attributes
album pagealbum review, discography, artistAlbum Name, Artist Name, Label, Release Date
album reviewalbum pageAlbum Name, Artist Name, Review Author, Source, Pub Date
discographyalbum review, artist descriptionArtist Name, Album Name, Release Date
artist descriptionartist bio, discography, concert calendar, TV listingArtist Name, Desc Author, Desc Date
artist bioartist descriptionArtist Name, Individual Artist Name
concert calendarartist descriptionArtist Name, Tour, Venue, Date, Time
TV listingartist descriptionArtist Name, Channel, Date, Time


Notice a pattern here? Certain metadata attributes show up more frequently than others. These are the attributes that are most necessary for the content model to succeed. If you're operating with limited resources (and who isn't?), now you'll have an excellent way to prioritize your investment in metadata attributes.

12.6.3. A Valuable Process

As you can see, content models are as much an exercise as a deliverable. While the primary output is a useful IA deliverable that informs the design of contextual navigation deep within a site, the process also generates two invaluable, if secondary, benefits.

First, content modeling forces us to determine which content is most important content to model. As you can see, it's worknot necessarily terribly difficult, but not trivial. Most likely you can't create content models for all of your content. So you'll have to ask yourself: which content fulfills the requirements of homogeneous, high volume, and, most of all, high value? You might find a set of priorities falls out of this exercise; for example, perhaps this year you'll develop a product-area content model, next year a support-area content model, and later you'll link those two models together for even greater benefit.

Second, content modeling also forces you to choose which of the many metadata attributes are the ones that will make your content model operational. The combination of focusing on and narrowing down to critical content and critical metadata means a huge simplification and clarification of a large and complex problem space. And that's what the Pareto Principle, the information architect's best friend (and commonly referred to as the 8020 rule), would recommend.




Information Architecture for the World Wide Web
Information Architecture for the World Wide Web: Designing Large-Scale Web Sites
ISBN: 0596527349
EAN: 2147483647
Year: 2006
Pages: 194

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net