|
|
There are two fundamental elements to content management: (1) storing stuff in a content repository, and (2) supporting the workflow of a group of people engaged in putting stuff into that repository. This chapter will treat the storage problem first and then the workflow support problem. We'll also look at version control for both content and software, at look and feel design for individual pages, and at navigation design and information architecture.
Part of the art of content management for an online learning community is reducing the number of types of content. For example, consider a community where the publisher says "I want articles [magnet content], comments from users on articles, news from the publisher, comments on news from users, questions from users, and answers to questions." A naive |
 |
implementation from these specifications would result in the creation of
six database tables: articles, comments_on_articles, news, comments_on_news, questions, answers. From the RDBMS's perspective,
there is nothing overwhelming about six tables. But consider that every new table defined in the RDBMS implies roughly twenty Web scripts. Ten of these scripts will constitute a user experience: view a directory of content in Table A, view one category, view one item, view the newest items, grab a form to insert an item, confirm insertion, request an email alert of comments on an item. Ten of these scripts will constitute an administrator's experience: view a directory of content in Table A, view one category, view one item, view the newest items, approve an item, disapprove an item, delete an item, confirm deletion of an item, etc. It will be a bit tough to code these twenty scripts in a general fashion because the SQL statements will differ in at least the table names used.
|
|
|
|
|
|
