In the last post we defined the high-level design, navigational elements, and templates for our content. Our writers now have everything set up and can begin writing with some additional style guides from our editors. We also took care, with roles and permissions, that writers do not have the right to publish the content. However, the content that they create needs to go through at least two reviews: a technical review, and an editorial review. The technical review, usually conducted by a development lead – or in case of Scrum methodology, the internal customer – checks for the technical accuracy of the content. The editorial review checks the content for language errors and consistency in style and image use among other cosmetic things. To make sure that the final content is complete and correct, we must put the content through a review workflow similar to Fig 1.

Review Workflow

Fig 1

To ensure that this workflow is implemented, we need to define rules that inform the subject matter expert after the writer completes the first draft. Similarly, WordPress should inform the editor and the writer once the technical review is complete. Apart from this, the reviewers should have the facility to comment on the writer’s draft and indicate changes in the content. We have already ensured that the subject matter expert cannot publish the topic and only edit the content using the User Role Editor plugin.

To apply our editor workflow, we will use the Edit Flow plugin. With this plugin, you can define custom status for your topics. For example, first draft, tech review, edit review, final draft and so on. Similarly, you can create User Groups for each category such as authors, editors, experts and so on as shown in Fig 2.

Fig 2

You can also define custom status for your topics. For our purpose, we will create statuses such as Draft, Pending Edit Review, and Pending Tech Review as illustrated in Fig 3.

Fig 3

Once the writer is finished with her work, she can change the status of the topic and select the users who should receive an update. The Publish widget (Fig 4) shows a list of statuses you define and are available here. The writer can also select the users she wants to notify as shown in Fig 5.

Post Status

Fig 4

Status Notification

Fig 5

Apart from notifications, each user can see topic status in their Dashboard (Fig 6). So, if I am a technical editor I know that I have one topic in my queue.

Topic Status

Fig 6

The technical editor can then add comments on the topic and change the status back to In Progress and send the author a notification. You can also create additional statuses such as ‘Tech review complete’ and ‘Editorial review complete’ to mark the topic status – you can customize it according to the process you define for your documentation projects.

With appropriate use of a plugins, we are now able to monitor the project progress and define a workflow for our team. This process definition will ensure that all your topics are checked and corrected before they are finalized and ready to publish. In our next post, we will populate the WordPress Web Help and start working on other Help features such as navigation and page-level design.

Please leave a comment on what you think about WordPress as a platform for WebHelp and the features you think it can and cannot support.