IPhone OS
From MobileDesign
The iPhone OS is used on the iPhone and iPod touch, both of which are in a "candybar" form factor with an almost exclusively multi-touch screen (also known as screen-input) interface; unlike most previous mobile devices (of whatever function, be it smartphone, PMP or GPS navigation), neither device has a physical keyboard.
Instead, almost all finger-based physical interaction with the devices take place in the 480×320px wide display. This results in an interactive experience that must balance a dual-natured focus on the eyes and the fingers.
Contents |
[edit] Home
The most notable meme of the native interface of the iPhone OS is the "button"; when one first turns on an iPhone or iPod touch, the home menu (to which the user is directed from any installed application by pressing one of the few non-display physical interaction devices on either device, the "home button" at the bottom) consists of several displayed buttons for each installed application. As of the software update from January 2008, "Web clips" for bookmarks of websites can also be added to the home screen. When tapped once, a home screen button should direct the user to the desired application in a "zooming" manner, and a pressed home button at the bottom always zooms the application out and into the home screen.
[edit] In-app or In-site Navigation
Several applications (both native and web-based) designed for iPhone OS navigation have followed the example set by the native, pre-installed applications:
[edit] Application home screen
Upon selection from the home screen, the application or website opens to a list of basic topics; this is usually realized as a list of large and long buttons (with, mind you, readable text to indicate the topic by button) spanning the width of whichever viewing mode the gyroscopic detection of the iPhone OS may place it in, with an arrow at the end of each button to indicate the "direction" that tapping the button may bring the view of the user to.
[edit] Subtopic items
Pressing the button of a topic results in a pulling left off the screen of the home page of the application, often replaced with another list of more-specific "subtopic" buttons. The list may often be longer than the previous list of topics since the "main topics" home page of the application may only show a few topics that cover a wide range of subtopics. These subtopics may themselves be specific items that, once tapped, direct (in a similar fashion as the previous transition) to a page that contains more textual or visual material than the previous list(s) and its buttons.
These buttons also span the width of the current mode of view (and with smaller indicatory text) and have arrows on the right side to indicate the forward direction of a tapping action on that specific item button.
[edit] Item in detail
When a subtopic item is tapped, it usually may direct to the "detail page", which has a brief organized set of explanations that are pertinent to the item selected.
Unlike the previous list, this page doesn't usually scroll in its initial state. However, a rounded rectangular "expand" button at the bottom of the page may be added to lengthen the page (to scrollable lengths) for either more details or other item detail pages to view. Other buttons, such as a "bookmark" button can be added to perform other user functions that are pertinent to the current item detail page.
[edit] Scrolling and selecting from a list
Lists, just like web pages (iPhone-formatted and friendly or not) in the iPhone OS version of Safari, are scrolled in an opposite fashion than to a list on a desktop GUI; the "scrollbar" of the desktop GUI, which is pulled down to bring the page up and vice versa, isn't present as a persistent widget on the iPhone OS, so one must flick or drag a list from the lower screen-upward to bring the page from the lower screen-upward, and vice versa.
Thus, it is preferable to design a iPhone-friendly list to not have too-many items to view, as this will propagate too many finger flicks (and other finger movements) in order to bring one to a preferred selection or to the bottom of the list.
HOWEVER, if one absolutely can't help a large list of items to select, then the next step to bring one to a selection of item(s) within a shorter time would be to allow the user, using the iPhone's virtual keyboard (which usually pops up when one taps the inside of a form field), to type a term or set of keywords that would narrow down the number of items in the scrollable list to a select few. This approach is used by such applications as Nullriver's Installer.app when searching through user-selected repositories for desired applications for installation on the iPhone OS; Installer's list search field is located at the top, between the top bezel and the list in the middle.
[edit] Top bezel
Throughout the navigation between pages, an in-display bezel at the top is shown with centered title text to indicate the title of the specific page in the application that the user is currently stationed. On either side of the top bezel, a back button on the left and/or a forward button on the right can be pressed to direct the user to the next page in either direction; it is, however, rare to find such buttons in web apps, since the main/most persistent top bezel in Safari is the URL bar (which, when tapped inside, results in a widening of both the URL field and the revealing of a search field, both of which usually take up slightly less than 1/3rd or 2/4th of the screen, with the keyboard taking up almost the rest of the usable real estate until an action that reverts this mode is accomplished); this may be avoided if the JavaScript in the web application forces the native top bezel out of view in favor of the web app's bezel. (See also: Back and Backstepping)
[edit] Bottom bezel
In some apps (and also in the home screen of the OS), a bottom bezel is added to add a persistent menu of items or actions that, when tapped, will immediately direct the user to a completely different menu of the application; again, this is mostly found in native apps, since Safari's slim, native bottom bezel, consisting of a back and a forward button with a bookmark button in the middle, takes up the bottom of the page if one scrolls to that nether region; again, this can be avoided through JavaScript manipulation of browser behaviors to emphasize the presence of the web app's bottom bezel upon loading the web application.
[edit] Keyboard
Because of its dynamic nature, the virtual keyboard, which pops up whenever one taps the inside of a form field, tends to have quite a bit of greater flexibility than a physical keyboard. The keys are larger and more recognizable to the eyes, and buttons for completion of the most used symbols and words in, say, entering a URL, are available in the "symbol" section, which is opened as a second "page" of the keyboard.
However, designing an application (web or native) for access with the virtual keyboard usually must take into account the limited available space apart from the virtual keyboard's occupation of around 2/3rds or 4/5ths of the screen from the bottom up; this is also a concern for mobile devices with physical keyboards.
[edit] Keyboard and field forms
As a result, if one must display a field form in the application, it makes sense to place any field forms in the immediate top of the application display from the getgo, since placing it anywhere else in the application display will usually result in the keyboard forcing the display of the form at the immediate top of the display above the keyboard for visibility purposes. It also makes sense to place any pertinent field forms within close proximity of each other for brevity and accessibility.
[edit] Internet
[edit] It won't go
[edit] What won't look right on the iPhone OS
[edit] What may not work right on the iPhone OS
- Carousel (since it's a touchscreen-input interface, the only way that this may work right is if virtual buttons to select between visual items in the carousel are included. For a similar effect, a "Cover Flow" effect or a variation thereof may be preferable for better screen screen real estate management)
[edit] Please don't ask your iPhone OS users for these requirements
- This page is best viewed in Internet Explorer (or other web browser)
- This page is best viewed in a 1024x768 screen resolution (since we're talking about a far smaller screen display here)
- This page doesn't detect Flash/Java/other external plugin application on this system (Flash isn't available for the iPhone OS, neither is Java, and a plugin API for Safari on the iPhone OS isn't available or documented yet)
