Philipp Heltewig

Today Sitecore announced its newest product, the Online Marketing Suite (OMS). The OMS combines analytics, lead tracking and personalization with Sitecore’s award winning CMS and puts the marketers in the drivers seat.

We’ve been using OMS on sitecore.net for quite a while now and it has become an integral part of our marketing and sales efforts. Every day our Australian sales team receives detailed reports on who from Australia and NZ visited our website (geolocation and IP lookup), what they did (e.g. downloaded a brochure, registered for a demo, answered a poll + their answer) and the system even identifies what kind of job the person is most likely working in (IT, Marketing, …). This gives our sales guys exactly the information they need when making contact with a prospect.

Our marketers in turn now have a tool to track their campaigns’ success. Which marketer wouldn’t like the answer to questions like “how many leads from Australia did our Google Adwords campaign bring us in the last week” or even better “how many visitors that came via banner X were identified as marketers and have downloaded at least one brochure and in the end signed up for a demo”? All this is now available via the OMS.

The real power lies in the personalization engine though. The collected information can not only be used for reports, but actually to present relevant content to every site visitors. Take a developer from an Australian government department as an example. The moment he enters our website we know that he is from a government entity (automatic IP lookup) and we can modify our homepage’s teasers to display information about our solutions for government. He then moves on to some technical pages, we’ve we tagged to identify the visitor as working in IT. So by now the system knows that the visitor is working in IT and for a government agency. The website content for this can now be automatically changed to show technical government case studies and guide the visitor to signing up for a technical demo. And guess what – there’s no need to write a single line of code – it’s all part of the OMS!

Head over to our website to read more about the OMS or contact us today for a demo.

Background

Accessibility is a hot topic for governments all around the world. As eGovernment initiatives become more sophisticated, it is now common to access government related information and services on the web. Governments in turn must make sure that the information and services are available to citizens of all abilities and disabilities. In many countries this has been codified in one way or another, making it mandatory for government departments to adhere to accessibility guidelines when developing new websites.

This article will explain how accessibility on the web is defined, what guidelines exist and how governments can achieve fully accessible websites through the application of the right processes and tools.

Web Accessibility

Just like government buildings offer ramps to be accessible by people in wheelchairs, government websites should be implemented in a way so that they are accessible by people who are for example vision impaired or have other kinds of limiting disabilities. This is what we call web accessibility. There are a number of measures a website operator can take to make information universally accessible, e.g. providing alternate texts for non-textual elements such as images or videos, making links not only accessible by a mouse click but also by providing access keys (shortcuts) or adhering to a colour contrast minimum. These measures are parts of accessibility guidelines like the Web Content Accessibility Guidelines (WCAG) or Section 508.

According to Wikipedia, “Web accessibility refers to the practice of making websites usable by people of all abilities and disabilities. When sites are correctly designed, developed and edited, all users can have equal access to information and functionality”.

This definition basically encapsulates what has been described before and outlines a 3-step model for website creation:

1. Design
2. Development
3. Content Editing

While these three steps can all be executed by the same entity (e.g. department), in most cases they are spread across at least two separate entities. One entity is designing and developing the website framework, which is like an empty shell of the website, containing the logo, header, footer, navigation and other functional elements like forms, but doesn’t contain any content. The second entity (the website owner) is in charge of adding and editing the actual content.

Most government departments work with an IT solution provider of some sorts, may it be another government department or an external implementation partner. This solution provider is usually in charge of designing and developing the initial website, called the framework.  Solution providers are usually experts in accessibility and have the knowledge on how to create fully accessible website frameworks. Most of the time the finished framework is then integrated with a web content management system (WCMS) to allow the government department to update the website content themselves.

Once the empty website has been finished, it is up to the content provider (e.g. the government department) to fill the website with content. If a WCMS is used, the content editors log into the backend and start adding content to the website. This is the point at which most previously accessible websites become non-accessible. If the WCMS doesn’t force the content author to adhere to certain accessibility guidelines (e.g. enter alternate texts for images), the authors will most likely not spend the extra effort to make the content accessible. Thus the WCMS must have inbuilt facilities to make the creation of accessible content effortless and seamlessly integrate it into the organisations workflows.

Sitecore and Accessibility

Modern WCMS like Sitecore offer features to support the creation of accessible content. Whilst Sitecore is not the only WCMS to offer content validation features, the unique integration into the content editing process stands out.

Let’s take the creation of a new page with a title, abstract and an image as an example. Using the Sitecore Content Editor, the content author adds the page and starts editing it. The system has been set up to make the title field mandatory and validate the image and abstract texts against accessibility guidelines.

 

The content author will immediately see that his content item has validation errors. The invalid fields are marked with a red bar to the left of them and an overview of validation errors can be found on the right side of the editor. Once a field’s content is fixed, it is automatically revalidated and the error will disappear. In certain cases (e.g. the abstract field in our example), Sitecore offers the option to automatically fix the content. This is especially useful it the content author is not an expert in web accessibility.

If the content author decides to not fix the content, but approve the page anyways, the system will throw a validation warning and tell the content author that items with validation errors cannot be approved.

By using tools like Sitecore, government departments can make sure that their websites stay accessible, even if edited by content authors with little knowledge of web content accessibility guidelines.

Sitecore comes with a set of standard validation rules, including accessibility validation. Should website owners need more customised validation, they can of course create their own validators, as explained in Alexey Rusakov's article series "Sitecore 6 Validation".

Video Demonstration

I have prepared a video of the content editing process above which can be viewed here:

Introduction

In my opinion the WebForms for Marketers module is one of the nicest Sitecore modules out there. It's beautifully designed and serves its purpose well. It comes bundled with a number of actions (which are executed after you submit), but one action is missing - an action which redirects the user to another page after the form has been submitted.

I was interested in how it works to set up a new action and thus I set out to create this action myself. Apart from just letting you download the package (here) I will explain what I did, step by step, because over and over again I find that certain XAML features are not documented and maybe this post will help some of you.

Let's have a look at what we need to create this action:

1. An item for the action itself and a corresponding class
2. An editor window that allows the user where to redirect to

Obviously we also need to have the Web Forms for Marketers module installed and we need a valid license for it.

Creating the action and class

To create a new action, we need to create a .NET class in our solution, plus an item in the content tree under /sitecore/system/Modules/Web Forms for Marketers/Settings/Actions. The item is easily created and doesn't need a lot of configuration for now, apart from the class and assembly names (these depend on your solutions setup).

Our class could look like this:

public

class RedirectAction : ISubmit
{
  public void Submit(ID formid, Sitecore.Form.Core.Client.Data.Submit.AdaptedResultList fields)
  {
    Sitecore.Data.Database curDB = Sitecore.Context.Database;
    Sitecore.Data.Items.Item redItem = curDB.GetItem("sitecore/content/home");
    Sitecore.Context.Item = redItem;
  }
}

The class is implementing the ISubmit interface and overrides the Submit method. All this class does at the moment is redirect the user to /sitecore/content/home. Simple, but for now this is exactly what we want.

That's it. Once the solution is compiled, the action can now be added to any form and after the form has been filled out, the user will be redirected to /sitecore/content/home.

Extending the solution with parameters

Currently the redirection path is hardcoded and we want to give our users the ability to choose a path for themselves (and a different one for each form).

To do this we need to implement an XML control which serves as the property window for our action. The property window is called when the user presses "Edit" in the action editor.

To enable the "Edit" button, we first need to tell Sitecore what to do when the button is pressed. We do this by filling out the "Editor" field on the redirect action item itself, pointing the editor to control:pickItem (see below). This will automatically call and display the Sitecore XML Control pickItem (it is important that the XML node of the control is called pickItem, e.g. <control ...><pickItem>...</pickItem></control>, but more about this in a second).

Now we have to create the pickItem control itself. I placed the pickItem.xml file into C:\inetpub\wwwroot\<yoursite>\WebSite\sitecore\shell\Applications\Modules\Web Forms for Marketers\Dialogs\Action Editor and the codebeside class myItemPickDialog.cs into C:\inetpub\wwwroot\<yoursite>\WebSite\starterkit. The locations don't really matter though.

pickItem.xml:

<?

xml version="1.0" encoding="utf-8" ?>
<control xmlns:def="Definition" xmlns="http://schemas.sitecore.net/Visual-Studio-Intellisense">
  <pickItem>
    <Stylesheet runat="server" Src="Content Manager.css" DeviceDependant="true"/>
      <FormDialog Icon="Applications/32x32/exchange.png" Header="Pick Item" Text="Select the item that you want to redirect to." OKButton="OK">
      <DataContext ID="TreePickerDataContext" />
      <CodeBeside Type="Sitecore.Starterkit.starterkit.MyItemPickDialog, Sitecore.Starterkit"/>
      <TreePicker ID="treepicker1" />
    </FormDialog>
  </pickItem>
</control>

This is our pickItem control. As we can see, it's a standard XML Control Form Dialog with just one extra control - TreePicker. A TreePicker control is a dropdown which displays a tree once the arrow in the right is clicked. In addition we need to add a DataContext control and a reference to our codebeside file (full class name, assembly).

myItemPickDialog.cs:

public

class MyItemPickDialog : DialogForm
{
  protected TreePicker treepicker1;
  protected DataContext TreePickerDataContext;
  protected override void OnLoad(EventArgs args)
  {
    // If this is not a postback...
    if (!Context.ClientPage.IsEvent)
    {
      // initialise DataContext
      TreePickerDataContext.DataViewName = "Master";
      // set root node for DataContext - only content items in this case
      Database mdb = Sitecore.Context.ContentDatabase;
      TreePickerDataContext.Root = mdb.GetItem("/sitecore/content").ID.ToString();
      treepicker1.DataContext = TreePickerDataContext.ID;
    }
    // without calling this, the OK and Cancel buttons will NOT work
    base.OnLoad(args);
  }

  protected override void OnOK(object sender, EventArgs args)
  {
    // add the current value of the treepicker to the parameters collection and close dialog
    NameValueCollection nvParams = new NameValueCollection();
    nvParams.Add("redirectItem", treepicker1.Value);
    string result = ParametersUtil.NameValueCollectionToXml(nvParams);
    SheerResponse.SetDialogValue(result);
    base.OnOK(sender, args);
  }

  protected override void OnCancel(object sender, EventArgs args)
  {
    base.OnCancel(sender, args);
  }
}

This class initialises the FormDialog by first registering all the controls and then (in the OnLoad method) sets the DataContext for the TreePicker control. At the end it calls the OnLoad method of its parent class, initialising the whole form. This is necessary, otherwise the Ok and Cancel buttons will not work (yes, I found out the hard way :) ).

The only really interesting method here is OnOk. This method is called, when the OK button on the form is clicked and stores the TreePicker selection (the item to which we want to redirect) into a NameValueCollection with they name "redirectItem", which is later accessible by the form action itself.

The result is the beautiful form shown above, all rendered using Sitecore's Sheer UI.

Now that we have the information on where to redirect to, we need to rewrite our RedirectAction class to actually not redirect to /sitecore/content/home anymore, but to whatever item the user has picked.

public class RedirectAction : ISubmit
{

  // Sitecore will automatically initialise this string for us
  public string redirectItem { get; set; }

  public void Submit(ID formid, Sitecore.Form.Core.Client.Data.Submit.AdaptedResultList fields)
  {
    Sitecore.Data.Database curDB = Sitecore.Context.Database;
    Sitecore.Data.ID redirectItemID = Sitecore.Data.ID.Parse(redirectItem);
    Sitecore.Data.Items.Item redItem = curDB.GetItem(redirectItemID);
    Sitecore.Context.Item = redItem;
  }
}

This is very basic - if you know that Sitecore automatically initialises the redirectItem string. We specified the name earlier in the myItemPickDialog's OnOK method, remember? So once you know this, it's a piece of cake.

Conclusion

The conclusion is, as always with Sitecore - everything is possible. You can obviously write any kind of form action you like, from a redirect action over an SMS action to a workflow trigger action. As long as you can do it in .NET, you can do it in Sitecore.

I want to thank Igor Zhukovsky, who initially developed the Web Forms module and was very helpful during my little coding exercise. I also want to thank Yan Sklyarenko for facilitating the contact with Igor.

Links of Interest

Sitecore Developer Network - My First Sheer/UI App

Sitecore Developer Network - Publishing Queue Viewer (great advanced Sheer UI/XAML tutorial)

It's always good to hear what customers have to say about Sitecore, especially, when it's something like this...

The speaker highlights a very important fact about how Sitecore's CMS solution is developed: We use customer and partner input to create what the market needs. So if you are a Sitecore customer or partner and you'd like to see certain features included in upcoming versions, contact your local Sitecore office and they will forward all your thoughts to the product management team.

Yesterday Sitecore Australia announced the opening of the Sitecore Australia and NZ User Group (SCAUG). The user group will be the central meeting place for Sitecore developers in the region and contains lots of valuable information and a mailing list for developers to communicate with each other.

The user group was rolled out by Sitecore Australia, but is from now on led by Alistair Deneys, Sitecore MVP.

You can join at http://scaug.sitecoreaustralia.com.au.