Today is a good day to code

Apple iPhone Human Interface Guidelines

Posted: December 31st, 1969 | Author: | Filed under: iPhone, Uncategorized | Tags: | No Comments »

Apple iPhone Human Interface Guidelines

Picture of IrvinApple's timing on this couldn't have been worse. I mean, with the news of the iBricks everywhere, and the removal of 3rd party applications, Apple goes and reminds everyone that there is no native 3rd party applications, and goes on to describe how to build a “native like” experience for the iPhone.

I don't know who is in charge of the releases, but I for one was quite angered while reading this. Not because it wasn't good information, but because it reminded me how limited development for the iPhone is.

They say that you can use AJAX and the full standards based Web 2.0 techniques to build web applications for the device, but they only give us really one event handler, maybe two if you count onscrollwheel, which I don't. No user I have ever seen inside of me has ever used two fingers to scroll within a div set up with the CSS overflow attribute. So let's look at the state of web development for the iPhone then.

The event support is shoddy. JavaScript is extensible, WebKit, perhaps more so than many other engines. Why didn't Apple extend it to deliver onpan and onzoom event handlers? It shouldn't have been tough, and it would have made designing pages much easier. If I could catch the onpinch event for example, it could give users another method of asking for navigation, or I could use it for copy-and-paste, it would allow for an entirely new class of mobile applications. Instead we have onclick.

It is possible, but difficult to provide a compelling rich web experience with so few event handlers, and a CPU that can not support extensive polling.

Then there is EDGE, Apple talks about keeping your web application responsive. There is nothing responsive at all about EDGE. Even pushing a few lines of text over XHR takes a second most places, so any immersive experience that would use images is pretty much out. Apples -webkit-appearance, and -webkit-border-image work very well as far as limiting the need to use images as long as you are happy with Apple's native controls.

Then there is the back button. Both IE and Firefox support injecting new URLs via JavaScript into iframe elements, which is a good method of allowing JavaScript to detect whether or not the back button has been pressed. Webkit doesn't support this, so that is out. It can be done with anchors and clever loading, but this is a really ugly method.

There are a couple of ways Apple could have resolved this. The easiest is to allow the developer to hide the bottom bar, unless the user scrolls to the bottom, similar to the way the top bar works. It would give us another 40px or so to work with, and make the application look more native. It would also stop users from inadvertently pressing the back button for an AJAX action.

Finally, there is the limitation of users having to navigate to a URL in the first place. The user should have the ability to promote a site to the front of their iPhone as an icon. Apple's safari should have a button for this and read a link rel tag pointing to the icon and the label. I mean, how easy would that be?

Then there is JavaScript performance. While it is better than any other handheld browser, it is far from being close to its desktop equivalent. The overhead of Safari itself and the other processes on the iPhone, coupled with the 128 MB or so of ram, and slow swapping all conspire to make AJAX heavy application with a lot of object caching in memory perform slowly. This could be addressed with more RAM, but in its current iteration, the iPhone's JavaScript performance, while decent, is far slower than the desktop browser user would expect.

The current implementation of Safari is very, very good, but the lack of events, EDGE, and limited RAM memory capacity, and graphical overhead make it barely acceptable for the current class of Web 2.0 Web applications. Apple suggests paring down the applications and focusing on limited pieces of functionality, but I would argue that users want the same functionality they get from the same site on their desktop. It looks like a desktop browser, why shouldn't it act like one.

This review is probably overly critical, but blame Apple for their timing. I am still steaming from the loss of productivity from the removal of 3rd party applications, the lack of similar applications from Apple, and the lack of a native SDK so I could get those applications back.