" ... practice makes perfect "      - stellentpmp aka Andrew
stellentpmp.blogspot.comContent Server

Tuesday, April 19, 2011

Consider workflow to release site studio content

With Site Studio contributor, every Save/Update is checked in as a new revision that is then immediately released by the content server.  While I think this is status quo for many instances, I urge you to reconsider this out-of-the-box functionality on a case-by-case basis.

Why?  One word:  drafting

When users edit content, they usually make countless changes before it's actually ready to be released [to the public].  Whether they're taking a break, thinking about what to write next, or just getting a head start, users want to be able to save a draft before it's published.  I wouldn't blog if I couldn't draft a posting.

If you're asking how this is any different from the default functionality, consider the following drawbacks:
  1. Multiple revisions are unnecessarily created
    As stated earlier, every save you make is checked in as a new revision.  Let's assume you took a week to add a new section to a document and saved it 25 times.  That would create 25 separate revisions; 24 more than you would probably ever need.  Seriously, would you ever need a copy of those 24 changes?

  2. The last published version is not easily identified for rollback
    Since all revisions are released by default, there is no unique identifier that lets you know which of those revisions is the last published version vs a draft. In the previous example, you would have to go through 25 revisions before finding it.  Who wants to do that?

  3. You are artificially creating a new "revision status"
    Since there is no distinction between drafted and published content, you are creating an 
    "in draft" revision status.  As far as the content server is concerned, however, all 25 revisions in the example are released; even though they shouldn't be.

  4. Disk space is wasted
    As the number of stored revisions goes up, disk space loss goes up.

  5. Drafted content could wind up being published
    Content is considered publishable when its revision status is "Released".  In the example, any of the 24 previous draft revisions could be published.

I've seen issue #5 usually [improperly] handled with a custom "xPublish" metadata field, but it still doesn't fully address items #1 thru #4.  Wouldn't it be great if there was a solution that not only eliminates the need for another metadata field, but encapsulates "draft mode" within a single revision; thereby resolving all the issues above?  No, keeping the contributor window open is not a viable option :)

Enter: workflow

The strategy is simple:  if you give contributors the ability to edit and approve their own content, drafting becomes compartmentalized within workflow and publishing becomes more controlled.  Here's how:

1. Open Workflow Admin and create a token named Current_Author with the following user:
<$wfAddUser(#active.dDocAuthor, "user")$>
2. Create a Criteria workflow that matches the content you want to allow drafting

3. Add a step named DraftAndEdit, select the "Users can review and edit (replace) the current revision" radio button

4. Add the token from #1 to the users assigned to this step.

5. Optional: add the following idoc to the Entry step: 
<$wfSet("wfJumpEntryNotifyOff", "1")$>
6. Enable the workflow


The key is step #3, where it gives the author the ability to make an infinite number of edits while the content is in "review".  It isn't until the author approves the piece of content that the workflow exits, releasing the content and making it available for consumption.

How this solves the issues above:
  1. Multiple revisions are unnecessarily created
    When a document is in workflow, all edits and changes are encapsulated within a single revision.

  2. The last published version is not easily identified for rollback
    With workflow, every content revision is in a published state. Therefore, the last published version is simply the previous revision.

  3. You are artificially creating a new "revision status"
    The "in draft" state has been replaced with workflow (revision status of "Review"). The "Released" revision status is now used as it was intended.

  4. Disk space is wasted
    Every save/update is temporarily stored, instead of checked in as a new revision. As the number of revisions goes down, disk space loss goes down.

  5. Drafted content could wind up being published
    Workflow content is never published because its revision status is not "Released".  Therefore, every revision is considered "publishable"; you will never have to worry about drafted (un-publishable) content being released.
Welcome to a cleaner, more efficient content server.

Good luck.


PS. One downside to this is that it may seem a little counter-intuitive to approve your own content.  It must always be kept in mind, however, that you are merely finalizing your draft edits.  Alternatively, you can create a "Finalize Edits" or "Publish" menu choice as described in Kyle's post to make it more logical.

No comments:

Post a Comment