Designing Websites for the iPad, Part 1

This will be part of a multi-part series describing how you can design a site that will look and function nearly like that of a native iPad application. You’ll need a bit of CSS, Javascript, and HTML skills, but nothing terribly hairy. Some experience with how the iPad works would be a good idea as well. Firstly, let me just say that none of this would have been as easy to develop without the already great resources that exist out there:

• http://www.evotech.net/blog/2007/07/web-development-for-the-iphone/
• http://davidbcalhoun.com/2010/using-mobile-specific-html-css-javascript
• http://matt.might.net/articles/how-to-native-iphone-ipad-apps-in-javascript/
• http://cubiq.org/iscroll-4
• http://lab.jeffbatterton.com/iphone-back-button/
• http://www.tabsicons.com/

Goals

The ultimate goal is to provide a functional and pretty website that mimics the iPad native application experience. While it isn’t possible to perfectly replicate the experience, we can get very, very close, and with astonishingly little HTML or javascript. We’ll be using a lot of CSS to describe the interface (and since we’re only developing for one platform, we don’t have to worry about browser incompatibilities), and the goal is to make the content (pages) as easy as possible to maintain. Also, the ultimate goal is to make the same site work on the iPhone – this will be coming soon. For now, let’s focus on the iPad.

Get the METAs out of the Way

Let’s start with some peskiness that the mobile Safari browser throws our way when developing pixel-perfect iPad websites, namely, that of fuzziness. Things tend to look a little fuzzy, and pixels don’t often seem to be pixels. Instead they seem to be a mush of pixels, and that won’t work for something that requires perfection. Turns out that Mobile Safari likes to see a few META tags before it behaves, primarily because it expects that most sites it encounters won’t be optimized for the iPad (and thus, attempts to scale the site appropriately).

<meta name="viewport" content="width=device-width, maximum-scale=1.0" />

This indicates to the iPad that the site is designed for the device’s width (typically 1024 pixels in landscape mode), and that we should also prevent scaling (hence the 1.0, or 100%). The iPad will now render our site pixel-perfectly, but it will also expect us to write code that will fill the screen in either portrait or landscape mode. (More on that later.) Another META that we will use lets the iPad know that this site can be treated like a regular application. By that I mean that the user could save the site to their homepage, and then when they open it from there, the user will see only the page, and none of the Safari Chrome. Brilliant, eh?

<meta name="apple-mobile-web-app-capable" content="yes" />

HTML Structure

Most iPad applications display in two manners, depending on the orientation:

• Portrait: One single pane of content, along with a menu button that allows users to navigate to other content.
• Landscape: Two panes of content: the right pane is the primary content area, while the left pane is primarily navigational.

It is entirely possible to create our HTML in a manner that the CSS and just a bit of Javascript will control the visual display based upon the orientation, and so, we will structure our HTML as if the user is viewing us in Landscape mode, and let the Javascript and CSS deal with making things work when the user is in Portrait mode.

 + body #pnlBody .ipad .landscape
 | + div #menuPanel .panel
 | | + div .navbar
 | | | + Title of left panel
 | | + div #pnlMainArea .container
 | | | + div #mainMenu .content
 | | | | + Content for the left pane
 | | | | + div #grpMainMenu .navSubItemGroup
 | | | | | + a #mnuNameofItem .nabSubItem
 | |
 | + div #bodyPanel .panel
 | | + div #navBodyArea .navBar
 | | | + a #btnBack .button .back .black
 | | | + a #btnMenu .button .black
 | | | + Title of the page
 | | | + span #navBodyTitle (Subsection, i.e., Home, Tweets, etc.)
 | | + div #pnlBodyArea .container
 | | | + div .content
 | | | | + Content (h1, p, anything.)

This structure mirrors that seen in the screenshot:

• Two panels, one on the left and the other on the right.
• Each panel contains a “navBar”, which contains the title of the panel and any buttons necessary for navigation (e.g., Back, Menu), hence the name.
• On the left panel, we have some image content, and then a series of navigational links.
• On the right panel, we have the primary content.
• In both panels, the content lives inside a “content” area, which is then inside a “container”, which is further inside a “panel”.

The CSS which governs this flow takes advantage of absolute and relative positioning, since we only have to worry about two screen sizes: 1024x768 and 768x1024. In all reality the height of the viewport is less important than the width since the user could be viewing the site from within Mobile Safari (and not as an App), so the height does need to be stretchy. But the width… not so much. Of course, at this point, if you coded the above structure into HTML, there would be little to see; we need some CSS to spruce things up. But the structure is important as it will play a part in how things interact later.

Content Management

Before I stop this post (it’s a bit long in the tooth!), let me detail how the content is accessed; as we have it now, the primary content appears to be inside the page, which would mean all of this would need to be copied to each page we built, or we would have to build all our pages in this one file. My primary goal was to separate the primary content from the rest of the design and secondary navigation. The site uses an AJAX request to do this: whenever a user clicks a link or button, a special Javascript routine is called to get the content from the appropriate page on the website, and then that content is rendered on the primary content panel. This means that the content of the site is kept separate, and thus is very easy to manage and maintain. Keep in mind that this is still a mobile device and a mobile website. We aren’t out to duplicate the entire website experience here - just to provide things that a person on-the-go would find useful and to hopefully utilize the social aspect of the device. Things still need to be kept relatively simple (no long pages, no huge long lists, no intensive javascript, and definitely no flash), since we are still living within the constraints of a mobile browser - just one that happens to be pretty spiffy.

Next Time…

So this post has mostly been about setting up the framework and getting the ideas down. Next post will cover some actual code, CSS, and Javascript that makes this tick. And along with the next post, hopefully a demo too.