Developing Content for iPhone’s Mobile Safari

Analysts are estimating that Apple has sold 700,000 iPhones in the U.S. According to Nielsen//NetRatings, there were about 209 million U.S. Internet users as of March/07, 69.2% of the nation’s population. Making the reasonable assumption that the 700,000 iPhones sold were to people who already regularly use the Internet, that means 0.25% of Internet users in the U.S. will occasionally be using the Mobile Safari browser on their iPhones to visit your web presence, and that’s after the first four days of sales. Does that make you warm and fuzzy, or send a chill down your spine? At RD2, we couldn’t be happier.

Which Web?

The iPhone falls squarely in a facet of the web that has been growing for some time now, a sort of limbo between the “desktop web” and the “mobile web.” Apple recently posted their which “read like a love-letter to standards-based design” .

Like Apple’s developer guidelines state, the iPhone doesn’t support any of the misguided mobile-only technologies that have sprung up over the years. Unlike Opera Mini, there isn’t a server piece sitting out in cyberspace that’s filtering the web before it reaches your phone. Mobile Safari also doesn’t even load CSS designed for mobile devices or betray any difference between it and the desktop version of Safari other than through its user agent string.

Nevertheless, it isn’t the same as having a desktop browser. The screen is small, the network is slow, and there’s no mouse or physical keyboard. Aside from the hardware, the software itself is different from what we have today in the Desktop versions of Safari. Mobile Safari does not support everything that Safari 2 does, supports part of Safari 3’s features (but not all, like SVG), and then brings its own features into the mix.

“Systems Integration” or URLs and Plugins

Apple’s provide excellent information, especially about the proprietary “viewport” meta tag options and optimizing rich media content for the Quicktime plugin, so I won’t repeat what’s already been written there.

The iPhone includes a feature called URLify which is used to auto-link recognizable data such as email addresses, URLs, and phone numbers as seen in the SMS and Mobile Mail applications. Previews of Apple’s Mac OS X Leopard also show Apple adding this to the desktop Mail application, including additional support for addresses and event details. While Mobile Safari supports the tel URI for creating links that dial phone numbers, it also uses URLify’s phone number auto-linking feature, as can be seen on the LogLogic Contact Us page. In testing pages from a current project which includes raw data and telephone numbers on the same page, including U.S. and European formats, the auto-linking has worked flawlessly. This auto-linking does mean a few things for web developers:

• Be sure to add appropriate CSS styles for linked phone numbers, even if you don’t build those links yourselves. To select these links specifically, you can use the attribute selector like so: a[href^=tel]
• Be sure to write JavaScript that takes these unexpected links into account. Mobile Safari adds the tel links by altering the DOM.
• For now, rely on Mobile Safari’s auto-linking for phone numbers instead of creating your own tel links. While tel is a bona-fide URI standard, the current leaves something to be desired.
• Also, be sure to always create links for email addresses and URLs. Aside from the user experience on desktop browsers, the iPhone currently has no concept of copy-and-paste. This means that the user would have to enter these manually, which is only made worse by the fact that the current web page is obscured when interacting with the address bar.

Sending an email, as one would expect, is handled by creating industry-standard mailto: links (tests have shown that additional parameters do work). The other two native iPhone applications that web developers can integrate with also work via hyperlink, but instead of industry-standard URI schemes or (to Apple’s credit) proprietary URI schemes, they work through URL interception. When you click tap a link to either Google Maps’ or YouTube’s sites, Mobile Safari will instead load the content in the iPhone’s native application. What this means is that while Apple has avoided creating new URI schemes, they’re also already compatible with the vast majority of existing web content such as lanelogic’s Contact Us page. It also seems that Apple built the URL interception in a way so that if you browse directly to either site, it loads the sites and behaves as expected.

Apple created both the native Maps and YouTube applications because neither web site works very well in Mobile Safari—but each service also provide a way to embed their content on your own web site, and that is where you’ll want to make special allowances. Embedded Google Maps technically work in Mobile Safari, but you’re left working with the tiny manual controls for panning and zooming, so you’ll either want to include a link to the Google Maps web site (an easy way to integrate this gracefully is to label it “Get Directions”) or create a PDF-based map like we do on RD2′s contact page. PDFs work well on the iPhone and work very well for maps since they are vector images and provide resolution-independence. Embedding the YouTube player on your site will only display a building block, so I recommend also including a “Watch on YouTube” link like we’ve done with our blog (the only change to any site we’ve made specifically for the iPhone).

In case you haven’t heard the news, the reason embedded YouTube videos don’t work in Mobile Safari is because it doesn’t bundle the Adobe Flash plugin, Lite or otherwise. Users also can’t download it, install it, or otherwise upgrade to the latest version. Your site should be detecting Flash availability and providing alternative content or an alternative experience. The worst thing you could do, possibly worse than simply failing to display rich content, is to pester the user to do something that they simple are unable to do. Luckily this has been RD2’s standard way of doing things for a long time, with one shining example being BancTec’s worldwide page (with Flash, the user gets rollovers and an info box, but without they still get a clickable map). Also worth noting is that Mobile Safari additionally does not support Java, SVG (for now), Silverlight, and even some of the Web Core Fonts.

JavaScript and the Finger is not a Mouse

While the iPhone has full JavaScript and AJAX support, you’ll still need to consider some concessions.

• Current drag & drop implementations do not work with the interactions provided by the Multi-touch interface, and one is still being researched. Joe Hewitt has a dragging demo using mousewheel events (generated by scrolling with 2 fingers) with a textarea. One thing this means is that not all JavaScript-created slider widgets will work, and while Safari on the desktop supports using the Web Forms 2.0 native slider widget, Mobile Safari fails to display either a slider or fallback to a text input.
• Modal JavaScript prompts all work very well, with two different interfaces depending on the length of the message. Long input prompts hamper the user experience because the message, text input, buttons, and keyboard all compete for screen space. Avoid pre-filling information into prompt inputs. While desktop browsers display these with the text pre-selected (making it easy to delete and begin typing), the iPhone does not because it currently has no concept of selected text. That means the user would have to delete it one word at a time. Reserve pre-filling for edit actions such as renaming.
• Print links silently fail. It would be nice if Apple would allow this lack of support to be detectable, similar to how document.all behaves in Firefox.
• Since there’s no mouse, there are no mouse over/out or even :hover interactions, meaning that sites that depend on fly-out navigation will lock users out of part of their site. Be sure to provide fallback navigation like we did in the sidebar on BancTec.
• Popup windows will display in a completely separate page/tab, so you’ll want to ensure that they provide enough information to stand-alone. When the popup is closed with JavaScript, the user is returned to their original page.
• JavaScript animations run very slowly due to the hardware limitations (typically Safari runs animations more smoothly than any other browser), so you’ll want to make sure the animation library you’re using adjust the “frame rate” of the animation to maintain a short overall duration, such as .

Forms, Files, and Footnotes

• As always, keep required form fields to a minimum and clearly mark them. If long forms are an annoyance to desktop users with large screens and a physical keyboard and mouse, just think of filling out forms without them.
• Apple has created a full set of resolution-independent form widgets. These scale well as the user zooms in and out, but they end up sizing different, even from their desktop Safari cousins.
• The drop-down select widget that Apple has created works as a sort of thumb wheel, displaying all options (and option groups) very cleanly. This upholds the current best practice of showing fewer options in a radio button group and many options as a select drop-down.
• If you pre-fill text inputs with help/label information, be sure you include JavaScript to clear that content so the user doesn’t have to manually do it (but also be sure not to clear any content the user has typed out).
• Position labels and help content near their relevant form input, such as CAPTCHAs. When entering form data, especially in a landscape orientation, the visible viewport is very small and must be shared between the text input itself and the help information.
• File upload widgets always show disabled since the iPhone has no user-perceivable file system. On that note, downloads also do not work, even for formats the iPhone could potentially recognize such as media files, vcards, etc. The extent of support for files is limited to viewing-only for images, PDFs, and Microsoft Word and Excel documents.
• It’s been discovered that Mobile Safari will make a guess as to what kind of data will be inputted into a text input based on its name attribute, and show an appropriate keyboard layout. As the example page shows, this can be problematic, so instead I personally would like to see Apple support the Web Forms 2.0 custom input types.
• HTTP Basic authentication works great from an interface perspective in both portrait and landscape orientations. You might consider using the iPhone’s interface for, at least, inspiration when laying out login forms.

View all of my iPhone test cases.