This is the third post in the series on how to create a modern web site. In previous post we covered how to set up the baseline for a web project and how to set up the site map. This post will cover the next step in a web project: the Web Content Model.
Before I started to write these posts we used to call this part of the project Information Architecture (IA). While browsing the web about the topic for this post, I noticed that IA is used in much broader sense. It usually includes the site map (we covered it already), navigation, content organization, wire frames, mock-ups and user scenarios. The topic covered in this post is very specific part of this broader picture: how the content should be organized, thus we can call it information structure or content model. A similar concept is the database model when designing a system which uses an SQL database (of course, content model could be implemented via a database, depends on the software used).
What is a web content model?
There are several definitions we could apply:
- it is a basic information architecture (focusing on just describing each specific page)
- it specifies information on each specific page
- assessing needed content on each specific page
First, you’ll notice that ‘specific page’ is mentioned always. In the process of specifying the content model all page types ought to be identified (we already defined some of them on the site map). The process is natural thing to do after site map is created. Also, with the content model in place you should have all the info for creating wire frames.
How to create it?
The content model is basically a sheet, so you can create it in Google spreadsheet, Excel or any other sheet application.
- Check your site map notes and collect all different types of pages specified there. Probably you will need to add more pages which were not in the site map. For example interstitial pages like login screen or error pages are usually not in the site map.
- Next step would be to list all pieces of information for each page type
- For each pieces of information set type and source
Example for this web site showing just few page types:
page type |
what |
type |
source |
---|---|---|---|
Frontpage |
3 messages with image |
slider |
|
list of news and posts |
title, image, intro |
news, blog |
|
manual list of references |
title, image, intro |
portfolio |
|
feedback box |
custom |
||
testimonial box |
custom |
||
contact box |
custom |
||
manual list of clients |
slider |
clients |
|
Blog post |
title |
text |
|
date |
date |
||
author |
text |
||
tags |
tags |
||
intro |
rich text |
||
image |
image |
||
body |
rich text |
||
user comments |
comments |
||
RSS subscribe box |
custom |
||
tags box |
cloud |
blog |
|
manual list of clients |
slider |
clients |
In “page type” column all specific pages are listed. In “what” column all specific pieces of information are listed. For each “what” there is a description in “type” column of what kind of information is shown. This can be a simple information type like text for Title or more complex like comments. Also for all pieces of information which are not directly managed on the page, the page which manages that content is listed in “source” column. For example: Title of the page is always managed by the page, but a List of News & Posts is usually not, that information is actually gathered from other pages to avoid duplicate entry.
It is important that all stakeholders understand how each piece of information works, so that the functionality is common to all team members. If this is not the case, it can lead to problems later. E.g. client could expect User Comments to behave in some different way so the specification could be broken down to even smaller pieces.
Creating this sheet is probably not needed is some cases:
- if the site is simple so all information can be specified in sitemap and wireframes,
- or, if the site is standard in some way (e.g blog site) so the content model is known,
- or for very simple pages that have no manageable information
But for more complex sites, especially with more customized content, this step should give a complete overview on all information that is presented and should be an excellent base for next steps:
- User scenarios
- Wireframes
- CMS page type definitions (if the site is being implement with modern CMS)
For even more complex sites additional columns would be very handy. If, for example, a site has more user groups with different policies an additional “can read” column would be good to have.
What is important to remember that this model should be revised in situations were you learn more information in the following steps. For example, if you produce a clickable demo for user testing purposes and the results are telling you to change the content model, do it.
That is all for know, hopefully next post from this series will be published in less than year time :)
Photo credit: Designed by Freepik