Should we upgrade to Sitecore 6.5?

This is a question we’re getting asked a lot these days, clients have been hearing about all the new fandangled features and want to know if an upgrade’s really worth it for their business or organisation. I’d say if you’re on anything less that Sitecore version 6.0 then definitely yes but if you’re on versions 6.0 to 6.4 I think the benefits may give you the answer.

The key benefits are the returns on investment that can be achieved with the new Customer Engagement Platform (CEP) incorporating the Digital Marketing System (DMS). These allow  you to analyse your site’s traffic in real-time and deliver targeted content to them to ensure they get the most value from a visit to your website.  The CEP effectively listens to your users and then reacts to them by serving up the most relevant content.

Here’s a real-life scenario based on my experience as someone who scans websites quickly to find information (especially at lunchtime when time is short):

A typical web search of mine (I want to buy some Wahl hair clippers like my barber uses):

• I search Google for “Wahl Hair Clippers”
• Scan results for relevant answers (is it just me or is Google showing me more results from outside the UK these days?)
• Right click on the relevant results links and open them in a new tab for ease of flicking through them
• Flick through each tab and discard the annoying ones that a) make it hard to find the relevant content b) are obviously built for SEO or worst of all c) splash pages
• I have a read of any relevant content on the sites that aren’t annoying
• I go off on a journey of discovery where I learn about different types of clippers, prices, reviews etc
• Decide on the clippers I now want, Wahl Super Taper Hair Clippers (which I highly recommend by the way)
• I buy them

Now there’s a plethora of things that effect my decision; design, usability, speed, time, content etc but to me, in this scenario, content is the key engagement factor…  I know what I want to find out about and I want to find it quickly. And before I get phone calls from our partners saying “how dare you say that usability/design are not the key engagers…” of course they are as well but I’m working on the premise that content is Queen here.

So could the new features of Sitecore 6.5 play a part here? Definitely, an engaging site would realise I’m coming from Google and realise that I know the brand (but I haven’t typed in a model) and react to that. Imagine if I arrived at a page that showed me all the models, their key features, had a model selector (e.g. faceted search), comparison facility, showed reviews of the popular models and an easy yet reassuring route to purchase. Sitecore’s DMS would know that I’m an undecided user and therefore deliver me personalised and relevant content to inform me and helps me make a decision, ultimately buying the product that I want. How happy would I be! And I’ve got most of my lunchtime left too!

Assuming that I buy from the site the personalisation doesn’t stop there, in 6 months time I’m going to need some more clipper oil. The DMS email campaign manager would have a rule set up saying “Mark bought some Wahl clippers 6 months ago, send him that pre-written post-sales email about the clipper oil we have in stock and contains the current prices”. I’m happy again and loving this company that still thinks about me. Who knows they may even email me in two years time to offer me new clipper blades.

Setting up the DMS doesn’t happen by magic and it does take time and investment to meet your businesses goals . To make your website incredibly relevant to a user by listening to them as they’re clicking around then react requires the setting up of the rules based system to surface that relevancy. That investment in Sitecore 6.5 will increase online conversions with real-time targeting and put you a good few step ahead of the competition.

To summarise:
This is just a minuscule element of what the new Customer Engagement Platform and Digital Marketing Suite can do and I’ll be writing about more about its features and benefits in the near future. An upgrade to Sitecore 6.5 will move your website onto the path from a basic level to highly engaged user level. Users who are engaged and have a personalised experience with you are more likely to convert, whatever you measure a conversion to be.

If you, or someone you know, has been affected by any of the issues above and want to talk to someone about it, feel free to call me, Mark Collins on 01179 32 77 00.

Organising Your Backlog

As a Product Owner one of my key responsibilities is ensuring that backlog items are worked on in the correct priority order. This is far more difficult than it sounds, as most clients have priorities that rapidly change along with the needs of the business. To help deal with this, I have always used the Kano Model as a guide for helping clients understand what priority should be given to an item of functionality.

The Kano model essentially breaks down requirements into three sections; ‘must haves’, ‘should haves’ and ‘could haves’.

‘Must have’ requirements

These are requirements that must be in place for clients to be able to use the product at its most basic level. For example if we were building a word processer, the ability to save or print work might be considered ‘must have’ functionality. Without these basic requirements, the project will not achieve the base level of acceptance by clients and will not be used by them, regardless of how many ‘should’ or ‘could have’ requirements are added.

‘Should have’ requirements

These requirements provide additional client satisfaction proportional to the amount of functionality added. Put simply, the more ‘should have’ requirements there are the more satisfied the client will be. With these requirements, there is a neutral satisfaction point prior to which clients will not be satisfied. This point will vary from product to product and is the average expected level for the product. Using our example of the word processor, it can be considered that changing font size and type or adding images to a document are examples of ‘should have’ requirements.

‘Could have’ requirements

Once a product has satisfied the must have requirements and sufficient ‘should have’ requirements to satisfy clients, attentions can be turned to requirements that ‘could’ be added to the product. These are traditionally requirements that set the product or service apart from the competition and are where most innovation lies. They add the ‘ooo’ factor to a product. Drag and drop functionality could be considered a recent ‘could have’ requirement.

A note of warning; as time passes, functionality will move from the ‘could have’ pot into the ‘should have’ pot and then from the ‘should have’ pot into the ‘must have’ pot. For example, a spell checker would once have been an exciting, innovative, ‘could have’ requirement. Nowadays it would be considered as a must have for any word processing product.

Take clients through the backlog

By taking clients through the backlog and putting stories into these groups, it is far easier to prioritise important functionality over and above work that may not affect the success of a project. Some clients may struggle at first to break stories down into these groups (“but it’s all necessary!”). When going through this process, I tend to use a tried and tested (also extreme) formula; whenever a client is unsure where a story should sit in the backlog, I ask;

“If the team were to be killed in a car crash/ hit by a meteor, drowned by a tidal wave (pick your favourite) at THIS point in time (specify a point in the backlog), would the product be in the best position possible?”

If not, reorganise the backlog as required.

This process should be repeated every so often (more often for those backlogs that change regularly) to ensure that the backlog is still appropriately prioritised. Hopefully, you will find that you work on the important tasks first and leave those sudden whims of the client until later in the project. This way, if you do run out of budget or time, the product will be in the best shape possible.

Ahead of the Curve – Drawing Quadratic Curves using Bing Maps

In recent months at True Clarity we have been working on a complex project, involving the integration of Bing Maps and Sitecore. One challenge we had to overcome as part of this required drawing nicely curved lines between two points, which sadly is not an “out-of-the-box” feature of Bing Maps.  So, with a little judicious research into how others in the development community had approached it, this is what we came up with:

The core code used to produce these curves is a simple method that returns an array of Location objects (which is available as a default Bing Maps Datatype); these location objects are then used to create a Polyline (again a Bing Maps Datatype); this can then be added to a layer and after that Bing maps will handle all the rendering.

This method allows you to specify the number of segments you wish the Polyline to be made up from (as ever, there is a trade-off where more segments gives a smoother curve, but more processing is required in the browser), as well as a factor that is used to adjust the curvature of the line.  The latter allows control over how “curvy” or “straight” the line looks, which can vary by your project’s requirements.  You must also specify the start and end points of the line as Location Objects.

// Creates Quadratic Curve approximation of the lines drawn between an array
// of points, by dividing each line into a number of segments.
function ToQuadratic(lineStart, lineEnd, n, factor)
{
if (!n) { n = 32 }; // The number of line segments to use
var locs = new Array();
with (Math)
{
var startLat = lineStart.latitude;
var startLong = lineStart.longitude;
var endLat = lineEnd.latitude;
var endLong = lineEnd.longitude;

if (!factor) { factor = 5 }; //potentially factor this inversely based on distance covered as amount of curve will increase exponentially as is

for (var k = 0; k <= n; k++)
{
var percent = (k / n);
var zeroOffset = (endLong - startLong) / factor;
var peakOffset = zeroOffset / 2;
var dist = (zeroOffset * percent) - zeroOffset;

// calc segments of straight line
var latitude = ((endLat - startLat) * percent) + startLat;
var longitude = ((endLong - startLong) * percent) + startLong;

//transform the line to add the curve, based on a quadratic -(X+(b))^2+b^2
//transform x and y sep
var latitudeDifference = -pow(dist + peakOffset, 2) + pow(peakOffset, 2);
latitude = latitudeDifference + latitude;

zeroOffset = (endLat - startLat) / factor;
peakOffset = zeroOffset / 2;
dist = (zeroOffset * percent) - zeroOffset;

//we transform x and y sep
var longitudeDifference = -pow(dist + peakOffset, 2) + pow(peakOffset, 2);

//ensure Curves correct way if going left or right the map
if (startLong < endLong)
{
longitude = longitudeDifference + longitude;
}
else
{
longitude = longitude - longitudeDifference;
}

var p = new Microsoft.Maps.Location(latitude, longitude);
// Add this to the array
locs.push(p);
}

}
return locs;
}

To use this code, you would simply call the method above and create a Polyline from the results, then push this to a layer of your map, as follows:

var geodesicLocs = ToQuadratic(new Microsoft.Maps.Location(origin.lat,origin.long), new Microsoft.Maps.Location(destination.lat,destination.long), 16, 5);
var geodesicShape = new Microsoft.Maps.Polyline(geodesicLocs);
mapContext.geodesicLayer.push(geodesicShape);

And the results are beautiful curves across the map.  Of course, if there are a large number of such curves to draw, or you choose to use a large number of intermediate points, then this will bring performance issues into the equation, but the basic mechanics of producing the curves is now done.

How an Agile environment can make testing more effective

As a tester I take great pride in knowing the work I do contributes to a client getting what they want. Yes you heard that right WHAT A CLIENT WANTS! Not what a long drawn out technical specification tells me they want, but actually what they want and need from their product. Is it really that hard to ask a client this simple question?

As a tester in a waterfall environment one of the most laborious and soul destroying tasks was writing the dreaded test script! Spending hours trawling through huge technical specifications and planning test routes, picking out holes in requirements, then spending days on end writing the script only to find you have to constantly have to re-write and update it. Then you still have to run all the tests! With all of this to do and deadlines looming you can see how QA always appears as a bottleneck in the development lifecycle.

“One small change” in a product can mean hours of re-work for something that is fundamentally quite small. In a waterfall environment the word “Change” sends shivers down a tester’s spine and is always met with resistance with the usual comeback of “That’s not what the spec says” as the tester knows this “One small change” always leads to huge amounts of work, updating scripts and regression testing. Why are testers so adverse to change as we are here to make sure the client gets what they want?

The reason behind this is we don’t like wasting our time as we always have deadline pressures being last in the chain. So how can a tester be more efficient and respond to change easily and ensure your client is happy? It’s pretty obvious that the easier it is to adapt to change and the more time testers spend actually testing the product, the better the quality of the product. The better quality product that meets the expectations of the client leads to you guessed it…… happier clients. So how can testers spend more time testing and adapting to change without missing deadlines? Be Agile and Innovative!

Ask yourself “WHAT IS MORE VALUABLE TO THE CUSTOMER?”, a product that has been thoroughly tested in all manner of scenarios and provides the customer with the functionality they require or a product that has been tested following a rigid test plan but does not fit the requirements of the user because you have not been able to adapt to changes that they require?

So how does an Agile approach help testers be more adaptive to change? Agile has provided a great platform for testers by providing them with a constant workflow of iterative chunks, these chunks can be thoroughly tested in isolation quickly and efficiently. Using an Agile approach, continuous feedback allows us to test little and often, making change simple and cost effective. By the time the work goes to UAT for final acceptance with the customer, most feedback has already been dealt with which mostly results in a simple confirmation of acceptance criteria. This provides QA a real opportunity to understand early on in the project the client needs and expectations and build a valuable relationship with the client which is crucial to the success of a project.

Using tools within an Agile environment to be more efficient is an excellent way to increase the team’s effectiveness and reduce the “QA bottleneck”. By working smarter you can relieve the test script burden. I am not saying you have to abandon test scripts they do have value in their own right as they provide anyone who cares to read them an insight into how the product should work and provide detailed information on legacy products, but you can be smart with how you document! For example creating automated test scripts that cover your essential tests provides anyone an insight into how the product should behave, but this script has more merit than a standard manual test script. So how does this magical time saving test script get created so quickly and easily? Adding automated tests to your script is not a long and boring task as it can be recorded whilst you are testing a new iterative chunk of functionality, as each iterative chunk is delivered to QA your script keeps evolving as each iteration passes until you have a fully automated regression script! Finally a document that actually helps people rather than hinders!

These simple changes make the life of a tester much more productive, reduces waste of resource by not having to sit around waiting for builds! It also provides better overall quality and happier clients. Not to mention make the life of a tester much more enjoyable and less stressful.