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?

iUI on Google App Engine Using Gaelyk

Since Google Code project hosting doesn't provide web hosting other than wiki pages, iUI has been using SVN to host the sample applications, like the music sample.  The problem is that neither of these solutions allows PHP or any other server-side solution to run properly (e.g. Search or Stats in the music sample)

I wanted a free hosting solution for the project and also am a big fan of the Groovy programming language (my Java background showing)  So, I thought I'd try using Gaelyk on Google App Engine.  I first pushed a test version several months ago, but I've just pushed a new version to iui-js.appspot.com and also checked in my work-in-progress to revision control.

I've also created a wiki page called iUI on Google App Engine.  The wiki page has (hastily-written) draft instructions on "How I Did It" -- as well as a to do list.  Please let me know if you have any suggestions on the to  do list.

Goal: I Wanna Be a JavaScript Ninja

I've wanted to create a blog that focuses specifically on software development, with a focus on JavaScript development for some time now.  Since Apple's introduction of the iPhone and initial announcement that all iPhone applications would be Web Applications, I've been interested in improving my knowledge of JavaScript and have made solid progress, but still have much to  learn.  Someday I hope to be a JavaScript Ninja (I bought the early access edition of the book, last week.)


I became involved in the iUI project over two years ago, and offered my skills as in the areas of revision control,  release management, and documentation.  I had hoped to learn more about JavaScript by assisting other experts on the project where I could.  Joe Hewitt, who created iUI had moved on to Facebook and was working insane hours on the initial Facebook iPhone Web Application.  A handful of other developers made contributions to the project but it didn't turn out to be the apprenticeship opportunity that I had hoped.  I used iUI on several consulting projects and over time learned much more about JavaScript and came to understand the iUI code base quite well.  Recently, I've decided that I have the expertise and can make the time to begin moving iUI forward and have made a few releases, fixed a few bugs, and added some minor features.  I'm hoping to get more developers involved with iUI and I'm also hoping to interact with and learn from the wider JavaScript community.


I've also had an interest in teaching JavaScript programming.  JavaScript is the de facto language of the Internet and is (at least indirectly) a part of everyone's daily online life.  In some ways it is well suited for beginners, in others it isn't.  I would like to write some posts for beginners or new developers as well.


I've debated whether I should use Apache Roller, Wordpress, or Blogger to do it.  Apache Roller is a great piece of software, I have a server side Java background, and there is a great team of helpful developers working on the project.  But ultimately, I didn't want to commit to maintaining a blog on an instance of Tomcat or on a hosted Java Servlet environment.  I may revisit this in the future, as I'd love to be able to be able to get under the hood of the blogging software I am using.


Blogger is overall the quickest and cheapest way to get started and now is the time as I have several subjects I want to discuss.