« Mind your grammar | Main | Chapters 5 and 7 Ready for Review »

Content Control Patterns - From Chapter 6

In the first draft of chapter 6 of our book on reputation system design we begin guiding the reader through a process to create their own reputation model. We start by helping identify the business and other goals they have for their application/site, and quickly move on to what kind control model they have in mind for users creating and interacting with content: What we're calling Content Control Patterns. These patterns have general applicability when talking about all social media design, so we wanted to share them widely and gather feedback as early as possible. We'd especially like suggestions for better names for the patterns.

The individual CCPs (Content Control Patterns) are detailed over on the wiki, so be sure to click through on one of the pattern names or images.

--- Begin Excerpt ---

Whether you need reputation at all, and the particular models that will serve you best, are largely a function of how content is generated and managed on your site. Consider the workflow and life-cycle of content that you have planned for your community, and the various actors that will influence that workflow.

First, who will be touching your communities content-will users be doing the bulk of content creation and management? Or staff? (We'll generically refer to these people as 'staff', but they could be people under your employ, or trusted third-party content providers, or even 'deputized' members of the community, depending on the level of trust & validation that you put into them.)

In most communities, you'll find that content control is a function of some combination of users and staff. Therefore, it's worth our while to dissect the types of activities that each might be doing. Consider all the potential activities around the content lifecycle at a very granular level:

  • Who will draft the content?
  • Will anyone edit it, or otherwise determine its readiness for publishing?
  • Who is responsible for actually publishing it to your site?
  • Can anyone edit content that's live?
  • Can live content be evaluated in some way? Who will do that?
  • What effect does evaluation have on content?
    • Promote or demote its prominence?
    • Remove it altogether from the site?

While you'll ultimately have to answer all of these questions, at this stage these fine-grained questions can be abstracted somewhat. Right now, there are really three questions you need to pay attention to:

  1. Who will create the content on your site? Users or staff?
  2. Who will evaluate the content?
  3. Who has responsibility for removing content that is inappropriate?

There are eight different content control patterns for each unique combination of answering the questions above. Each pattern has unique characteristics when considering what reputation systems you may, or may not, wish to consider for your application. For convenience, we've given each pattern a name: Web 1.0, Submit-Publish, Bug Report, Reviews, Surveys, Agents, Basic Social Media, The Full Monty, but these names are just place holders for discussion, they are not a suggestion to recategorize your product marketing. We will now cover each of these content control patterns in detail so you will understand the implications and ramifications of each.

Web 1.0 Submit-Publish
Bug Report Basic Social Media
Reviews Agents
Surveys The Full Monty
The Content Control Patterns for communities of content. These largely determine the amount, and types, of reputation models that you will need.
If you have multiple content control patterns, consider them all and focus on any shared reputation opportunities. For example, you may have a community site with a hierarchy of categories that are created, evaluated and removed by staff, but perhaps the content within that hierarchy is created by users. In that case, two patterns apply: the staff-tended category tree is an example of the Web 1.0 content control pattern and as such it can effectively be ignored when selecting your reputation models. Focus instead on the options suggested by the Submit-Publish pattern formed by the users populating the tree.