2009-09-17

Mobile Best Practices in the iPhone Era?

A friend e-mailed me this evening asking about what the current best practices are for mobile web access.  My immediate, flip response is "Make it look good on mobile WebKit and if the others can't read it, that's their problem."

I've been so focused on iPhone (and compatible sites) over the last year, that I have almost no idea what people are doing to support other devices.  Maybe the best practice is (essentially) to make it look good on the iPhone.   Most of the other devices are using Mobile Safari and are pretty close to the iPhone in capabilities.  Those that aren't are moving quickly to catch up.  WebKit is pretty much standards-based and when you look at actual mobile web usage statistics all the other phones don't add up to much.

She asked about a specific client that has an existing site that currently uses Flash navigation and has a limited budget.  The client wants improved mobile support.  Without knowing any details on the implementation of the site, the clients needs or budget, I'd guess there are four possibilities:


  1. Remove the Flash navigation and replace with HTML and CSS navigation that is as modern as possible given the structure and complexity of the existing site and the customers budget.  Use the iPhone viewport tag and other techniques to make the site iPhone-compatible.
  2. Create an alternative mobile site using XHTML that can be viewed by iPhones and other mobile devices, even older ones with limited web browsers.  Redirect mobile users to the mobile site (giving them an option to return to the main site, of course)
  3. Redirect users to an iPhone-optimized site using iUI or another of the iPhone-centric mobile libraries.
  4. Create an XHTML and an iPhone-centric site (In other words #2 and #3)  (Optionally remove the Flash navigation on the desktop site, as well.)
I would recommend #1 or #3 depending upon the budget.  But I'm an iPhone bigot (or at least Mobile WebKit bigot.)  Ultimately, it's a matter of return on investment.  For a relatively small site, why make the huge investment of supporting all the older phones with small screens and lousy browsers that no one uses anyway?

Whichever strategy is chosen, testing needs to be performed starting with the most popular devices and extending as far down the "long tail" as the testing budget and ROI calculations can justify.


Am I too much of an Apple fan boy?  Does anyone else have some pragmatic alternative best practices?

8 comments:

  1. Great post. I probably should have been more explicit: all the client wants (and all she can afford) is to have her flash navbar replaced with a non-flash(HTML & CSS) one, which is easy and inexpensive to implement. But, having never coded for mobile devices (and not even owning one), I was unsure whether a horizontal navbar would render correctly and be accessible without requiring exessive panning. One site recommended vertical navigation. Another recommended placing the navigation at the bottom of the page so the content would be visible first (this was not echoed on any other site, most of which recommended placing a slim, text-based navigation bar at the very top). I was also unsure how to ensure mobile devices would access the correct CSS. I've since come across an excellent article that explicitly addresses the latter issue. I'm still looking for input on which mobile devices besides the iPhone have the largest market share and how to test the site on the iPhone and the other top devices without owning them. Opera offers a very nice online simulator. The iUI looks like it requires a fairly daunting investement of time for a project I estimated would take me two hours, but it could come in handy for future projects. Did you find it time-consuming to install and/or use?

    ReplyDelete
  2. You're definitely in category #1 then. I think your goal should be to have a desktop site that is as mobile-friendly as possible. I would lay out the navigation so it looks best for desktop users. Use desktop best practices to be as standards-compliant as possible (given the existing code.). You can then fine tune for iPhone and similar devices. More on that later...

    ReplyDelete
  3. I hope 'later' means today or tomorrow. I'll be done with the project within a week. :-)

    ReplyDelete
  4. Bunnyslippers: I got an emergency phone call as I was writing the comment. I'm pretty swamped today, but would like to keep this conversation going, as I'm hoping others may chime in and I'll learn a thing or to myself. I've got some paying customers I need to take care of first, though...

    ReplyDelete
  5. @Bunnyslippers iUI is designed for creating new sites for iPhone or for putting a new 'front end' on content that is being pulled from a database. It is not meant to be added to an existing layout.

    You can create a new site in iUI in a matter of a few hours, if it is a simple site. C.W. Zachary has written a great article iUI 0.13 - An Overview. (iUI has been updated, but the basics covered in the article have not changed)

    ReplyDelete
  6. I don't think this is applicable. The client is paying to have the navbar redone, not the whole site. It's a Web site, not an app. Do you see the iUI as applicable under these parameters? If so, how?

    ReplyDelete
  7. @Bunnyslippers Correct, iUI is not applicable to your client's project. iUI can be used for both web sites and webapps, but when used for web sites, it is used to create a separate iPhone/mobile version.

    ReplyDelete