One Web, Not the Mobile Web

IanFogg | August 06, 2008, 11:25 AM

The W3 argues in their new Mobile Web Best Practices that the mobile web should be integrated in with the full [PC] web. This is their "One Web" position. I agree. It's quite unlike the .mobi approach. Ideally, the w3 believes all of the same content should be available to website visitors from a mobile phone as from a PC. The content simply needs to be delivered in a different design and layout.

Why build a mobile website? What's the best way of targetting the mobile Internet audience? This is an area we've debated extensively at Jupiter over the last year.

• Should the mobile web be separate from [PC] web sites?
• Should companies build mobile applications/widgets or should they build mobile websites, or both?
• What determines what tactics organisations should follow? Type of content or service, geography, or whether they seek a mass audience or a carefully chosen niche target segment?

The w3 alludes to this, but the main web standards body doesn't face the "why the web on mobile" issue head on.

Here's my take on why marketers need to ensure their organisations build mobile websites, in addition to whatever applications they develop:

• Websites enable marketers and publishers to target the broadest share of the mobile audience. Every modern handset has some form of browser, every modern smartphone has a web browser. Building one application will limit its the audience to one of the many different operating systems in use (iPhone, Blackberry, Windows Mobile Pro, WM Standard, Symbian S60, Symbian UIQ, Google Android, Java, etc.).
• Building websites is relatively cheap. Existing web staff, web tools, expertise, and equipment can be deployed. Often a few site designs will deliver content to all smartphones. To reach such a wide audience an organisation would have to build multiple versions of the application, most likely from the ground up, similar to writing software for the Mac and Windows. Building those applications requires many completely separate full software development projects. Maintainenance costs are also much higher again due to the multiplicity of handset platforms.
• Leverages normal PC website traffic which can be easily diverted to a mobile version. iPhone, Symbian and Windows Mobile users are already visiting PC websites but finding an uneven experience. This is a ready source of traffic that organisations should embrace.
• Are more compatible with email newsletter links. If a publisher or marketer is maintaining user engagement through email newsletters with links to full articles, a mobile website ensures that these links are successfully delivered when a user clicks on them on their Blackberry or other phone. Linking from an email message to content within a specific phone application is hard to do, and to my knowledge impossible to do in a standards, universally-compatible with all handsets way.
• Provides universally-compatible landing pages for mobile advertising campaigns, which can then link to the rest of an advertisers' mobile website. If a mobile advertiser wishes to solicit requests for follow-up information, they have two options: trigger a SMS-based interaction (as Blyk favour), or link to a mobile website. SMS is a completely universally compatible tool but is purely text-based. Mobile websites enable a richer experience suitable for branding.
• Enables marketers to get to market fast, test the water, learn, and then re-plan and build the case for a bigger budget. Mobile websites are quick to develop, as well as being cheap.

The "One Web" position is contained in the W3's just published guidelines for building mobile web sites, Mobile Web Best Practices. It's a good read and is full of common sense tips all collected into one neat place. While it's aimed at actual website builders as it's lucidly written most of the mandates are easy for marketers and strategists to understand, and should be appled to normal websites too to maximise usability. A few examples:

• Keep website addresses short.
• Do not use pop-ups / unders.
• Limit [page] content to what the user has requested [only].
• Avoid free text entry where possible.
• Provide pre-selected default values where possible.