Given how the iPhone's growth has made some ripples in the world of mobile browsing, we here at CNET decided to spend a little time and make an iPhone friendly version of our sites. At first I (Vladimir Olexa) considered the excellent iUI from Joe Hewitt but eventually decided to write our own.

The result is CiUI (CNET iPhone UI) that mimics iPhone UI behavior. It's already being used on CNET's iPhone page (http://iphone.cnet.com). It's been greatly inspired by iUI with a few key differences:

1. AJAX calls are performed after a page slides
2. DOM doesn't get overloaded with "pages" as they load. Instead, two DIVs are constantly being reused
3. Page titles are set on the source page, not on the destination page
4. Only specified "a" tags are assumed a part of the UI

CNET | iPhone Edition

1. Slide 'n load

Placement of AJAX calls is probably just a matter of preference. However, I believe placing it after a page slides reduces a lot of overhead associated with highlighting clicked items, rendering the loader and then undoing all of that. This also allows for a custom loading page to maybe place an ad, a cancel button, or whatever you may want while the page is loading.

Example: regular link vs. "iPhone-ized" link

PLAIN TEXT
HTML:
<!-- goes to cnet.com, just like any other regular link -->
<a href="http://www.cnet.com">CNET</a>

<!-- slides forward and loads the content of cnet.com within the iPhone webapp -->
<a title="CNET" class="go_forward" href="http://www.cnet.com">CNET</a>

drag to resize


2. One page at a time

iUI creates new elements as they're loaded and keeps them in the DOM. While this gives you faster load times (since you're not performing remote calls every time), with a large app you can easily bring your iPhone Safari to its knees and eventually crash it (which is really not that hard to do).

In contrast, there are only two DIVs used in CiUI's body element. Those DIVs get filled up with each page load. That means an AJAX request is fired up with each navigation event.

(Note: I'm currently working on a feature that will let you mark pages for caching. It will store the content of cached pages in the DOM so they can be loaded faster on subsequent requests. That should give us the best of both worlds - speed vs. memory footprint).

3. Give it a name before it's born

This, again, is a matter of preference. However, I wanted to break the dependency of destination page on source page. In other words, I wanted the destination page be any page without requiring it to include certain elements in it for the app to properly function.

iUI extracts the page title from an element on the destination page. In CiUI, you specify the page title on the element that is calling your destination page. So, the page you're calling can be pretty much anything and the app will still render properly.

4. Pick what to Click

In iUI, any clicked element (granted it has an "a" tag in its parent DOM tree) will trigger an iPhone specific event. There is also no way of specifying on the fly whether you want to animate forward or backward. With CiUI, unless your element has the class attribute set to either go_forward or go_back it will be treated as a regular element (will not trigger any iPhone UI specific events). Intuitively, go_forward will slide page forward and go_back will slide backwards.
While these are all subtle differences from iUI, they were significant enough for me to just start from scratch and write my own iPhone UI library.

Check out the source and an enclosed working example or go to iphone.cnet.com to see it in live action. You can download the library from Google Code or from our download page. Enjoy!