Bytes and pieces from Apple's iPhone interface guide

The document discusses the iPhone environment and how that might affect content and services offered to customers. Some things are similar to the interaction of larger computers. However, other differences are huge (or small as the case may be).

The document offers up some concepts that seem obvious, but have significant impact for developers. After all, the iPhone provides a Safari browser interface, with no layered windows nor desktop interface, oh, and no user-accessible file system.

Here are a few items that caught my eye:

Users not only use iPhone differently, they also feel differently about it. For example, users have a much more personal relationship with iPhone than they have with their computer and this influences which user experience characteristics are most important. One aspect of this bond is the fact that iPhone is a small device that can accompany users wherever they go. This view encourages the development of a broad range of products that provide quick, easy access to things users need and want no matter where they are, such as shopping lists, movie reviews, maps and directions, email, and games.

The user interaction model also informs content design. Because there is no external physical device that comes between the user and iPhone, the user interface of iPhone content must be especially streamlined and inviting.

I guess this latter point is talking about a keyboard and a mouse? Bigger computing devices have monitors and speakers like the iPhone. So, this must be about how the user actually touches the screen and the icons, rather than using some intermediary physical input device. It sounds vaguely religious, doesn't it?

Apple describes three types of compatibility with web pages: compatible, optimized and iPhone applications.

Compatible pages display successfully on iPhone, the document says, even if some content is missing or the missing plug-in icon is displayed. And users may have to pan and zoom around a page to read the content.

Optimized pages scale content for the small iPhone screen but has no elements that rely on technology that the iPhone doesn't support, such as Java, Flash or plug-ins.

In addition to meeting the requirements for a webpage that is optimized for Safari on iPhone, the third type of webpage provides discrete functionality to users and is often implemented using modern web technologies, such as AJAX. ... An iPhone application emulates built-in iPhone applications by providing a focused solution to users, integrating with iPhone features and services where appropriate, and minimizing the user’s awareness of the browser experience.

The document runs down a long list of principles and guidelines for creating iPhone content. One gave me a laugh:

Provide Fingertip-Sized Targets. If your layout places links and controls too close together, users must spend extra time and attention being careful where they tap and are more likely to tap the wrong element. A simple, easy-to-use user interface spaces controls and other user-interaction elements so that users can tap accurately with a minimum of effort.

Er, guys, perhaps this guideline was made after text input method on the iPhone was coded? Did someone miss the meeting about input "so that users can tap accurately with a minimum of effort?"

Users may get into trouble with forms, too.

Remember that there is no local storage on iPhone that is available to your application. Therefore, you need to make sure you save important information when you can. And, if users are in the midst of providing information to your webpage (by filling in a form, for example), you should alert them to the possibility of data loss if they navigate away from your webpage before they are finished.

Performance, or responsiveness, is a concern users and we can all hope that it is as well for developers of iPhone apps. Apple tries to send a firm message to content developers.

Responsiveness in an iPhone application or webpage is even more important than it is in an application or webpage on the desktop, because users are constantly aware of the passage of time, both in terms of the flow of real-world events and in the usage of the battery.

Developers are warned to test content speeds on both Wi-Fi and Edge networks. Of course, content providers can't tell what network will be used by iPhone users at any one time (neither can the users for the most part).

Apple tells developers to consider using JavaScript to draw some elements instead of using images, which may be speedier. At the same time, that can be overdone:

Be mindful of resource limits. Make sure your webpage or application does not contain unneeded JavaScript, which consumes memory resources without providing any benefit.

If it's not one thing, it's another.