Unless you’ve been hiding in a cave with Osama bin Laden, you know that Apple is selling an iPhone and that it’s a hit. Apple is well on its way to selling ten million mobile Internet devices by the end of 2008. Besides being a great phone, the iPhone also includes a sophisticated new Safari browser. This version is touted as “the most advanced web browser on a portable device” and from what I’ve seen, it deserves this accolade.
So what does this mean for you? Millions of visitors accessing your content on a small display with very high resolution. At some point in the near future, you’re going to want to take a look at your current site design to make sure that it looks good and works well on this new device and its Mobile Safari browser.
(Note: For the remainder of this article, I’ll refer to this new browser as Mobile Safari to avoid confusion with its desktop sibling.)
In this first of two articles on bringing your content to the iPhone, I’ll explain what your options are and give you some guidance for tuning your site and making changes that enhance your users’ experience. In the second part of this series, I’ll examine some of the pitfalls and problems with this new web development environment.
While these articles are specifically targeted at the iPhone, many of the ideas and concepts I’m presenting can be useful and effective with other mobile devices. The processing power of these devices will continue to increase, bringing an end to the “dumbed down” mobile web, and it’s likely that the iPhone is just the beginning of an exciting new chapter in the storied life of HTML.
Time to clean up#section2
The iPhone developers did a really smart thing—they designed the iPhone so that you really don’t need to do anything with your site for it to display correctly. So why am I writing this article? Well, you don’t really need to bathe periodically, either. But dealing with a clean person is much more palatable than one who hasn’t touched a bar of soap for several months. So it is with the iPhone: clean up a few things and your visitors will love you for it.
The first thing you’ll want to do is check your site for compatibility. After that, you can begin to make some simple changes that adapt your content to the iPhone. Finally, you may wish to make a version of your site that is targeted directly at the iPhone: a site fully optimized for the device.
Keep in mind that, like most things on the web, adding support for the iPhone is an evolutionary endeavor: you don’t need to completely change your site overnight. Many of these changes can be done incrementally without adversely affecting the other parts of your site.
Compatibility#section3
First, you’ll want to make sure that your site is accessible by the iPhone. As I said earlier, it’s likely that you won’t need to do much—for the most part, compatibility just happens.
If you’ve been using web standards to develop your site, you’ll find that Mobile Safari works just as you’d expect. Because it uses the same Web Kit rendering engine as Safari on the desktop, it supports—with a few exceptions—the latest versions of HTML/XHTML, CSS, JavaScript, and the W3C DOM. (While Part I of this series will provide an overview of iPhone-friendly development, Part II will detail the iPhone’s deficiencies and limitations, including those exceptions.) Many of the AJAX technologies, including getElementById and XMLHttpRequest, work just like their counterparts on the desktop.
Still, there are some areas in which Mobile Safari will work differently or not at all.
Trouble with the plug-in#section4
The omission causing the most grief for developers is that the Flash plug-in is not supported. If your site relies on Flash, all iPhone visitors will see is a blue Lego-style brick with question marks.
If you rely on Flash for navigation or multimedia, you have a few options, only one of which is truly compelling:
- Wait, possibly in vain, for Apple to add Flash support. It is likely that Flash is not being included due to performance and battery life problems.
- Use browser detection. Those of us who remember the halcyon days of the late 90s, and a web before standards, will know that maintaining different site versions based on browser type is more trouble than it’s worth.
- Rely on web standards. If actions speak louder than words, note that Apple has replaced Flash with web standards on its own corporate website.
Safari for everyone#section5
Developers on both Mac and Windows can use the Safari browser as a proxy for web development on the iPhone. For the most part, the way Safari renders content is identical to the way it’s rendered on the phone. There are some differences and caveats, which I’ll cover in the second article of this series.
Apple also has a website dedicated to web development on the iPhone. The Apple site is a great place to look for the latest news and information: if I’m having a problem with some aspect of iPhone web development, their “Web Development Guidelines” are the first place I look.
The iPhone works well with non-Flash multimedia content—a special version of the QuickTime plug-in is available using normal <object> and <embed> tags. Mobile Safari, however, behaves differently than Safari on the desktop. Embedded movies or audio only display a “play” button which opens the media in a separate window that overlays your content (referred to as “playback mode”). Additionally, you don’t have any control over this playback mode with JavaScript.
Because of these differences, Apple recommends that you add a poster image when you embed multimedia content (Line wraps marked » —Ed.):
<embed src="poster.jpg" href="movie.mov" »
width="456" height="123" ...> The poster image is displayed until the user clicks on it to play the multimedia content. This gives a consistent user experience for both mobile and desktop visitors.
Adapting#section6
After you’ve verified that your site is compatible with the iPhone, you’ll want to focus on some simple changes that give your visitors the best possible experience.
In my opinion, you’ll need to have an iPhone for this type of development. As noted above, you can use the desktop version of Safari to preview content, but the types of changes I’m going to talk about now consist of fine-tuning that content. Unless you are holding a phone in your hand, you can’t tell whether or not your changes are effective. Remind yourself (or your boss) that the IRS would consider the iPhone a valid business expense and pick one up.
The iPhone makes prominent a little-discussed web development concept: the viewport. To deal with the problem of fitting a relatively large web page onto a small phone display, the iPhone’s developers use a viewport to select the part of the page you are viewing.
Conceptually, the viewport is like a loupe whose magnification is adjustable. When you open a page in Mobile Safari, it will render a 980-pixel-wide section of your website (Apple chose this size to accommodate the largest number of websites). The magnification of the loupe, or scaling factor, is set to shrink these 980 pixels to the iPhone’s 320-pixel-wide screen.
As you pinch or spread your fingers, you are effectively changing the magnification of the loupe (and adjusting the scaling factor). Likewise, double-tapping on a page element, such as a <div>, will adjust the scaling factor so that the viewport is optimized for viewing the element.
Thanks to a new <meta> tag recognized by the iPhone, you can control the behavior of the viewport. Imagine a site whose <body> content is exactly 808 pixels wide. By specifying the following <meta> tag, we can tell Mobile Safari how big to make the initial viewport:
<meta name="viewport" c />
This cuts the number of pixels the iPhone has to squeeze onto its screen from 980 to 808. It may not seem like much, but when you consider that the phone’s display width is just 320 pixels, it makes a big difference. In the case of my personal site, it makes the title of each posting readable on the first view—a huge usability improvement.
You also need to be aware that the iPhone adjusts text sizes as the viewport changes. The font size increases automatically to make text as readable as possible. Sometimes this negatively affects elements that use absolute positioning or fixed sizes (especially when using pixels to specify page coordinates). If you find that this causes overflow or other unsightly results, you can easily turn it off using the following CSS rule:
-webkit-text-size-adjust: none;
Alternatively, you can use ems to specify coordinates. Sizes specified this way will increase along with the text size.
In some cases, you may want to use this feature to increase font size for important information on your page. As an example, you could increase type size in a header tag used for a weblog title with a rule like this:
h1 {
-webkit-text-size-adjust: 200%;
}
Styling for the iPhone#section7
Before pursuing further adaptions, consider the hardware we’re dealing with—that of both the phone and our bodies. The screen on the iPhone squeezes 160 pixels into every inch of display space—and you’re using your finger to access that display. If you press your finger against the edge of a ruler, you’ll see it uses somewhere between 1/4” and 1/2” at the point of contact. That corresponds to anywhere between 40 and 80 pixels of display space.
Now, look at your web page. How many pixels are between the items on your navbar? If you answer less than 40, then you’re effectively asking your visitor to play Russian roulette: their 40-80 pixel finger isn’t going to hit your 20 pixel link effectively.
When you use iPhone specific styles, it improves accessibility for someone working on a high-density mobile device. My rule of thumb is to double important elements: bumping a font-size from 18px to 36px, for example. You’ll want to focus both on interactive elements (such as <a> and <input>) and navigational indicators (such as section titles and bread crumb trails).
So how do you use styling rules that apply only to the iPhone? The answer is to use a media query on a <link> tag. The following rule is recommended by Apple:
<link media="only screen and (max-device-width: 480px)"
href="iPhone.css" type="text/css" rel="stylesheet" />
Other browsers will ignore iPhone.css since they have a maximum device width greater than 480px.
Integrating your site with the rest of the iWorld#section8
As you continue to adapt your site to the iPhone, you’ll want to think about how Mobile Safari integrates with other services on the phone. It’s easy to have your page pass information to the Mail, Maps, and Phone applications—all you need to do is craft special hrefs for your links.
A link with a mailto: in the href works as expected—it opens the iPhone Mail application using the specified parameters. You can specify some HTML markup in the body, but I’d advise against it since not all mail clients will handle it correctly. For example, the following will work fine on the iPhone (Line wraps marked » —Ed.):
<a href="mailto:zippy@example.com?subject=Sarcasm » &body=I <b>love</b> <html> mail!">Hi!
And create a message that looks like this:
To: zippy@example.com Subject: Sarcasm I love <html> mail!
However, most other mail clients will create a message with a body that looks like this:
I love <html> mail!
Mobile Safari handles links to Google Maps differently than other browsers, too. It checks to see if a link href begins with “http://maps.google.com/maps” and will automatically load the remaining part of the URL into the Maps application instead of a new web page. The normal ?q=location and ?saddr=start&daddr=destination map queries will be handed by Maps from that point on. Note that since you’re switching applications, the user will have to click the Home button, then the Safari icon to return to your web page from the Maps application. Be judicious when using map links as this can be a disruptive context switch for the user—in most cases it would be wise to provide a map preview on the link so the user can get basic directions without loading the interactive Maps.
The sexiest links ever#section9
Now to the newest and most interesting linking feature on the iPhone: clicking on a link to make a call.
Say you have the following hCard microformat on your contact page:
<div id="hcard-Ernestine" class="vcard">
<span class="fn">Ernestine</span>
<div class="tel">555-1212</div>
</div>
By default, the iPhone will turn the 555-1212 into a clickable link. It will take whatever styling has been specified for the parent (i.e. there isn’t any way to specify an id or class for the automatically generated link).
If you’d like more control over the link that is generated, you can use markup like this:
<a class="call" href="tel:555-1212">Call Me</a>
When the user clicks on the link, it will initiate a call to the number specified. You need to be careful with these links. Many browsers will display an error message because they don’t recognize the tel: protocol. You’ll probably want to hide these links in your site-wide CSS.
a.call {
display: none;
}
And then use your iPhone-specific CSS, to show them with the following:
a.call {
display: inline;
}
Going deeper: designing for the iPhone#section10
After taking care of the structural and presentational aspects of your page, you may want to examine some of your design decisions.
One thing that’s important to remember when working with Mobile Safari web pages is that they will often be served over the EDGE network. This network, based on cell phone technology, is much slower than broadband networks. It also has higher latency—it takes longer for your HTTP requests to reach a server and for the responses for the request to arrive back at the phone.
The feeling is very similar to the days when the 56K modem reigned supreme. And like those days, it’s important to keep an eye on the size of what’s on your server:
- HTML—Leverage web standards to keep markup and page size to a minimum.
- CSS—Use media queries to ensure that a minimum number of rules are loaded and parsed.
- Multimedia—Use QuickTime H.264 encoding and pay attention to bit rates. Reference movies allow you to serve up different sized content using the same HTML.
- Images—Use iPhone-specific CSS to load lower resolution images.
- JavaScript—Be careful about including large JavaScript frameworks—loading hundreds of KB of scripts to show and hide a
<div>doesn’t make sense.
Finally, remember the width of the iPhone screen: 320 pixels (for portrait) and 480 pixels (for landscape). Content that fits naturally within these sizes works best and will require less scrolling by the user. Likewise, content that does not span across multiple columns will be easier for the iPhone user to access.
Targeting#section11
Now let’s talk about taking the big plunge: creating a separate part of your website that is dedicated to iPhone users.
Why would you want to do this?
Again, before we can answer this question, we need to take a high-level look at the surroundings for our web designs. We’re all familiar with the current desktop and the browsers that run in this environment—so much so that we take its high density for granted.
The desktop allows us to do many things at once: browsing, e-mail, multimedia, chat, etc. There’s enough space for us to move our attention between many disparate tasks.
Now look at your iPhone. Typically, you’re only doing one thing at a time—making a call, finding a restaurant, or checking your appointments. The interfaces for these tasks are much simpler, making it much easier for you to focus on the work at hand.
Your website probably has functionality for many different use cases. Some of that functionality may be inappropriate for someone who’s on the go, and this is a great reason to make a site targeted towards the iPhone. If you have e-commerce or other transactional functionality, you may find that your current interface makes transactions cumbersome on the iPhone—and making it easy for people to give you money can be a direct benefit, even if that means streamlining your existing site or creating an iPhone-specific site. Other types of sites, like blogs, with their low information density, don’t need this kind of special treatment.
Once you’ve decided that you want to customize your site for the iPhone, there are things you need to keep in mind:
- Simplify—On the iPhone, less is more. Let the user focus on your content. Use one column layouts instead of two or three columns.
- Size—Bigger is better. Make it easy for the user to manipulate your content. Element sizes should start at 40 pixels and go up from there.
- Emulate—Designs that mimic the iPhone user interface will be more successful. The user doesn’t have to learn new conventions when dealing with your content.
Emulation and frameworks#section12
Let’s take a quick look at some of the tools you can use to help emulate the iPhone UI. Since you’re only worried about this working in Mobile Safari, you can utilize features that aren’t available in other browsers. You don’t have to worry about how a design looks in Internet Explorer—dreams do come true!
- Use the
-webkit-border-radiusCSS rule to create elements with rounded corners. - Apply the
-webkit-border-imageCSS rule to use images for nice looking backgrounds on links. - Use the
<canvas>tag for drawing dynamic images and graphics.
There are also JavaScript-based frameworks being developed to ease the development of iPhone-specific interfaces. One of the more advanced and popular ones is Joe Hewitt’s iUI. If you’ve used the iPhone, you already know how to use his examples.
One final thing to keep in mind when you start this kind of development: make it an addition to your existing site. Don’t force an iPhone to use this special section of your site—it’s an enhancement, not a jail. Likewise, if a user without an iPhone wants to look at this part of your site, don’t block them with some “for iPhone only” nonsense. Remember that the web always works best when it’s open and developers don’t try to outsmart their visitors.
Summary#section13
I realize that a lot of information has been presented in this article—there’s a lot to learn about this new device. But don’t be overwhelmed: much of what I’ve presented can be done incrementally. Start by setting up the <meta> tag with the viewport information and then experiment and test your ideas and changes. In the end you’ll end up with a site whose content is much more accessible from the iPhone. I, and millions of other visitors, will thank you.
Thanks for that interesting coverage of iPhones HTML and CSS capabilities. While the iPhone is not available in Europe yet, it’s good to be prepared.
Sometimes it may be necessary to have two versions of your website: one for web browsers and one for mobile devices. Even if your website is clean you might want to reduce the content for mobile devices and you even might to have a different page flow. The capabilities of mobile devices always increase and the iPhone might be a low end web browser or a high end mobile browser. So it’s ion between the two versions and you have to think how to cover it without making a third version.
Thank you very much for this really interesting article!
So far when I designed a new website I wasn’t considering mobile phones and even just didn’t know that there are special tags for mobile browsers. But as the mobile internet is growing so quickly, it is in deed more and more important to think about the special problems of mobile devices.
I’m a bit disappointed by safari on the iPhone. I have owned the Nokia N770 for a long time now and it has an excellent version of opera installed. The new N800 has an even more advanced version, though both can handle css/javascript/flash. I have yet to find a website which can not be displayed. Although as developers we need to strive for perfection with our code, I think that mobile devices need to learn from Nokia and stop forcing users into a water downed version of the internet.
It depresses me that, after a brief discussion about web standards, the first code I see in the article makes use of the element. I’m also disappointed that the CSS media type of “handheld” is unsupported.
Thanks for the insightful article Craig. I’m also disappointed by safari on the iPhone. James I agree “The new N800 has an even more advanced version, though both can handle css/javascript/flash.” I tested N800 and it’s really great, I like flash on N800 it looks very good. Nokia is the king od mobile devices for me!
I think far too much attention is being given to the iPhone, especially with the issues presented here. When developing for a mobile platform, no one should be focusing soley on the iPhone. That would be about as presumptuous as only checking your site for IE compatability. What needs to be realized is that the reason the iPhone is important is that it is adding to the growing demand for content provided to the mobile web. While I have no problem developing a mobile-specific style, it is arrogant for anyone to assume that I’m going to waste my time developing for one specific device. There are enough incompatability issues already, we don’t need any more.
If you follow the logic of this article, the only conclusion you should come to is that developers should go back to what we did years ago when we had to create different versions of our sites for different browsers and then but a notice on the site saying it’s been optimized for x browser. The purpose of creating standards was so we could design once for all browsers. Should we all start to limit the widths of our pages so people using an iPhone don’t have to scroll horizontally to see everything?
Richard, et. al.: This article is not about creating a version of your site that’s built specifically for a single device. It’s about taking into consideration the viewing environment and the needs of the user–they are very different on a small screen.
The only thing special about the iPhone is that it will allow A LOT of new users to experience the mobile Web. If the layout of your site doesn’t work for them, you’ll want to address the problem or lose visitors.
The biggest downside with not supporting flash (in my opinion) is how much that limits web experiences that include video. From a developer standpoint, flash has certainly become the easiest way to deliver video. Does this mean that iPhone will only support websites that use Quicktime as their video plugin?
Craig, you wrote about the iPhone that “it will allow a lot of new users to experience the mobile web”. I think that is true if you just have a look at the absolute numbers. But there are billions of web users out there and the number of mobile web users is so small yet. Only the few more iPhone users will not make a difference. And even if they do you still have to get them onto your site. Will iPhone users find the iPhone enhanced web sites?
Your comments say you are not telling people to create different versions of their site specifically for one device, yet in your article you say
“Finally, you may wish to make a version of your site that is targeted directly at the iPhone: a site fully optimized for the device.”
“Going deeper: designing for the iPhone”
“Finally, remember the width of the iPhone screen: 320 pixels (for portrait) and 480 pixels (for landscape). Content that fits naturally within these sizes works best and will require less scrolling by the user. Likewise, content that does not span across multiple columns will be easier for the iPhone user to access.”
“Now let’s talk about taking the big plunge: creating a separate part of your website that is dedicated to iPhone users.”
To me, this sounds a lot like you are saying we should all develop sites specifically for the iPhone to make yours and the millions of other iPhone users happy.
Adam, it’s true that there are not a lot of mobile web users. Yet.
Take a look around and count how many white earbuds you see in your daily travels. Now think about each one of those people migrating to an iPhone or some similar type of mobile device and you’ll get an idea of the scale of the coming change.
The iPhone is just a beginning.
And they’ll find the content that best suits their device. People share links.
Richard, these recommendations are options, not edicts.
Do whatever you want. Just be aware that your decisions COULD impact a visitors experience.
The comments people have made about making multiple versions of a site are quite valid. This article suggest, even advocates, the sort of forking we have been trying to avoid for years. It is for this same reason that I did not approve of the .mobi top-level domain.
I’m sorry, but although this is a well-written and interesting article, I think this sort of encouragement is a backward step for A List Apart.
I gotta back Craig up on this one. Phones are stealth thin clients, and while mobile web is not new, it just got a huge boost in momentum from Apple. If you want to look at the numbers, don’t look at PC users vs. smart phone users. Look at the total number of mobile phone users, and think about how it is more than likely that more and more of these users will be accessing the mobile web as phone manufacturers feel the need to compete with Apple.
Also, just going by iPhone users, keep in mind that these are people that are willing to drop $500 – $600 on an unsubsidized phone. iPhone users are people with money to spend, a very desirable group from an advertising and marketing POV.
Rather than complain, you should be thanking Craig for giving you the heads up so you can stay ahead of the curve in implementing these changes. From a purist standpoint, mobile web might be a step backwards, but real artists embrace challenges and limitations.
I believe that given enough time, most people who design for the web realize they are information architects at the core. We become devoted to standards, not the client apparatuses no matter how glorious they may be.
Mike, what’s the first thing you get from Googling “define:Information Architecture”?
bq. Term used to describe the organisation of information, the content, functionality, navigation and usability of a web site.
In the case of the mobile web, the client apparatus has a direct and substantial impact on functionality, navigation and usability.
You state: “Rely on web standards. If actions speak louder than words, note that Apple has replaced Flash with web standards on its own corporate website.”
Very good article but what’s the web standard Apple is using? If you’re saying Quicktime, then I would argue the statement. How can Flash not be considered one if the penetration of the player is even higher than QT. I rarely design Flash content but in the end, both technologies are not necessarily “standards” but different means to an end.
Very few companies will be issuing iPhones to employees, like Blackberry hand-helds. But still, the iPhone and everything to come from Apple sure may tackle the younger, non-executive market. Yep, I have one– and I’m not executive. I have it because it’s VERY cool, and has everything I want in a mobile device. Unfortunately, the service isn’t that great as a phone. How many dropped calls did I have yesterday….
I’m also a Web Producer, and am excited about making some content that works really well on an iPhone. I’m impressed with the Web applications available already, as well as the tools (iUI).
I let out a sigh when I used the iPhone Safari browser to view my Web sites… and they looked just fine, apart from missing Flash. Thanks, Apple. Nice article too!
I was surprised that Apple chose not to support the handheld CSS media type – not even a preference or an option. This _is_ a handheld device is it not? I get that Apple wants to provide the whole web and all, and Safari does handle big and wide sites quite elegantly. But at the same time, we have a handheld device here and a “whole entire site”:http://developer.apple.com/iphone/ at Apple dedicated to optimizing for the small screen, complete with a whole set of iPhone-only markup and CSS techniques to facilitate this optimization. And there is clearly a large and growing movement to build sites and applications _specifically_ for the iPhone.
Why not just support the handheld media type and be done with it? I’ve already optimized several sites for handheld media – they are now like the tiny little towns on Route 66 that got bypassed by the interstate. Apple could _own_ this space in no-time with all the rush to build iPhone-compatible layouts. With Apple’s current guidelines, I feel like I’m having to fork my code unnecessarily.
The iPhone should support the handheld media type, at least as a preference or an option. And all that font sizing and viewport setting should in my opinion be set in the styesheet and not in the markup. I love my iPhone, but this is the only area where I take issue.
iPhone is the new Internet Explorer 4…
Please, whenever you hack your website for iPhone, keep in mind that it’s not the only mobile browser in the world. It’s not even the only WebKit-based nor Acid2-compliant mobile browser (S60, Opera Mobile).
It’s nice to see that there’s such wide support for the iPhone (albeit from iPod users), and as much as I agree with Craig that the mobile internet ‘revolution’ is inevitably going to grow in both coverage and usage (more so when internet speeds and g3 actually get up to speed).
But although Craig doesn’t advocate the creation of an iPhone specific site, and in fact only offers it as an option, it’s plain as day that Apple would love us all to create an alternative site for their format.
Their creation of a huge knowledge base of supported micro-formats and new methods, and their ignorance in ditching flash in favour of yet another naff Quicktime format (that unfortunately gained more weighting when Youtube decided to start converting all it’s videos to follow the trend); shows to me that Apple, like Microsoft in past year, prefer to write the standards and rules that we all must follow rather then making use of well established technologies and techniques.
Jesus even media temple jumped on the bandwagon (granted their time could be better spent solving other issues), but it does show that more and more “trend” following companies are jumping to kick their developers into creating new sites and systems implementing Apples new obscure, phone specific CSS.
I’m very much with Joe’s observation in that they should have taken a more industry standard approach and implemented the hand-held media type as its base.
In the end though I expect if sales are big enough (which with all the iPod fan boys out there they will be), and mobile networks finally get their 3G up to speed; we’ll all find ourselves developing iPhone friendly sites to please a directors whim (who will of no doubt got the idea off their 11 year old kid).
Lets hope Nokia doesn’t release a contender and its own set of CSS rules, then Sony, then Motorola.
If they wanted a new standard it should have gone through the W3C, granted they may not have been able to make the product for 8 years while they argue over semantics but the standard would have been recognised.
Anyway, I’m ranting, back to work.
I should have been a little less curt in my comment. I liked the article and thought the reasoning in it illustrates well the challenge we face in designing for the mobile web, and I’d like to stress the word design. I guess that was the point I was trying to make, that my primary focus is structure with design being secondary.
As you demonstrated in the article, design solutions for the iPhone (and the rest of the mobile web) should be left to CSS. But I will never change the structure of the information based on what type of client is reading it; proper structure is the path to functionality, navigability, and ultimately usability.
Is it possible to detect the iPhone on the server using user-agent?
hcabbos, You’re absolutely right — neither QuickTime or Flash is standard in the sense that it’s supported without the use of a plug-in.
To be honest, I’m not an expert on web video. I do know that Apple pitches QuickTime as a “wrapper” around video standards such at MPEG-4, H.264 and AAC. From what I understand, Flash relies on proprietary codecs (although they have announced H.264 support in a future version.)
From a pragmatic point-of-view, it doesn’t really matter: QuickTime is available, Flash is not.
Joe, you’re not the first person to wonder about the “handheld media type”:http://my.opera.com/dstorey/blog/iphone-and-developing-for-mobile
All that I can suggest is that you sign up for a “free ADC membership”:http://developer.apple.com/products/online.html and submit a bug report. From what I’ve seen, the Safari and WebKit developers are very responsive to this kind of feedback from the developer community.
And if you see that your bug has been marked as a duplicate, that’s a good thing: it means that other developers share your concern (and therefore carries more weight with the people that can fix the bug.)
Mike, From what I’ve seen, there can be benefits to restructuring information on a mobile device.
The main reason is that you want to see *less* information on a mobile device. Filtering some content can actually improve the user experience.
Of course, this could be done with CSS and “display: none;” but that means you’re sending a lot of structural markup that is unused (and wasting bandwidth on a device that doesn’t have much.) The alternative of forking your information structure and maintaining two versions of a site is also unattractive.
The best course of action is to evaluate development on a case-by-case basis: know the costs and find the solution that fits best.
As far as the user agent is concerned, the iPhone specifies this platform information: “(iPhone; U; CPU like Mac OS X; en)”. There’s more detail in the “iPhone guidelines”:http://developer.apple.com/iphone/designingcontent.html
As others have pointed out, you shouldn’t place too much weight on that string, since there are other mobile devices that can benefit from handheld markup and styling.
By sheer coincidence, Cameron Moll released a PDF book entitled _Mobile Web Design_ on the same day of my article.
I took a look at the preview pages and it looks like a great resource for anyone thinking about developing for mobile devices: especially for ones other than the iPhone. There is more information on “his weblog”:http://cameronmoll.com/archives/2007/08/mobile_web_design_the_book_available_august_28/
Please do remember that in a global scale, iPhone is in a niche — and will stay there for a long time.
Nokia, for example, is shipping more than 1.1 million phones a day (“see here”:http://www.tgdaily.com/content/view/33204/118/ ), so they’ll sell more phones in nine days than Apple during the rest of the year. Further, 1.1 million is number of real shipments, not predictions.
N95 has sold more than iPhone and it is a quite capable phone, but I haven’t seen any tips and tricks to made sites just for it. Maybe ALA would pick the topic?
Thanks for the info! As an iPhone lover (I never leave home or the office without it) and someone concerned with making sure my websites are as mobile friendly as possible, I will use this info and will encourages my own readers to read your article.
I’m looking forward to installment #2.
I’m shocked that ALA has allowed an article to be published that goes against it’s prior preaching of code once for all browsers and devices. Device specific design seems like a trip back to the dark ages when everyone “optimized” their site for a specific browser.
Yes, the iPhone is neat and shiny but what about the 650 million other mobile-web devices out there? The iPhone only accounts for 0.046% of mobile devices.
Here is a graphic that will help put things into perspective -> http://www.russellheimlich.com/blog/the-iphone-is-not-the-only-mobile-web-device/
I think it is absurd that Nokia and Apple haven’t implemented the support for handheld mediatype in their browsers. It would make everyone’s life so much easier helping the developers and users both. Fortunately Nokia has give people the opportunity to have their “say in the future development of the S60 platform”:http://www.s60.com/business/productinfo/wishlist/displayWishDetails.do?wishId=1021&activeCat=10. I even think that Nokia is subconsciously admitting that it might have been a mistake not to support the handheld media as “discussed on the Boagworld forum”:http://boagworld.com/forum/comments.php?DiscussionID=2572&page=1#Item_5. Of course I might just be imagining.
Another thing what I don’t understand is the fuzz about iPhone. Of course it is sexy and cool and every geek must have a one but as mentioned before it’s sales are only a needle in a haystack. The one thing that I consider important in the whole iPhone phenomenon is that it brings more attention on the whole mobile web issue and even main stream users will eventually understand that they have the Internet in their pockets.
How do you detect an iPhone that access the site?
I would have prefered an article on the growth of Opera Mini and to a lesser extent Opera Mobile. There is a far wider user base out there. I’m a new student to all this but if i was to adapt a site i’d be optimizing it for Opera Mini.
“Opera Mini Market share”:http://operawatch.com/news/2007/09/opera-minis-growth-over-the-past-5-months-027-of-total-market-share.html
Thank you so much for including the numbers about how many mobile devices Apple is selling. This great post (and the one on “Switchy McLayout”) have helped me to decide on building sites to accommodate screens that are under 640px.
I can’t wait to test these ideas out on my Boss iPhone. (That line about her buying ME one back fired…)
The first question in my mind, how to build my website to really accommodate little devices like iPhone and others? It’s like “extensibility” question on the web?
At last time, I am testing one version of my website which is extensible, but I suppose that isn’t enough or satisfying. I see as the Safari browser implements tools to improve for displaying media (image for example). It’s very interesting.
But a subject of your article makes me being attentive : “the tag with the viewport information” !
I would like to learn more about that.
Can you really explain me how is it used?
Thank you for your answer.
I own a iPhone now, thanks for the post of iPhone’s HTML and CSS capabilities.
One of the main limitations I’ve noticed with the iPhone concerns scrollable divs within the page. For example “wide comic strips”:http://matthewjamestaylor.com/comics/ogga-cyclone are no longer scrollable even though they still work on the full Safari.
I imported mine as i live in Germany and it isnt out here yet, a wonderful peace of hardware..
Hm, we’ve been spent some long hours XSLT’ing our XML-based Flash flashcards for web browsers, and lo and behold, guess what’s on iPhone Safari’s list of unsupported technologies?
Here’s the full list, from the iPhone Dev Center:
Safari on iPhone does not support:
* window.showModalDialog() or window.print()
* Mouse-over events
* Hover styles
* Tool tips
* Java applets
* Flash
* SVG
* XSLT
* Plug-in installation
* Custom x.509 certificates
* WML
* File uploads and downloads
Hm, we’ve been spent some long hours XSLT’ing our XML-based Flash flashcards for web browsers, and lo and behold, guess what’s on iPhone Safari’s list of unsupported technologies?
Here’s the full list, from the iPhone Dev Center:
Safari on iPhone does not support:
* window.showModalDialog() or window.print()
* Mouse-over events
* Hover styles
* Tool tips
* Java applets
* Flash
* SVG
* XSLT
* Plug-in installation
* Custom x.509 certificates
* WML
* File uploads and downloads
Love the great feature of the iphone. It has the futuristic look and it works great. Looking to get my hands on this phone coming feb 2008! Iphone rocks!
I’ve been fighting this issue for days and the Quicktime tags just don’t work…
I had it working somewhat but ONLY if the poster image was a full path to it and the video was NOT full path AND in the same folder. I am using the embed tags exactly as described in Apples site and here.
Hello!
First of all thank you for posting such a great and easy to understand info.
Some links however are broken (do not need .html part):
http://www.css3.info/preview/rounded-border.html
should be
http://www.css3.info/preview/rounded-border/
Same goes for http://www.css3.info/preview/border-image.html
Regards! Saf
This is a great article, but I would like a little more info on the section where you talk about adding video to an iphone optimized site. Do you have any resources for doing this?
Thanks, great article!
I’m wondering how the hcard code handles International calls where numbers need to be omitted or added to dial out of the country and into another.
For example, the standard for displaying a French phone number with country code is: “33 (0)4 68 71 31 58” and you assume that an International caller knows to ignore the Zero in parentheses. Does the hcard have similar ignore if international protocol?
You mentioned using css to load lower res images for the iPhone, did you mean using css background images, or some other technique? Css background images are not really appropriate in a lot of cases as they don’t have alt tags.