Designing web pages for the iPhone

Jun 19, 2010 insic 5 Comments

In this article you will know the basic steps and fundamentals in designing and redeveloping your web pages for the iPhone. I will explain to you the iPhone viewport, and how to make your pages iPhone Friendly and iPhone optimized. The following is very important aspects in Mobile web Design.

The iPhone viewport

The most fundamental concept in any iPhone web work is the viewport. It should be a part of every web page you write for the iPhone, from the simplest web redevelopment to the most complex Canvas-based graphical web app.

iPhone has a display resolution of 320×480 (or vice versa, depending on orientation), it maps a much larger “virtual” window to that screen when you run Safari. The default virtual window (or viewport) is 980 pixels wide, which is then scaled down by a factor of approximately 3:1 or 2:1.
iPhone Viewport

If you choose to stay with the default viewport size, In portrait mode, things will appear much as you’d expect, as the viewport will be approximately square; everything above 1090 pixels will appear “above the fold.” In landscape mode viewers will see a much abbreviated page, with only the first 425 pixels appearing above the fold.

Fortunately, you’re not stuck with the default viewport size. You have two ways to change it. First, any web page served on a .mobi domain and any web page containing mobile XHTML markup automatically uses an alternative default viewport of 320 pixels. Second, you can purposefully change the viewport of any web page by introducing the new viewport metatag. You’ll probably do this through a default header that you load across your entire site:

Defining a viewport width of 500 would make your web page look as if it appeared in a 500-pixel-wide window before it was scaled onto an iPhone display. It’s the simplest sort of viewport command, and probably what you’ll do most often.

The remaining question is: why? What’s the purpose of using a viewport?

Most of the time, you probably won’t have to use the viewport at all. If you call up your web pages on an iPhone, and nothing looks too small, then you’re fine. If you instead find out that things are small—due either to sitewide decisions or to the content of local pages—that’s when you have to add a viewport tag to your web pages. Likewise, if you discover that your page looks really bad in the landscape orientation—due to the small live area—that might be another reason for a new viewport.

Generally, you should look at the viewport as an opportunity. In the world of desktop browsers, you have no idea what size of browser window a user might open, but on the iPhone you can control that exactly.

About the WebKit
The viewport command is part of the WebKit, an open source application browser engine that offers extensions to the core web standards. WebKit is being used by a number of browser developers, including Apache and Google. More importantly (at least for the iPhone designer) it’s the basis of Apple’s Safari. This means that a number of WebKit’s extensions, not yet broadly available in browsers like Internet Explorer or Firefox, will work on the iPhone. iPhone web developers thus have access to lots of cool gestures and transformations that can give them considerable power using entirely web-based designs.

We’re going to cover most of the possibilities of the WebKit in the next chapter. We’ve opted to cover one WebKit element here—the viewport—because it’s crucial to any sort of iPhone-related web design, whether it be a page redevelopment or a fullfledged web app.

Making sitewide viewport changes

Two elements might cause you to make sitewide viewport changes in your global header file: graphics or fonts that are too small.

Graphics are the most common problem. If you use them for navigation or to depict any other critical information, you’ll probably have a problem because they’re unlikely to be very readable at a 3:1 scale.

Font problems are usually due to absolute values used in the CSS font-size property. Clearly a font set to a small point size is going to be even smaller on the iPhone screen. The better answer is to make changes to your CSS files, which we’ll return to shortly. But if you can’t for some reason, this may be another reason to change your sitewide headers.

Typically, deciding on a sitewide viewport size will take some fiddling. The exact size of graphics or fonts may force you to select a certain value. If you have a sitewide navigation bar, you’ll probably use its width as your viewport size. In the absence of any specific issues, a viewport size of 480 tends to work great. It’ll be readable in portrait mode (at a 3:2 scale) and very readable in landscape mode (at a 1:1 scale). You won’t want to go much lower than that, and you definitely shouldn’t go all the way down to a 320-wide viewport; a change that extreme will probably make your web page break in other ways, and also ignores the excellent clarity of the iPhone screen.

The goal is to figure that things will be smaller on an iPhone than on a desktop browser and find a good compromise within that constraint.

Making local viewport changes

Adjusting your global viewport is the first step in making your web pages readable on an iPhone. However, you may also find individual pages that look bad. This situation is most likely to occur on pages that display an individual graphic or applet. The Apple developer pages give an example of a Sudoku applet that appears much too small on an iPhone page because it was only designed to be a few hundred pixels wide. The authors ran into problems with pages that displayed book covers, which tended to max out at 450 pixels wide. In both cases when using a default viewport of 980 pixels, the individual elements appeared up in the top-left of the iPhone screen, much too small and left wasted white space on all sides.

One solution to this problem is to set an individual viewport on each relevant page with a width equal to the known (or calculated) width of the applet or graphic. The other is to use a special device-width constant in the metatag, like this:

device-width is one of several advanced elements that may be added to the viewport metatag by developers who have more complex sites.

Viewport properties and constants
The iPhone recognizes a total of six viewport properties, as shown in table below. The width is the only viewport property that you will use on most web pages.

iPhone Viewport properties

We’ve already discussed how the height and width properties work: they assume a virtual window of the indicated height or width and then scale appropriately for display on the iPhone. Note that the device-width constant (which we’ve already met) has a match in device-height; you can decide whether you want your web page to fill the width of an iPhone display or its height.

The other four properties all control how zooming works. initial-scale determines how much an iPhone zooms when you initially view a page. The default value of 1 fits a web page to the iPhone screen. You might set it to a value smaller than 1 to immediately zoom to a leftmost column to make things more readable to iPhone viewers. But be careful when you use this technique, since it may not be obvious to your users that they’re viewing only part of the page.

user-scalable determines whether iPhone viewers are allowed to zoom in and out using pinch-zooming. If it’s set to no, then no zooming is allowed. If—as by default—it’s set to yes, then users may zoom in down to the minimum-scale value and they may zoom out up to the maximum-scale value. Generally, you shouldn’t have to change these last three values for redeveloped web pages, as a viewer choosing how your page looks is what the web is all about. However, if there are good UI reasons for controlling scalability or if you think a page looks particularly bad at certain scales, you may choose to modify them. On the other hand, you probably should turn scaling off for web apps, as those will be programs that you’re developing explicitly for viewing on an iPhone.

Note that you can set multiple values in a metatag by separating them either with a comma or a semicolon:

You’ll find that we’ll keep coming back to viewports in the next several chapters—it’s a crucial technique for iPhone web pages.

Making your web pages iPhone friendly

The simplest sort of web page redevelopment involves making your page’s “iPhone friendly,” which we briefly defined in the previous chapter. In short, this concept involves you taking a day or less of work to do the simple cleanup required to turn existing web pages into web pages that work pretty well on the iPhone.

iPhone Site

The basis of an iPhone-friendly page—as with any iPhone-based web page—is a good viewport. Once you’ve figured that out, you should also look at your pages’ technologies and generally consider good web design techniques to make sure your page looks nice. Making a page iPhone friendly is more about fixing problems than about showing off the iPhone’s strengths.

Avoiding missing iPhone functionality

Although the iPhone is often described as a fully functioning web browser, it’s not. In particular, you won’t have access to certain third-party plug-ins and you’ll discover that many events aren’t available on the iPhone.

1. iPhone missing technology such as Flash and Java must be avoided in your webpage else you should ideally deliver the user to an alternative page that displays the same information in a different format.

2. iPhone Missing Events – as we all know about iPhone’s input device is not a mouse. The finger is may or may not be on the screen at any time, your web page suddenly becomes stateless; you can no longer depend on events that presume that the mouse always moves from point A to point B through all the space in-between.

The statelessness of iPhone events causes two traditional categories of events to fail on the iPhone: drags and hovers. Thus, you can no longer allow click and drag (because the iPhone instead uses that gesture for its scrolling) and you can no longer test when the mouse moves over an area (because it doesn’t).

The loss of these events is going to affect the way you program using both CSS and JavaScript. In CSS your biggest problem will be with hover styles, which will of course no longer appear, but in all likelihood that won’t be a major issue for your web pages.

Creating good links

Events show us once more how finger mousing isn’t the same as mechanical mousing. The topic comes up again for basic web designs when you think about how your users select links. The topic is important enough that it’s another thing you need to consider when first redeveloping your web pages for the iPhone.

The main problem here is that a mouse pointer typically has a hot spot that’s one pixel wide—and a user’s finger point is many, many pixels wide. Thus, if you put your links too close together—such as in a column-based navigation bar (navbar) with links one under the other—a user won’t be able to select them without zooming in. It’s the same story for forms.

Practicing good web work

If you’ve defined a viewport, created alternate pages for missing web technologies, and redisplayed any links that were too close together, you’ve done 90% of the work you need to make your web pages look good on the iPhone. However, before we leave the topic entirely, we’d like to offer our top suggestions for using generally good web practices to make your pages look their best. If you’re already an experienced web designer, you’ve probably got this in hand already, in which case you should skip ahead to iPhone optimization.

1. Good CSS - To make your web pages more accessible on different platforms, we suggest you don’t use absolutes in your CSS. Instead, use relative values. For font sizes, use percentages like 80% and 120%, not absolutes like 10pt or 12px.

Consider carefully how you do any CSS positioning on your web pages. Sure, absolute positioning can make a web page look great, but it’ll ensure that your page only works at standard sizes—which means on an iPhone that you’ll be forced to use a default viewport size (like 980 pixels) rather than a smaller one that may allow for better scaling of fonts and graphics.

2. Good Tables and Good Columns- Column-based layouts have become a de facto part of web design over the last decade. This sort of design is more important than ever on the iPhone because users can zoom into a specific column using the double-tap feature of the iPhone. While this generally works without additional development work required, a careful developer can make sure that columns are optimized for the iPhone viewer.

Making your web pages iPhone optimized

In the previous section we explained how to make your web pages look better on the iPhone using a bare minimum of redevelopment. Our goal there was to fix problems and to thus give your iPhone users the same experience as your desktop users.

Detecting the iPhone through USER_AGENT

The idea behind iPhone optimization is to redevelop web pages so that they work great on the iPhone. To begin this process, you must know when a user is browsing from an iPhone. The easiest way to do this is—as is typical in web design—by looking at the user agent.

Below is a PHP code that look up the user’s agent.

There are several ways in detecting iPhone user agent. See below the code I have found in David Walsh Blog.

The JavaScript Method

The PHP Method

Detecting the iPhone through CSS

Depending on the precise dynamic language you use, you may have other ways that you prefer to use to detect which browser your users are using. Even CSS has its own methods that can be used to detect some browser capabilities.

We note this in particular because this method was originally Apple’s only supported way for detecting iPhone usage. Code below shows how CSS can recognize an iPhone and thus apply a different style sheet.

Besides being supported, Apple’s method also has the interesting side effect that it will apply your small-device style sheet to any small screen that views your website, which may give you instant compatibility with future smarterphone devices.

Optimizing with CSS

The easiest way to improve your web page’s readability on the iPhone is to start with your existing big-screen style sheet and then create a new small-screen style sheet that makes everything a little bigger.


iPhone in Action
iPhone Dev Center
Web Development For The iPhone And iPad: Getting Started

About the author: insic

Subscribe in my RSS Feed for more updates on Web Design and Development related articles. Follow me on twitter or drop a message to my inbox.