Why your mobile web strategy should not simply be a question of layout

I write this post from a position of bias; I develop Mobile Web sites for my employer, Zappos, and I’ve previously done so at other companies. I strongly believe in Mobile Web as a critical part of Mobile strategy as a whole. But with that said, let me share my reasoning.

A quick clarification to begin with: While I may reference “m.” sites, I am not insistent on your mobile web (mWeb) site being served from a dedicated subdomain; Rather, I prefer the technique of serving your mWeb offering from your main domain as you would the desktop site, intelligently delivering the correct experience based on device metrics or user agent as appropriate. Similarly, I will at times argue against Responsive Design (or at the very least, the practice most commonly accepted as the definition of this term); I do not, however, believe there isn’t a place for being responsive in this manner.

There are several key factors that, to me, suggest the importance of your Mobile Web experience. So without further ado…

Your Mobile Web experience is Platform Agnostic

Any smartphone with internet access (and therefore, a mobile customer you care about) has a web browser. Increasingly, these web browsers are somewhat standards-adherent, and as such you can develop using valid HTML5, CSS3 and JavaScript safe in the knowledge that unless you really pushed the envelope, your site will be usable on the majority of consumer devices.

Being in the Apple App Store or the Google Play Store is a great way to reach customers or users, but what about those without an iPhone or Android device?

Furthermore, consider the startup cost of developing a native app — if a new platform arrives (such as Windows 8 Phone) do you invest that time, effort and financial expense before you’re sure the platform is going to represent a large (potential) customer or user base? If not, are you comfortable saying “Sorry, no access for you yet” to people using those devices who try to use your service?

Discoverability

Plenty of people who could be a customer or user have never heard of you. While it would be wonderful to be a household name in every market or amongst your target audience, very few brands actually achieve this — so maximising the likelihood of someone finding you is key.

Correctly offering an optimized Mobile Web site that is crawlable will allow you to harness Search Engine traffic, both organic and paid.

Low barrier to entry, minimal commitment

When a new customer first stumbles upon your brand, they are not already sold on what you can offer them. Opening a link and browsing a web site in their phone’s browser requires very little in the way of investment of time or effort. Will someone who’s never heard of you go through the steps of transferring to the applicable App Store, download and install your app, then open it? Some will, but the majority almost certainly won’t at this stage of the relationship. Will they at least view the page they landed on? Much more often, the answer will be yes.

Control your release cycle

The promotional benefits of being in Apple’s App Store or Google’s Play Store are great, but you are surrendering control over your release cycle to a third party. You may have plans to release a new version of your app on a certain day, but you have no guarantee that you will receive the necessary approval in time to meet that target.

On Mobile Web, you control the timing of the release down to the second — allowing you to release at the most appropriate time, be that determined by a marketing plan, or necessitated by a bug in production that you’d really like to fix.

Rollbacks and Monitoring

Pushed out a breaking change that you need to correct? Much easier to roll back and fix then redeploy in a short timeframe when you’re talking about Mobile Web. Another benefit of controlling your release cycle yourself.

When it comes to monitoring (and Analytics) there are a great many tried and tested solutions available that you’re almost certainly already using on your desktop site and its associated systems — they apply just as easily to your Mobile Web properties.

Multi-variate Testing

While many startups and incumbent corporations are tackling the A|B testing problem, as well as offering other forms of Multi-variate testing, there’s no unified solution that seems to stand out as a foolproof, tried and tested leader. Doing this sort of testing in a truly native app is hard today.

Conversely, the same tools and methods you’re using on Desktop for Multi-variate testing work on Mobile Web (because it’s just the Web!) equally well.

Developer and resourcing benefits

Finally, you get to have your cake AND eat it when it comes to your developers. The technical skill sets you need for your Mobile Web efforts are the same that you need for your Desktop team, so you can share resources amongst both mediums. So that’s a benefit to you — but what about the developers themselves?

Well, I’ll end on an anecdotal point, but I’ve found in speaking to many devs that mobile presents a set of new challenges. For the generation of developers coming through now that didn’t get to participate in the initial brave-new-world of the web at its inception and during its early days, there’s a motivating and thought-provoking feel to the work we do when delivering the best experience for a user on a smartphone — one where so many of the problems and challenges haven’t already been solved.

How do you approach Mobile Web in your wider Mobile strategy? - let’s talk on Twitter