Content Management, Business Champions and Developers

The Customer Engagement Series: A quick time check

2012-02-02T14:01:00.001-05:00

In the spirit of quick rules examples, I recently had a question about simply doing something on the site based on what time it is. Easy with Sitecore’s Rules Engine, but let’s mock something up to go through putting the pieces together.

First, the item to represent the Rule Condition. I created an item in this location:

/sitecore/system/Settings/Rules/Conditional Renderings/Conditions/Events/Time Is Before Condition

….where the item itself is named “Time is Before Condition”. Sitecore 6.5 has lots of categorization folders in this area (or you could create your own). I decided Events was a good enough categorization for this condition. This item is based on the data template:

/sitecore/templates/System/Rules/Condition

Here’s how the item looks:

Now someone who’s not a developer should be able to simply add a time to this condition. Using the very handy Rule Set Editor in 6.5, we could easily string together a bunch of time conditions from top to bottom (“if it’s before 12:30 PM do this, if not but it’s still before 1:30 PM do this, etc.”)

From the Rules Engine Cookbook, in describing the four parameters in the bracketed expression within the Text field above:

1. The name of the property that the parameter sets in the .NET class that implements the condition.
2. The name of an item beneath the /Sitecore/System/Settings/Rules/Common/Macros item providing predefined functionality, or an empty string. For example, to activate a user interface allowing the user to select an item from the content tree, specify the value tree.
3. URL parameters to the user interface activated by the macro specified by the previous parameter, or an empty string. For example, to specify the /Sitecore/Content/Home item as the root for a selection tree, enter root=/sitecore/content/home.
4. Text to display if the user has not specified a value for the parameter.

With that, the condition will now display in the Rule Set Editor like this:

And the simple class that is called on when this rule is evaluated:

using Sitecore.Rules;
using Sitecore.Diagnostics;
using Sitecore.Data;
using Sitecore.Data.Items;
using Sitecore.Rules.Conditions;

namespace Examples
{
    public class TimeIsBeforeCondition<T> : WhenCondition<T> where T : RuleContext
    {
        public TimeIsBeforeCondition()
        {
        }

        protected override bool Execute(T ruleContext)
        {
            Assert.ArgumentNotNull(ruleContext, "ruleContext");

            //if t1 is less than t2 then result is Less than zero
            //if t1 equals t2 then result is Zero
            //if t1 is greater than t2 then result isGreater zero 
            System.DateTime t1 = System.DateTime.Now;
            System.DateTime t2 = System.Convert.ToDateTime(this.Value);
            int i = System.DateTime.Compare(t1,t2);
            return i < 0;

        }

        public string Value { get; set; }

    }
}

Note that the Value property is set by the value entered into the textbox above. This certainly could be improved (beyond checking for errors) by enforcing a content item representing each hour to be chosen from a Tree View (though this of course doesn’t make sense when you want to provide minute by minute choices.

The Customer Engagement Series: A quick connect to Facebook

2012-02-01T15:31:00.001-05:00

I am really excited about the huge growth in socially-connected Sitecore sites we’re going to see this year. With the Sitecore Rules Engine, it just makes a lot of sense—make recommendations based on your visitor’s Likes, birthday, location…just about anything. I like demonstrating the many ways Sitecore has made the mechanics of this--grabbing some profile information from Facebook and changing the page experience because of it--natural and simple. The story gets even better when we consider how easy it is to introduce our own custom logic altogether—but for today, let’s stick to a use case and solution that doesn’t involve any coding.

First, Sitecore has introduced a free module called Sitecore Social Connected. In about 20 minutes with the documentation, you can have this module installed and working. Most of the time involves getting familiar with setting up a Facebook App if you’re not already. Nothing that requires a developer here.

The Social Connected feature contains lots of cool features—prebuilt Like and Tweet controls that you can use as is, login controls and functionality for Facebook, Twitter, LinkedIn and Google+.

What I’d like to concentrate on in this quick article is the ability to allow your visitor to login using his Facebook credentials to customize his experience. Remember that the Sitecore Rules Engine is a simple way to tie a Condition (does it exist, yes/no) to an Action (what should my control do differently as a result of the condition evaluation….show some different HTML, invoke a different control, message an external system).

In Sitecore 6.5, there’s even a prebuilt condition that can allow a content editor / marketer to look for a specific profile value. My use of the word profile here means a persistent attribute for a logged in user (the Sitecore .NET Profile table, a CRM via a connection, some external system—in this case Facebook).

Here’s my Condition that looks in the “Movies” area of the logged in Facebook user profile for the word “Drive”:

The Social Connected module comes preconfigured with mappings to lots of Facebook profile fields…through configuration you can extend these properties.

Here’s the full fb_movies profile field for someone who has included the movie Drive in his list of Movies He Likes:

fb_movies

= data => name => Drive category => Movie id => 105687816178274 created_time => 2012-02-01T13:55:03+0000 name => The Town category => Movie id => 92320479952 created_time => 2012-01-04T16:34:30+0000 paging => next => https://graph.facebook.com/me/movies?

As you can see, we could have gotten a lot more fancy with our parsing of this or any other Facebook profile field, but the simple “Contains” operator from Sitecore does the trick here.

Now, as a simple control (like the Sidebar control in the Sitecore Starter Kit site) can show a different content item / HTML block as a result of this conditional.

If Drive isn’t found in his movie Likes, use the default message and opportunity to ask him to sign up:

If he’s already logged in and Likes Drive, ask him to watch it again:

That’s all there is to it! A simple Hack to write out all Facebook profile properties is helpful as you start to investigate what’s there for you to use:

Sitecore.Security.Accounts.User user = Sitecore.Context.User; 
           Sitecore.Security.UserProfile profile = user.Profile; 
           litOutput.Text = "";

           foreach (string attributeKey in profile.GetCustomPropertyNames()) 
           { 
               string attributeValue = profile.GetCustomProperty(attributeKey); 
               litOutput.Text += "<h3>" + attributeKey + "</h3> =" + attributeValue + "<br />"; 
               
           }

The Customer Engagement Series: Investigating Engagement Plans

2012-01-31T16:08:00.001-05:00

One of the many interesting features in Sitecore’s Customer Engagement Platform is the ability to design and monitor “Engagement Plans”. These Engagement Plans allow you to envision and lay out the path you are hoping your customers take—from entry point to ultimate goal. I’ve had enough discussions about this feature in Sitecore 6.5 to know (at least) two things:

It’s really cool
It’s pretty hard to describe and absorb in the short window of time people generally have to evaluate it

It’s not that the concept is above us, it’s just that the nature of an Engagement Plan is such that by definition it describes a process over time—a set of states, triggers and decision points that can confuse our already busy minds. Sitecore 6.5 does a nice job at setting some of these up for us…one that I find particularly compelling is the Engagement Plan that is set up by default when using the Email Campaign Manager. Below is a screenshot of this plan that is put in place automatically for all my Email Campaigns. Don’t worry, we’re going to concentrate on a much simpler one today, but we can all agree that the States (the rectangles below) are all very understandable buckets we’d expect our audience to be in if they were part of your Email Campaign. I’ll let you draw arrows and match the states:

You might have learned (via the Message Transfer Agent) that the email address you had was bad.
Your recipient might have received the message but it’s sitting there in his inbox unopened.
He might have opened the message but not yet visited your site.
He might have followed the link in the email but became distracted as soon as he hit your landing page
He might have spent time on your site after hitting the landing page, done something OF VALUE on our site (your definition of value of course)

OK, what we want to do today is create one of these from scratch. A really simple one that will help us investigate the main concepts. I encourage you to take a look at the Engagement Automation Cookbook for a more thorough description of these mechanics.

For this one, here’s the scenario:

Your visitor got to your site as part of a well-placed link on your company’s Facebook page.
The link was trying to get that visitor to hit the landing page and fill out a registration form (the definition of valuable in this scenario).
If the visitor followed the link and got to the landing page but didn’t fill in the registration form, you want to give him five days of peace before you send him an email (OK, we might not do this in the real world, but it helps with the concept) telling him he better hurry up and fill in the form.

Here’s the overall model for our simple example:

The top rectangle describes our initial state. All visitors that have reached our site as a result of clicking on the Facebook wall link are part of this state. As an aside, here’s the field (“Enroll in Engagement Plan”) in our overall Facebook Wall campaign where we can automatically place the visitor into this state:

The state itself is pretty straightforward. Think of these states as the “buckets” any of our audience members might be in at any time during this overall Engagement Plan. Many things can move people from state to state—from their own actions (like opening an email or registering using a Web Forms for Marketers form) to our actions as site owners (manually moving members to a different state) to automated triggers (move them to a different state if they’ve been in this state for 5 days).

When we take a closer look and edit the Conditions (the diamonds), we see a bit more detail:

Here we are able to create a branching decision point—a Yes/No decision point where a particular condition will be evaluated. In our example, it’s simply a check as to whether the current visitor in this Engagement Plan has filled in our contest registration form. In our example, we simply apply the “Register” goal to the act of filling in the form. Web Forms for Marketers makes this incredibly easy, as the out of the box submit actions include the ability to tie to this very goal. For those of you new to CEP/DMS, a goal can be anything you deem an important event on your site, from filling in this form to downloading your newest whitepaper to following a particular trail through your pages. The rules engine is fully at our disposal here as you can see from the capability to “Edit Rule” above.

In our scenario, a YES answer to this condition means that we’ve achieved our modest objective….the campaign was a success and we have a VALUABLE visitor. Let’s put that visitor into the Valuable state bucket. As we do that, we have an opportunity to perform any number of additional Actions—change a profile attribute in the CRM, send a thank you email, move them to another Engagement Plan:

OK, we’re done with our Valuable visitors. Now to those procrastinators who have refused to fill in our registration form (even though they saw that juicy offer to on our landing page). Our scenario states that we will wait 5 days and then really hound them with an email.

Editing our condition gives us the ability to easily model this rule:

Now, if 5 days has passed, we can send that reminder email to this group:

Hopefully this article highlighted the basic concepts of the Sitecore Engagement Plans. I will use this simple scenario and expand on it in the coming weeks to dive deeper into Sitecore’s Customer Engagement Platform.

Sitecore Customer Engagement Platform: Segmenting the Audience

2011-09-14T10:57:00.000-04:00

I'm amazed at the richness of the conditions that exist in Sitecore's Customer Engagement platform that can be used to strategize audience segmentation. This new release takes huge leaps towards the very exciting goal of synthesizing customer activity--online, offline, implicit behavior, explicit profile attributes (either in Sitecore or external to it), channel activity based on email campaigns, mobile experiences, subscriptions, external social sites and much more.

I've had lots of conversations recently that boil down to "where do I begin?"

Mark Twain reminds us:

"Never put off till tomorrow, what you can do the day after tomorrow."

Remember, this is a marathon, not a sprint. The great thing is, you've chosen (or are now choosing) a Customer Engagement Platform that is built on the groundwork of THE world-class Sitecore Web Content Management System. This is not a new building. This is not new set of really high floors set to topple. This is an expansion of an amazing platform that is the right combination of high and wide, with incredibly sturdy sections all over the place that are ready for your designer touches, when you're ready. (Walk around for a while).

But let's use another Twain quote as an addendum today:

"All good things arrive unto them that wait - and don't die in the meantime"

After all, we are trying to have the best digital marketing strategy on the planet. Put one foot in front of the other, eat the elephant one bite at at time, and now my trite quoting is officially done. Let's look at a really simple starting plan:

In this scenario, we decide that our visitors (or potentially even more compelling--our members or customers), are in one of four states. These states could also be envisioned as a sales funnel, with the first state I'll describe being the entry point to the funnel:

Just Browsing. Think of this as a default state where you don't want to make any assumptions yet. You have content for this--compelling content pages that keep this visitor engaged and circling down the funnel. In terms of Sitecore's Customer Engagement Platform, maybe this visitor hasn't yet hit your predefined and prestrategized thresholds of goal achievement or profile values. You're just not ready to guide this visitor in any particular direction until she "tells" you a bit more about herself. She also hasn't logged in (although this doesn't necessarily mean that she hasn't been to your site before).
Interested in featured product line. It's the end of the quarter and you have three million of these widgets to sell. The company is buzzing with ideas about how to promote and unload this last batch--from email newsletters going out to new subscribers, customer service agents noting the promotion to all call in customers, an add running directly on your home page and various landing pages pushing the widget. While this impression is going to be everywhere--both online and off--you obviously don't want to assume someone is interested in the widget because they've heard about it. Your criteria is more specific--it's the conversion, the achievement of a predefined goal you've identified as a confident assumption of customer engagement. As we'll see, this doesn't have to be one thing. Maybe he specifically searched Google for the exact part number of the widget. Maybe he opens the email, goes to the landing page, and fills out a form asking for pricing. Maybe he's downloaded both the widget installation manual AND watched the Getting Started Video. Maybe he's talked to a customer service agent and told him that he's "very interested" in purchasing by the end of the quarter. However he got to to this state, now you're ready. You're ready to change his experience as he gets to the next landing page two days before the quarter ends. He now gets the very aggressive coupon clearly presented on his arrival.
Ready to buy online. It's down to the wire and we only have a few days left to the quarter. Salespeople are carefully watching the transition to this state. These visitors have been presented the coupon (and maybe even that coupon was part of a multi-variate test where different messaging was presented). There's been contact outside of the site, where customer service has entered detailed notes in the CRM about the questions asked last week. This company's DNS record is all over your Sitecore Analytics data--multiple employees of the company have filled out Web Forms for Marketers forms and we've tagged names and email addresses. We see conversions all over the place, from downloads, to form submissions, to poll questions showing buying intent. Finally, we see that a shopping cart has been started and 50,000 widgets are in it. The shopping cart is almost complete. It's the 30th. Time for a call.
Existing customer. Any time during the month we can have an authentication event--someone logged in and we now know him. Whether his profile data is directly in Sitecore's security tables or sitting in Dynamics, Salesforce or another CRM or home-grown system, we know have a rich set of profile information to work with as we customize this visiting experience. Has he purchased the Widget in the past? Has he purchased products that are profiled in a similar way? Has he specifically told us that he wants to receive email campaigns with these types of offers?

With the four possible states fully described, let's see some conditions we could use to personalize the experience for our visitor. In follow up posts, I'll keep this theme alive and talk about how we could monitor this with the new Customer Engagement Platform Engagement Plans.

Keep in mind that, while there is an incredible set of predefined conditions available in Sitecore by default, this condition engine is easily extensible to account for your own very specific conditions--conditions that may be based on information in Sitecore or in any external system in your overall solution.

To keep the example simple, let's imagine a simple News Story that we're writing for our site. You could think of this News Story as being a landing page, the Widget product page itself....whatever. The point is that we can simply have an image control on this page that can show something different based on the state the visitor is in.

It all starts with placing our simple Show Image control on the page. We can easily do this in the Device Editor shown below, or we can do it directly in the Page Editor:

Adding our Show Image control in Content Editor's Device Editor.

Now we can set up the set of conditions that will segregate our visiting audience into the four states. For our example, we'll simply upload some images that are nice visual indications of the current visitor's state. In the real world case, we might have the Image control vary the advertisement image, we may swap out the control altogether based on the visitor's state, we may have a very rich control that uses dramatically different logic, markup, access to external systems, etc. Here's our images:

Funnel images to depict the visitor's state

Now we are able to have our Show Image control easily switch between these images. Techically the control itself is able to switch its Data Source....point to a different content item in the overall Sitecore content tree.

Now, personalizing the component is an exercise of thinking through all the conditions that would lead to our decision that this visitor is part of a particular state. First one is easy (working from the top of the funnel down). Here, we just have the "Just Browsing" image, since we're not ready to differentiate the experience for the visitor based on our current information.

Now, it's on to the Interested in Product state. We've decided that we'll determine a visitor to be interested in the Widget product if ANY of these conditions exist (we could have used AND clauses to ensure multiple factors exist):

This visitor is a known user that has received an email campaign focusing on widgets from us and has opened the email.
This visitor has reached a landing page we set up (maybe by browsing through the site, maybe they saw the link in a featured search result, maybe a Facebook wall post) AND they've filled out the form that they see there.
This visitor reached our site by searching on a specific term in a search engine.

Here's what that set of conditions looks like using prebuilt conditions in Sitecore's Rule Set Editor:

Rule Set Editor for our multiple, independent clause condition

Similarly, we'll list the conditions that brings a visitor down to the "Ready to Buy" section of the funnel. For our example, we decide that this person could:

Have an "Engagement Value" greater than 10. This will be covered more in my follow up posts, but think of a combination of goals, events and conversions each having a specific value associated with them.
Have a user name (could just be a tag that we've captured, doesn't need to be an authentication event) of Mike Casey. Maybe our customer service agent has talked to Mike.
Be a member of the Flagged in CRM role. More again in a future post, but our connection to a CRM could allow a non-CMS user (like a customer service agent working in a CRM) to affect the existance of this condition simply by completing their day-to-day tasks.
Have a lead profile score of greater than 25. Since your content authors are able to assign profile values to the content they create, you are now able to determine a threshold at which you'd be confident on the lead value of this visitor.

Completing our rule set by including a check for a particular customer role (this could get a lot more interesting by tying our knowledge of this customer to this clause--what products did they buy, what are their site preferences, etc), we know have a fully built out set of conditions to match a visitor into the approrpriate state:

Our finished set of conditions

Hopefully this gets you thinking about where to start and how rich the set of prebuilt conditions in Sitecore really is. Remember that you don't have to consider sweeping changes to your Web site based on these conditions--little things, nuanced changes in site navigation, featured image spots, customized landing pages can be incredibly powerful. In future posts we'll dive deeper into the Engagement Plans that can help us move our audience along the path towards our predefined goals for our digital strategy.

New Patterns in the Customer Engagement Platform

2011-09-08T11:02:00.001-04:00

I have to admit--at first I was pretty confused about this new Patterns feature in Sitecore 6.5. I understood the intent of allowing content authors the ability to assign a set of profile values in one fell swoop, wrapping up a bunch of attributes into a package that could be easily assigned to a piece of content they are working on. Now, when I'm writing an article for instance, I could envision "who" this article is most targeted towards, give that audience member a name and face and set of "typical" demographic information.

The confusion in my head came down to terminology....profiles, profile cards, patterns, personas. This won't be official documentation (Sitecore has plenty of that), but instead a quick and goofy example of how I started to get my own head around these concepts. Specifically, this will dive into the Patterns concept, as I think you'll agree that this is an amazingly cool new feature in Sitecore's personalization engine.

One statement that helped me understand the difference between Profile Cards and Patterns: Profile Cards are for assigning attribute values to content items. Patterns allow rules to assess how closely a visitor matches an expected "mix" of attribute values.

Now starts my goofy example. Instead of wrapping my head around nebulous attributes (yours will of course be concrete and real-world), I wanted to think about three cartoon characters that differed along three attribute axes. The three axes--partyer, academic and worker:

Homer Simpson doesn't have a ton of redeeming qualities. Donuts and beer provide sustenance. He wins on the partyer scale:

While still showing hope with a value of 1 for Worker and Academic, Homer is off the charts at 10 on the Partyer scale

Scooby Doo is driven by snacks, but this leads to a particularly strong work ethic. He wins on the Worker scale:

Scooby's snacks drive his work ethic. A smart and fun loving dog, he still gets 1's for Academic and Partyer

Brian Griffin gets a little tricky. Martinis are definitely a weakness, but his self-proclaimed academic prowess is what we'll concentrate on. And for this example's simplicity sake, we'll hide his partying ways:

A true academic (let's concentrate on how he sees himself)

OK, let's see what we've done here. Below is the area of the content tree where we can model profile attributes, profile cards and patterns:

In the Marketing Center, under the Profiles item we see the overall Profile I created, called Characters. Directly under Characters are the three Profile Keys (which I've been calling attributes) that make up the possible segregation within the profile. Remember that this is a mix--I can be on a scale of values between all these Profile Keys. Profile Keys have a minimum and maximum value so you can decide on the granularity that content authors will have as they assign these values.

Notice there are no Profile Cards included above. I kept this out on purpose--let's stick to one thing at a time. Profile Cards would have allowed me to create a predefined mix of attributes that a content author could assign to a piece of content in one operation. It could LOOK exactly like the patterns above, but a profile card's purpose is to promote the simple and consistent application of these Profile Keys to content. The way I have it now (as we'll soon see) I will have to assign the value of 10 for Academic, 1 for Partyer and 1 for Worker individually. Had I created a Profile Card, I could have assigned Brian Griffin to get the same result of those independent Profile Key assignments.

But let's get back to Patterns. As you can see, under the Pattern Cards item, I added three new Pattern Cards (those are the screen shots with the character images above). Basically a Pattern is an anticipation of shapes between the axis in the overall Profile.

Because Brian Griffin would be interested, I have to include the formula Sitecore uses to decide which Pattern is matched:

Squared Euclidean Distance
d(p,q) = (p1 − q1)2 + (p2 − q2)2 + ... + (pi − qi)2 + ... + (pn − qn)2

For you Homers...ah, forget it you already stopped reading.

Thanks to Adam Conn for a much more serious coverage of this subject.

In our example, let's think of it like this. We're going to label a visitor of our site with one of these characters. A visitor is always going to be one....they might move from being a Homer to a Brian as they start reading more about the Ivy League. They might move from Brian to Scooby as they read about the Industrial Revolution. But they will always be one.

Now our controls on our Sitecore pages know who are visitor is at any one time and can start customizing the experience. 10% off on Scooby Snacks, Happy Hour tickets, virtual tours of the Louvre. Maybe it's not so dramatic--a movement of a message from the bottom right to the top left, a slight reordering of navigation elements.

Two parts to accomplish this:

First, we have to get smart about our content authoring process, our workflow and review process. Let's ensure that assigning Profile Keys is an important part of the content lifecycle. Below you'll see an article that I'm writing called Martinis and Novels (shamelessly pandering to the Brian Griffin crowd). In addition to the article itself, I've decided to apply the appropriate Profile Keys (remember for simplicity's sake I'm pandering to Brian's self-proclaimed academic prowess).

Clicking on the Profile icons on the right hand side of the Content Editor screen brings up this dialog

I've assigned the value of 10 for Academic, 1 for Partyer and 1 for Worker to my news article. Now as a visitor browses to my article page, they accumulate those values for their session (or even across multiple sessions). The "shape" of my article is a triangle that reaches high on the Academic scale and low on the other two.

I'd now go through a similar exercise for my articles targeted at other audiences and each content item will carry its own shape. Doughnuts and Beer will reach way over on the Partyer axis.

Second, we want to implement a Rule on one of our controls that takes advantage of this shape matching. We'll keep it simple and just show a different image (technically we'll change the Data Source of our control to point to a different content item containing an Image field). Below shows how I can accomplish this in the Sitecore 6.5 Page Editor. I have a simple control that renders an image. It's default data source (the image it chooses) is the question mark. Based on our pattern matching, though, I will switch the image to the appropriate content item that contains an image targeted towards that character:

This is an pre-built rule available in Sitecore 6.5. I am able to simply look for a condition where the pattern matches the Profile Key distribution of the current visitor. By looking for these three conditions, I am able to easily move between the cases (as someone becomes more of a Brian than a Homer). I could also easily switch out the control altogether.

Keep in mind that these conditions can be much more elaborate. Maybe this pattern matching is a single clause of an overall condition...think about the checks you could make to a CRM or any other persistent profile store in addition to the checks you can make against current visitor browsing patterns. Sky's the limit...hopefully this gave you way to understand a simple scenario that can open up your significant real world ideas.

My Widget Control

2010-11-24T07:45:00.001-05:00

I put the term widget in the same category as out-of-the-box. Out-of-the-box is a very appropriate term for how and why we bought our favorite software package in 1995. There was, in fact, a box with a stack of 3.5 inch disks, there was a printed instruction booklet, there was a set of well documented and well bordered features. Maybe there was some extensibility—the hint of some macro-based or API strategy and the ability for a top-notch developer to crack into the box and extend it for your business’ purposes. Fast forward to now. There is no box (good for the company not packaging it and shipping it, good for the environment not digesting it), documentation is online (with the new challenge in finding a balance between release management and immediate editorial changes), and the installation involves saying OK and grabbing your next cup of coffee. But, more importantly, whereas in 1995 you threw the box away and started marking up your copy of the instruction manual (errata available by including proof of purchase serial number—oh man, already threw the box away—and mailing to PO Box…), now, in 2010, you have entered into a relationship. You don’t (and shouldn’t) expect your experience with this software to be boxed in. You expect your documentation to be task driven, continually updated with new and more focused code samples. You expect a community to be there when you enter your search phrase and wonder if anyone ever had that exact same challenge before. You expect—and this is a really important one—you expect that the owner of the business process should be able to model that process with the software directly. You expect the developer to run alongside the business process owner (no baton passing here), building features and functionality that are derived from the business process model conversation your software was able to facilitate.

Sitecore does not ship in a box.

One reason—the features wouldn’t fit inside. Really, if anyone has recently had a demo of Sitecore, you have seen that the conversation can go for hours on end and still not touch half of the feature set. Building a product on such a solid foundation has yielded an amazingly expansive structure above.

The more important reason—Sitecore doesn’t claim to know your business better than you do. With all of the amazing features available in the product, one thing always holds true and consistent—the feature is built with the dedication to your ability to change it and model it to your business process needs. And if you’ve seen the demo, you realize that you’re using the incredibly intuitive Sitecore UI’s to do the modeling. If you want a software company to tell you what your business process needs are, I think I still have a box somewhere in my attic.

Oh yeah, the widget. I couldn’t think of a better title for this control based on the disorganized rant of this blog. While the widget is perfect for calculating throughput in a freshman Operations 101 class, I’ve found them to be less than satisfying in developing a Web site feature (“What is it?, “It’s the new widget we got out of the box because we bought on Black Friday”).

Let’s use it today though, as we look at a couple of quick concepts—the use of Web Server controls, and playing around with Fast Query.

Recently I worked on a proof of concept where it was important to show the ease of adding “widgets” to a Sitecore page. The scenario is one that we’ve all thought through for our site—someone is writing a news article and they want to add some things to the right column next to the story itself. For this, let’s consider the ability to add:

An image
A set of images
Just any old block of HTML
A really smart list of items that is relevant to my content item that I'm working on

A disclaimer here. There are MANY ways of tackling this and this little story isn’t trying to be a best practices discussion about the best way to create the information architecture for ease-of-use and extensibility. Instead, in going through this exercise we simply want to:

Go through the steps of “hooking up” a Web Server control
Play around with a couple cool Fast Query expressions

To create the new Web Server control, let’s create a class. The idea behind this class is that the Sitecore.Context.Item is going to have a Multilist field where a content author can select any of these prebuilt widgets to include on their page. The widgets themselves will be of four different varieties that you can see in the switch statement.

using System;
using System.Web.UI;
using Sitecore.Data.Items;
using Sitecore.Links;
using Sitecore.Web.UI.WebControls;
using System.Text;

namespace examples
{
    public class widget: Sitecore.Web.UI.WebControl
    {
        
        protected override void DoRender(HtmlTextWriter output)
        {

            Item item = Sitecore.Context.Item;
            if (item != null)
            {
                Sitecore.Data.Fields.MultilistField widgetsField = (Sitecore.Data.Fields.MultilistField)item.Fields["Widgets"];
                if (widgetsField != null && widgetsField.Count > 0)
                {
                    foreach (Item widget in widgetsField.GetItems())
                    {

                        switch (widget.TemplateName)
                        {
                            case "HTML Widget":
                                //todo:  RenderHTMLWidget(output, widget);
                                break;
                            case "Single Image Widget":
                                //todo:  RenderSingleImageWidget(output, widget);
                                break;
                            case "Query Widget":
                                //todo:  RenderQueryWidget(output, widget);
                                break;
                            case "Image Gallery Widget":
                                //todo:  RenderImageGalleryWidget(output, widget);
                                break;
                            default:
                                break;
                        }
                    }
                }
            }
        }
    }
}

Now we can compile our project…our new class isn’t ready to do anything just yet (we can investigate that later), but we can go through the steps to register the control with Sitecore. To do this, we can use the Developer Center user interface. We can also do this by simply creating a new content item and filling in the appropriate fields, but let’s use the Developer Center at least this first time.

Please see our full documentation set (especially the Presentation Component Cookbook and Presentation Component Reference) for much better documentation around this process. Below are steps to get us going quickly….

In Developer Center, click on File—>New. From there you will see the ability to create a new Web Control. Select Web Control and click Create.

Follow the Wizard until you get to the Configuration step:

Notes on these steps:

Name will be the name of the content item

Tag Prefix/Tag will be how the control is registered on the page

Be sure to check your namespace and the check in your project for your assembly name (and you don’t need to add the .dll extension).

Click the Test button to be sure your class was found in the assembly, and complete the Wizard by choosing where to create the Sitecore content item that represents your new control.

After finishing the Wizard, the Developer Center will open to the item itself, so you can see how the item’s fields are populated with the results of your Wizard entry.

To make your next Web Control, you could simply duplicate or copy/paste this item and change the fields to reflect your next class……or you can go through the Wizard steps again.

Here’s my final:

And here’s how the control could be registered and included in an .aspx:

<%@RegisterTagPrefix="mc"Namespace="examples"Assembly="myproject"%>

<%@PageLanguage="c#"CodePage="65001"AutoEventWireup="true"%>

<%@OutputCacheLocation="None"VaryByParam="none"%>

<!DOCTYPEhtml PUBLIC"-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<htmllang="en"xml:lang="en"xmlns="http://www.w3.org/1999/xhtml">

<head>

    <title>Insert the page title here.</title>

</head>

<body>

    <formmethod="post"runat="server"id="mainform">

    <mc:widgetrunat="server"id="widget1"xmlns:mc="http://www.sitecore.net/xhtml">

    </mc:widget>

    </form>

</body>

</html>

Now we can get back to our class. I’ve included the shell that we saw before, and added a method to return the results of a Sitecore Fast Query:

using System;
using System.Web.UI;
using Sitecore.Data.Items;
using Sitecore.Links;
using Sitecore.Web.UI.WebControls;
using System.Text;

namespace examples
{
    public class widget: Sitecore.Web.UI.WebControl
    {

        protected override void DoRender(HtmlTextWriter output)
        {
            Item item = Sitecore.Context.Item;
            if (item != null)
            {
                Sitecore.Data.Fields.MultilistField widgetsField = (Sitecore.Data.Fields.MultilistField)item.Fields["Widgets"];
                if (widgetsField != null && widgetsField.Count > 0)
                {
                    foreach (Item widget in widgetsField.GetItems())
                    {

                        switch (widget.TemplateName)
                        {
                            case "HTML Widget":
                                //todo:  RenderHTMLWidget(output, widget);
                                break;
                            case "Single Image Widget":
                                //todo:  RenderSingleImageWidget(output, widget);
                                break;
                            case "Query Widget":
                                RenderQueryWidget(output, widget);
                                break;
                            case "Image Gallery Widget":
                                //todo:  RenderImageGalleryWidget(output, widget);
                                break;
                            default:
                                break;
                        }
                    }
                }
            }
        }


        protected void RenderQueryWidget(HtmlTextWriter output, Item widget)
        {
            output.AddAttribute(HtmlTextWriterAttribute.Class, "Widget");
            output.RenderBeginTag(HtmlTextWriterTag.Div);
            output.AddAttribute(HtmlTextWriterAttribute.Class, "WidgetPanelTab");
            output.RenderBeginTag(HtmlTextWriterTag.Div);
            output.Write(FieldRenderer.Render(widget, "Title"));
            output.RenderEndTag();//WidgetPanelTab Div
            output.AddAttribute(HtmlTextWriterAttribute.Class, "WidgetPanelContent");
            output.RenderBeginTag(HtmlTextWriterTag.Div);
            string fastQuery = widget.Fields["Widget"].Value;
            Sitecore.Data.Database db = Sitecore.Context.Database;
            Item[] results = db.SelectItems(fastQuery);
            foreach (Item result in results)
            {
                string menuTitle = result.Name;
                if (result.Fields["Menu Title"] != null)
                {
                    if (!string.IsNullOrEmpty(result.Fields["Menu Title"].Value.ToString()))
                    {
                        menuTitle = result.Fields["Menu Title"].Value.ToString();
                    }
                }
                if (result.Paths.IsMediaItem)
                {
                    output.Write(string.Format(@"<li><a href=""{0}"">{1}</a></li>", Sitecore.Resources.Media.MediaManager.GetMediaUrl(result), menuTitle));
                }
                else
                {
                    output.Write(string.Format(@"<li><a href=""{0}"">{1}</a></li>", Sitecore.Links.LinkManager.GetItemUrl(result), menuTitle));
                }
            }
            output.RenderEndTag();//WidgetPanelContentTab Div
            output.RenderEndTag();//Widget Div
        }
    }
}

Notice that the class inherits from the Sitecore.Web.UI.WebControl and must override the DoRender method (using and HTMLTextWriter object to add HTML to the output). For our RenderQueryWidget method, here are the assumptions:

The Context Item (which caused this control to be invoked because it was part of the item’s presentation details) has a MuliList field called “Widgets”.

In that MultiList field are 1 to N of these Widget items.

The Widget items can be of 4 different data templates, representing the different types of widgets available

If the Widget item is created from the Query Widget data template, the Widget item will have a single line text box with a Fast Query expression.

The RenderQueryWidget will use that expression to grab the appropriate items from the content tree and render an unordered list of links to those items.

The output will be a series of divs with the ability to call out a CSS class to format them.

Here’s a screenshot of how the Query Widget data template could be created. Some features to implement after this article. Having a single-line text field for the fast query is obviously not the most intuitive business champion interface, so we can start thinking of the criteria (and the Sitecore field type to go with it) that would provide a better user interface experience.

For now, let’s concentrate on some of the Fast Queries we could use. And for a detailed description of this feature, please see our Sitecore Query and Fast Query documentation. Also, if you want to test these expressions in your own installation, use the Developer Center Tools:XPath Builder feature.

Need	Fast Query to solve
“Give me all the items that are based on the News Story Data Template (that are descendants of the content node)”	fast:/sitecore/content//*[@@templatename='news story']
“Give me all items that have been tagged with the Professional OMS Profile”	fast://*[@__Tracking = '%Professional%']
“Give me items that are definitely products in the home site that have also been tagged with the Male OMS Profile”	fast:/sitecore/content/home//*[@@templatename='product' and @__Tracking='%Male%']

Here’s how the Widget content item for the previous example could look:

Now, if you include a MultiList field (think of creating a separate Widgets Data Template and include it as an inherited template where needed). This template could just contain the MultiLIst field itself (sourced to find widgets in the content tree) where an author could select the appropriate widget for their content item.

I end with the full class listing below so you could start thinking of improved and extended uses of this. In this example, the Widget field itself is of a different type depending on the type of Widget (it’s an image field, it’s a Rich Text field, etc.). Tongue firmly implanted in cheek, a widget, of course, can do anything!

using System;
using System.Web.UI;
using Sitecore.Data.Items;
using Sitecore.Links;
using Sitecore.Web.UI.WebControls;
using System.Text;

namespace examples
{
    public class widget : Sitecore.Web.UI.WebControl
    {

        protected override void DoRender(HtmlTextWriter output)
        {
            Item item = Sitecore.Context.Item;
            if (item != null)
            {
                Sitecore.Data.Fields.MultilistField widgetsField = (Sitecore.Data.Fields.MultilistField)item.Fields["Widgets"];
                if (widgetsField != null && widgetsField.Count > 0)
                {
                    foreach (Item widget in widgetsField.GetItems())
                    {

                        switch (widget.TemplateName)
                        {
                            case "HTML Widget":
                                RenderHTMLWidget(output, widget);
                                break;
                            case "Single Image Widget":
                                RenderSingleImageWidget(output, widget);
                                break;
                            case "Query Widget":
                                RenderQueryWidget(output, widget);
                                break;
                            case "Image Gallery Widget":
                                RenderImageGalleryWidget(output, widget);
                                break;
                            default:
                                break;
                        }
                    }
                }
            }
        }


        protected void RenderQueryWidget(HtmlTextWriter output, Item widget)
        {
            output.AddAttribute(HtmlTextWriterAttribute.Class, "Widget");
            output.RenderBeginTag(HtmlTextWriterTag.Div);
            output.AddAttribute(HtmlTextWriterAttribute.Class, "WidgetPanelTab");
            output.RenderBeginTag(HtmlTextWriterTag.Div);
            output.Write(FieldRenderer.Render(widget, "Title"));
            output.RenderEndTag();//WidgetPanelTab Div
            output.AddAttribute(HtmlTextWriterAttribute.Class, "WidgetPanelContent");
            output.RenderBeginTag(HtmlTextWriterTag.Div);
            string fastQuery = widget.Fields["Widget"].Value;
            Sitecore.Data.Database db = Sitecore.Context.Database;
            Item[] results = db.SelectItems(fastQuery);
            foreach (Item result in results)
            {
                string menuTitle = result.Name;
                if (result.Fields["Menu Title"] != null)
                {
                    if (!string.IsNullOrEmpty(result.Fields["Menu Title"].Value.ToString()))
                    {
                        menuTitle = result.Fields["Menu Title"].Value.ToString();
                    }
                }
                if (result.Paths.IsMediaItem)
                {
                    output.Write(string.Format(@"<li><a href=""{0}"">{1}</a></li>", Sitecore.Resources.Media.MediaManager.GetMediaUrl(result), menuTitle));
                }
                else
                {
                    output.Write(string.Format(@"<li><a href=""{0}"">{1}</a></li>", Sitecore.Links.LinkManager.GetItemUrl(result), menuTitle));
                }
            }
            output.RenderEndTag();//WidgetPanelContentTab Div
            output.RenderEndTag();//Widget Div
        }

        protected void RenderImageGalleryWidget(HtmlTextWriter output, Item widget)
        {

            output.AddAttribute(HtmlTextWriterAttribute.Class, "Widget");
            output.RenderBeginTag(HtmlTextWriterTag.Div);

            output.AddAttribute(HtmlTextWriterAttribute.Class, "WidgetPanelTab");
            output.RenderBeginTag(HtmlTextWriterTag.Div);
            output.Write(FieldRenderer.Render(widget, "Title"));
            output.RenderEndTag();//WidgetPanelTab Div

            output.AddAttribute(HtmlTextWriterAttribute.Class, "WidgetPanelContent");
            output.RenderBeginTag(HtmlTextWriterTag.Div);

            Sitecore.Data.Fields.MultilistField imageList = (Sitecore.Data.Fields.MultilistField)widget.Fields["Widget"];
            foreach (Sitecore.Data.Items.MediaItem media in imageList.GetItems())
            {
                output.Write(string.Format(@"<a href=""{0}""><img src=""{0}"" width=""90px;"" alt=""{1}"" /></a>", Sitecore.Resources.Media.MediaManager.GetMediaUrl(media), media.Name));
            }


            output.RenderEndTag();//WidgetPanelContentTab Div

            output.RenderEndTag();//Widget Div

        }
        protected void RenderSingleImageWidget(HtmlTextWriter output, Item widget)
        {

            output.AddAttribute(HtmlTextWriterAttribute.Class, "Widget");
            output.RenderBeginTag(HtmlTextWriterTag.Div);

            output.AddAttribute(HtmlTextWriterAttribute.Class, "WidgetPanelTab");
            output.RenderBeginTag(HtmlTextWriterTag.Div);
            output.Write(FieldRenderer.Render(widget, "Title"));
            output.RenderEndTag();//WidgetPanelTab Div

            output.AddAttribute(HtmlTextWriterAttribute.Class, "WidgetPanelContent");
            output.RenderBeginTag(HtmlTextWriterTag.Div);
            output.Write(FieldRenderer.Render(widget, "Widget", "mw=300"));
            output.RenderEndTag();//WidgetPanelContentTab Div

            output.RenderEndTag();//Widget Div

        }


        protected void RenderHTMLWidget(HtmlTextWriter output, Item widget)
        {

            output.AddAttribute(HtmlTextWriterAttribute.Class, "Widget");
            output.RenderBeginTag(HtmlTextWriterTag.Div);

            output.AddAttribute(HtmlTextWriterAttribute.Class, "WidgetPanelTab");
            output.RenderBeginTag(HtmlTextWriterTag.Div);
            output.Write(FieldRenderer.Render(widget, "Title"));
            output.RenderEndTag();//WidgetPanelTab Div

            output.AddAttribute(HtmlTextWriterAttribute.Class, "WidgetPanelContent");
            output.RenderBeginTag(HtmlTextWriterTag.Div);
            output.Write(FieldRenderer.Render(widget, "Widget"));
            output.RenderEndTag();//WidgetPanelContentTab Div

            output.RenderEndTag();//Widget Div

        }

    }
}

Technorati Tags: Sitecore,OMS,Fast query

Checking an external source for an OMS condition

2010-08-06T16:39:00.001-04:00

In talking through potential Online Marketing Suite scenarios with prospects, clients and partners these days, the discussion often leads to very interesting possibilities in evaluating external data sources as part of an overall personalization strategy. For those of you that have worked with Sitecore, you know it’s built for this. Rather than enforce a migration of data to the content repository, a well developed Sitecore strategy continues to take advantage of data and application functionality wherever it is best served from. OMS is no different.

The following is a simple example of a common scenario. We want to develop an OMS condition that queries an external database and determines whether a product is available before showing the promotion our marketing team has created for it. With the condition in place, it will be easy for us to build a rule that does something when the condition is true. This is a classic “When” condition, and we can think of all kinds of rules that might be appropriate based on the boolean value returned.

Many of my conversations lately have been around “Who does what in OMS?”. A very fair question. I get excited by the question, because it gives me confidence in the “newness”of what OMS is doing. Sure, every piece of OMS could be developed separately (it is software, and everything is possible), but Sitecore has sparked the questions because it’s not JUST developers anymore. While developers are certainly creating the great methods that evaluate conditions and implement rule-driven functionality, others (you get to decide who) are mapping the business processes and visualizing the results. These two sides are equally important—if a Condition falls in the woods and nobody….you get the idea.

Back to it. 1st step is the condition definition itself. Who does this? Well, in most cases this one’s for the developer. The reason is that we’re coding brand new logic here. If you’re talking about the rich set of standard OMS Conditions (geolocation info, DNS info, authenticated user, the visitor entered as as part of an Email Campaign, etc), then there’s no work to do here. These Conditions are already defined and available to you as you build a rule to evaluate that particular Condition. More on that later. The screenshot below shows the beginning of the scrollable list of prebuilt Conditions:

In standard Sitecore fashion, all prebuilt Sitecore functionality is built and referenced in the same way you’ll build yours. If you look in the Content Editor under /sitecore/system/Settings/Rules/Conditional Renderings/Conditions/Area Code Condition, you’ll see the definition (the Item in the tree) that represents the condition. Even though this is a standard OMS Condition, Sitecore shows you the class being used:

You’ll notice that the AreaCodeCondition class in the Sitecore.Analytics assembly is referenced. You’ll also see that the Text field allows you to define placeholders where a content author can enter additional parameters to the condition evaluation. I talk a little more about these values here, and our Rules Engine Cookbook does a great job of going into more detail.

So for our purposes today, it’s going to be even easier. Rather that doing a compare of values between Analytics data and content author entered parameters, we’re simply going to check the “trueness” of a condition. Does the product have any availability? Based on the result, we can then decide what to do about it.

The reason for the belaboring: this is the thought process you’ll go through as you answer the “Who does what?” question with OMS.

A cross-functional team discusses the Conditions that need to be evaluated. Some will exist in OMS already, some will need to have these comparisons / when-condition methods crafted to encapsulate your business rules, query external sources, etc.
A cross-functional team discusses the Rules, the things that should HAPPEN when a Condition is evaluated. Some will exist in OMS already (easily hiding or showing a control, having a control display a different piece of content, moving a control to a different area of the page, initiating a specific Email Campaign, etc.) and some will do fun and exciting things outside of the Sitecore application domain and context.
A cross-functional team discusses where and when these rules are appropriate (the marching red ants theorem first developed in the 90’s has new corollaries).
A cross-functional team ensures that both sides of the brain communicate, and that the development efforts and the business process mapping stay on the same (albeit flexibly winding) trail.

The point here isn’t that you need a huge cross-functional team. The point is that if you’re a team of one (or 2, or 10, or 100), you need to think cross-functionality. Nothing new here.

Back to it. Now that we’ve seen where the Condition definitions are, we’ll simply add our own and call out our own Class.

This condition is set up to take a look at the Northwind database, see if there is any Tofu available, and return true if so:

using Sitecore.Diagnostics;
using Sitecore.Rules.Conditions;
using Sitecore.Rules;
using System;
using System.Linq;
using System.Data.Linq;
using nwind;


namespace Examples
{
    public class NorthwindProductAvailable<T> : RuleCondition<T> where T : RuleContext
    {
        // Methods
        protected void WhenCondition()
        {
        }

        public override void Evaluate(T ruleContext, RuleStack stack)
        {
            Assert.ArgumentNotNull(ruleContext, "ruleContext");
            Assert.ArgumentNotNull(stack, "stack");
            stack.Push(this.Execute(ruleContext));
        }

        protected bool Execute(T ruleContext)
        {
            try
            {
                Northwind_Extended db = new Northwind_Extended(@"Data Source=(local);Initial Catalog=Northwind; user=sa; password=*");               
                   var numUnits = (from m in db.Products
                                where m.ProductName == "Tofu"
                                select m.UnitsInStock).SingleOrDefault();


                   return numUnits > 0;
          
            }
            catch
            { return false; }

        }

    }
}

That’s it. As my previous post shows, now this condition is available to us to define any action to take after the evaluation of it.

We’d certainly have a more complex business rule in the real world, and that would invariably lead to the ability to have marketers and other content authors being able to include their parameters to the condition evaluation. By including tokens for replacement, this becomes a very easy exercise.

Zen and the Art of CMS, Chapter 1

2010-04-05T17:56:00.001-04:00

What you have to do, if you get caught in this gumption trap of value rigidity, is slow down—you’re going to have to slow down anyway whether you want to or not—but slow down deliberately and go over ground that you’ve been over before to see if the things you thought were important were really important and to…well…just stare at the machine. There’s nothing wrong with that. Just live with it for a while. Watch it the way you watch a line when fishing and before long, as sure as you live, you’ll get a little nibble, a little fact asking in a timid, humble way if you’re interested in it. That’s the way the world keeps on happening. Be interested in it.

Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance

I’ve been looking for a model to use as an ongoing discussion of Sitecore. I’ve decided on a tried and true classic (translation: might be outdated) in Bob Boiko’s Content Management Bible. With 40 chapters and over 1,000 pages, this should give me plenty as a structure to describe every part of the Sitecore CMS, sprinkling in my own lessons learned, discussions with Sitecore implementation partners and clients, and an occasional code sample here and there. With any system there are absolutely great things and things that become absolutely great with the right mechanic. There are always challenges. In almost all cases these are very human challenges, where implementation details follow a frustratingly parallel and distinct path from poorly communicated expectations; where use cases are copied from comfortable but outdated business processes; where the the tool is used with unintended force until it strips the bolt; where the wrong tool is used altogether.

Time to step back, take our time, stare at the machine. With patience and focus, we’ll tune it for a very long and prosperous ride….

Chapter 1, What is Content?

For Sitecore, What is an Item?

Boiko’s introduction allows us to consider the complementary and colliding concepts of information, data and content. This introduction to core CMS concepts gives me an opportunity to talk about a core Sitecore concept—the Item. The Item in Sitecore is the core unit of content. An item is, on the surface, a collection of Fields. An Item is much more, though. It is the container (the honey jar with the label in Boiko’s example) that describes its purpose, its relevance, its allowed position in the information architecture, its review process (workflow), its rules for validation (its page should be XHTML compliant, a particular field within it should be required, another field within should follow a regular expression describing U.S. zip codes, etc.), its access rights for various roles and users of the application.

Let’s take a brief look at the Item, its lifecycle and some of the many things that it can do to help describe your information. Sitecore has very rich documentation on the Item, the Data Templates that serve as the data and business rules model for the Item and the various user interfaces used to create and maintain the rich content that this architecture promotes.

Let’s create a new News Article and see what we have available to us. Now, of course, the News Article we create has already been fully modeled for us. A News Article Data Template has been created in my site (ideally a cross-functional group got together and really talked about what a News Article is for our company) and is available for us to build a new News Article from. In addition, this group got together and talked about where News Articles should appear in the site—from presentation, navigation and content hierarchy perspectives. As you can see below, there’s a News-and-Events area of the content hierarchy, and Sitecore dutifully guides me that my new News Article can go here.

Let’s name our new News Article:

…and our News Article is inserted into the content hierarchy. Notice the right column, where sections upon sections of available fields await our editing. Many of these are Standard Fields (fields given to our new News Article by its automatic inheritance of the Sitecore Standard Template). This automatically gives me an incredibly rich container of information—some fields I might never see, care about or maintain, but they are there to further describe my News Article and track its movement through the system. I can see that this News Article has already begun its track through a workflow process (a handy automatic review process that the cross-functional group decided should be a requirement of all News Articles across the site and therefore set the rule on the Data Template for News Articles):

As we start to expand some of these sections, we can get down to the Field level of detail. Now we’re at the individual pieces of information that go into our container. Some of these fields will be the core of the News Article itself. A Title field may be automatically populated by the name of the News Article I just created. Other fields may be populated with static text (to tell me as a content author what I should do with this field):

Other fields may allow me to create links, references within my content hierarchy, tying together like-content:

Still other fields allow me to describe my content, targeting it towards specific personas, profiles, campaigns, describing it as appropriate for certain geographical locations, assessing a score or value in a sales or marketing category:

All along the way, as this new News Article moves from creation through edited versions to various workflow / review states to readiness for site publication, this container, this Item contains all the fields necessary to track and report on this activity:

…and a consistent event architecture to react in your own way as this item moves through the process. If I wanted to write to my own log file, communicate with another application, etc., I have a clear event model in place. I could easily call out some Sitecore actions (as in this Validation action that is called out as someone Approves my News Article):

Or I could call my own Hello World code when the News Article is Saved:

Boiko's chapter 1 is certainly not a comprehensive coverage of Content Management. Likewise, this article isn’t an in-depth, complete document on the Item in Sitecore. Hopefully this scratched the surface about everything this honey jar is in Sitecore—with the rich field typing system, standard fields and other techniques that promote the meta-information surrounding the Item’s core informational fields, business rules (and I didn’t even yet mention presentation) containment, and an event model to track and react to everything the Item becomes along the way….

Thinking about static files

2010-03-30T17:15:00.001-04:00

OK, this isn’t going to be a typical Sitecore article. And this isn’t going to be a good code sample. With those 2 caveats firmly in place…

In my position I often try to think through good examples to highlight possible solutions, rather than developing them in a fully-built-out, real world deliverable. I’ll leave the expansion of this one (and the well-built code sample) to our fantastic Sitecore developers at our company and within our partner and client ranks.

In talking to many government and financial clients (this applies to many more, but those are two verticals where this is particularly important), the discussion often turns to auditing. Not only auditing from an internal CMS-activity perspective (who changed which piece of content when, who approved what, etc.—Sitecore certainly has rich features around this activity), but from a web site visitor experience perspective. What did I quote that person on Monday, October 12, 2009 at 2pm? What was the banner ad in place when Customer Casey clicked through based on a multi-variate test I was performing?

With the possibilities of very different presentations to different visitors (made possible by Sitecore’s Online Marketing Suite Rules Engine), I might want to ensure we have a record of those various situations or I might want to see what they will look like ahead of time.

Now this is where developers might leave the article. Again, this isn’t going to be a robust solution to the problem above. This is demowear with a purpose. The purpose is to start thinking about the real solution that could be put in place, and, along the way, to talk about a couple of entry points, events and hooks that Sitecore exposes which serve as great options to develop against. As always, Sitecore provides the access to the entire CMS lifecycle.

There are a number of tools on the market that perform the function of crawling a dynamically generated site for the purposes of creating an “offline” or file-system version of the site. One of these tools that some of our clients have used with success is HTTrack (http://www.httrack.com/) .

I wanted to play around with this idea a bit in the Content Editor. So I created a simple command button which would allow a content author to have any item in the tree highlighted and to create an HTML file based on that item’s default presentation:

Since I decided to place the command in the Preview chunk, the item in my Core database is at:

/sitecore/content/Applications/Content Editor/Ribbons/Chunks/Preview/CreateHTMLFile

The command item looks like this:

And the command is included in App_Config/Commands.config

So the command calls a simple class where we’ll request the response based on the default presentation for the item. The assumption here is that the item is published and available at the default url based on its location in the content tree.

namespace Examples
{
    public class UrlReaderWriter : Sitecore.Shell.Framework.Commands.Command
    {
       /// <summary>
       /// This command will create an HTML file based on a request to the currently selected item as it is responded to from the public site (Web)
       /// </summary>
       /// <param name="context"></param>
 
        public override void Execute(Sitecore.Shell.Framework.Commands.CommandContext context)
        {

            if (context.Items.Length == 1)
            {
                Sitecore.Data.Items.Item thisItem = context.Items[0];
                Sitecore.Data.Database web = Sitecore.Data.Database.GetDatabase("web");
                Sitecore.Data.Items.Item webItem = web.GetItem(thisItem.ID);
             
                string itemUrl;
                if (webItem != null)
                {
                    
                    itemUrl = Sitecore.Links.LinkManager.GetItemUrl(webItem);
                    string url = itemUrl.Replace("/sitecore/shell/", "/");
                    WriteFile(thisItem.Name, LoadSiteContents(url));
                }
            }
             
            
        }

        public static string LoadSiteContents(string url)
        {

            //create a new WebRequest object
            WebRequest request = WebRequest.Create(url);

            //create StreamReader to hold the returned request
            StreamReader stream = new StreamReader(request.GetResponse().GetResponseStream());

            //StringBuilder to hold info from the request
            StringBuilder builder = new StringBuilder();

            try
            {
                //now loop through the response
                while (!(stream.Peek() == 0))
                {
                    //now make sure we're not looking at a blank line
                    //if (stream.ReadLine().Length != null && stream.ReadLine().Length > 0) builder.Append(stream.ReadLine()); 
                    if (stream.ReadLine().Length > 0) builder.Append(stream.ReadLine());
                }
            }
            catch { }

            //close up the StreamReader
            stream.Close();

            //return the information
            return builder.ToString();


        }
        public static void WriteFile(string itemName, string fileText)
        {

            // Write the string to a file.
            System.IO.StreamWriter file = new System.IO.StreamWriter(HttpContext.Current.Server.MapPath("~/App_Data/" + itemName + ".html"));
            file.WriteLine(fileText);
            file.Close();
        }

    }
}

Some obvious things that this code needs:

A better read of John West’s Dynamic Links Document to avoid the string replace for the URL.

A better place to invoke this. A button in Content Editor is OK….but better yet, this fits into the Publishing event to create files when necessary (based on data template, branch of the tree, etc.).

A better strategy than creating a WebRequest. In reality, this would be interesting to build from the content in the Master db (get a snapshot of what is actually being published, maybe in contrast to what is currently in the Web db).

More variables (a drop-down added to the control button, for instance) where I can define the criteria for the presentation I’m trying to retrieve—device, OMS persona, security role, etc.

But, I told you this was a cheap piece of demoware…you’re up!

Adding Rendering Parameters to a Server Control

2010-01-18T12:18:00.001-05:00

Something I missed along the way is the ease with which you can add rendering parameters to a server control. Many of the examples we use in training use content items to show how easily the values that a control renders can be changed by a content author. Many times the update makes a lot of sense to become a parameter in the layout details themselves.

Let’s take the example of the Footer control (Footer.cs) that is used in Sitecore developer training and is part of both the Starter Kit and Office Core example sites. The Footer control looks to the content tree for its values. A “Copyright” item allows content authors to affect the values that appear in the footer of the page:

Let’s assume that, in addition to wanting to define the actual text in the Copyright (year, holder, text, etc), we want our content authors to define whether or not the link to the Terms of Use should appear in the footer at all. Now, this could certainly be accomplished in many ways. An addition of a checkbox field (“Include Link Text”, for instance) on the Copyright item itself would allow the Footer control to show this link or not depending on a content author’s wishes. For this example, though, let’s do it as part of the attributes of the control itself, in the hopes of a simple example leading to more complex real-world solutions.

The Footer control item (under Layout—>Renderings—>Footer Control) has a field in the Editor Options section that allows us to define the Presentation Template that will drive our new attribute:

Now, we can define a new template to hold these presentation attributes. For our simple example, we’ll only define one—a checkbox field that will allow a content author (or more accurately a page designer….someone responsible now for the look and feel of the site) to decide whether or not our link text will appear on pages that use this Footer control.

This new template inherits from the /sitecore/templates/System/Layout/Rendering Parameters/Standard Rendering Parameters template. We add our new IncludeTermsOfUse field to it.

N0w, if we choose to add the Footer control to a page, we can also set this new attribute:

And do a simple check for its value in our presentation code:

// ...Link to "Terms of Use" text
           string link_text = "";
           if (IncludeTermsOfUse=="1")
               link_text = FieldRenderer.Render(copyright_item, _linkTextField);

An OMS Rules Engine Example

2009-11-24T08:32:00.002-05:00

Many of you have now at least seen a demonstration of the Sitecore Online Marketing Suite capabilities. If not, make sure you contact us so we can show you the power of the personalization engine now central to the product. In today’s discussion, I will go through a complete (albeit simple) example of what you can do with Rules Engine. If you are a developer, this will get you started with the mechanics involved in hooking things up. If you are a business champion, you will see the flexibility to match personalization rules with whatever business rules challenges you face.
First, some terms:
Conditions are tied to Actions by Rules
Sitecore has generously provided quite a few conditions, many derived from the reverse DNS lookup functionality….things like:

…but these conditions are all yours to define (like everything in Sitecore, you have complete flexibility to define your own items in the tree and these items can be representative of your own business logic).
So, let’s take an oversimplified example:

We want to send an Alert to a Web site visitor
The Alert should only be sent to someone who visits a News story (an item based on the News Article Data Template)
The Alert should only be sent on a particular day of the week, and a content author should be able to pick the day
The Alert should use an editable field of the News story as the message

Let’s look at the rules we have by default to start putting together the Conditions that will trigger this alert. If we scroll down to the bottom of the Rule Set Editor (you get here by clicking Edit Rule in the Marketing Center when you’re working with an item based on a Rule template), we see the “Common” conditions:

(You won’t see “where today is a specific day of the week”…that’s the one we’ll add). You will see “where item has specific template”. Great. That takes care of 1/2 of the condition. Let’s investigate how this Common condition came to be.

Under System—>Settings—>Rules—>Common—>Conditions, we find this When Template Rule. We see that the Class called (Type) is included in the 6.1 Kernel. We know from other extensibility exercises (adding functionality to UI events, workflow, validation, etc.) that calling our own Class and business logic is very easily done. For now, let’s look at the Text field of the existing Condition.
where item has [templateid, Tree, root=/sitecore/templates, specific] template.
Here is how the Rule will look when I add it in the Marketing Center:

Notice that the word where was automatically changed to a hyperlink. Clicking this in the Rule Set Editor will automatically reverse the condition to except where. The Rule Set Editor will do this for where, when and if clauses. The other link is the word specific which appears until we have chosen a specific Data Template to use for this Condition. From the original Text field above, the 4 parameters are as follows:

templateid is the name of the property that will be set in the .NET Class (Sitecore.Rules.Conditions.WhenTemplateIs)
Tree is the name of a Macro that will be run in the UI. Tree is one of the preset Macros, and will invoke the Content tree window where we can select the Data Template
root=/sitecore/templates is the URL parameter sent to the UI invoked by the Tree macro and will become the source, or top level of the tree that we see as we are asked to select the Data Template

Technorati Tags:

specific is the text that is displayed before we select a value for this parameter (the Data Template)

Completing this part of the condition is easy…we simply select the News Article Data Template:

Now, the second part of the condition requires us to invoke some of our own business logic. We want to evaluate whether or not today is a certain day of the week, and we want the marketer setting the rule to be able to choose the day. Let’s make some simple content items that represent the days of the week to allow for this choice:

These items don’t need any fields…we’ll just use their names to evaluate the day of the week. Now we need to set up a new Condition definition:

From our discussion above, we can now see that these parameters in the Text field will invoke the Tree Macro and allow the Marketer to choose from the days of the week Items. The .NET Class (our new WhenDay Class) will have the itemid property set by this day of the week Item choice.
For the developers, let’s take a look at the new WhenDay class. It inherits from the Sitecore WhenCondition class to return a Boolean condition (whether or not today is the chosen day of the week). Notice the itemid property that is set by selecting the Item.

using Sitecore.Rules;
using Sitecore.Diagnostics;
using Sitecore.Data;
using Sitecore.Data.Items;
using Sitecore.Rules.Conditions;

namespace Examples
{
public class WhenDay<T> : WhenCondition<T> where T: RuleContext

{

private ID itemid;

public WhenDay()
{
this.itemid = ID.Null;

}

protected override bool Execute(T ruleContext)
{
Assert.ArgumentNotNull(ruleContext, "ruleContext");
Item item = ruleContext.Item;

if (item != null)
{
Item item2 = item.Database.GetItem(this.ItemId);
if (item2 == null)
{
return false;
}
if (System.DateTime.Today.DayOfWeek.ToString() == item2.Name)
{
return true;
}

}
return false;
}
// Properties
public ID ItemId
{
get
{
return this.itemid;
}
set
{
Assert.ArgumentNotNull(value, "value");
this.itemid = value;
}
}
}
}

Now we can finish our condition by adding the day of the week clause:

With the Condition completed, our Rule can be completed by calling out an Action to perform. You can see some of the default Actions we could perform here….hiding a rendering, setting a placeholder for a rendering, changing the Data Source for a rendering, etc. To simplify the example of invoking your own business rules, I simply created a class that sends a JavaScript Alert message to the visitor, using the Menu Tooltip field of the News Article as the message.

With the Action created, we can now complete our Rule, tying the Conditions of the News Article Data Template and the chosen day of the week to the Alert Action:

And the Marketer can add a quick Alert to the page he is responsible for:

An Example of using Edit Frames in Nicam

2009-11-09T11:17:00.002-05:00

For those of you that work with, or used to work with, 5.3 Green Dots Web Edit functionality, you might really appreciate the ease with which you can create contextual editing menus. The 6.0 Page Editor (with all its significant usability features and improvements) might have left you questioning your ability to implement the same contextual functionality. Enter Edit Frames as of 6.1, a great new feature that should have you dreaming up some incredibly focused Page Editor-based contextual editing functionality.
John West, as always, has a great description of this functionality here.
For my discussion today, I wanted to show a couple of quick examples of where this could be used. As you know, Sitecore Data Templates promote the encapsulation of complex content types. Some fields in these Data Templates are presentation-driven (Short Description, Image), while others are meta-driven (Rating, Keywords, Category). The Content Editor interface shows all fields on both sides of this fence in a comprehensive, section-organized form view. In Page Editor, we get the very handy inline frame editing of all presented fields. But what about those meta-fields behind the scenes? Page Editor presents the “Blue Boxes” to split the screen and get to those fields behind the presented page.

Clicking on Edit the related item splits the screen and allows us to navigate the sections of fields that make up the News Article Data Template:

While this is intuitive and simple, we’re always striving to make this Page Editor experience as streamlined as possible. Instead of splitting the screen and having to find a field (within what could be a very complex Data Template), it would certainly be nice to define the field(s) that the editor would be most interested in getting to, and to simplify and focus the editing interface even more.
Edit Frames allow for just that. Let’s take this same example. We’re editing a News Article (Nicam Camera K200D) that has fields for Title, Short Description, Image, etc. Via the Online Marketing Suite, we article authors also want to tag this piece with the appropriate keywords that match up to our profile keys. Let’s build an Edit Frame around the article’s title that allows us to see the checklist of Keywords with which to tag this article.
First, we need to define the Buttons that will be part of our Edit Frame contextual menu. Sitecore provides a couple of handy default buttons (Insert and Edit). For today, we’ll simply use the default behavior of Edit Field, but for you developers, you can already imagine that any command functionality can be invoked here. The Buttons themselves are defined in the Core database (very much like the commands available to the Rich Text Editor).

Switching to the Core database and navigating to /sitecore/content/Applications/WebEdit/Edit Frame Buttons will show us all Edit Frame toolbars configured for the site.

The system is installed with the Default toolbar in place. If an Edit Frame does not specifically call out a Buttons property, the Default is used. Let’s copy the Default item, paste it under Edit Frame Buttons, and rename it Keywords.

If you select the newly renamed Keywords item, you’ll see that the Edit Frame toolbar has fields for a Title and Tooltip. Expand the Keywords item to reveal the default Buttons available to it. We’re using the Edit Button (you can delete this Insert button), and selecting it shows the fields available to the Field Editor Button template that it is based on.

The Fields field allows a pipe-separated list of fields that will become readily available to the Page Editor. For our example, we’re using only one:

Now, with the toolbar in place and configured, we simply need to add the Edit Frame to a presentation control. This Edit Frame can be added, of course, to a .NET or XSLT control. Since the news article already has a NewsItem xslt to present its fields, let’s add the frame there:

<xsl:template match="*" mode="main">
<sc:editFrame Buttons="/sitecore/content/Applications/WebEdit/Edit Frame Buttons/Keywords">
<h1>
<sc:text field="Title" select="." />
</h1>
</sc:editFrame>

Notice the Buttons property calls out the path in the Core database to the Keywords toolbar we set up. The <sc:editFrame> itself will present hover-over region including any HTML we wrap it with:

Clicking on the new Keywords (Default Title of the Keywords toolbar itself) drop-down shows us any buttons within the Toolbar.

And now we can easily edit the Keywords checklist field:

That’s all there is to it. This article simply covered the mechanics…now we can think through the many creative places where this technique makes sense to make the Page Editor even more powerful.

Some simple API code to insert Sitecore content items

2009-09-04T17:06:00.004-04:00

Derek Roberti, Sitecore Director of Technical Services, recently put together an excellent paper on a question we often discuss in various sales and technical services conversations: how are we going to integrate our external data with Sitecore? While Derek’s paper does a much better job at getting to the very important details around this subject, I’d like to create a snippet today that illustrates one simple and fundamental concept to matching up external data with Sitecore data templates.
I like to divide the discussion of integration of external data sources with the Sitecore content tree into the various "buckets" these integrations can fall into (there are more).

Presentation level integration, where standard controls coordinate fields from the CMS item with data from external sources (Web Service calls, db queries, enterprise system APIs, etc). Often a key value (productID) allows the storage of descriptive, marketing-driven data in Sitecore, while allowing pricing and availability to remain the realm of the ERP system designed for its maintenance and accessibility. This integration doesn’t require any API method in Sitecore, since no data is moved into the CMS—after presentation, the link is no longer necessary.
Content editor level integration, where lists and other data stored in external systems are referenced by content editors as they maintain Sitecore CMS items. Custom editing interfaces, drop down and tree lists, etc. lookup values stored in external tables for the purposes of choosing values that will be stored in the CMS.
Data provider level integration, where permanent mappings exist between Sitecore data template fields and fields of an external system. Data continues to be maintained in its native system, while the Sitecore content tree exposes these data as native to Sitecore. Items take advantage of externally manageable fields of data while also taking advantage of native Sitecore functionality, validation, workflow, security and more.

Somewhere in the middle bullet (or maybe prevalent enough to be its own) is the simple need to map existing data to Data Template fields in the effort to create new Sitecore content items. This is certainly an important stage of many migration projects, where current enterprise content (whatever its current format or storage mechanism) needs to be mapped to the new and well-thought out Sitecore-enabled information architecture.
While this subject is an article in of itself, the effort can often be broken down to its main stages. The purpose of this snippet is not to belittle the complexity and importance of any of these stages—deciding on an efficient mapping between current information and Sitecore Data Templates deserves the appropriate amount of time, skill and effort. Instead, I wanted to end with a quick code sample that shows the stages quickly. This example simply takes in an XML node as a parameter (representing an external RSS Feed), parses the feed and maps a couple of its fields to our newly created Sitecore Data Template, inserting new items under the “News” section of the content tree.
The main stages:

Analyze current content, information, organization of data.
Create data template(s) in Sitecore to map current organization, taking advantage of Sitecore’s granular field types to encapsulate reusable components.
Identify the area of the content tree where this content will be inserted.
Map existing data to Data Template fields and create items under the appropriate parent.
Rinse and repeat.

private void CreateRssItems(XmlNode rssItem)
{
// login in as an admin User
using (new Sitecore.SecurityModel.SecurityDisabler())
{
// The ContentDatabase points to the Master database.
// This assumes that this code runs in the Sitecore client.

Item News = Sitecore.Context.Database.GetItem("/sitecore/content/Home/News");
if (News != null)
{

// add a new Item based on  the Document Template
string title = rssItem.SelectSingleNode("title").InnerText;
title = Regex.Replace(title, @"[\[\]?:\/*""<>|]", "");
string description = rssItem.SelectSingleNode("description").InnerText;

// optionally, you can do this by referring to the content tree path
// of the data template you will use to map fields
Sitecore.Data.Items.Item NewRssItem = 
News.Add(title, Sitecore.Context.Database.GetTemplate("{A18D8CDE-AD94-4F84-BB74-648B20FE739A}"));
if (NewRssItem != null)
{

// optionally, impersonate a user with appropriate security priveleges
using (new Sitecore.SecurityModel.SecurityDisabler())
{
using (new EditContext(NewRssItem))
{
NewRssItem.Fields["Title"].Value = title;
NewRssItem.Fields["Description"].Value = description;
NewRssItem.Fields["__Display Name"].Value = title; 
}

}
}

}

}

}

One of those custom Web Forms for Marketers actions

2009-09-04T16:31:00.003-04:00

I often have discussions with prospects and clients around the ease with which you can create custom submit actions for the Web Forms for Marketers module. I finally had the opportunity to go through the mechanics and jot down the steps.
Because of the great, simple, consistent Item paradigm in Sitecore, each of the actions used by the Web Forms for Marketers module are themselves part of the content tree:

I copied the Save to Database action, pasted it and renamed it to “Save to CRM”. We won’t implement anything like a CRM mapping today, but it sets up a good follow-up. For today, just the mechanics….set up the item in the tree to call out to a class that follows the interface set up for an action, get access to the names and values of the submitted form.
As with this same capability to our code from workflow actions, validation actions, etc., the WFFM action provides the same ability to call out our class:

Using .NET Reflector, I borrowed the implementation of the Send Mail action, stripped it down to just the code necessary to get access to the field names and values, and pasted it below:

using System;
using System.Web;
using Sitecore.Form.Core;
using Sitecore.Form.Submit;
using Sitecore.Form.Core.Client.Data.Submit;
using Sitecore.Data;

namespace NiCam.Classes.Mike
{
  public class SaveToCRM : ISubmit
  {

    public virtual void Submit(ID formid, AdaptedResultList fields)
    {
       foreach (Sitecore.Form.Core.Controls.Data.AdaptedControlResult formField in fields)
       {
          string fieldName = formField.FieldName;
          string fieldValue = formField.Value;
       }

     }

   }
}

This action will now be available to the Web Forms for Marketers UI drop down.

A simple XML Device Presentation Layer

2009-08-24T16:32:00.000-04:00

At Sitecore we often talk about the many uses of the Device concept. Sometimes this is obvious (a mobile device requesting content vs. a browser requesting content will expect some particulars around the HTML sent to it). Sometimes it is a bit more subtle (Internet Explorer and Firefox continue to disagree about something, so I have a control that implements a method or CSS class a bit differently based on the detection of the browser). One of the situations we often talk about is the ease of availability of an XML representation of each content item in the content tree. This conversation often centers around integration points, where I can send an XSLT-translated XML document based on Sitecore content to an external application or Web service.

I wanted to prove in a quick concept--creating a Device presentation layer that shows an XML document based on the requested content item. I took the easy way out in many areas of this, and I welcome real world "yeah, but this is actually how you should do it" wherever appropriate.

Basically, I started by creating the Device in Sitecore. I called it XML and added it to the Devices in the content tree.

The new XML device is defined by any URL with xml=1 included in the query string. To keep things simple, I created a new Layout (.aspx) file to handle requests from the XML device. The Layout has a statically placed control (RenderXML.ascx) that does the work of:

Creating an XML document out of the fields of the Sitecore context item (the currently requested item from the content tree)
Transfer the request (Server.Transfer) to the newly created XML document (allowing the browser's CSS for XML files to format the display).

The code that does this, in the Page_Load event within RenderXML.ascs.cs, is shown below:

protected voidPage_Load(objectsender, EventArgs e)
        {
            Sitecore.Data.Items.ItemthisItem = Sitecore.Context.Item;
            XmlTextWriter writer = newXmlTextWriter(Server.MapPath("/layouts/dynamic/XmlDevice.xml"),System.Text.Encoding.UTF8);
            writer.WriteStartDocument();
            writer.WriteStartElement("item");
            writer.WriteAttributeString("name", thisItem.Name);

             foreach(Sitecore.Data.Fields.Fieldfld inthisItem.Fields)
            {
                    writer.WriteStartElement("field");
                    writer.WriteAttributeString("name", fld.Name);
                    writer.WriteAttributeString("value", fld.Value);
                    writer.WriteEndElement();
            }

            writer.WriteEndElement();
            writer.WriteEndDocument();
            writer.Close();
            Server.Transfer("/layouts/dynamic/XMLDevice.xml");
        }

Height of Rich Text Fields in Content Editor

2009-08-24T12:15:00.001-04:00

A short one for the Sitecore Admins out there. Question came up recently, "How do I make one of the Rich Text fields take up less screen real estate in Content Editor?"

Note the Long Description field below:

If you are choose to see Standard Fields (View-->Standard Fields), you'll be able to see the Appearance section of the template field. In this case, I expanded the node for my template and found the Long Description field. In the Long Description, I added the following to the Style field:

height: 20px;

Now the field in Content Editor takes up only the 20px height:

Starting Out

2009-08-21T09:39:00.003-04:00

"It is content, or rather the consciousness of content, that fills the void. But the mere presence of content is not enough. It is style that gives content the capacity to absorb us, to move us; it is style that makes us care." --Tom Robbins, Another Roadside Attraction

A quick note about, well, what this is about. I want to capture (thoughts captured as blogs, blogs captured as more in-depth articles, more in-depth articles captured as--who knows?) an appreciation for the collaboration necessary in choosing and implementing a content management solution. This is of course true for all great software projects. This is of course true for all great projects. But with content management software projects, this collaboration seems to have a head start.

It seems like everyone is at the table early on--project managers, marketers, champions, network administrators, developers. The goal is (at least in comparison to many failed projects in the past) clear--let's create a Web presence that means something, that reacts to my visitor, that learns from that visitor to enable the system to grow on its own, guided in its growth by agreed upon business rules. Let everyone's voice be heard--quickly, efficiently, without departmental roadblocks shriveling ideas on the vine. At the same time, let me ensure our company voice is succinct and targeted, consistent and powerful. OK, clear goals...but aggressive too. This will require everyone's attention.

Developers will have to loosen the reins a bit, face the fears of a user community gone mad with the sweet taste of flexibility. Marketers will have to wield their new-found control with an architect's respect for foundations. Project managers will have to define communications workflows to keep the arrow pointing up and to the right. That's why you're all sitting at the table now....you're looking for the right tool to help you in this adventure.

Content Management is not new to you. You have lots of content--it's sprawling all over your site right now, failing to report back to you its conversations. Content Management isn't new to me either. Actually, technically it is. I've only recently starting working in this exciting and growing area of software. But I've understood the need for great conversations among great people seeking great goals for a while now. I've had well over a decade of managing software projects from all corners of the table. Now I've been given the privilege of working with what I consider to be the best tool for this job--Sitecore.

I will use this forum to relay the conversations I hear as groups like you make this very important decision to bring in an enterprise-level content management system. Depending on the day, I will dive into the technical and business considerations that are so important to this decision. I welcome your feedback and I appreciate your joining in this learning process.