Monday, November 17th, 2008

Shopping cart zoom UI

Category: Showcase

Chris Vanrensburg has added a nice little effect at Zazzle. Mouse over a product in the results, and you will see it zoom in for a closer look. Ben and I often talk about the zoomable UI that Apple uses in their store (and many others) and how it makes shoppers feel like they can see a lot more of the product and sense that they are really interacting with it. This hopefully leads to more sales as you don’t get the “hmm, don’t know if I can buy this online” feeling.

Chris talked to us about the features, including the implementation:

On the technical front one of the major requirements for that feature was to have little (ideally zero) impact on the page weight and load time. Criteria we considered, in this regard, included things such as:

1) not adding any extra image load to the initial page load (so, none of the larger images are loaded in initially – they are loaded on demand when the effect is activated)

2) not adding any extra DOM that would add to initial page render time (so the extra DOM node used for the zoom & pan effect for each cell is added dynamically when the effect is activated)

3) not adding too much to initial page wiring time (so, progressive wiring of cells to defer impact to when effect is activated)

4) not adding too much extra JS code (so, just efficient implementation and good code reuse satisfied this requirement).

Other UX requirements were…

1) It should be discoverable (accomplished with this implementation, because if someone’s interested in something, they will contemplate going to the product page and, therefore, hover over the cells and discover the interaction).

2) Operation should feel intuitive and “lightweight” (so, no added control UI needed for the interaction). Our user testing found that users learned quickly how to pan, understood the interaction well, found it compelling, and quickly became addicted to inspecting every product that way.

3) Shouldn’t create a minefield. We wanted to ensure that users wouldn’t develop an aversion to the results grid (potentially disastrous for sales). We didn’t want to deliver a seizure inducing experience every time the user moves their mouse from one side of the screen to the other, so there is a rest delay before the effect is activated. This is different to a hover/mouseover duration threshold, in that the user needs to have rested the mouse for a minimum amount of time (easily configurable, we used 150ms) before the effect is activated – long enough to prevent triggering as the mouse moves around, but short enough that the user doesn’t become impatient.

4) We didn’t want an experience that would add obscuring overlays on top off the grid and risk the user creating a clutter that might frustrate them and that they might not be able to recover from / clean up. We deliberately wanted to “contain” the experience within the real estate of each cell, to not have the interaction block other results from view (ala a lightbox UX), potentially contaminating the user’s receptivity to adjacent results and potentially creating confounding data points in our conversion metrics.

Some other points…

1) Zoom level was designed to be easily configurable, but we chose 2.5 (too high a zoom and the interaction starts to feel very touchy / sensitive to mouse movement).

2) An early version of the effect switched immediately to the zoomed image with pan activated. Ultimately, we decided that the zoom in animation was key to the user understanding the effect when they experience it for the first time, and not feeling disoriented by immediately being thrust into the higher zoom level where they may lose the context for what they’re seeing.

3) Immediately as the effect is activated, lowsrc is used for the zoom node so that the already loaded and cached smaller image is stretched to stand in as a proxy for the larger image while it loads (so, no waiting to load the large image before the zoom effect is initiated – it starts immediately once the mouse rest threshold is crossed).

Needless to say, search is a critical link in the flow that leads to conversion and revenue, so we didn’t approach adding this feature lightly. Fortunately, we looked for – and found – other areas that could be performance optimized in the search results page to buy some budget for the new feature. That, combined with heavy emphasis on a low impact approach to the implementation, allowed us to add this enhancement to the results page while simultaneously doubling the number of results in the grid from 15 to 30, while still achieving a small performance improvement in the page.

Posted by Dion Almaer at 9:01 am

3.8 rating from 19 votes


Comments feed TrackBack URI

What’s great about this implementation is that they quickly identified the Lightbox effect being problematic.

Much too often we see sites use the Lightbox just because it’s available and may semi-serve the purpose, ignoring all its faults.

Kudos to Zazzle creating an effective solution that minimizes the “cons” (such as “minefields”).

Comment by Liquidrums — November 17, 2008

this article has too much text and too few examples / links to any working code….

Comment by grosser — November 17, 2008

I find that displaying images on e commerce web site is an interesting problem. Making them work in templated designs is difficult and this is a creative solution. Does anyone know if there are any publically available solutions that have this same kind of effect?

Comment by cwpollock — November 18, 2008

Oh, and since I submitted this article to ajaxian, I think it’s reasonable for me to point out that the implementation – like all the rich client JS on the Zazzle Web site – is built on the UIZE JavaScript Framework…

Comment by uize — December 4, 2008

Leave a comment

You must be logged in to post a comment.