Hopefully, you’ve now read the first part of this series and have started to think about the iPhone and how it relates to your own web development efforts. In this second article of the series, I’ll focus on some of the things that made me scratch my head and dig around for answers or otherwise impeded my work.
If you had any doubts about the relevancy of this series to your own web properties, last week’s announcement of Mobile Safari being available on the iPod sweetens the deal: there have been over 100 million iPods sold to date. The mobile web is no longer just about phones.
Size matters#section2
Let’s begin with the size of the screen. There are two sets of dimensions to consider, depending on how the user has oriented the device: 320×480 pixels (portrait) or 480×320 pixels (landscape). But you don’t get to use all of those pixels: the top status bar, where the signal strength, time, and battery indicators are located, uses 20 pixels of screen real estate. Then there’s the Mobile Safari address bar (60 pixels at the top) and toolbar (44 pixels at the bottom in portrait, 32 pixels in landscape).
Additionally, Mobile Safari—unlike other browsers—does not maintain a constant size for content viewing. Because of the small screen, the content area is constantly adjusted to maximize the space available for the task at hand. For one thing, Mobile Safari’s address bar moves out of the way as you scroll down the page. If the user is in portrait mode, the height of the viewport is 356px at the top and 416px further down the page (with a constant width of 320 pixels). In landscape mode, the dimensions are 208px or 268px by 480px.
Available screen real state with iPhone in portrait orientation
Available screen real state with iPhone in landscape orientation
The onscreen keyboard will also hide some of your content while the user is typing. In portrait mode, the keyboard uses 260px at the bottom of the screen (covering the toolbar). The portrait keyboard uses 224px.
Remember also that viewport scaling means that your content may not be displayed pixel-for-pixel within these dimensions. If you’d like to prevent that, you can use the <meta> tag to disable scaling—a very useful trick when you are trying to emulate the iPhone UI. You can disable scaling using this meta tag:
<meta name="viewport" c user-scalable=no" />
Smart phone, tiny brain#section3
The physical size of the display is not your only limitation. Unlike your desktop, with its gigabytes of memory, the iPhone has a much smaller area to store data. The four or eight GB of storage on the iPhone is for files, not for caching data like web pages.
Only Apple knows how much RAM is actually in the iPhone. What we do know are the limits imposed by the Mobile Safari browser when loading a page:
- Each text resource must be less than 10 MB (
.html,.css, and.jsfiles as well as any other text-based resources). - Images must be less than eight MB uncompressed, calculated as width x height x four bytes. In other words, less than two megapixels. (The exception: JPEG images up to 32 MB will be loaded, but automatically resampled down to the eight MB size.)
- Animated GIF graphics must be less than two MB.
- Total page content size should be less than 30 MB.
Not only are there limits on how much data can be stored, but there are limits on how fast it can be processed. Again, Apple is keeping quiet about the CPU that’s in the phone, but it’s rumored to be about 400-600 mhz. Compare this with your desktop that’s running three or four times as fast.
To get an idea of the performance differences between the two platforms, I ran some simple benchmarks. The test results show that the iPhone executes JavaScript about 80 times more slowly than an average desktop computer. If your application takes 1/10 of a second to execute on your desktop, it could take up to eight seconds on the iPhone.
Because of the memory and speed limitations, the JavaScript interpreter also places limits on your code: a maximum of 10 MB of data (objects) can be created, and any JavaScript that runs for more than five seconds in a function call will be terminated with an exception.
Note also that scripts will pause frequently to minimize CPU usage. Scripts will not run during a phone call, if a window is inactive, or if another iPhone application is running. Scripts will continue to run during QuickTime playback—though there is no way to control the playback with a script.
Eight windows OK. Nine? Nein.#section4
Finally, there are limits in the Mobile Safari browser itself. The user is only allowed to open a total of eight windows. You can create a new window using either window.open() or “_new” as a link target attribute. If you try to open a pop-up when there are no windows left, the user will see an error (“Could not open a pop-up because there are too many pages open”) and the page load will fail. This also triggers a bug in the current version of Mobile Safari: the browser history in the original window becomes unusable. My advice is to open links in the same window and let the user control the creation of new pages.
Missing in action#section5
As you explore the iPhone, you’ll be happy to learn that the browser works surprisingly well. Still, there are cases where functionality is either missing or behaves differently than it does on the desktop.
Much of what’s missing in Mobile Safari is missing because the user is working with a finger, not a mouse. There are no gestural equivalents to many familiar desktop actions, so corresponding events cannot be generated. When developing on the phone, you’ll find that events for cut/copy/paste, drag and drop, or selection changes (select/unselect) do not fire. Other events behave differently on the phone—most notably mouseDown, which fires after the completion of a tap instead of at the beginning.
In a similar vein, you’ll find that there is no multiple-selection mechanism, since there is no Command or Control key to use while tapping. This may be a good thing: how many sites have you seen with a note to “hold down the key” next to the <select> element? Multiple selection is not an intuitive action for many users.
It’s not surprising that the showModalDialog() method doesn’t work either, since there are no such windows on the iPhone. The same is true about the print() method—there is no way to get printed output from the phone.
There are also issues that arise because of the simplified user interface. After using the phone for awhile, you’ll notice that there are no open or save dialogs. Indeed, there is no file system that’s visible to the user, so it’s not surprising that the <input type=“file” ...> does not work—there’s no way for a user to pick the file to upload.
Likewise, you’ll find that download links may not work. If the linked file is a known content type, then Mobile Safari can display it directly; if the file type is unknown, an error dialog will display (“Safari can’t download this file”) since there is no way for a user to store it. The valid content types on the iPhone are:
- JPEG, GIF, PNG, TIFF
- Excel, Word (converted to HTML on demand, they are not editable)
- Plain Text (.TXT)
- MOV (QuickTime)
Be aware that the following file types will not work in Mobile Safari, even though they are supported in the desktop version of Safari:
- BMP (Microsoft Bitmap), PICT (Macintosh Picture)
- RTF (Rich Text Format)
- SVG (Scalable Vector Graphics)
- AVI (Video for Windows), MPEG
Finally, there’s an interesting behavior when scrolling with a script: window.scrollTo(0,1) will hide the address bar in Mobile Safari. Use this trick with care, since it hides the refresh button and can lead to usability problems.
The sincerest form of flattery#section6
If you decide to build an application that tries to mimic the iPhone user interface, you’ll want to stick to some of the standards set by Apple.
Of course, you may choose your own color scheme and other branding elements, but remember that sizes for controls, fonts and other interface elements were chosen by Apple to maximize usability. You’d do well to follow their lead:
Fonts:#section7
- Use Helvetica.
- Use bold
font-weightto maximize readability (remember, your design will often be used in daylight conditions). - Use normal
font weightfor secondary information.
Lists:#section8
- Each row should be 44 pixels high.
- Set text at 20px.
- Inset text 10px from edges, and center vertically in row.
- Make controls 29px high, with 12px bold text and a 5px border radius, centered vertically in row.
Groups:#section9
- Group items in a 300px wide box with 8px radius (10px on each side of box).
- Set text at 20px.
- Inset text 10px from edges.
- Place labels above group box.
- Inset labels 20px (so that they line up with 10px inset for group box and 10px inset for text within the box).
Standard colors:#section10
- Use #d9d9d9 for borders and list dividers.
- Use #c5ccd3 for light blue (background).
- Use #4c566c for dark blue (group box header).
A picture is worth a thousand words. Here’re some simple HTML and CSS examples that illustrate the way to define these UI elements: list example, group example.
Wire tap#section11
Generally, it’s not a good idea to sniff the user agent when developing sites: the whole point of web standards is “one size fits all.” It’s much smarter to detect JavaScript objects and deal with the browser’s deficiencies:
if ("showModalDialog" in window)
{
// show a modal dialog
}
else
{
// the iPhone cannot show
// a modal dialog, so do
// something else
}
With the recent announcement of Mobile Safari on the iPod, you may find it necessary to detect the different types of hardware being used. The iPhone’s user agent will look something like this (line wraps marked » —Ed.):
Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) » AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 » Mobile/1C25 Safari/419.3
We don’t yet know what the user agent for the iPod will be, but it’s pretty safe to assume that the platform string won’t contain “iPhone;”. If you need to know that the browser is Safari, then you can use “Safari/” and “Mobile/” will indicate that the visitor was using an iPod or iPhone. Note that “AppleWebKit/” can be present even when the browser is not Safari: this will be the case when other applications and devices, such as NetNewsWire and the Nokia S60, use Web Kit to implement a browsing environment.
Again, the best use for this information is gathering statistics, not blocking users from content.
Resources#section12
Of course, you’ll encounter problems in your own development that I haven’t covered in this overview. I’ll finish this article by mentioning some resources that I’ve found useful in my own work. I think you’ll find that these sites will quickly find their way into your bookmarks:
- Apple—The mothership is the first place I look if I encounter a problem.
- iPhoneWebDev.com—A resource for more advanced information on the iPhone. If I don’t find what I need at Apple, this is the next stop in my browsing.
- John Allsopp’s CSS3 support on iPhone—John Allsopp is documenting the extent of CSS3 support on the iPhone. This is a great resource when using more advanced CSS techniques in your designs.
- The iPhoneWebDev Google Group—The only stupid question is the one you don’t ask. This Google group is a great place to connect with other developers who are targeting the iPhone.
user-scalable is part of the content attribute, not its own attribute, so:
should be:
Craig I read the first one and the second one is also very good written! I think everyone can agree that size matters for me 480×320 pixels (landscape) is the best option so I will buy it next month and check how it really works! Regards
I noticed how some websites rushed to create subdomains like iphone.somedomain.com when the iPhone first came out. But, now that mobile Safari is appearing in other places (like iPod Touch) that line of reasoning doesn’t make sense.
I realize (and agree) that the best practices is to have one web address where all of your users can go. But, since not everyone actually takes that approach I’m just curious as to what people would actually call their mobile Safari friendly site?
I think maybe it’s time to ditch those iPhone specific URLs since no one’s going to remember them.
James, thanks for spotting that! I’ve let the editors know so we should see an update later today.
-ch
I had a hunch that the multi-touch UI would make it into other devices offered by Apple. Using iphone.domain.com or domain.com/iphone seemed shortsighted to me.
In the long term, I think the most important thing about the iPhone/iPod is that they raise the bar for mobile devices. I think there will be a lot of manufacturers that follow Apple’s lead — making devices that use the real Web, not some dumbed down version. (Some manufacturers are already doing this, more will follow just to remain competitive.)
The best way to look at the problem is from an information architecture point-of-view (specifically in regard to usability.) From that vantage point, it seems that domains like mobile.domain.com and domain.com/mobile make the most sense. It lets the user get to a part of the site where layouts can be larger and less essential content can be filtered out.
-ch
Is there a reason to not use relative font sizes? And, by the way, what is the calculated default for font size in Mobile Safari?
One problem I ran into as a developer is that while Mobile Safari supports basic authentication, the media player doesn’t. What this means is that when Safari hands basic auth-protected video off to the media player, you get an error and it doesn’t stream.
I’ve filed a bug report with Apple for this, but no news yet!
How about ie.somedomain.com, firefox.somedomain.com, 800×600.somedomain.com, or maybe combined firefox.800×600.16bitcolors.somedomain.com…
Isn’t it the wrong direction to develop pages specific to some devices? I think you should rather try to make your sites flexible and accessible so you can view them from any browser. So now it’s not only the iPhone, but also iTouch and the Samsung F700 and so on…
That you should develop mobile pages for every single device. I think it’s more that you should be aware of mobile devices and that this article shows some examples of things to consider. Of course, as more mobile devices come up, you should have a more abstract approach to that.
First apple has commercials stating the iphone as not having a “watered down version of the internet”, then I hear “making devices that use the real Web, not some dumbed down version”, but here we are as developers trying to figure out how we need to rewrite websites to accommodate this device.
If this is really a true browser and not a watered down/dumbed down version then we should not need to change our code.
As for the article, it is well written, and will be very useful to developers who need to be concerned with iPhone/iPod users. My comment is not to detract from the article, only to point out the flaws in apple’s “mobile web”.
While I know this article primarily focuses on the iPhone, my question relates to the mobile web in general, including the iPhone. Have we reached a point in the mobile web where they standardized the protocols used by mobile devices?
Last I heard, each phone for instance, had its own standard and that meant different style sheets etc. for Nokia, Motorola, Samsung, iPhone, and likewise for other mobile devices like PDA’s.
Any suggestions on some good resources regarding considerations for developing mobile web applications to work across a wide number of devices?
James Luterek, if you have to rebuild your whole site to accomodate the iPhone, I think you might have built the website in the wrong way in the first place. A well-designed web site that follows the standards and guidelines set down by W3C and web design experts shouldn’t need much more than a new CSS file to accomodate the iPhone. If your site requires heaps of more changes than this, it’s clearly not well designed.
Oh and what’s the deal with the fixed font sizes? Can’t a relative font size be used? On a default installation, what will e.g. “1em” correspond to in pixels?
Asbjørn Ulsberg,
I was trying to state that we should not need to rewrite our code. Unfortunately in my experience the iPhone has not been able to correctly handle most websites, with smaller more simple ones it get does get close. Perhaps I just haven’t seen a website written to well enough to not need iPhone specific code. If you would be kind enough to point an example I would be very thankful.
THank you.
You mentioned that we don’t know what the iPod Touch user agent will be yet but there is a detection script made by the WebKit team themselves.
http://webkit.org/blog/119/webkit-detect-script-updated-for-iphone-and-ipod-touch/
bq. Unfortunately in my experience the iPhone has not been able to correctly handle most websites
Really? That’s not been my experience. Most sites looks great on my iPhone. (Which is good, because I get lost all the time in my car, and Google maps on my iPhone renders beautifully. I wish my iPhone had a GPS. Then I’d be set.)
1) I’m writing and app and I want it to be exactly one screenful. (Screenfull? Screen-full?) I found this when I was searching for ‘mobile safari pixels’–I wanted to know exactly how many pixels are presented to the user when they first load a page in Safari. Since you did 90% of the work for me, here’s the punchline:
Safari is…
* 320w x 356h in portrait mode
* 480w x 208h in landscape mode.
Note that that’s approximately 114k pixels vs. 100k pixels–about a 14% difference in real estate.
2) Writing numbers vs. spelling them out: it looks like you’re following the old rule of spelling numbers less than or equal to ten. However, this makes it tough to skim the page for info since numbers jump out at you and words don’t. For example, compare these two lines:
* Animated GIF graphics must be less than two MB.
* Total page content size should be less than 30 MB.
or…
“JPEG images up to 32 MB will be loaded, but automatically resampled down to the eight MB size.”
When skimming the page, the values ’30 MB’ and ’32 MB’ jump right out at you but ‘two MB’ and ‘eight MB’ don’t. You also can’t compare numbers to words–the brain automatically determines in an instant that 32>8, but it takes a second to figure out if 32>eight. In a case like this, I’d use numbers throughout.
3) Speaking of mimicking the iPhone’s style: iPhone main screen icons are 57x57px and the corner radius is 10px. (My icons are 52×52 to fit 6 across in portrait mode and 9 across in landscape.)
4) James L–it’s possible to make something _work_ in all environments and still _optimize_ for some environments. I see nothing wrong with a site creator doing that if he wants to. For example, there are some (valid) sites that work better on my Axim than on the iPhone (for reasons I won’t go into here since this post is already rivaling the article’s length.) A few tweaks to enhance the experience on any platform are always welcome if the site designer wants to put in the effort. Furthermore, since writing Web apps is the _only_ (supported) way to get apps onto an iPhone, _of course_ we’re going to optimize for the device when we’re writing something that will only be used on an iPhone.
If anyone’s curious what I’m up to, I’m working on a free way to stream an iTunes library to an iPhone or iPod touch via WiFi, either on a local network or over the Internet. Here’s the page for my project:
http://pixelcity.com/iphone-streaming-music/
(iPhone-friendly URL: http://pixelcity.com/iphone/ )
(Not much there at the moment, but you can see the start of a UI. It works but it’s ugly–another day of prettying up and it’ll be ready for release.)
Craig,
You say:
“You can create a new window using either window.open() or “_new” as a link target attribute.”
I don’t get that behavior from target=”_new”. If I have 2 links each with target=”_new”, and I tap one, go back to the page with the links, and tap the second, the second link/page replaces the first. I thought you were saying _new would *always* try to create a brand-new tab, even if it was used twice. It doesn’t seem to be treated different than any other target value. Am I missing a trick here?
bq. “You can create a new window using either window.open() or “?_new”? as a link target attribute.”?
It should of course be target=”_blank”.
The four keywords are _blank, _top, _parent and _self. Specifying anything else in the target attribute will (i) load the referenced page in that window/frame/tab, if one with that name already exists, or (ii) will open the referenced page in a new window/tab with that name.
MobileSafari keeps replacing the previous page/tab with the next one each time I follow a different link with target=”_blank”.
“As you explore the iPhone, you’ll be happy to learn that the browser works surprisingly well” Of course, I would like to get it correctly.
LOL! I’m sorry but if you haven’t been sniffying user agents you have not been deliberately sending anything to a phone UNTIL the Iphone! You’ve just been ignoring the mobile user, and hoping blindly their phone supported flash, javascript, gifs, bitmaps, streamign media, non streaming music and video formats… etc.
Really astounding that images must be less than several megabytes … I’m assuming that’s what’s being said? To me, it would be an extremely unusual circumstance in which we’d include images of that size.
Good analysis, everyone. Very helpful.
As someone who is tech savvy, I do agree with your comments. However, I think that the typical, non-techie is not hypersensitive about these issues and are fine with it.
Use window.scrollTo (0.1) is a strong plus. Especially when intensive press articles in the information services. This surprised me very much that does not support the well-known formats such as AVI or MPEG? I have a format based on these few pages and can not imagine now change the code into another format. Very good article particular section of styles. My blood is always flooded when checking style look at the iPhone. Amendments, modifications and workarounds. ahh
thank you very much for such an awesome post really worth it i think thts te best posted artile on this particular topic