Outlined below are steps to reproduce NLC’s typical workflow security implementation. It focuses on flexibility, ensuring content authors can access multiple workflows [...]]]> Workflows are essential to the content author experience in Sitecore. Along with security, they determine when (and by whom) content can be edited as well as identify when it is ready to be published.

Outlined below are steps to reproduce NLC’s typical workflow security implementation. It focuses on flexibility, ensuring content authors can access multiple workflows and workflow states through the addition of roles to their profile. This implementation may not meet your exact needs, but it is a good starting point to consider.

For the purpose of this post, I will not be focusing a content author’s security access on the underlying item going through workflow, but instead I will focus on the security implementation on the workflows and workflow states themselves. It is important to note however, that a content author must have both write access to the content item in workflow as well as the workflow state the item is currently in before they can edit an item.

My Goal:

As a content author who is a member of the WFEditor role (created for this walkthrough):

1. Secure the workflows in the build so members of the WFEditor role can see the Sample Workflow only.
2. Secure the Draft state in the Sample Workflow to allow members of the WFEditor role to see items in that state.

Setup:

In addition to creating the WFEditor role, I’ve created a new workflow named Test Workflow which I will use with the out-of-the-box Sitecore Sample Workflow to illustrate the changes to the content author experience as the security changes.

Security Implementation:

1. As a member of the WFEditor role and without changing any Sitecore security, you can see all workflow states and both workflows in the Workbox.

2. The first step is to secure each workflow so that the workflows do not appear in the in the Workbox by default. You do that by securing each workflow via the sitecore\Everyone role.

3. The result of this security change is that a WFEditor role is no longer able to see anything in the Workbox.

4. Now that the role can’t see any workflows in the Workbox, go ahead and apply read permissions on the Sample Workflow itself so that the WFEditor role can see the workflow in the Workbox. There is no need to further change the Test Workflow security settings since the main goal of removing the content author’s ability to see it listed in the Workbox has been accomplished.

5. You may have noticed in the screenshot above that the Descendants have been denied read permissions. The reason for this is simple. Our scenario requires that the WFEditor role must have read access to only the Draft state, and not the other states. Granting read access to the Descendants would mean members of the WFEditor role would have read access to all workflow states.

6. The WFEditor can now see the following in their Workbox.

7. The next step is to grant the appropriate security access on the Draft state.

8. As a result, the WFEditor role is able to see and use the Sample Workflow Draft state.

Conclusion:

With the above scenario, we’ve secured a single role to a single workflow state without using security settings to explicitly deny the role access to any of the other workflow states. This is important. It means that this process can be repeated for additional roles across multiple workflows and workflow states. In the end, adding any of these roles to a content author’s profile will grant them access to those workflow states, ensuring that there is never a situation where deny permissions in one role overrides the grant permissions of another.

For this purpose, Sitecore enables the concept of Predictive Personalization. A visitor’s behavior in the website is analyzed and mapped to predefined patterns.  Following this mapping, personalization rules can be [...]]]>
As part of the Customer Engagement Platform, Sitecore’s Digital Marketing System (DMS) presents various tools to enhance content personalization within a website.

For this purpose, Sitecore enables the concept of Predictive Personalization. A visitor’s behavior in the website is analyzed and mapped to predefined patterns.  Following this mapping, personalization rules can be applied such that targeted content is displayed.

This blog post assumes a basic knowledge of Sitecore and gives a brief guide of how to configure profile and pattern cards in Sitecore using a very simple case study (a complete investigation on Profiling and Predictive Personalization can be found here). However, we recommend clients undertake a thorough planning exercise before they begin experimenting with personalization. This post talks about the how but a future post will tackle the bigger questions of the why and when.

Pre-requisites

Prior to configuring the profile and pattern cards, an in-depth study of the targeted customers and their relevant content should be completed to ensure accurate results. We can’t underscore this point enough; when you’re looking to introduce personalization to your site there is a temptation to dive in and start experimenting right away. However, as discussed in a previous post on this blog, getting personalization wrong can have dire consequences for your site and your company’s reputation. Hence, among others, the following pieces of information should be available for content authors:

• What are your organizational goals for your site? All personalization activities should always lead back to your site’s ultimate goals.
• Who is your target audience? Does your site cater to groups with different needs? (e.g. new vs. returning visitors, amateur vs. professional, consumer vs. business, etc.) What are the characteristics and needs of each group? What does each group hope to achieve on your site?
• What are the stages in your sales/engagement/donation cycle? What stages do users go through before purchasing/signing up/donating?
• Which content is most relevant to each group and/or each stage in the cycle? One of personalization’s greatest benefits is the ability to show each user content that is relevant to them. So it is essential to identify which pieces of content are most useful for each group at each stage.
• Which areas of the site do you plan to personalize? Keeping personalization focused in one or two key areas of the site simplifies the process of planning and maintenance and prevents the user from getting trapped in a filter bubble.

Definitions

Below is a definition of the key terms used in this blog post.

• Profile: is a category used to define the criteria by which you want to track visitors’ behavior.
• Profile Key: an attribute related to a specific profile.
• Profile Cards: a preset collection of profile key values gathered in one card that can be applied to content.
• Profile Cards – Persona:  a profile card associated with a persona with specific aspects of a potential website visitor.
• Pattern Cards: cards with pattern values that are used to match a visitor profile in real time with its closest pattern.

Personalization using Profile and Pattern Cards

For this example, let’s consider a website that sells bikes.  Different categories of bikes will suit different personas. Ideally, when visitors browse our site, we would like to show them the bikes that match best their profile/needs. To achieve this we are going to follow these steps:

• Configure Profile & Pattern Cards
• Profile Content
• Configure Pattern Personalization Rules

Configure Profile & Pattern Cards

First, we would like to have our potential customer cyclists categorized according to reasons for bicycle use. We are considering this list of reasons:

• Fitness
• Leisure
• Off-Road Cycling
• Travel to school
• Travel to work

In Sitecore Marketing Center, we create Cyclists Categories profile under Profiles. Then create the Profile Keys following the list above.

Next, we create profile cards based on persona that combine a preset collection of profile key values related to a specific persona, with information about the latter, e.g. age, education, interests, psychographics, etc. For example, a middle-aged commuter cyclist who uses the bike to travel to work has the following combination of profile keys: Fitness 2, Leisure 1, Off-road cycling 0, Travel to school 0, and Travel to work 5. A young mountain cyclist will have a different combination of profile keys: Fitness 2, Leisure 2, Off-road cycling 5, Travel to school 1, and Travel to work 0 (see figure below).   This is a good opportunity to validate the legwork you did prior to starting down the path to personalization. If you can’t prepare a good persona for your key audiences, odds are you haven’t done the requisite amount of strategic thinking.

We then create the pattern cards for the Cyclists Categories profile against which the visitor profile will be matched in real time to decide in what cyclist category the visitor fits in.

Profile Cards and Pattern Cards might look similar, as they both have a radar diagram. However, they are different in terms of usage. Profile cards are used to assign attribute values to content items.  Pattern cards allow personalization rules engine to assess how closely a visitor matches a predefined mix of attribute values.  In the following two sections we demonstrate the usage of these two cards.

Profile Content

Profiling content refers to assigning one or more profile cards to a content item. In the following screenshot, we assign George, as a commuter cyclist, to a content item representing a commuter bike by clicking on the right side profile icon .   It is possible to create a customized profile during this step, but it is always a good practice to use the preset profile cards for consistency reasons, especially in case multiple content authors from different backgrounds are controlling the content.

Configure Pattern Personalization Rules

The last step in configuring profiles and patterns is setting rules to personalize the component. In Page Editor, we select the component we would like to personalize, and click on the personalize icon .  We then choose to add a new condition and select rule from Profiles and Patterns list. Finally, we specify the content we would like to show if the condition is verified.

You can see why you want to make sure you get the content profiling and persona development right from the start. When it comes to real-time content personalization, the opportunities are endless – for good and for bad. A good strategic foundation is key to ensuring the tactics outlined in this post are deployed effectively.

The PageEvents table holds a record of all page [...]]]> In the opening post of this series I shared basic sizing guidelines for Sitecore CEP, but if your organization intends to fully leverage the capabilities of CEP you will also need to consider the impacts of goals, conversions and events.

Goals, Campaigns and Page Events

The PageEvents table holds a record of all page events that occur on the published site.  This covers goals, campaigns and other events.  Our analysis of the data in this table indicates that a single event consumes approximately 0.635 KB of space for data and indexes.  While this number is not significant, it is comparable to the data required for a page hit (0.5905 KB).    While nowhere as substantial as the visitors and page views it can easily add 3% – 6% to the database and can have additional impacts when you consider backup, disaster recovery and other elements.

Being able to model the page event data requirement will be largely based on supposition in the early days.  If you have previous analytics, that should give you some indication of traffic that would follow a conversion funnel and trigger events.  Start there.  By way of anecdotal evidence, on NLC’s website there is approximately 1 page event for every 2 pages viewed.

Going back to our fictional example of a moderately busy site with 100,000 visitors / month and an average of 10 page views / session the data required for a single month was 727 MB.  If we now add on 50,000 page events this will increase the monthly size by:

(50,000 x 0.635) =  31,750 KB or 31 MB

This now brings our monthly data requirement to 758MB.

Engagement plans and testing

There are many other features of CEP that can generate significant data footprint; however at this time we do not feel that we have enough information to properly model their impact.  A/B testing and the engagement plans in particular are so dependent on your implementation that any guidance we can provide would potentially be misleading.  Our suggestion is that you setup your plans as early as possible and then use load generation software to mimic traffic to collect actual statistics.  These capabilities can generate several GB’s of data in a month.

Dedicated Reporting

Many of our clients duplicate the analytics data captured on the website to a second database.  That second database is used entirely for reporting in order to isolate the performance load of heavy reporting from the website.    If you choose to do this it will effectively double your data needs.  In our fictional example our need to capture and store data has moved from 758MB to 1.48GB monthly and our total data footprint at 6 months to 8.88GB.  You can see the projected growth depicted in the following chart.

For more on the topics of DMS database performance and dedicated reporting databases, please see Sitecore’s DMS tuning guide at http://sdn.sitecore.net/SDN5/Reference/Sitecore%206/DMS%20Performance%20Tuning%20Guide.aspx.

Conclusion

Understanding your traffic patterns, usage of events and reporting requirements will provide a reasonable estimation of your DMS data requirements.  The remaining factors are projected site growth, high availability, disaster recovery and backup.  These topics will be covered in my third and final post of the series.

At first glance [...]]]> The Sitecore Customer Engagement Platform (CEP) provides rich capabilities that can transform the way you engage with your customers online. The technical foundation to that capability is Sitecore’s ability to capture and store visitor behavior. Planning for the storage of this invaluable data should be top of mind for any Sitecore architect.

At first glance the Analytics database of the Digital Marketing Suite (DMS) is a very simple data-model. While the data-model is simple, the sizing characteristics of the database are not as clear cut. Driven primarily by the features you have deployed on your site and your visitor’s behavior, some level of modeling is required to estimate capacity needs.

In order to tackle the sizing of the database, I have segmented this post into a series. The first post will focus on some basic lookup tables and the data required to track visits, visitors and page views.

Technical note: the information in this post is based on Sitecore 6.5 revision 111230.

Lookup Data

The following DMS database tables track data sets that – in most instances – will have little influence on the size of the database.  The level of effort to model these tables is likely not worth the return, but have been included to let you judge for yourself.

Visits, Visitors and Page Views

In the simplest deployment, the DMS capabilities will track sessions (visits), visitors and the pages viewed.  For high volume sites the amount of data stored can be quite substantial.  Our testing indicates that the following data footprint is required:

• 0.0888 KB / visitor
• 1.45 KB / visit
• 0.5909 KB / page view

Sitecore recommends the Analytics database be provisioned with 3-6 months of space pre-allocated to ensure the fragmentation of the database is kept to a minimum.   For a moderately busy site with 100,000 visitors / month and an average of 10 page views / session the data required for a single month would be:

(100,000 x 0.0888) + (100,000 x 1.45) + (100,000 x 0.5909) = 744,780 KB or 727 MB.

Giving room for growth over 3-6 months you would provision the initial database with 2.2 GB – 4.3 GB.

Conclusion

For the initial launch of the CEP capabilities, modeling Visits, Visitors and Page Views should provide enough information to ensure a successful launch.  For high volume sites , deployment of the more robust capabilities of CEP and for long term planning you will also need to consider:

1. How other features of CEP such as goals, and page events impact size
2. Additional considerations for dedicated reporting, availability, backup and disaster recovery
3. Growth over time and archival

These topics will be covered in subsequent posts.

We might just be able to help.

NLC’s own Amanda Holtstrom is hosting a two-hour workshop for Girl Develop It called “A Developer’s Guide [...]]]> Are you a developer who’s sick of complaints about the usability of your interfaces? Looking for some simple rules to follow to make nice looking, usable solutions?

NLC’s own Amanda Holtstrom is hosting a two-hour workshop for Girl Develop It called “A Developer’s Guide to Interaction and Interface Design” at the Code Factory in Ottawa on March 27 (don’t worry, boys are welcome too).

During this two-hour session, Amanda will review some common interface design patterns and test drive some pragmatic approaches you can use to create and validate simple, intuitive interactions.

The course will be packed with examples with plenty of time for hands-on exercises so sign up today!

You know the one: the stranger on [...]]]> Marketing automation tools and website personalization can transform your site from a source of static information into a two-way conversation with your users. But as in any real-world conversation you need to follow the social ground rules or risk alienating your users.

Don’t be “that guy” (or gal)

You know the one: the stranger on the bus who asks you overly personal questions; the nosy neighbor who eavesdrops on your phone calls; the kid in school who just wouldn’t leave you alone no matter how many times you told them to go away. Creepy people don’t respect the unspoken rules of social interaction. Websites need to respect the same social rules or risk leaving their users with an icky feeling.

5 ways to prevent your site from being creepy

1. Don’t ask for too much information up front

Just like the stranger who asks you overly-intimate questions, websites shouldn’t ask users for detailed personal information too soon. Users want to get to know you before they tell you too much. The question in their mind is always “why do you want to know?” If they don’t feel comfortable, they will lie (you know it’s true, we’ve all done it). So, when requesting personal details:

• only ask for the most essential information (e.g. don’t ask for an address and phone number if users are signing up for an email newsletter)
• let users know why you want the information and what you will do with it
• let them know you won’t share their information with other organizations

2. Don’t try to move the relationship along too fast

Remember that many of your users are “just browsing”. They’re not necessarily ready to buy, sign up, or join anything on the first visit. They probably want to take a look, see what you have and get to know you a little bit. Don’t rush them. Of course, there’s nothing wrong with putting offers in front of users. Just make sure that you give them the chance to walk away if they’re not interested. And if they’ve told you “no,” don’t keep bugging them. Sites that are overly aggressive in seeking conversions feel creepy.

3. Don’t make too many assumptions

When creating personalized content for users, getting it wrong is potentially worse than not personalizing at all. Like the 6’6” accountant tired of being asked if they’re a basketball player, nobody likes to have wrong assumptions made about them. It leaves them with the feeling that they’ve been stereotyped or misunderstood. The best approach to personalization is to start small, track your success, and validate your assumptions using analytics, user surveys and real customer data.

4. Don’t be a stalker

Finding things out about someone without asking them is pretty much the creepiest thing you can do – no one wants to feel like their every move is being tracked without their permission. It is important to let users know how you gathered the information you have about them. When presenting personalized content, provide some context as well, e.g. “Based on what you downloaded/bought/viewed we recommend…”

5. Let your user get a word in edgewise

Finally, it’s important to give your user a chance to participate in the conversation. You may not know as much as you think you do: people travel, use their friends’ computers or shop for gifts for people with different tastes or interests.

How do you let them talk back? Give them a way to correct your initial assumptions. Let them change their personalization settings, correct their location, or tell you what their interests are. And ideally, give them a chance to opt out of personalization entirely if they’re not comfortable with it. It shows that you respect their wishes and aren’t going to be “that creep” stalking them.

By giving your users an opportunity to talk, you gain an opportunity to get real, accurate information about them that you might never learn otherwise, opening the door to a true two-way conversation.

What do you think? Are there other website behaviours that creep you out?

In part 2 of this series Introduction to [...]]]> In part 1 of this series Introduction to Sitecore Parameter Templates: Making Sublayout configuration more intuitive we looked at the advantages of using Parameter Templates.

In part 2 of this series Introduction to Sitecore Parameter Templates: Sitecore client configuration deep dive we took a closer look at the steps required to configure the author experience using the Sitecore client.

In this final part of the series we are going to take a developers look at how to retrieve the values of the parameters chosen by the content authors in our solution code and supply them to the Sublayout that will render the content on the page. There are 5 components in the approach taken

1. A Sublayout base class
2. A parameter template base class
3. A class to represent our promotions parameters
4. A utility class interface
5. The Sublayout to render the promotions on the page

NOTE:  For brevity the code samples provided have been simplified.

1. The Sublayout base class

Since any Sublayout (UserControl) in our solution can have a data source and parameter collection it makes sense to expose these properties in a base class that extends UserControl. The first property that we want to expose is the actual Sublayout itself, which is a container for your UserControl…

private Sublayout Sublayout
{
    get { return Parent as Sublayout; }
}

Now that we have a reference to the Sublayout we also want to access the data source…

public Item DataSourceItem
{
    get { return Sitecore.Context.Database.GetItem(Sublayout.DataSource); }
}

Finally a third property to expose the Sublayout parameters, which are supplied to us in a query string format. We can take advantage of a Sitecore utility method to obtain the parameters in a NameValueCollection object…

public NameValueCollection Parameters
{
    get { return WebUtil.ParseUrlParameters(Sublayout.Parameters); }
}

2. The parameter template base class

The parameter template base class has a single responsibility. Take a collection of Sublayout parameters, map them to properties of the parameter template class and set the mapped property values. The constructor takes a single argument, the Sublayout parameters, instantiates a utility class for setting the property values and then calls the method that will perform the mapping…

public ParameterTemplateBase(NameValueCollection parameters)
{
    _propertySetter = new PropertySetter(); // implements IPropertySetter    

    MapParameters(this, parameters);
}

private void MapParameters(object template, NameValueCollection parameters)
{
    var templateType = template.GetType();

    // the parameter keys are the parameter template fields
    foreach (var key in parameters.AllKeys)
    {
        // protect ourselves from spaces in template field names
        var property = templateType.GetProperty(key.Replace(" ", string.Empty));

        if (property != null)
        {
            _propertySetter.SetProperty(property, template, parameters[key]);
        }
    }
}

3. The promotions parameter class

The purpose of this class is to provide a strongly typed representation of the Sitecore parameter template item that can be used by the presentation layer. We need a public property with an appropriate type per field on our parameter template and the class needs to extend our parameter template base class to have it’s values set…

public class PromotionsParameters : ParameterTemplateBase
{
    public PromotionsParameters(NameValueCollection parameters) : base(parameters) { }

    public int PromotionLimit { get; set; }
    public DateTime DisplayFrom { get; set; }
    public DateTime DisplayUntil { get; set; }
}

4. The utility class interface

To carry out the property setting task we instantiate the PropertySetter utility class that implements IPropertySetter…

public interface IPropertySetter
{
    void SetDateTime(PropertyInfo propertyInfo, object obj, string value);
    void SetInt(PropertyInfo propertyInfo, object obj, string value);
    void SetString(PropertyInfo propertyInfo, object obj, string value);
    void SetProperty(PropertyInfo propertyInfo, object obj, string value);
}

The SetProperty implementation calls the appropriate utlility method depending on the property type, we can add additional methods to IPropertySetter as the need arises. Here is a sample implementation that uses a Sitecore date utility method…

public void SetDateTime(System.Reflection.PropertyInfo propertyInfo, object obj, string value)
{
    propertyInfo.SetValue(obj, DateUtil.ParseDateTime(value, DateTime.MinValue) , null);
}

5. The Sublayout (UserControl)

Now we have all of our required components we can code our presentation layer. We will bind our promotions to a simple repeater…

<asp:Repeater ID="RptPromotions" runat="server">
    <HeaderTemplate><ol></HeaderTemplate>
    <ItemTemplate>
        <li>
            <asp:HyperLink
            ID="LnkPromotion"
            runat="server"
            Text='<%# ((Item)Container.DataItem).DisplayName %>'
            NavigateUrl='<%# Sitecore.Links.LinkManager.GetItemUrl((Item)Container.DataItem) %>'/>
        </li>
    </ItemTemplate>
    <FooterTemplate></ol></FooterTemplate>
</asp:Repeater>

In our code-behind we need the Sublayout to extend SublayoutBase to gain access to the data source and parameters, we then use the parameters to instantiate the promotions parameter template class…

protected PromotionsParameters PromotionsParameters
{
    get { return _promotionsParameters ?? (_promotionsParameters = new PromotionsParameters(base.Parameters)); }
}

Finally on page load we can bind the promotions to our repeater taking the parameters into account, in a full scenario we would also check the DisplayFrom and DisplayUntil rules..

if (base.DataSourceItem != null)
{
    RptPromotions.DataSource = (from i
                                    in
                                base.DataSourceItem.Children
                                select i).Take(PromotionsParameters.PromotionLimit);
    RptPromotions.DataBind();
}

For the context of this article I will be working on a simple online department store, with multiple departments.

In part 1 of this series Introduction to Sitecore Parameter Templates: Making sublayout configuration more intuitive we looked at the advantages of using parameter templates

For the context of this article I will be working on a simple online department store, with multiple departments.

I want to create a Sublayout that can be used on a department homepage, I want the Sublayout to display the latest promotions relevant to the department, I also want to be able to configure the behavior of the Sublayout after it has been created without writing code or editing global settings fields that would affect all instances of the Sublayout, in short it needs to behave differently for each department and it needs to be easily configurable.

As previously mentioned in part 1 we could use the “Additional Parameters” field to generate a NameValueCollection but this doesn’t help future users of the Sublayout to know what options are available to them and it does not provide us with a mechanism to restrict the values entered.

So let’s be more explicit about what options we can have, what their types are and let’s provide an appropriate user interface to make those choices. Sounds like a Sitecore template doesn’t it?

Sublayout parameter templates are applied on individual Sublayouts by first selecting the Sublayout and then selecting the Content tab, these parameters will then be available wherever the Sublayout is used. By default the parameters will be configurable in the Page Editor, to disable this uncheck the Editable option.

Our Sublayout parameters template then behaves like a regular Sitecore data template but with one important difference. Your template must inherit from…

/sitecore/templates/System/Layout/Rendering Parameters/Standard Rendering Parameters

…instead of the normal Standard template, if you do not do this you will be prompted with an error message when you try to edit the Sublayout. So our finished Sublayout parameters template looks like this:

So you can see we are providing options to limit the number of promotions displayed as well as a mechanism for only showing the promotions in certain date ranges or months. So now we can modify presentation details on the individual department items and take advantage of these new options.

This can also be done by content authors using the Page Editor by selecting the Sublayout, clicking the more button and then selecting the “Edit the Component Properties” option.

So what if we edit the configuration of a Sublayout on an item and the item template’s presentation details are updated on the standard values afterwards, related links were removed for example. Won’t the item not receive the changes? Yes and no, in Sitecore 6.4.0 rev.101012 layout deltas were introduced, which allows us to partially update an item’s presentation details without breaking inheritance on the Sublayouts/Renderings that were not changed, prior to this that assertion would be correct so this is a caveat to be aware of.

In the next installment of this series, we will look at how best to retrieve the Sublayout configuration values in our  codebase.