Content Workflow and the Sitecore Workbox

 Welcome to the second part of Productivity Tips for Sitecore Content Authors and Experience Marketers. In the first post, I covered content governance and listed important considerations when creating your policies and processes.

Keeping in step, the second part of productivity is the importance of having a defined content workflow. Your content workflow outlines the work processes of who will create and review new content, and who will enforce the rules outlined in the governance policy, before content is published for the world to see.

Many companies do this “instinctively” (without a clearly defined process) so it isn’t always enforced or consistently followed so shortcuts are often taken. These shortcuts can cost companies tens of thousands of dollars, if legal issues arise, or damage the company’s reputation as I described in the post on content governance.

So where do you start with Content Workflow?

Great question! In fact, the place to start is by asking yourself several questions while thinking about your current process. Consider your company's rules and regulations around each stage of your content's life-cycle such as creating, publishing, archiving, retaining and disposing of content along with it's rules around data collection and information exchange. Be sure to document the answers so you can translate them into Sitecore workflow states, commands and actions. Examples of questions you should ask:

• Who determines what content gets created?
• Who writes the content? Are there different rules and regulations for different regions and or languages?
• Who’s responsible for the styling and branding of content?
• Who ensures the content is “accessible” to those with disabilities?
• Who edits/approves what is written to ensure it falls within the style guide and governance policy?
• What happens when content is rejected by an approver?
• Who checks to ensure the content is not damaging or copyright protected?
• Who publishes the content once it’s approved?
• What is our process for archiving and removing content?
• Are there government or industry regulations we need to take into consideration?

Once you have the answers documented you can diagram it and use the diagram to construct and configure your workflow within Sitecore. Because every business is different, Sitecore allows you to custom design one or more workflows for Authoring, Publishing, Archiving, Retaining, and Disposing of content. Don't worry if it's not perfect from the start, you can always adjust and tweak the workflow as your process becomes better defined or changed.

TIP: You can also use Sitecore’s sample workflow as a starting point and modify it to meet the needs of your organization. Here is a process diagram of the default states within Sitecore’s Sample Workflow.

In the above diagram, the green arrow for Auto Publish is an automatic action that has been setup to publish content the moment it has been approved.

Here is the Sample Workflow as configured within Sitecore:

Notice in this version of Sitecore (version 8.0) there are two “Approve” actions. The “Approve with Test” is a quick way to begin an A/B Test between the new version of content and the previous version. To skip testing the content approver would choose the “Approve without Test” action.

Best Practice Notes:

1. Always launch a site with Workflow defined and implemented as it can be hard for Content Authors to unlearn bad authoring habits down the road.
2. Include a step that Approves content for publishing to the “stage” or "pre-production" for a final review – this can be done in the building phase to encourage the use of workflow before the site goes live.
3. If you are not able to define an accurate/complete workflow up-front, and implement it before you launch, use the Sample Workflow to start, and develop the habit of using it.

Dangers of Not Having a Workflow Process

Still not convinced you need a workflow? Consider the following.

1. Without a workflow in place it’s very dangerous to use the “Publish Site” option (often requested when installing Sitecore modules), because you don’t know what’s ready and not ready to be published live.
2. As mentioned earlier, it’s hard to change authoring habits and implement workflow later when there are hundreds or even thousands of items not in workflow.
3. It's harder to enforce the content guidelines and legal reviews of content if it’s not built into the solution. Anyone can publish content, whether it’s poorly written, copyrighted or otherwise.

Once you have a workflow in place, you can use the Sitecore Workbox to review all the items awaiting approval, check the differences between versions, and assign access to these items to one or more approvers.

Additional Resources

• How to use the Sitecore Workbox
• Sitecore Content Governance

5 things you should consider testing when optimizing a Sitecore form for conversion

 In previous posts, we covered the steps of how to A/B test a Sitecore form to optimize for conversion. We used a very simple scenario to illustrate the process: testing two variations of the action button copy. This was a good start to get our feet wet with testing Sitecore forms. In this post, we’ll look at what we should consider testing when optimizing Sitecore forms for conversions. We’ll go through the thinking behind testing these elements and touch on what’s involved when creating the form variations needed to test.

Let’s dive in.

1. Multi-step vs single step forms

A multi-step form is, as the name implies, a long form that is broken down into steps. A single step form, on the other hand, shows the user all the questions at once. This test is relevant with forms that have between 4-6 fields. Why? Because with fewer than 4 fields, it could be easily argued that it’s not worth breaking down into steps. With more than 6 fields, you’re probably better off breaking down the form. But you know what? You can still test that.

The thinking behind it

There’s a high probability that multi-step forms will work in your advantage. They tend to reduce psychological friction, because users are less likely to get overwhelmed when they see a few questions compared to when they see a ton of them. Additionally, multi-step forms usually have progress indicators. These tend to encourage users to complete the form (endowed progress effect). Why not test what works for you?

What’s involved in creating the form variation

• Duplicate the original form
• In Sitecore’s Forms application, drag a Page (under the Structure elements) to the form

• Drag and drop questions from the first page to the second page as needed
• Change the Navigation step of what was previously the submit button to Next
• Change the label of what was previously the submit button to something like ‘Next’

 

2. Wording of questions

The thinking behind it

Is it possible that some of the questions in your form are not worded in the simplest way possible? Could that be the reason why some users are not making it to the finish line? When in doubt, test.

What’s involved in creating the form variation

• Duplicate the original form
• Reword your question in a simpler way
• Pay attention to test one question at a time
• If you can’t decide what question you should test first, look at the performance of the form (in Forms, select the form in question and go the Performance tab), and find the question that has the highest abandonment 

3. Removing the least necessary fields/questions

The thinking behind it

It’s important that what you’re offering users who submit the form balances the amount of information you’re asking them to provide. Otherwise, conversion will suffer. But how do you make sure you’re hitting that sweet spot? Remove the least necessary questions and test.

What’s involved in creating the form variation

• Duplicate the original form
• Remove the questions that are least necessary (ones that are easy to get answers to later on as you qualify them further)

   

4. Order of fields/questions

The thinking behind it

There are some best practices around the order of questions in a form, which include but are not limited to: following how the user thinks, asking easy questions before difficult ones, and grouping related ones together. Sometimes these principles are not enough to help you decide if you should ask A before B, and you are not even sure it matters. Testing helps.

What’s involved in creating the form variation

• Duplicate the original form
• Drag and drop a question to change the order of questions in the form

5. Action button copy and style

The thinking behind it

Ultimately, the more users hit that submit button, the happier you are. But what if the button doesn’t stand out enough or doesn’t have sufficient breathing space? What if changing the copy to make it provoke emotion or enthusiasm gets you more submissions? Why not test? 

What’s involved in creating the form variation

• Duplicate the original form
• Change the label of the action button
• Depending on your Sitecore implementation, you might be able to change the style by changing the CSS class, but you might need the help of your Sitecore partner there

 

And there you have it! 5 things you should consider testing when optimizing a Sitecore form. If you have any questions, ask away in the comments below. Happy testing!

Powershell script to search a keyword in all items in Sitecore

This Powershell script is used to search for an occurrence of a string in all Sitecore items and in all the fields, including the standard fields.

The script traverse through all the items under the item path provided in the script. For each item, it gets all the fields and in each field it tries to match the input string. If the input matches then that item along with additional details is added to an ArrayList which is displayed at the end.

Note: As the script goes through each item and all its fields, this script would take time to run. It is suggested not to run on the entire site root, instead run it on the sections needed.

Powershell script

$startPath = "master:/sitecore/content/Site1"
Write-Host "Search started $(Get-Date -format 'u')"
$list = [System.Collections.ArrayList]@()
$itemsToProcess = Get-ChildItem $startPath -Language * -Recurse
if($itemsToProcess -ne $null) {
    $itemsToProcess | ForEach-Object { 
        $match = 0;
        foreach($field in $_.Fields) {
                if($field -match '.*productName.*') {
                    $info = [PSCustomObject]@{
                        "ID"=$_.Paths.FullPath
                        "Language"=$_.Language
                        "TemplateName"=$_.TemplateName
                        "FieldName"=$field.Name
                        "FieldType"=$field.Type
                        "FieldValue"=$field
                    }
                    [void]$list.Add($info)
            }
        }
    }
}
Write-Host "Search ended $(Get-Date -format 'u')"
Write-Host "Items found: $($list.Count)"
$list | Format-Table

Hope it helps. Please do share!!

Sitecore Experience editor error /ribbon.aspx siteName

 If you see this error when you open a page in experience editor, then this is the post you should look for.

Below is the screenshot of how the error looks from experience editor. The ribbon will completely error out and does not load.

If you check the network tab on the chrome browser developer tools, you would see the below request would show a 500 server error. If you preview the request response, then you would see the detailed error as below.

https://mydomain/sitecore/client/Applications/ExperienceEditor/Ribbon.aspx?sc_content=core&ribbonId=%7B570A52B6-6755-461A-8052-5B95EF766F74%7D&itemId=%7BC5296239-4409-4279-BA52-851A6CF9AF38%7D&deviceId=%7BFE5D7FDF-89C0-4D99-9AA3-B5FBD009C9F3%7D&database=master&mode=edit&url=%2F%3Fsc_mode%3Dedit%26sc_itemid%3D%257bC5296239-4409-4279-BA52-851A6CF9AF38%257d%26sc_version%3D1%26sc_lang%3Den%26sc_site%3Dmysite&lang=en&pageSite=mysite&version=1

The solution for this error would be to check the following setting.

<setting name="Preview.DefaultSite">

The setting value would be "Website" by default. If you are patching in your custom config files, make sure you are giving the name which is a valid site as per your SiteDefinition.config file.

Hope it helps. Let me know your thoughts.