B2B/B2C online strategy and enterprise eBusiness blog

I’m pleased to announce the launch of our public beta on Levolor.com. We are now selling custom blinds and shades online via our manufacturer website, direct to the consumer.

What many people outside of the blinds and shades industry don’t realize is that custom blinds are extremely complex. A typical blind consists of the following questions that need to be answered by consumers:

1. What type of blind (wood, faux wood, cellular, vertical, etc.)?
2. Inside or outside-mounted?
3. What color?
4. What width?
5. What height?
6. Where do you want the controls to be (right, left, center, no controls, etc.)?
7. Do you want any special features like insulation, privacy, motorization, etc.?

…and the list goes on. Add on top of this the engineering constraints behind these options, and the number of rules/conflicts that must be enforced so a consumer cannot place an order for a product that we cannot physically manufacture. The number of combinations across all products is literally in the millions.

The Ajax Configurator
Enter Ajax, our dear friend. Without the Ajax “technology,” a consumer-friendly, web-based configuration tool would be a usability nightmare. Due to the amount of rules, validations, options, price grids, and surcharges that are factored into the order on a custom blind/shade, this requires many back-and-forth requests between the client and the server.

In the “old days,” this logic would have been taken care of with many, many page refreshes as the user navigates their way down the configuration funnel for a custom blind or shade. If you hop over to a 2″ Premium Hardwood blind, you’ll not only see the color on the picture to your left update, but you’ll also see conflict messages, required messages, options, and pricing update as you make selections. The Ajax calls make all of this rule checking appear transparent which makes for a very pleasant user experience (technically speaking).

Ajax is not the end-all be-all of usability, however
One important note is that Ajax is not the final solution by any means. There is still a lot of learning for us to do in terms of the feedback the user receives as they navigate through the configuration tool. By not seeing a browser refresh, we have to use a series of animations to indicate “work is being done” behind the scenes so the user doesn’t think the site has become unresponsive. And we also don’t know if this is the ideal layout for options in the configurator.

Through the use of web analytics (via Omniture’s SiteCatalyst), consumer usability studies, heat-mapping/eye-tracking, OpinionLab’s real-time feedback tool, and other feedback funnels (customer service, word of mouth, etc.), we’ll continue to build on this first release of the configuration tool.

I came across an interesting post which I commented on over at Read/Write Web, discussing the recent Forrester Research
results of RIA (Rich Internet Applications) vs. HTML. While I think the result of the research is nothing shocking (RIA provides a better user experience than HTML), the bigger issue I would like more insight on is ajax vs. Adobe Flex.

Apparently, this has already been discussed on several sites/blogs (google search “ajax vs. flex”). There are inherent pros and cons to each platform, and I think the debate could go on forever on which is “better.” Sort of like J2EE vs. PHP for web application development…or better yet, Mac vs. Windows, or Ford vs. Chevy. Two types of technology that can really get to the same end result (more or less). Obviously, depending on the end result you need, one technology may be better than another. In the case of cars, if you need to do any real work, then you need a Ford ( sorry, I’m a “Ford” guy).

I digress. The issue I would like to initially evaluate is not really the technical implementation discussion but rather the usability and user experience discussion.

Ajax User Experience vs. Adobe Flex User Experience
Do consumers really care that an application is done using Flex vs. Ajax? Does one technology fair well for certain demographics, industries/markets, or services better than another?

Take Glidden Paint for example. Here is their RIA utilizing Adobe Flex:

Painting is a very interactive experience, and the color-picking process should arguably be, too. In the Glidden application, you navigate down to color families which they’ve so kindly organized for you, and you drag and drop color swatches onto the areas of the photo so you can see how it looks. Very effective. Does it help sell more paint? Probably. Could the same application be done utilizing ajax? Probably, minus drag-and-drop features.

Let’s say it was done in ajax, to the best of the most-talented developer’s capabilities, designed to look nearly identical where it could:

• Would a consumer know the difference?
• Would consumers using the Flex-based app convert to buyers at a higher percentage?
• Maybe it does become a technical consideration after all?
• What was the cost to get to this solution utilizing flex vs. ajax?

Knowing what I know now, flex is definitely the way to go for the Glidden environment. Why? The subtle touches that flex offers:

• smooth animations
• nice transitions from one color family to the next
• the function of dragging the paint color to the floor or wall

These all contribute to making it a very usable, inspirational, and, well, fun application to use! This is an important consideration that needs to also be made when choosing the technology — how will your customers benefit from one technology vs. another?

OK, so when is Ajax better than Flex?
In many places. Google maps is one. The ability to grab the map and move it with your mouse is a significant usability benefit of Google Maps over competitor mapping systems. Not to mention that there really are no page loads. Google benefits from a very “plain Jane” UI throughout all of its applications it offers for free. Ajax is a clear winner for them because it provides extreme flexibility, runs entirely on open source software, and well, their target audience wants their product to just work. Light-weight portability is also critical for Google as they branch out into mobile phones, syndicating services, licensing search engine appliances — dealing with the inherent licensing fees of Flex and the portability to all of the different mediums they play in would be rather difficult. When your target market is the entire world, it’s best to K.I.S.S.

I already have an ajax-based web application. Should I port it over to flex?
This is a really interesting question that I do not have the answer to. We will face this same dilemma for our ajax-based project. We’ve already spent 12 months on the project, it’s nearly finished — does it make technical sense to port the client-facing side of the application over to flex? Does it make business sense? Will it create a happier customer? Will it generate more revenue? Will it be more or less of an ongoing burden as it pertains to maintenance? What about portability to other mediums besides the web (mobile phones, kiosks, etc.)?

I will continue to comment on our progress on our ajax application (I will talk more about it when we actually launch it — so for now, I have to be vague). We will most certainly do a technical and business analysis of converting from ajax to flex to see if we will see a return on investment. The last thing we want to do is to do something just for the sake of doing it. Converting to flex essentially means halting new development of the existing ajax application — which also will have an affect on current revenue streams and customer satisfaction. Instead of pumping time and resources into improving what we have already, we’re essentially starting the client-side from scratch. Anyway, we’ll weigh the pros and cons and I’ll post more details as we cross that bridge.

Moral of the story: 3 components to choosing the right RIA technology

1. Which is the best solution for your customer?
2. Which is the best solution from a technical resource standpoint?
3. Which is the best solution from a business/financial standpoint?

In the meantime, we’ll chew on research like Forrester’s RIA vs. HTML — but this is fairly common sense. RIA’s inherently provide an improved user experience, so they are a home run with consumers. I’ll eagerly await more data on which RIA technology drives higher satisfaction and ROI.

In this post, the author predicts 4 more years until the “page view” metric is no more and advertisers/publishers are scrambling to find other ways to measure traffic on a site. This is something I have had in the back of my mind as well. While I’m not interested in attaching a timeline-to-extinction to the page view metric, it is of legitimate concern to us on SuperMotors. We generate revenue via user subscriptions (for advanced site features) and banner advertising. We sell our own banner space but also rely on the likes of Tribal Fusion and Google AdSense to fill our unsold inventory (and there’s a lot of it!). What’s interesting is that with Ajax, you essentially eliminate the need for several page views to navigate a site quickly and easily. Granted, pages will still need to remain, but certain functionality within pages definitely can take advantage of Ajax.

For example, we allow users to post media files to their accounts on SuperMotors. Here is the hierarchy of clicks (from the home page) to post 1 picture, sound, or video:

1. (From Homepage) click “My Garage”
2. Choose “Edit Album” from your list of registry entries (vehicles, atvs, boats, etc.)
3. Choose the album section to add to, or create a new one
4. Select the file you wish to post, click submit.
5. Site refreshes. Repeat for each file. (it should be noted that subscribers can post more files at a time and use drag & drop functionality we have implemented, thus requireing fewer page views at this step)

Including the visit to the homepage and the 5 page views above, that’s 6 total page views. Each page view displays 2 advertisements for our site. That’s 10 total ads being displayed in the course of posting one photo. Add 2 page views for each additional photo/file posted. Our members have posted nearly 300,000 photos, sounds, and videos — over time, this adds up to significant revenue from CPM-based advertising campaigns like Tribal Fusion and our in-house ads.

Now, enter Ajax (which we will be implementing in the next 2-3 months). Ajax could potentially eliminate page refreshes on steps 3-5, thus bringing total page views down from 10 (for 1 file posting) to 3 (for 1 file posting), with no additional page views generated for each file posted. Makes for a superb user experience but at the cost of sacrificing advertising revenue.

So, how do we measure this traffic and use of the website? Or do we? From an analytics standpoint, yes, I want to measure the use of our site even through Ajax functionality so we can determine if users like it, are stumbling with it, or if it doesn’t work at all. From an ad revenue standpoint, Tribal Fusion and Google AdSense policies state that you can’t automatically refresh ad units on a page. So, do we include ad units within the Ajax functionality? There are technically many screens passing by and that’s a lot of potential advertisements to expose a user to, just like we do today with our page view/non-ajax model. Where’s the happy medium?

So, for any site selling ads based on CPM, Ajax is a double-edged sword. Increase usability, decrease revenue.

So, what will the new metric be on Ajax-enabled websites (or Ajax-enabled features within a site)? Time spent on site? Will ads run in 15, 30, or 60-second allotments, similar to television? How will you prevent someone from just leaving a page open forever and allowing ads to rotate through? I’m excited to introduce Ajax to our user base to see how they react to it and also to see how we can best create the best of both worlds: improved usability & sustained revenue.