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?
My Original Strategy
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?
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).
How it Works
- 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. www.detailedimage.com?mobile=on). m.DetailedImage.com 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.
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.
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.