I decided a while back that I wasn’t going to get an iPad. Instead, I’d wait for the second generation iPad next year. This has been my approach when it comes to new Apple products. Yes, I’m scared of the early adopter regret. As the launch date neared, my mind changed a bit. My wife is an avid book reader, and I thought it’d be a perfect device for her. But more importantly, I think the iPad will have a significant impact on how us web designers approach interaction design for this medium and the coding behind it. I need one to tinker with.
I bought one on Saturday. I love it. I won’t get into the philosophical aspects that have been debated by many recently, instead I’ll focus the rest of this post on web design/development for iPad’s Mobile Safari. Creating web sites that look and behave consistently on different browsers and versions have been the bane of us web designers’ existence since Mosaic/Netscape days. While I’m happy with the experience surfing on the iPad, I can’t help but to think, “argh another browser.” Even though Mobile Safari on the iPad is identical to iPhone’s, but the term “optimized for mobile” means differently for each device. The iPhone optimized sites are often minified version of the desktop sites, for speed and better use of screen real estate. The iPad’s browser offers the desktop experience, so it should be treated as one. I divided the rest of this post to two sections: iPad ready and iPad optimized, depending on how far you want to customize your site for iPad.
In my opinion, for a site to be “iPad ready” simply means that all the content and functionality are accessible via the iPad. Sites that were written according to the web standard are in a good shape already. A few things to consider:
Flash – It’s unlikely that Apple will allow Flash on its mobile devices anytime soon, or ever. Sites that are done entirely in Flash will have to have a HTML alternative(as they should anyways). I embed Youtube and Vimeo videos on this site sometimes. Even though they both support HTML5
<audio> for major browsers.
P.S. I can’t figure out how this embedded Youtube video is being displayed properly without any HTML5 embedding code. Please let me know if you know the answer.
Mouse Events – Make sure your site’s functionality does not rely purely on mouse events (mousemove, mouseover, mouseout, and CSS :hover) . Mobile Safari can trigger onMouseover, but it involves quite a bit of timing and effort on the user. You need to press down on the element that has the onMouseOver event and release fairly fast. To make it easier for the user, either remove unnecessary mouse events or have a visible link that reveals the hidden elements. A good example of inaccessible functionality is twitter’s web interface. You cannot hover therefore you lose the ability to retweet or reply.
Scrolling Content – The default one-finger swipe on iPhone/iPad triggers window.scroll(). Two-finger swipe has the same effect as the mouse scroll wheel. Not a lot of users may know this, therefore I think it’s best not to have content in scrolling in fixed sized block elements such as <div>s. The Safari Reference Library has good documentation on handling events.
Fixed Positioning – In short, don’t use it:
Safari on iPad and Safari on iPhone do not have resizable windows. In Safari on iPhone and iPad, the window size is set to the size of the screen (minus Safari user interface controls), and cannot be changed by the user. To move around a webpage, the user changes the zoom level and position of the viewport as they double tap or pinch to zoom in or out, or by touching and dragging to pan the page. As a user changes the zoom level and position of the viewport they are doing so within a viewable content area of fixed size (that is, the window). This means that webpage elements that have their position “fixed” to the viewport can end up outside the viewable content area, offscreen.
But if you must, Richard Herrera has a work around.
contenteditable – Mobile Safari currently does not support
contenteditable attribute. Use a styled
Disabling Cut/Copy/Paste Dialog – Pressing down on a text block or image brings up the Cut/Copy/Paste dialog box by default. Sometimes this behavior is not desired. For example, when pressing the top link of a navigation menu. To disable this, use
Fortunately, Safari is one of the leading browsers to support HTML5 and CSS3. If you want to take advantage of all iPad’s mobile Safari has to offer, here is some useful info:
Mozilla/5.0(iPad; U; CPU iPhone OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B314 Safari/531.21.10
Media Query – In a way, designing for iPad is a bit easier since the screen is fixed to two sizes(portrait and landscape). We can take advantage of this by using Media Query.
<link rel="stylesheet" media="all and (orientation:portrait)" href="portrait.css">
<link rel="stylesheet" media="all and (orientation:landscape)" href="landscape.css">
Please keep in mind, just because you can, doesn’t mean you have to. I don’t recommend making the two sets of styles drastically different from each other because it’d make the users relearn the UI. One case where I can see it’d be useful is when in portrait mode, show only the main content of the site; when in landscape, display more meta info. For example, on a blog site, show just the post body in portrait, and unhide the meta navigation, Ads blocks when in landscape.
Jason Grigsby has a simple demo page to display different CSS styling depending on the orientation.
Format Detection – On iPhone, Safari automatically renders telephone numbers as a link to call. On the iPad the default action is to add the number phone to Contacts. You can disable this by:
<meta name="format-detection" content="telephone=no">
Viewport setting – Do not use hard-coded pixel for view port dimensions. Use
<meta name="viewport" content="width=device-width" />
Disable Automatic Format – Automatic Correction and Automatic Capitalization are default behaviors for text input. But sometimes you may not want inputs to be auto formatted. For example, inputting user name and passwords. To disable them:
<input type="password" autocorrect="off" autocapitalize="off">
<textarea rows="4" cols="50" autocapitalize="off"> </textarea">
Keyboard Types – You can make make it easier for the users by presenting content appropriate keyboards by using the new HTML5 attributes:
<input type="text" />
<input type="tel" />
<input type="url" />
<input type="email" />
<input type="text" pattern="[0-9]*" />
Not all there is to know of course. But that’s all I know for now :) I hope you find the information in this post helpful. Please feel free to add to the list, I’ll credit you for it.