Friday 30 March 2007

It was only a small fire....

Prevention is better than cure

We all know the power of effective communications in business. Conversely poor communications can have equally large impact but in a negative sense. Consider a scene that was played out some twenty plus years ago. My elder brother and I had reached a trustworthy [and legal] age where we could be left in charge of our parents house for a week while they took a hard earned first holiday alone. My heroic brother took the phone call from Mum when she landed at East Midlands airport on returning to ‘Good ‘ol Blighty’. Now, consider the crucial detail here – we were responsible enough to look after home for a week but still were incredibly naive in certain matters. I had caused the toaster to emit some minor wisps of what could have been described as ‘smoke’ during the week…I propelled the toaster to a safe spot in the garden to ‘chill out’ and all was well. I’m not just trivialising the sorry tale through guilt – it really was minor, honest!!! So, this was communicated to Mum over the phone. Three points to look for in terms of the ensuing communication:

• Wrong time
• Wrong place
• Wrong information

Well, wrong may not be the word – too much information may be. Anyway, enough digression and diversion, my brothers [far from] wise and [far from] learned opening gambit was to render those fateful words ‘Don’t worry Mum, it was only a small fire’. ‘FIRE! FIRE! FIRE!’ screams Mum down the phone in a packed airport terminal with obvious consequences…You can picture the scene – I’ll just keep cringing.

What’s the moral here? My sibling and I considered the incident (outage, you might say) as being hardly worthy of mention. On reflection, we were pleased with how we had handled it! In actual fact, the really important person (dearest Mother in this case but it could be a valued customer) in the transaction (verbal in this case but it could apply to the economic variety) considered it to be quite a major incident and we should have realised this from the start.

Don’t read me wrong here – I am not suggesting that burying the truth when things go pear shaped is the correct course of action. If things go wrong – see them as users do – MORE IMPORTANT THAN THE END OF THE WORLD.

This article is not about ‘solving’ the end of the world though – I’m going to help you prevent it.

I am going to describe common experiences with hosting partners, flaky backend systems and unacceptable behaviours on websites. I am going to introduce the idea of graceful degradation through intelligently designed systems that are built to withstand ‘issues’, that are aware of ‘issues’ and how to maintain a good level of service. I will lead on to the value of testing internally – users don’t do testing you know... I am going to advocate the use of strong procedures for configuration management and version control so that deployment does not become another project – it’s just a part of the current one isn’t it?

You will see how time and money can be saved, risk reduced, customer trust grows and most importantly users aren’t shouting ‘FIRE!’ in crowded public places.

Monday 19 March 2007

Final Agile installment

Leverage the full power of Agile and agile technology

Now, the feature differences we can see between the two examples are fairly significant even though functionality is equivalent. Investment is obviously required in order to address the legacy issues we may encounter with our existing pages – there are skills to learn and pages to rebuild but this investment can be repaid quickly.

Given the enhanced flexibility our rebuilt site affords us we can now embark on an Agile driven enhancement programme on our site. Fully adopting an Agile approach to site enhancements means the designers can sit with the marketing department and work through textual and structural changes, introduce new images, change colours and test these changes on a range of clients (browsers and devices) in real time. The real power of face to face communication during this phase has to be experienced but should be self evident.

Testing

Eventually Rudi has to commit to a change – or set of changes. Being able to offer a number of options to users via A/B split testing or multivariate testing is facilitated through the new site implementation techniques. As you can see from the examples we can adjust the position, shape and size of content areas easily and quickly. The content within a content area can change completely under the control of business rules. Users experiencing these changes have their sessions tracked. Through analysis of this data, final versions can be seen to increase sales conversion, reduce basket drop outs or enhance navigation effectiveness through evidence based decision making. Rudiger is gleaming with happiness at this point – he can make informed, rapid, easy, repeatable and safe changes.

Conclusion

The power of the Agile process coupled with an agile framework can be seen from the simple examples above. You should see the business benefits that can be derived from the features that have been discussed and demonstrated. This trivial example is used as a simple clear vehicle for the Agile/agile technology message but the principles scale tremendously well. In adopting these ideas and applying them to pages on your website, the whole site, a new project and your business as a whole you will be able to demonstrate through hard data a clear positive economic impact.

So, to summarise we will see how Rudi can address each of the ten issues highlighted for his simple example using agile technology:

Intellectual property ownership

Rudi can now rightfully claim ownership of his content. He can access the content because he knows where to find it and it makes sense. The site now lends itself to change whereas before it was actually a hinderance.

Accountability

Rudiger is now fully in control and can justify changes based on accurate Key Performance Indicators to the marketing department, his shareholders and himself.

Resource skills

You don’t need to be a rocket scientist to write copy for your website. Those with the marketing skills market your products. Rudiger can accept the marketing teams input and act on it through his website.

Information

Communication is improved through use of the Agile methodology. Changes are made based on an informed consensus between Rudiger, the marketing folk and shareholders. Testing verifies the effectiveness of changes so all parties are happily glowing rather than rowing.

Process bloat

Really, Rudi do you need three sign-offs any more? No! The red tape is reduced as is risk. A happy cause and effect that makes Rudis life easier and costs reduce.

Systems complexity

Significantly reduced – just look at the example HTML. Rudi may have been on the verge of wastefully hiring a new designer/HTML/Code guru at great cost just to make website changes. He knew that was going to be a bad move and now doesn’t have to.

Legacy issues - Removed.
Time and Cost - Reduced.
Accessibility - Rudi can get his hands on the content he wants as can disabled users and search engines.

To draw our fictional aspect to a close, the sum of the parts of Rudis solution made more of a difference to his business than taking the methodology and technology in isolation. Moneyspyder takes a holistic approach to business problems and associated solutions. Rather than waiting for the research to drop in to your inbox, as thought leaders in all aspects of e-commerce website implementation Moneyspyder proactively seeks out the answers. If they don’t exist, we’ll extend the field. If you have similar issues to Rudi, get in touch.

Thursday 15 March 2007

Some Agile meat to get your teeth into

Let us continue in our exploration of Agile...

Best-Practice Page Implementation

Best-practice is a term oft used in many technology circles to describe what should be but frequently isn’t. We will use best practice as the banner for our much improved approach to building e-commerce websites to describe what can and will be. What we mean in essence by best practice is adhering to current and correct site implementation standards: now and forever amen brother Rudi.

The importance of standards

What standards are we talking about?

• Correct use of external Cascading Style Sheets
• Correct use of external java-script assets
• Not using tables for describing content
o The W3C, in its Web Content Accessibility Guidelines, explicitly says “do not use tables for layout...”
• Correct use of image assets
• XHTML compliant mark-up
• Level 1 CSS compliance
• Semantic coding

Standards compliance means the consumers of our sites – not necessarily users but the technology that our users use to visit our sites – have an easier and therefore guaranteed better user experience, ensuring good longevity for our sites, simplicity and therefore reduced time to market and lowered cost of production

Complying with current best practice means we can build websites according to published standards without having to explicitly cater for the lowest common denominator. This takes a lot of the ‘think’ out of site implementation meaning we can build websites that:

• will not suffer as they are adjusted
• will encourage reuse
• embrace change
• are as simple
• are lean
• degrade gracefully

See how ‘lean’ and ‘simple’ address the issue of complexity as mentioned above in our ‘list of ten’? Not degrading through adjustment and encouraging reuse address one aspect of accessibility. By this I mean if one designer builds a page, Rudi can take on the responsibility without weighty tomes of documentation to support the beast. Thus, we can reduce the level of skill required to maintain pages on our sites.

Now would be a good time to demonstrate what we mean. Consider the two HTML examples below. One uses ‘old style’ table layout, inline style where the other uses standards compliant mark-up:

Retro old school style

<table cellspacing="0" width="700" cellpadding="10" align="center"><tr><td colspan="3" bgcolor="#000033" align="center"><font size="4" color="#ffffff"><b>This is a typical 3 column table layout</b></font></td>
</tr>
<tr>
<td width="105" bgcolor="#003366" valign="top" align="left">
<font size="3" color="#ffffff"><b>left menu</b></font><br><br>
  <a href="css-1-column-layout.html">1 column layout</a><br>
  <a href="css-2-column-layout.html">2 column layout</a><br>
  <a href="css-faux-columns.html">3 column layout</a><br>
</td>
<td align="left">content area<br><br>
This page is simply a visualization of a table layout and another similar layout using CSS. This part is layed out without any css. It is all table cells and font tags. Click on the links in the left menu to view actual CSS layouts.
</td>
<td width="105" bgcolor="#003366" valign="top">
<font size="3" color="#ffffff">right sidebar</font>
</td>
</tr>
<tr>
<td colspan="3" align="center" bgcolor="#006699">
<font color="#ffffff"><b>footer - usually contains a text menu</b></font>
</td>
</tr>
</table>


Standards compliant goodness


<link rel="stylesheet" type="text/css" href="style.css" />
<div id="layoutdemo">
<div id="header">
<br />this is the same layout using css without a table
</div>

<div id="leftmenu">left menu<br /><br />
  <a href="css-1-column-layout.html">1 column layout</a><br />
  <a href="css-2-column-layout.html">2 column layout</a><br />
  <a href="css-faux-columns.html">3 column layout</a><br />
</div>
<div id="contentarea">
<br />
content area
<br />
<p>All of the layout for this portion of the page is made using css. Although this looks like the table layout above, it is layed out with divs.</p>
<p>The main benefit with using css is the ease with which you can make changes to the site. If you wanted to add a second footer to every page on the site. For instance, an "add this site to your favorites" could be added by modifying one file. With a table layout you would have to change every single page on the site or use server side includes (SSI).</p>
</div>
<div id="rightsidebar">right sidebar</div>
<div id="footer">
<br />footer - usually contains a text menu
</div>



Page Weight

The first thing to consider is the size of each HTML segment. We can see that the standards compliant HTML is a fair bit smaller than the ‘old school’ example but when one takes into account the size of the style sheet, the standards compliant model seems to look poor in comparison(1.11Kb for old school vs 3.39Kb for the ‘great’ new standards). Not so fast! Our sites (hopefully) exhibit some degree of consistency in terms of layout and style. This means we can reuse our style sheet again and again. Now, browsers will only request the style sheet once – when they don’t have it. Subsequent requests will reuse the cached copy. This well documented behaviour represents the weight saving we are looking for. The study by Akamai Technologies and JupiterResearch that Rudi was excited to receive suggests that an average online shopper will only wait four seconds for a page to download before leaving in favour of a faster site. Indeed, site speed is second only to price in terms of repelling users. Jupiter suggests the following guidelines:

• The consequences for an online retailer whose site underperforms include diminished goodwill, negative brand perception and, most importantly, significant loss in overall sales.
• Online shopper loyalty is contingent upon quick page loading, especially for high-spending shoppers and people with more online shopping experience.
• JupiterResearch recommends that retailers make every effort to keep page rendering to no longer than four seconds.

With respect to our trivial example, saving a few Kb on such a small page seems like lots of effort for minimal return. Moneyspyder has consistently demonstrated a 50% saving in page weight to clients by adopting best practice implementation and standards compliance. Every 5Kb saved roughly equates to 1 second of download time on a 56K modem – easy savings. What if most of your users use broadband? Well, even if you are absolutely sure of your analytics data you have to ask why Google insists on such a light homepage – 13Kb. Surely there is something to page weight after all?

Robustness

We are starting to see some degree of agility already…let’s demonstrate some robustness. We can demonstrate the fragility of the use of tables by clumsy editing/inserting/deleting of table elements. See what happens when clumsy Rudi drops in a table row tag
<tr>
in the middle of the main section copy – oops! Ctrl-Z, quick Rudiger!

Trying this with the standards compliant demo has no effect. Now we have strength and some great new agile concepts at our finger tips and we’ve only just scratched the surface!

Semantic Coding

Semantic coding is an approach to writing human and computer readable HTML. In essence, to write code to describe the content rather than code how the content should look. For example, the HTML below will render a page title correctly but there is nothing in the HTML to clearly identify the text as a page title for content managers, search engine spiders or browsers. The end result may appear fine to the end user but meaning and clarity have diminished for other consumers:

<font size="6"><b>This is the page title</b></font>


In comparison, humans as well as computers can understand that this is a page title. The authors intentions are clearer to all given the universal knowledge that the use of the
<h1>
tag implies ‘page title-ness’:

<h1>This is a heading</h1>


So, adding fuel to our already raging fire of compliant goodness we have further reduced complexity, code bloat and having increased the clarity of the HTML we have significantly reduced the level of skill required to understand what the site does.

Repurpose Content

Significant effort is typically required to reposition or repurpose tabulated content. This ‘feature’ becomes more burdensome with every new level of tables that are introduced. Extraction of the right content section without impacting the overall page structure and reintroducing elsewhere, again without breaking the page layout can be arcane at best. Reliance on the style sheet to position content sections goes a long way to reducing the content obfuscation problem. The examples here are not illustrative of this point – way too simple. An indicative example of the level of tabular complexity that can easily be achieved can be seen on www.dell.co.uk. Using simple tools in Firefox, you can highlight the tables and the depth to which tables are nested. In comparison, the BBC homepage, whilst not perfect is very light on table usage. Go ahead, try it!

A third example amply demonstrates the ideal – http://www.moneyspyder.co.uk uses no tables. All content is easily extractable, reusable and can be repositioned with relative ease. Want to move your search box from top left to top right Rudi? With the right page implementation – no problem. Do it the old way and you could have a significant project on your hands – needlessly.

Revisit Process

With the risk associated with site changes mitigated to a large extent it is wholly appropriate to reconsider our bullet proof, belt and braces sign off process. As long as our CMS restricts the extent to which changes can be made to those areas that are appropriate then we have another item ticked. That list keeps on shrinking with these exciting techniques, Rudi’s getting closer to a solution but we can’t quite shake off those exclamation marks!

Accessibility

Leanness, simplicity and accessibility have other positive properties that cannot be ignored. Content that is simple to access and understand benefits users regardless of what tool they use to access your site. If content can be presented in a usable format to Internet Explorer, Firefox, a PDA, a screen reader or a search engine spider then all these users will have happy user experiences. This is another Good Thing!

Wednesday 14 March 2007

Continuing our Agile journey

Agile technology

Let’s consider Rudis simple scenario some more; one that we probably encounter on a daily basis: small, simple changes to an e-commerce website. We’re not talking an entire redesign or launching promotional micro-sites here although the points listed below and the solutions discussed do scale rather nicely…

So, what are the primary issues that affect us and Rudi? I suggest this non-exhaustive list as a starter for ten (yes there are ten!):

• intellectual property ownership – Rudi: its my website damnit!
• accountability – Rudi: so let me own it!
• resource skills – Rudi: surely I don’t need to know all that technology to make changes?
• information – Rudi: I need to know what/why/how/who/if/where/when…….
• process bloat – Rudi: how many signoffs?
• systems complexity – Rudi: run that by me one more time please…!
• legacy issues – Rudi: I thought we got rid of the old system years ago – where’s John?
• cost – Rudi: but its just changing a few words on the footer!!!
• time – Rudi: why can’t it happen this month?!?
• accessibility – Rudi: just gimme access will ya!

As you have probably gleaned from earlier ramblings and additional material, Agile can go a long way to addressing a number of these points but it’s not the silver bullet on its own. We need to think about our technology platform: time to grasp the nettle that is our lifeblood my friends: let’s talk tech.

Fear not, I’ll make it an easy example: Rudi is making changes to the ‘front end’ of his site. This is the part of your site that your customers see and can be considered as most important in many respects. The front end is key to quality customer experience but also an area where business owners can make most difference without requiring heavy tech skills, process, technology or spending a small fortune every month.

How?

Good question Rudi! And I apologise for catching ‘exclamation mark-itis’. There is some ground work required first in terms of our understanding of why we have a less than ideal situation to begin with and then we can explore the agile technology solution that works so well with the Agile methodology.

Think Rudi and Reader – does any of this sound familiar? We have all been subject to products of the last internet bubble at some point in our professional lives. Meaning: we will have experienced the joys of (at least) five year old HTML that has been subject to numerous rewrites, updates and additions. The proverbial ‘woodsmans axe’ if you like…lets take a peek at what we are dealing with in reality.

Rudis first impression of this sweet little page may have been that it was lovingly crafted originally, looking superb and downloading in under a minute(!) with all the latest trends cleverly incorporated.

In actual fact, this sick puppy exhibits a nasty bite as soon as he takes a closer look under its tail. Simple changes are going to require a careful inspection of its internal workings. Rudi needs to be sure he doesn’t undo the last ‘n’ changes (where n is large) if he misses that vital closing table cell tag or Marketing will not be best pleased... he doesn’t even glance at the javascript pile steaming at the bottom of the kilometre long listing – it makes his eyes water.

I’m painting a dark, grim, cynical and pessimistic picture here but it may well be a familiar landscape that we gaze on every time we want to introduce a new promotion to our homepage. To start afresh, I shall guide you towards a relatively infrequently visited corner of the gallery that is our world of e-commerce.

Tuesday 6 March 2007

Agile continued

Today we continue our exploration of Agile...

The Agile manifesto

The principles of the Agile Manifesto refer specifically to software development; however we will consider the effects of trust, embracing change, motivation, empowerment, communication and delivery focus in the context of our e-commerce businesses and how they relate to our goals.

Welcome back! You just opened a new tab (or browser if you aren’t yet fully 2.0) and had a quick read of the manifesto didn’t you? If you didn’t - come back in five when you have done so - if you did, Well Done and on we go. You have seen that far from being a strict ‘Thou shall/shall not’ set of policies, the manifesto reads like a set of aspirations or goals. We can see how these principles relate to our own goals – not necessarily in a software project sense of course but the parallels are obvious, for example:

• Reducing risk
• Enhancing communications
• Reducing project delivery time

There are some interesting examples that are worthy of note that may not be in common usage:

• The self tuning team – review and act on past performance metrics
• Delivery as a measure of progress
• Constant/sustainable delivery as the goal – not peaks and troughs

Clearly the drive is towards repeatability and reuse implying, correctly that Agile engagements are heavily cyclical. Revisiting, revising and refactoring towards the desired outcome are key Agile concepts.

Can Agile save money?

Rudiger, the star of our introduction is of course concerned all about the bottom line: Cost reduction through use of Agile methodologies is a partly symptomatic of time saving which in turn is attributable to reduction in complexity of systems, bureaucracy and process. All Agile aims…

The Independent research that Rudi received earlier has measured the impact of adopting Agile methodologies on ThoughtWorks complex software projects:

• Reduced cost by 57 percent compared to other IT solutions for similar complex projects.
• Reduced effort by 62 percent compared to alternatives, including in-house development and previously employed consultants.
• Reduced critical defects by nearly 80 percent.
• Reduced overall defects by more than 60 percent.

Whilst reading the remainder of this article, bear in mind how business benefits for Rudiger and yourself can be derived from the other features described:

• Fewer defects reduces the number of test-fix cycles
• Clearer lines of communication mean important features are prioritised and dealt with accurately
• Embracing change is motivational and fuels innovation
• Closing the gap between business and technology people
• See working products with key features sooner
• Focus on quality
• Make testing easier and more accurate

...more next time folks

Sunday 4 March 2007

Agility: What it means to business and why it is a Good Thing.

Back in 2000 Bill Gates wrote ‘Business @ the speed of thought’. As described on the Microsoft website:

Business @ the Speed of Thought was written to inspire you to demand - and get - more from technology, enabling you and your company to respond faster to your customers, adapt to changing business demands, and prosper in the digital economy.

‘Imagine that!’ thought Rudiger, ‘My business being able to respond faster!’ he continued whilst over using exclamation marks… Rudi was in the process of trying to make some small changes to his website before the new season started – or so he thought. The pages were large and overly complex. Working with the marketing department was proving to be a ‘mare. Conversion was plummeting fast and no-one seemed to know why. Rudiger needed answers and actions but they had to be the right ones.

Two pieces of research seemed to point the way. Simultaneously landing in Rudi’s in-box were a Forrester paper on the economic impact of something called ‘Agile’ and a study by JupiterResearch and Akamai Technologies on the detrimental effect of page weight on customer attraction. ‘Could these be the answers?’ thought Rudi, for once avoiding an exclamation opportunity.

Well, the studies are real where poor Rudiger is fictional but he just might sound familiar. The two research papers might turn out to be the solution. Exploring the subject matter further, this series of posts explores a set of simple measures from methodology to technology that enable a wonderful trait known to the cognoscenti as ‘agility’. ‘Please fastbloke, can you explain agility in terms of my business?’ I hear Rudiger ask. Well Rudi, physical agility in humans and animals is defined on dictionary.com as ‘the power of moving quickly and easily; nimbleness’. The second definition (the ability to think and draw conclusions quickly; intellectual acuity) translates more appropriately into the world of e-commerce. Rudi (and you Dear Reader) will soon see how these qualities enable rapid change, enhanced flexibility equating to cost savings, reduced time to market and increased overall effectiveness of your business.

The Agile approach

Waterfall, RAD, RUP, Prince and DSDM are all well known approaches to projects. Let’s take the best bits from each and build a best of breed set of ideas, a framework, a set of guidelines. Let’s not constrain ourselves to rigid, heavyweight doctrine – after all, that’s what we are striving against isn’t it? Hey, rigidity and constraints impact our agility so let’s bring the fight to the fore and call our new approach ‘Agile’!

The thought process may have been different but the end result is what we want to discuss here: Agile is currently hot so let’s explore why and what it could offer to our businesses....next time!

Saturday 3 March 2007

On the road again

Ah, deep joyous aching legs. The weather is good, I am healthy and so I got to run today for the first time in three weeks. I won't post a time here 'cos it's just too embarrassing but I did a full 5k with no stops and a 1k warm down so not too bad.

Next week will be tricky to find the time to run as I have a lot of travel with work which means carting this behemoth of a laptop around...too much weight for running comfortably and after all, I do this for fun - not to get injured.

Fingers crossed, the two trips next week should really spell the big kick off for Moneyspyder and hopefully a third will come on line too.

Next weekend is going to be taken up by our first trip to Budapest this year to furnish our flat...no time for running but Hungarian food and beer means I really will need to run some after the trip ;-)

Happy, busy days!