invalid command name "ns_adp_include"
while executing
"ns_adp_include header.adp "
invoked from within chunk: 2 of adp: /home/dvr/web/dvr/cmd/what-to-build.adp
"Content Management" is such a vague term that it's almost meaningless. (If you told someone your job was "managing content", they would claim you told them nothing.)
In order to produce something concrete, we look at a traditional CM problem: an online magazine. This chapter asks "What features would a publishing staff want from a CMS?"
Our hypothetical publishing team produces an online magazine, similar to salon.com or slate.com. It has a staff of writers, editors, graphics designers, and programmers, all working together to publish content daily. Content is organized into departments -- News, Sports, etc.
Here's what each type of employee needs from the system:
| Writers | Should be able to add stories to the system or modify existing stories. |
| Editors | Stories added to the system don't automatically go live; they must be reviewed and approved by the editor. When a writer completes a story, it's routed to the editor, who will review it, possibly make changes, and click a button to make the story go live. |
| Graphic designers | Writers and editors deal mostly in plain text; the graphic
designer is responsible for the final html. They choose the
background color, the font face, the size of the font, the
placement of images, etc.
To make their job as easy as possible, the graphic designer spends part of his time maintaining a set of templates that can be applied to stories to give them a consistent look. The CMS should provide a way to manage these templates and attach them to stories. |
| Programmers | The programmers are responsible for keeping the site running and improving the CMS -- adding features, fixing bugs, and fine-tuning the interface to make the rest of the staff more productive. |
|
| A staff member's workspace |
The CMS should ensure that only one person can edit a story at a time. Staff members "check out" a story to edit it, then check it back in when they're done. If a staff member needs to make a change to a story when someone else has it checked out, they must wait for that person to check it back in. (Editors will have a special feature that allow them to steal an item away from another staff member, but this feature will be used only in rare occasions.)
The CMS should keep a record of each person's changes. If a story was (1) added to the system by the writer, (2) edited by the editor, then (3) marked up by the designer, the system will have three revisions of the story, each a snapshot taken when the staff member completed their part.
If you wanted to know what changes the editor made, you could compare revisions #1 and #2. Since each revision is equal to the previous revision plus one person's changes, it's always possible to get an answer to the question "Who made this change?".
Since old revisions are never thrown away, it's only a small problem if the wrong person makes changes to a story; the system will know what the story looked like before that person made their changes, so the unwanted changes can be rolled back.
Any staff member can add or update a story, but the system won't allow it to be seen by the public before being approved by an editor.
A writer should also be able to make updates to a live story, but his updates shouldn't be seen by the public before being approved. Here is the scenario:
Even though revision #4 is the latest, only revision #3 has been approved, so that's the revision shown to the public. When the writer completes his changes, the story will be routed to the editor (resulting in revision #5 if he makes any changes), and once approved, the new revision can go live.
If more than one revision of a story has been approved, the editor will be able to choose which of the approved revisions is the live one.
 |
| The editor can choose which revision is live |
In most cases, a story goes from the writer, to the editor, to the graphic designer, then back to the editor for final approval.
Keeping old revisions of stories allows us to be less concerned with workflow. If the editor doesn't like the changes made to revision #4, he can roll back the changes. (This won't cause revision 4 to disappear, but it would create a fifth revision that's based on revision #3, allowing him to ignore the changes he didn't like.)
The philosophy behind the system is to give any staff member the ability to change content, but record who did what and provide a way to step back to any point in time. The staff has its own rules about who is allowed to edit content (for example, a writers in the sports department knows not to edit News stories), but enforcement is handled outside the system -- if the editor finds that someone incorrectly modified a story, it's easy to discover who made the change and easy to revert the story to the state it was in before that person touched the story.
For this publishing team, the best system is one that suggests a workflow, but doesn't enforce it. Our safety net is the rule (enforced by the software) that an editor must approve every piece of content before it appears on the public site. Little or no damage is done by the wrong person checking out a story and making changes.
Every revision will be in a workflow state. For a story, the possible states are:
Any staff member can put any revision in any of these states, except for 'approved', which is reserved for editors.
Since the system won't enforce a workflow, states have two uses. First, they're used to tell staff members when it's their turn to work on a story -- when a story reaches the 'written' state, it should be reviewed by an editor; when it reaches the 'edited' state, the designer should do his part; when it reaches 'formatted', the editor should give the story a final review and make it go live.
Second, the state information tells us who touched the story and why. If a story has gone through the 'writing', 'written', 'formatting', and 'formatted' states, but not the 'edited' states, we know the designer did his work before the editor reviewed the text. The editor should review the text and make it go live without sending it through the designer a second time.
Every story has the same parts: a title, a subhead, a body, a publishing date, a writer, and some associated photos. Every story should be displayed the same way -- the headline should always be in the same place, the fonts should be the same, etc.
When a writer sits down to edit a story, he doesn't need to worry about html because he's not formatting the page that holds the story; he's editing fields -- one for the title, one for the subhead, and so on.
 |
| The form used to edit stories |
The completed page shown to the public is the result of combining the text from these fields with a template -- created by the designer -- that determines layout. To ensure that all stories look alike, most stories in a department will use the same template. If the designer wants to change the appearance of all stories in a department, he only needs to change that department's template.
Since most stories will use pre-existing templates, it's likely that most stories can be published without the designer's involvement. The editor can choose the template, preview the final html, and make the story go live.
If a story is published about Bush and the war with Iraq, links to the story should appear in these places:
Since manually updating these pages takes time and leads to errors, the CMS should generate all these links automatically, and remove them automatically if the story is removed. In the screen shot below, the "Highlighted?" menu item determines whether the story appears on the front page in addition to the front News pages. Specifying a topic for the story, e.g., "George W Bush", tells the system to create a link to the story from that topic's page.
invalid command name "ns_adp_include"
while executing
"ns_adp_include footer.adp "
invoked from within chunk: 3 of adp: /home/dvr/web/dvr/cmd/what-to-build.adp