Alson Kemp

You’ve probably heard of Six Sigma, the quality management philosophy/practice started at Motorola. Great way to identify problem areas of product design, development and production. Sets a goal of having 99.9997% efficiency in the product life cycle.

We have a fairly traditional SDLC process for our web site development and I’ve been thinking about what the “right” process is for our development efforts. While poking around, I’ve seen a few blog posts about applying six sigma to web marketing or software development.

Got me thinking: should 6 sigma be applied to web software development? Maybe 4 sigma would be better?

Really, do I want NetFlix to provide me with 99.9997% quality in their website? Well, they better handle credit cards with 99.9997% accuracy, but I would prefer that they provide very good quality on their website and focus on rolling out new and improved features. I wouldn’t be too irked if their recommendation engine got better and, in return, I saw an occasional visual flaw or 404. Considering that most web flaws are quickly spotted and easily fixed, it makes some sense to “release early, release often”: don’t overinvest in quality when fixing the issue costs little in terms of time, money or reputation, especially when the benefit of additional features to the user is great.

What about Microsoft Windows? Unlike a web application, I have to install this bit of software and, unlike a web application, it’s not easily updated.

So I’ll vote for Four Sigma quality levels on non-critical areas of consumer websites. 99.379% quality in features is pretty good and I won’t lose sleep over the 0.621% of features that have some issues… But we’ll commit to fix them ASAP.

Since I’ve used Ruby on Rails quite a bit in the past and since I’m now using ASP.NET, I often find myself doing comparisons between the two frameworks.  Recently, I found myself comparing Rails’ controllers/views and ASP.NET’s controls.  The following is an example of where ASP.NET’s declarative instantiation/configuration of controls worked well.  I’m not sure how I could do the same in Rails.

We had to insert Google Ad Manager code into a number of our web pages with varying numbers of ads on each page.  We really wanted to be able to declaratively configure the controls, so that inserting a <UserControl:GoogleAdManager /> tag or two or three into a page would correctly generate the Javascript to place the ads.  The Javascript for two slots looks something like this:

<script src="http://partner.googleadservices.com/gampad/google_service.js" type="text/javascript"></script>
<script type="text/javascript">
GS_googleAddAdSenseService("publisher-code");
GS_googleEnableAllServices();
</script>
<script type="text/javascript">
GA_googleAddSlot('publisher-code', 'slot1-code');
GA_googleAddSlot('publisher-code', 'slot2-code');
</script>
<script type="text/javascript">
GA_googleFetchAds();
</script>
 
<!-- Goes in the proper location -->
<script type="text/javascript">
GA_googleFillSlot("slot1-code");
</script>
 
<!-- Goes in the proper location -->
<script type="text/javascript">
GA_googleFillSlot("slot1-code");
</script>

Optimally, I’d like to generate that code by placing two controls in my markup:

  <UserControls:GoogleAdManager Slot="slot1" runat="server" />
  <... lots of HTML ... >
  <UserControls:GoogleAdManager Slot="slot2" runat="server" />

Doing this in Rails would be a bit difficult: we only know which ads are being included after we parse the page, but we only parse the page in order to render the page.  We’d really like to know which ads are on the page before we render the page.  In Rails, I think that we’d have to do this by creating an array of ads up in the controller and then rendering them in the View using a helper.  But now the controller is responsible for knowing which HTML elements should be on a page…  So maybe we’d drop all the logic down into Javascript and use Javascript’s implicit page load events to fire the right bits of code at the right time.  Neither of these is pretty.

The key to doing this in ASP.NET is ASP.NET’s page event model in which pages and control go through 3 or so phases before they’re actually rendered.  We wound up breaking the Javascript generation as follows.

In the Page_Load event for each control, we try to insert the following code. Of course, once one control has inserted (“this.Page.ClientScript.RegisterClientScriptInclude”) the javascript, the other control won’t insert it.

<script src="http://partner.googleadservices.com/gampad/google_service.js" type="text/javascript"></script>
<script type="text/javascript">
GS_googleAddAdSenseService("publisher-code");
GS_googleEnableAllServices();
</script>
<script type="text/javascript">

Then on PageLoad each control add its slot code. Control 1:

GA_googleAddSlot('publisher-code', 'slot1-code');

Control 2:

GA_googleAddSlot('publisher-code', 'slot2-code');

On PreRender, each control tries to add the following code to close off the previous script tag and to fetch the ads:

</script>
<script type="text/javascript">
GA_googleFetchAds();
</script>

Finally, each control renders its code into the div. Control 1:

<script type="text/javascript">
GA_googleFillSlot("slot2-code");
</script>

Control 2:

<script type="text/javascript">
GA_googleFillSlot("slot2-code");
</script>

Gotta dip down into C# a bit for the ASP.NET, but the pay-off is a simple declarative configuration of Google’s Ad Manager. I didn’t implement the functionality in Rails, but I suspect that it would be rather more complicated… ASP.NET wins this round… but I still miss Rails something fierce…

Note: this may have been what Rails’ components did. But they got canned.

Great post about the benefits of using AJAX to shrink a conversion funnel here.

Recently, we were working on a workflow within our site and and spent a bunch of time taking a 6-page funnel down to a pretty AJAXed 3-page funnel. Got it all tested, put it in production!, and …no effect on fallout in the funnel… But, wait, everyone knows that “making a workflow short and snappy will decrease fallout”, right?

The explanation we came up with when thinking about the lack of improvement was that we’d neglected to consider our user’s motivations & incentives when thinking about our funnel.

The funnel we were working on was a Submit A Review type funnel. We’re unusual in that we collect a lot of data from members in that funnel. We get big, comprehensive reviews from members. It takes 2-3 minutes to fill out our review form. Which is awesome for our other members because, when they’re trying to figure out with whom to spend $75,000 adding a room to their house, they get serious data on the possible contractors.

That said, it’s kinda hard on the member that’s submitting the data and the member knows that’s it’s going to be hard, so they only enter the funnel if they’re serious about completing it.  The hard work we did on simplifying the funnel made things easier on the highly-motivated members who were going to submit reports anyway. Great for the member; not so great for us (ROI ~= 0%).

Why are these members so highly motivated? Our guess is because their incentive to post a review is altruism. They had a great experience with a service provider or a horrible experience with a service provider and they want to let the other members know.  Posting a review gets them a bit of personal satisfaction.

Naturally, the number of members who are driven by altruism is pretty low. So if we want to get review submissions up, we need to add other incentives. The incentive hierarchy probably looks something like: altruism … reminder/call-to-action … community/reputation … chance-to-win-a-prize … $$$.  As we use other incentives to drive review submissions, the shorter, snapper funnel will help keep fallout low. So our work wasn’t for nought… Just maybe not for much right now…

Helpr, Inc is joining up with Angie’s List to bring the exciting and rapid development that we’ve conducted within the Facebook ecosystem to a large, very-well-subscribed site.  Why?

• Angie’s List is a very large and growing web property which is looking for a great team to join to help push forward their web presence.
• Angie’s List already has a great development team in house, so we can focus our efforts entirely on driving the web presence forward.
• Everyone’s got app fatigue and justifiably so.
• The social local search sector on Facebook just isn’t growing.   Check out stats on Loladex and GigPark for evidence.  Excellent apps all lost in the app cacophony.

So hurry up!  Join Angie’s List and give us feedback on how you’d like to see the site improved!