The Story Behind the Detailed Image Mobile Site

DI Mobile

DI Mobile Browsing

Yesterday we launched a dedicated mobile site for Detailed Image. Above are a few screenshots. Overall I’m extremely pleased with how it came out. The functionality is nearly 100% of the full site. That said, the story of how this mobile site came about over the past two weeks is much more interesting than the functionality of the site so that’s going to be the focus of this post.

Why a Mobile Site?

I think the main answer to this is obvious – more and more people are browsing the web from mobile devices. The second reason, and what threw me off course on the scope of this project, was to simplify functionality. The Detailed Image site when it was launched in early 2009 was one of the few e-commerce sites that really pushed the use of AJAX. Some features, such as a dropdown notification after adding a product to cart (instead of being taken off page), or adding/removing products from your cart, or applying a coupon code, greatly benefit from a usability perspective. Initially, that level of javascript processing wasn’t possible on mobile phones. In 2009 the majority of the people trying to buy from an iPhone ran into issues and couldn’t complete their purchase. If you recall, it was one of the four major reasons that people failed our checkout.

My Original Strategy

Given that reasoning, our original strategy was to build a completely separate mobile site at similar to how we built our scaled back mobile site for LockerPulse. The mobile site would have stripped down functionality, removing the need for javascript in the shopping process to accommodate phone browsers. Just to get all of the portions of the site critical to shopping (home page, browsing, item pages, registration, checkout, etc) I figured it would take 1-2 months plus testing time. While the back-end functionality would remain the same and utilize all of the existing classes, the front-end would be totally new.

Initially I had this in my dev plan for early 2011, prior to our Spring rush. Then I looked at the stats and saw that about 6% of our visitors were coming from mobile devices. I decided to try to bust ass and get it done prior to the Holidays – even an increase in conversion rate of a percentage or two amongst those mobile users would make it worth my time. However, as I sat down to map the project out I started to freak out a bit (this was only last Monday, some 11 days ago). There was no way that I could get it done prior to the holidays and still get everything else done that I had planned. In addition, I wasn’t really looking forward to all of the tedious testing. What to do?

When I mentioned my plan to work on the mobile site, George pointed out that many people were in fact checking out OK on their devices. That prompted me to look into the data a bit more. Turns out that all throughout 2010 people have been checking out fine using their mobile devices. Only 1 failed checkout, in February, and I’m pretty sure it was one of the other reasons that caused it. All in all, lots of sales through mobile devices, almost all on iOS and Android. It does make sense – given the advance in the Webkit browsers that both use, any javascript issues from early 2009 that I assumed were still there are now gone. Just for good measure I picked up my Android phone and tested everything I could think of – no issues.

That completely changed my approach. Now we’re not talking about functionality at all. We’re talking strictly aesthetics, which led me to the idea…

My New Strategy

What if we simply just served a new stylesheet to mobile users? It would be inserted into the header after all of the other stylesheets so that it would over-ride the main styles and display them properly for mobile devices. I remembered MOBIFY, a company that will “mobify” your site in minutes with the same approach.

I whipped open Firefox, opened up Firebug, and within minutes had proved my concept to myself. From the LockerPulse site, I remembered all of the “rules” for mobile design – full width, no sidebars, variable font sizes, small images, etc. It was pretty easy to show myself that it was possible. I was so excited – the benefits of doing it this way are astronomical (see below).

Instead of spending months, I spent a handful of days going page by page through Detailed Image and re-styling the pages, although once the template was done many of the pages already looked just fine. Only ~150 styles were required to transform the entire site. We benefited immensely from haven written all W3C compliant HTML and structuring our CSS well. I had to write one small javascript function, do tiny bit of work with the HTML served (such as changing the doctype to a mobile doctype), and build in the device detection from LockerPulse, and we were all set.

How it Works

When someone is determined to be a mobile user, we simply change the doctype declaration and add in the new stylesheet and javascript function. Everything – including both blogs, the guides, reviews, and the entire shopping process – still has the functionality that it does on the main site. How do we determine if someone is a mobile user? There are a few ways:

  • URL variable – the URL variable “mobile” can be toggled on any page of the site to put you in or take you out of “mobile site mode” (i.e. simply directs there. There are links in the footer of both versions to go back and forth (no visitor ever actually has to use the URL variable).
  • Cookie – once the URL variable is set one way or another, the rest of your session will remain that way unless you change your mind and click one of the links in the footer.
  • Device detection – if there isn’t a URL variable or a cookie, we use a class I built for LockerPulse to detect whether or not you’re using a mobile device. Given that it’s been proven on LP, this was a very quick implementation.


First, the pros:

  • Way faster – took less than two weeks from idea to implementation!
  • Little/no maintenance, very scalable – assuming we stick to our coding/styling standards, new pages should look just fine without any work. Occasionally we’ll need to do something minor like hide an element, shrink an image, or remove a border.
  • Cool features that help mobile browsing – I never would have thought to include the autosuggest for the search box in a mobile version, but it’s maybe even more important because of how tedious it is to type on a mobile screen. In the same manner, drilling through products by criteria such as brand, price, and usage become even more helpful on a small screen.
  • The entire site – the blogs and the guides are a large portion of our traffic. It’s great to get those into a readable format for someone who has a few seconds to kill on their phone.
  • No redirects – no redirects to maintain, and if the device detection happens to be wrong there’s no messy incorrect redirects going on.

Of course, there are a few cons:

  • Extra HTML – a dedicated site would have only the HTML necessary for the mobile site. Our mobile pages serve up some elements, only to have them hidden with CSS.
  • A lot of requests – in the same manner, we have our main stylesheet, only to have an additional request being made to another stylesheet that over-writes a large portion of the original stylesheet.

Clearly, the cons are NBD (no big deal) given the relative advantages of the pros.

SEO Impact

But how does this affect how search engines see the site? Good question. Thankfully Google answers it in full in their recently updated SEO guide (I know I’ve said it before in my essay, but it’s a must-read for any site owner – who better to get your advice from than the search engine itself?).

Google does two things that are really smart – they have separate sitemap syntax for mobile sites, and they use a separate user agent when crawling mobile sites. The first lets you submit your mobile sitemap to them. In our case, the URLs I submitted were exactly the same as the ones in our regular sitemap. The difference being that they’ll send Googlebot-Mobile instead of Googlebot to visit those mobile URLs. By adding Googlebot-Mobile to your device detection, you’re serving your mobile pages to the mobile crawler and your normal pages to the normal crawler. It’s explained in full in their guide, but basically they just want you to show them what you show a visitor of the same criteria (mobile vs non mobile) and you’ll be fine.

Business Impact

Bottom line: I just got a two month project done in two weeks, and got it done better. For me, this serves as a reminder to always challenge my own assumptions. Things change fast in the web world. What wouldn’t have worked in September 2009 worked just fine in September 2010.

8 comments on The Story Behind the Detailed Image Mobile Site

  1. Anthony says:

    Great post – you do always need to challenge your assumptions in this industry.

    The only thing I’m a bit skeptical about is how no-big-of-a-deal the cons are. You got the mobile site done quickly & efficiently, in time for the holiday season, and it was almost definitely the right short-term move from that standpoint. But as you noted, the site is still downloading all that extra HTML and CSS. It’s also presumably downloading the full-size, normally-compressed images, only to size them down with CSS. I just tried the site for the first time on my Droid X, so my cache was fresh, and it took quite a while to show up. If I clicked on DI from Google search result, I’d probably have hit the back button before it got a chance to finally appear. That said, this solution is 100%, undoubtedly, a step above a site that takes the same amount of time to show up and is not even usable once it does. But obviously, the optimal experience (and conversion rate) will be realized once the site is *both* aesthetically pleasing *and* fast.

    Hope that input/advice is taken at face value, nothing more, nothing less. As I said a couple times, this is still a huge step above the previous experience. And as I’m painfully aware, when a small business can make a huge incremental step in just 2 weeks, that’s a success in its own right.

    • Adam McFarland says:

      Anthony – totally hear what you’re saying. I only take them as no big deal relative to the time input, the other pros, and the fact that if someone was visiting DI on their mobile device last week it would have taken just as long to load. I’m definitely not shutting the door to improving that at some point in the future.

  2. Neville says:

    Awesome post….

    You say 6% of visitors were mobile….do they actually buy?

    I just checked my stats for
    iPhone 781 $213.97 4 $53.49 0.51% $0.27
    Android 472 $0.00 0 $0.00 0.00% $0.00
    iPod 343 $0.00 0 $0.00 0.00% $0.00
    iPad 193 $41.80 1 $41.80 0.52% $0.22
    BlackBerry 115 $27.20 1 $27.20 0.87% $0.24
    Danger Hiptop 21 $0.00 0 $0.00 0.00% $0.00
    SymbianOS 14 $0.00 0 $0.00 0.00% $0.00

    (Hopefully that formatting doesn’t come out all funkified).

    Basically all mobile users (including iPad) counted for:
    4.97% of my traffic.
    1.15% of my revenue.

    ….I’m curious what kind of increase this will have on your current mobile sales.

    • Adam McFarland says:

      Good question Nev. Our stats are similar to yours. For the past 30 days it looks like we’ve had 6.52% of our visitors from mobile devices, but only 2.26% of transactions and 2.23% of revenue…which means conversion rate is about a full percent below than the rest of our site.

      Any incremental improvement will be a big deal, although looking at it further we’re probably not going to get a percent or two like I mentioned in the post, more like half a percent would be a big win. I think it’s hard to expect conversion rates to be close to the regular site. I mean, shopping on your phone kind of sucks. I personally do it passively but then I tend to sit down and buy on a computer. The only exception for us is if you already have an acct with us there isn’t much typing because all of your info is saved. The only thing you’d have to type would be your CC info. Still, I think it’s tough to expect people to sit on their phones for an entire purchase process. Even quickly that’s probably 5+ minutes at least from start to finish. In my mind I look at it as two separate entities – I don’t ever expect that a mobile site, at least in their current forms, will ever convert as well as a regular website for a variety of reasons.

      • nethy says:

        Great post Adam, a few quick notes:

        1. Browsing is important too. (a) It leads to buying later. Most online purchases occur on the second or third visit of that specific search/shop “session.” (b) Browsing is awareness & branding. Amazon benefits a lot from the fact that it’s the best place to research products, even if you buy them elsewhere.

        2. Mobile may be someplace you can get an edge easier. Most sites are much better on mobile than on pc, both in UX and in SEO (maybe other areas too). It’s just not part of the standard practice for most platforms/vendors. If you can do 25% better than an average competitor on the standard web with x effort, you can probably do 300% with the same effort.

        3. Shopping on the ipad doesn’t suck so much. It seems a good bet that new device categories will get decent market share in the next 2-3 years. Maybe you should treat the phone site as practice. As you code in the future, you will be more aware of what it takes to make it work on multiple device categories.

        • Adam McFarland says:

          Really good points Nethy. One of the reasons I was happy to get the whole site mobile, content included, was to get the most out of the “browsing” people do from their phones. I hypothesize that the guide, reviews, and blog might be even more critical to the mobile experience. If you’ve got a few minutes to kill sometimes it’s more practical to read/research than it is to shop.

          The iPad/tablet category is interesting. Agreed that it’s much easier to shop on an iPad vs an iPhone, but typing is still difficult. For a first time buyer who is registering there’s only so much you can do to make it not suck. Long term, it will be interesting to see if we truly have a 3rd device to plan for other than the phone and computer, or if the tablet category is more of a small niche like the netbook category.

  3. […] totally mentally spent. Ever since then we’ve been meticulously chipping away one feature at a time up to the […]

  4. […] mobile conversion rates be lower you say? Industry data seems to suggest so, but we knew that our old half-baked mobile site was costing us sales. We’d only find out how many sales by releasing a site where the […]

Comments are closed for this post.