Sitecore engagements done really well take 2 primary personas into account. The first is the most obvious, since all of us tend to devote almost our entire focus on them: they are the consumers of the site. After countless usability studies, customer experience design sessions, and other efforts, we arrive at an ideal combination of IA and UI design to help our consumers quickly and easily solve their problems on the site. Quite often, we tend to forget about our content authors.
Workflow "Best Practices"
Sitecore recommends keeping workflow design simple. This translates best to minimizing number of workflow states and keeping the number of commands that can occur at each state to a minimum. I dimly recall from my earlier SharePoint days designing workflows that resembled spider webs, often requiring multiple levels of approval from various job roles. With Sitecore, we want a workflow that is close to Draft -> Approved as possible. Sitecore provides a great example of what they recommend out of the box. The "Simple Workflow" provides a very simple set of workflow states with Approve and Reject actions. Final approval publishes the content revision out to the Content Delivery databases. Unfortunately, simple workflow isn't as simple as it is made out to be.
Sitecore Page Design
A page in Sitecore is best described as a composition of layers. The first layer or the "Layout" defines the skeletal structure of every page. As we layer renderings on top of the Layout we start to see the page take shape.
When pages are composed in Sitecore, we create a content item in the tree that represents the page as well as several content items that serve purely as content on the page. For example, this blog post consists of meta data, the rich text body and thus far, an image. When pages are composed we also create relationships between content items. These relationships are expressed in two ways. First, we have indirect relationships between a page content item and its child items (any items that are children in the content tree). Second, we have direct relationships either through referencing an item in the media library or through establishing a relationship to content item from a rendering to its data source. Last, we have other indirect relationships that occur as a result of content authors organizing their content in folders. While a page may directly reference a content item there is an indirect dependency on the folder in which the item exists. When a content item is published to a delivery database, it isn't accessible if its parent folder isn't also published.
The Links Database
The Links database is used behind the scenes in Sitecore whenever an author attempts to delete a content item. Sitecore will check first to see if there are any references and if there will prompt the Author to take an action. They can either continue to delete creating a broken link, they can point the relationship to another item or they can cancel. This leads us to the second use of the Links database. If you've ever executed the broken links report, Sitecore essentially returns all references to content that doesn't exist in the content tree. Broken links are bad. Period. While historically they represent 404s on a web site, most often in Sitecore they will yield an error page to our consumers.
Composite Workflow extends the concept of Page Composition in Sitecore. Essentially, it conveys the idea that a Page in Sitecore consisting of multiple renderings and their relationships to content, should be treated as a single "Item" that transitions workflow states. In the example image above, a newly created page with all new datasources represents 4 content items in the Workbox. In a world where there is only one content author, and they only work on one thing at a time, things remain simple. The workbox would only have 4 content items all in draft. We could train our content authors to approve datasource content first and follow that with approval of the page content. Unfortunately, there are few, if any, shops that work this way. On my current engagement, there are typically no fewer than a dozen "Pages" flowing through workflow along with a number of smaller changes happening to content. There are most likely many shops who have abandoned the use of Workbox for just this reason. In the real world, a vertical list of content in a Draft state simply isn't manageable.
Composite Workflow partially, if not fully, solves this dilemma. Using Composite Workflow, the page item is the only item submitted; however, all of its references and structural content items are pulled in and sent first. The page quickly follows resulting in no broken links for end users and no hunting and pecking through Workbox for the content author.
Composite Workflow in Action!
In the following image, a content author has created a page containing a hero rendering. The hero rendering requires a "Hero" data source which in turn points to an image in the media library. Since our content author likes to keep the content highly organized, the author has also created an organizational folder in the media library where they will store the hero images for the page. The author then personalizes the hero to handle 4 scenarios. Scenario 1 occurs when the consumer can't be geolocated. In this case, we show an alternate rendering that allows the consumer to tell us where they are. The other 3 scenarios are for when a consumer has been geolocated in New York, North Carolina, or Virginia. Each scenario represents a separate hero image. There are also some text items referenced for another rendering and these are also organized into "folders". Finally, there are some call to action links added to the page. The resulting change emits the page, 4 images, 4 hero content items, and a collection of text items, call to action items and folders into workflow (this is assuming you have your "folder" content items running through workflow and are not depending on background publishing to send them to delivery). A single change to this page results in 15 items in Workbox. Given Workbox's nature of listing items, all of these items are co-mingled with other items also in Draft state. With WorxBox, the author is instead presented with this view.
WorxBox Item Filtering
One additional feature that snuck its way into the initial release of WorxBox is filtering. We want to provide a solution that is both intuitive and extensible. Ultimately we arrived at using Sitecore's Rules Engine. Each author can create their own set of conditions to apply to the Workbox and once the filter is set, items are automatically filtered when the workbox is opened. For authors who have performed personalization on renderings, no training is required. Additionally, the two most commonly requested conditions are available for use. Items Changed and Items Modified by me give authors a quick way to see only their content. Extending filtering is as simple as adding new conditions; a minimal development effort.
Sneak Preview of WorxBox 8.1
If you want to try out WorxBox early, you can get your hands on it here. Please see the Wiki for detailed post-install setup instructions. I will be adding additional features to WorxBox to make work in Workbox more enjoyable. Please note that WorxBox hasn't been thoroughly tested; however, light testing on Sitecore 8.1 and 8.2 show promise. As with any soft release of a beta product, you will find scenarios that I haven't thought about. I'd love to hear about them, and you can record them in the Issues list on Github. This is an open source project so if you want to change it to suit your own needs, feel free to fork it.