Good morning. This is Designing Web Content for iPhone. I'm Richard Williamson, the manager of the iPhone web technologies group. Even though this session is about designing web content for iPhone, I want to start by saying that you don't have to design your web content for the iPhone. As you already know, Safari on iPhone is a desktop caliber browser. That means that it can display the same pages that are displayed on the desktop.

And that's because the technology behind Safari on iPhone is the same as the technology behind Safari on OS X and now Safari on Windows. This is an important point because you can develop sites on the desktop and be confident that they'll work well on the iPhone. And now with Safari 3.0, we have some sophisticated development tools built into Safari that you can use to optimize your content, not just for the desktop, but also for the iPhone.

So what are we going to talk about in this session? First, I'd like to walk you through the experience of browsing the web with iPhone. Then I'd like to cover a few of the features of Safari on iPhone and then talk about how you can specifically optimize your sites for deployment to iPhone.

To show you what it's like to browse the web with iPhone, I've put together a few movies of browsing on iPhone. I'd like to show you those now. When you load a page on iPhone, it's very natural to pan the page up and down with your finger. The blue circle represents your finger.

To enter a URL it's a simple matter to click in the field and then using the keyboard type in the URL. In this case we're going to go to news.google.com and hit the go button. And the page loads. One thing to point out is that we do scale a page to fit, and at this size, text really isn't legible, so we've added a feature called double tap. That lets you focus in on a specific element on the page.

We'll talk a lot more about double tap. The icon in the corner there is what we call page view. And the iPhone doesn't have Windows, but we all like tabbed browsing. So page view lets you look at multiple documents inside Safari. And if on the desktop you clicked on a link, it would normally open a new window. On iPhone, you click on a link and it opens up in page view, like this. In page view you can manage your documents, close them and select them, keep a document set open.

Safari on iPhone has auto complete of course, auto complete will match on your history and on your bookmarks. So I can type A, for example, and it'll pull up URLs. I'm going to go to www.Apple.com, load the page, browse to another page. Of course on iPhone we have bookmarks, too. That's what the other icon does at the bottom of the screen here.

Bookmarks on Safari on iPhone synchronize with your bookmarks on your desktop. These are the same bookmarks. The same hierarchy it follows that you have on your desktop. Let's load a few, New York Times, navigate to a few links. History on the iPhone is also in bookmarks. Let's load a few more links. This is the WWC website. Maybe on final link here, the Yahoo finance site. Zoom in on an article.

Let's go back to bookmarks and look at history. History is the top folder in the bookmarks list here. We can go back and look at documents that we've previously loaded. Safari on iPhone also has full support for PDF. Let's go back and load a PDF document. This happens to be the iPod feature guide.

And you'll not as you scroll through the document, the page indicator updates. And just like you can zoom in on web content, you can also zoom in on PDF content. And you can rotate the iPhone to look at any landscape, too. I think this looks great. So I'd like to show you, too, integration with the other applications on iPhone. Let's do a search for a local restaurant, LuLu. It's very close to Moscone, here, great restaurant.

Here's the Google page for it. Now I could make a phone call directly from the web page, maybe make a reservation, or look at their website, look at the menu. Instead, I'd like to look at it in Google Maps on iPhone. And you can see that it's just around the corner from Moscone here. And then we can look at the details for the restaurant.

Now I'd like to show you the Safari TV commercial. You may have seen this before, but I'd like to show you it one more time. Could I get audio, please?

Kind of, sort of looks like the internet. It's just the internet, on your phone.

That's Safari on the iPhone. We're really proud of it. Now I'd like to talk specifically about some of the features of Safari. Of course, we support all of the latest, greatest standards because it's the same engine as Safari on OS X and Safari now on Windows. But I'd like to emphasize one additional point.

Web standards are evolving. There's a lot of current active work to include the capabilities of web applications, in particular the WHATWG group in HTML5 and the W3 are doing a lot of work to improve, especially in areas like offline storage, offline caching and enhanced media support. So you can expect that these standards will evolve over time. And of course, Safari on iPhone will pick up these changes.

We support the top four image formats on iPhone, GIF, JPEG, PING, not PNG, it's pronounced PING, and TIFF. We support animated GIFS up to a certain size, 2 megabytes. Beyond that we'll just show the first frame of the animated GIF. And the maximum decoded image size on iPhone is eight megabytes, with one exception, and that is JPEG's. we can sub sample JPEG's to show much larger images.

This is what that means. With a JPEG, we can decode to a reduced size, effectively using 16 times fewer pixels and a corresponding reduction in memory. So 4 by 4 pixels like this get sub sampled to one, and this allows us on the iPhone to show images generated by the latest generation's digital cameras, like the new Canon Mach III.

In fact, this is an image directly off the Canon website, rendered on the iPhone. Now, of course, typically if you're designing content, you wouldn't want to have such a large image on your website, you'd want to reduce the image so that it's more appropriate for the iPhone, but it's nice to know that we do have this capability.

There are a few other resource limits on your iPhone. The maximum size of your HTML, CSS and JavaScript is limited to 10 megabytes. That's an awful lot. You can do a lot with that limit. As I mentioned already, decoded image size is limited to eight megabytes. Now on the iPhone we want to provide a secure environment for executing your web applications and web pages.

So to that end, JavaScript execution is limited to five seconds. That means for each entry point into the interpreter, either from a timer or an event, you have a maximum of five seconds execution. This really keeps the responsiveness of the device pretty fluid. You're also limited to 10 megabyte of allocations on each of your web pages. If your script exceeds either of these limits, you will get an exception. And most likely that exception is going to be at some random point in your code. So try and stay within these limits. They're pretty generous, and you can do an awful lot within these limits.

Finally we have a maximum of eight documents that can be opened at any one point in page view. So if you design a site where you have lots of new windows opening up, keep this in mind. And a few extras here. Of course, we do support PDF natively. We have a rich support for audio and video formats and we'll talk a lot more about that later in the session. No Flash and no Java.

So, we've seen what it's like to browse with iPhone. We've seen some of the features of Safari. Now I'd like to talk specifically about optimizing your sites and applications for iPhone in two areas. Some good design practices and then pages that are written specifically for iPhone. Now these good design practices are applicable to the desktop just as much as they are to the iPhone, so some of this may be obvious to those of you who have already done a lot of web design.

Separate your HTML and your CSS. Don't replicate style inline in your elements inside the HTML. Factor that out into a CSS document. Use well structured and valid HTML. With the new development tools that we have built into Safari 3.0, this is very easy to do. Take the time to validate your HTML. You can do this on Windows as well as OS X now. And there are a lot of other validators out there that you can use.

Size your images appropriately. Don't have a five megabyte image on your site and then display it as a thumbnail on the client. Use small images as background images that get tiled. Don't have a large background image. And finally, avoid framesets. I hate framesets. Better yet, don't even use framesets at all.

This is a general principle in terms of static's and layout. It's typically not so good to have text that fits the full width of the screen, instead break your content up into columns and blocks like this. Not only is this more aesthetically pleasing, it also happens to work much better with double tap.

Size does matter. Especially on the iPhone. The Edge Pipe is much smaller than the WiFi Pipe, maybe by a factor of 10 or so. So if you're concerned about your applications loading quickly on iPhone, really think about the bandwidth of the Edge Pipe. Here are two example pages, the page on the left, news.google.com is a very large page with lots of resources, lots of text and lots of images. It's 242 K. It takes about 19 seconds to download over Edge. The page on the right is much smaller, much less content.

It's 643 K. Takes about 51 seconds to download. That's because this page turns out to have about 300 K of JavaScript, mostly redundant. It's used, that JavaScript is used on other areas of the site, but isn't used on this main page. Don't download resources that you aren't going to use.

What about the baby web? Well we don't do transcoding. We'll render the pages as you intended them to be rendered. We don't support WML. We do support XHTML mobile documents. XHTML mobile is a spec that includes a subset of HTML. And because it is a subset of HTML, we render them just fine on iPhone. There are quite a few sites out there, like the Google.com search site that is an XHTML mobile site.

.mobi domains. There's nothing particularly about .mobi domains, but typically sites of .mobie domains are targeted towards mobile devices, so we render these just fine. This is BMW.mobi. now you may have noticed that both of these sites are actually rendered at 100 percent? And that's because we have a special viewport for these kinds of sites, XHTML mobile and .mobi sites at .mobi domains. And we'll talk a lot more about the viewport in a moment.

Here's the Safari user agent. This has leaked out already on the net. People are seeing this pop up quite a bit. Just a few things I want to point out. The platform is iPhone, not surprising. We've added a couple of different version strings to the user agent. Version 3.0 will be the same version across all platforms. So if you want to look for, if you want to get aggregate statistics for browser usage across all three platforms, you really want to look at this version 3.0 string as well as Apple WebKit and Safari.

We've also added a version number for the mobile platform. Now I'm not going to go into a lot of detail about how you should or shouldn't use the user agent string because there's a lot of great sites out there that describe this already. I'm going to point you to a couple. webkit.org has a great site about good practices in terms of looking at the user agent string. And there are other techniques that you can use to conditionally load content or change content, including object detection, and there's two articles at developer.apple.com that talk about that.

So one thing that you can do to have conditional content just for the iPhone is to use media query. And existing media queries look like this. You can a media rule like at media screen or at media print or at media handheld and this will select a style sheet based upon the target media type.

On iPhone we don't support the handheld or print media type. You might ask why don't we support the handheld media type? And the answer is that sites that use the handheld media type today typically were designed for low end devices and we don't want to show low end content, we want to show the web in all of it's full glory.

With CSS3, media queries have been substantially improved. Now you can use an expression language to select a style sheet that's tailored to the capabilities of a device. This is a draft spec and here's the URL to the W3 site that covers the spec. let me walk you through what a query would look like using CSS3. so I'd like to specify an expression that selects for iPhone.

So first cut I could do something like this, the screen media type and the devices that match the device width of 320 or 480 pixels and these happen to be the resolutions of the iPhone in portrait and landscape. And this would select the iPhone.css style sheet. But thinking about this a little more, I really don't want to limit myself just to the iPhone, I want to select for all devices that have similar small form factors. I really want to select all devices that have a screen width of less than 480 pixels.

So that's what this query would do. Screen media type and a max device width of 480 pixels. And it would specify the small device CSS. Now this is great except for one other issue, all the browsers don't support CSS3 media queries. So there's a new keyword that you can use in this expression language only, and older browsers who encounter this expression will not recognize only and not match at all so they wouldn't load the style sheet. So this is the expression that you should use if you want to specify style just for the iPhone.

Now in your content, you've got to make small content that's going to load a style sheet just for the iPhone and an alternate style sheet for the desktop. What does that alternate style sheet look like? It looks like this. This is gone match on any device that has a device width greater than 480 pixels.

And this would work even for browsers that don't support CSS3 media queries because they will recognize the screen media type and then ignore the rest of the expression. So using these two CSS3 media queries together, the same HTML document can be styled both for the iPhone and for the desktop. Of course, alternatively, you can use a CSS media rule like this, with the same expression syntax.

Here's an example of a page that has a three column layer that works great on a desktop with a wide window. But on iPhone, I'd like to have more of a vertical orientation, so here's the same document without the window chrome and for the iPhone. Same HTML, different CSS.

So that covers some general good design practices that aren't specific to the iPhone. Now we're going to cover some things that really are specific to the iPhone. So a disembodied hand isn't the same as a mouse, as far as input devices are concerned. Your finger is much bigger than a mouse cursor, so things like wind density are important.

And the hand on the iPhone has a lot of responsibilities in addition to emulating a mouse, so we'll talk more about that in the upcoming slides. The iPhone doesn't have Windows, which means there are no scrollbars and there's no resize knob. That's important. We do have scaling. So you've seen already that we'll scale to fit a document when we first load a page and then the user controls the scale with either the pinch gesture or the double tap gesture. An important point about scaling is that we don't scale a bitmap. We will actually re-render the page at the target resolution, at the target scale, so you get gorgeous text as you scale into a page.

These are the six areas that we're going to talk about with regard to optimizing for iPhone. Viewports, what you can do with double tap, text sizing, how events are handled, form controls and three special links. So first, viewports. What is the viewport? On the desktop people don't typically think a lot about the viewport. But the viewport really is determined by the window size. And on the desktop, the viewport determines how the page is laid out and how the content wraps. So if you resize a window in a browser, often the content will re-flow. That's because the viewport is changing size.

The viewport also determines whether or not you need scroll bars. And it's tied to the window size and controlled by the user. On iPhone, just like on the desktop, the viewport determines how the page is laid out and where the content wraps. But there is no resize know, so the viewport can be controlled by you, the content designer, not by the user. And you can do this by specifying a new viewport property at the head of your document. Here's an example. A viewport with a width property of 320 pixels, and there are other properties too that we'll talk about in more detail.

Here's an example of a page that appears to be too narrow on the iPhone. And that's because the content designer really wasn't thinking about the viewport. And on iPhone, the default viewport width is 390 pixels. This is the equivalent of opening up your window on the desktop to 390 pixels and then loading a page.

So really what the designer intended is to have this portion of the page fill the entire screen. And a designer could do this by adding a viewport with property of 590 pixels and then the page would layout like this, filling the entire width of visible portion of the page.

It's applicable to web applications, too. This is a sample app that without the viewport tag, looks kind of goofy. But really, the designer intended to clip it so that it fits the screen. And again, by default, we have 980 viewport pixel width, but the designer wanted this portion of the page to fill the screen.

So that can be done with, again, a viewport width property of 320. now 320 turns out that is the width of portrait on iPhone, so you get no scaling. This is content rendered at 100 percent. This is one of the few modifications that had to be added to the directory application that Scott Forstall demoed. An additional viewport width property.

There are six viewport properties that you can specify. Width and height, which are obvious. Initial scale, this is the scale that the page will be first rendered at when it's first loaded. Whether or not the page can be scaled at all by the user using double tap or pinch. A minimum scale and a maximum scale. So by specifying an appropriate viewport, you really get to control exactly how your pages are going to be laid out on iPhone.

Somewhat related to viewport are framesets. Again, avoid framesets if you possible can. On iPhone they present somewhat of a problem because each frame in a frameset can be independently scrollable. And if you're interacting with a finger, how does that work? Well, we do something called exploding the frameset. We'll take a scrollable frame in a frameset and expand it to fit the actual content. Similarly for full width iFrames. We'll expand those to fit their content.

But, all of the iFrames are scrollable using a two finger gesture like this within the iFrame. So that same frameset on iPhone looks like this. Each of the frames has been exploded to their full size and then the whole frameset itself has been scaled down to fit, so you can pan the entire frameset, you can't scroll each frame independently. But if you do want scrollable regions, you can still achieve that with a scrollable iFrame overflow element.

Double tap zooming, let's talk about that. So double tap zooming works by finding a tapped element and then working up and down for the first appropriate block, and there's some fuzzy rules about an appropriate block, or an image element and then it takes the block and it zooms it to fit width wise. If it's an image, it'll zoom the image to fit.

It will also center that element within the visible region. And if you've already zoomed in, when you double tap, it will zoom out. So what should you do on your side of web application to account for double tap? You don't really have to modify your site in any way except for the layout.

So use a simple block structure throughout your page. Really think about regions that the user will be double tapping on. Organize your site into digestible sections. And digestible really is something left as an exercise to the reader, but something that makes some logical sense and use a column layout.

And avoid wide blocks of text that fill the full width of the page. Here are some examples. This is the old, from yesterday, the old apple.com website. Bringing the hand of God here. Double tap. We double tapped on that image element. It works very well. Here's another example. slashdot.org has a three column layout and double tapping works great on this site. We'll double type on the center column, find their blog and then zoom in and center.

Here's an example of a site that doesn't work so well. It's a great site, but the layout isn't so good. And the layout is the full width of the screen, so when we try and double tap, we'll select a block, we'll center it, but it already fits the screen so there's nothing to zoom in on.

Now you could say well, why don't we zoom in anyway? And we tried this, but the matter of fact is that you end up with something like this, where not only do you have to pan vertically to read the content, you've also got to pan horizontally. And it doesn't make for a very good user experience. So the better experience is for the user to locate the device and look at the content in landscape and then just pan vertically.

So that's double tapping and what you can do on your sites to make it work well on iPhone. Now I'd like to talk about a new concept, text size adjustment. Naturally, if we load a page without any changes on iPhone, it would look like this. Even with double tap, this text is kind of hard to read. It's too small. It's not legible. What we'd like to do is after double tap, have the text look like this. And at this size, it's quite legible. That's what text size adjustment is all about.

We will adjust the font size of text on your documents so that it's readable after double tap. We do this by getting the width of a block of text, determining the double tap scale from that width and then adjusting the font size so that after the double tap it's legible. Now this works remarkably well. So well, in fact, that people don't even realize it's happening.

But just in case, we've added a CSS property, WebKit Text Size Adjustor, that allows you to have fine control of the text size adjustment. There are three possible values. None, none will disable text size adjustment. So if you don't want this futzing with your page, add this to an element and we won't modify the text size. Auto, that's the default. And then multiply a percentage. And multiply a percentage allows you to do something very much like make text bigger, make text smaller in Safari. Here's none, auto and 200 percent.

So when would you want to override the auto behavior of text size adjustment? Well if you really care about having direct control of how your site looks on iPhone, turn it off. Or sometimes, the automatic behavior does disrupt the layout of a site. Here's one specific example at Wikipedia.

You'll not that the menus at the top of the page are clipped and that's because we've adjusted the text size a little too big. Under fixed position elements, they're not actually fixed, they're absolute positioned elements, that caused the clipping of those menu items. So the fix is simple to add text size adjust none to those elements and then the page is restored to it's original intended layout.

Now I'd like to show you a movie of the internal directory application and some of these principles to fix size viewport. We're going to do a search with employees with CH in their name and then select Henry Chan. This is the same demo that Scott Forstall showed in his keynote, if you saw that. And it feels a lot like a native application on an iPhone. You get the same kind of scrolling behavior. We can look at Henry's boss, Kathy, and look at her director ports. There's Henry. We can do another search. We'll search for Pete.

Here's Pete Jensen. And then we have integration with the other applications on iPhone, so I can click on a map link and go directly to the map application right from my web application. There's the Apple Campus. And I can go back to Safari from the map application and make a phone call. This is with the simple Tel Link.

So here's another example. This is the iTunes website at apple.com and on the left side of the page, there's a little widget that lets you search the things in the iTunes catalog. This is directly on the, this is an existing page, we didn't do anything for it for the iPhone. And then you can scroll through the album art for the search results. So what we though is what can we do to take this existing content and just tune it a little bit for iPhone. So that's what we did in this demo.

It's pretty much exactly the same JavaScript, the same AJAX, almost the same layout, we tweaked the style and a viewport tag and it looks vastly better now on the iPhone. We'll do the same search. And using simple DHTML we can scroll back and forth through this list of album art. So doing these kinds of things are really simple on the iPhone. Small tweaks to your web applications or sites make them look great.

So we talked about double tap and text size adjustment. Now I'd like to talk about events on iPhone. So when you have a mouse, events are pretty straight forward. You move the mouse back and forth on the desktop and your page gets a mousemove event. You click the button and your page gets a mousedown event. You release you get a mouseup and a click. Things aren't quite so simple on the iPhone. Your fingers are the input device on the iPhone.

And fingers, a single finger on the iPhone has to do quadruple duty. It has to pan the page, it has to zoom the page via double tap, and if you click and hold on a link, you'll get an information bubble telling you about that link, and then finally, it has to emulate the mouse so that you get expected mouse events in your content.

Two fingers on iPhone do triple duty. They pinch zoom the page, they pan the page, and for overflow elements and iFrames, they can do two finger panning and generate scroll wheel events. So here's kind of a rough flow chart of how events get from the device to your page. The touch screen generates lots of touch events. Those get interpreted by Safari, often intercepted, and your webpage will get no events whatsoever. But in some cases, you will get the expected mouse events.

So those cases can best be described by defining two terms, clickable elements and scrollable elements. Clickable elements aren't just clickable elements, but they're those elements that can receive mouse events, mousedown, mouseup, mousemove and click. And scrollable elements are those elements that will get scroll wheel events. Let's talk specifically about what I mean.

A clickable element is either a link, a form element, an image map area, or an element with a handler, like a mousemove, down, up or click. So if you have elements like this on your pages, they will get the expected events and Safari won't use any of the other thing it needs to, like panning or double tapping. The events will go directly to your page.

A scrollable element is either an element with an appropriate overflow style, this happens to be the linked in contact sheet, which is great. It's an overflow auto scroll region in the center of the page and you can use two fingers to scroll that region. Text areas. If you have a large block of text you can scroll it using two fingers.

And a scrollable iFrame. And really, if you want to use frames, really think about using iFrames instead. Avoid using framesets. So if you have clickable elements or scrollable elements, for the most part your site will get events as though the user were interacting with it via a mouse and not with a finger. Things just work correctly.

These are the summary of the mouse events. In addition to the mouse events, all the usual kinds of life cycle events are sent to a page as well as blur and focus. There's a category of things that the iPhone doesn't do, and as a result you don't get the corresponding events. The iPhone doesn't do copy and paste. It doesn't do drag and drop. And it doesn't do selection. So your page will never get these events. Here's an example of a great site, dpreview.com.

and on the left side of the screen there's some DHTML menus that make use of mouse move. These menus work just fine. You can click on a menu, see the exploded sub items and maybe select an item. Let's select a review of the Canon 940X, or D40X, I think it is. They work just fine. This site, of course, wasn't modified in any way. It's the existing dpreview.com site. So we've talked about events. Now I'd like to talk about form controls on iPhone.

Form controls on iPhone are resolution independent. What that means is as you scale up and down, we'll render the appropriate scale. They look beautiful. And they're stylable. You can make form controls look like whatever you want. I'm not necessarily saying this is good design, but you can go crazy. You can do whatever you want with these form controls. Same goes for text fields.

And also select controls. And again, this isn't necessarily good design, but you can do whatever you want with form controls. The iPhone doesn't have a user visible file system. So as a result, there is no file upload. We will, however, render a disable control in your web content. It looks like this, and this is so the layout doesn't get disrupted if you include one of these controls on your site.

So that's forms on iPhone. Now I'd like to talk about three special links that are supported on iPhone. Telephone links. It is a phone, after all, so you can make calls directly from y our websites and web applications. You can do that by specifying a Tel Link, like this. Now if you don't specify a Tel Link, and there's a lot of content out there that doesn't use the Tel Link, we'll scan the page and look for anything that appears to be a phone number and convert it to a Tel Link.

And 99 percent of the time this does the right thing, but if you really want to have a number on your page that isn't a telephone number, but looks like a telephone number, if you break it up into two elements, maybe two side by side spans, we won't convert it to a telephone link.

Mail links. Safari has a built in mail compose sheet, so you don't have to leave Safari to compose an email. You can click on an email, the compose sheet will come up, you can send email and go directly back to Safari without having to go to SpinBoard by the menu button. And Google Map Links. If your site includes links to maps.google.com, we'll send you to the built in Google Maps client instead of going over the web to maps.google.com.

so that's an overview of what it takes to optimize your applications for iPhone in terms of the HTML and the CSS. Now I'd like to introduce Sam Bushell from the QuickTime Engineering Team. And he's going to talk about what you can do to encode your content for iPhone.

Thank you, Richard. Okay. It's time to take off your CSS hats. It's time to put on your H.264 goggles. I'm here to talk to the media folks in the audience. The iPhone is a terrific media device. It's not just a wide screen video iPod, it is a wide screen video iPod that can play video and audio while it's being streamed over the wireless web. It is terrific.

I'm going to talk to you about three things. I'm going to talk about how you can encode movies to optimize them for the iPhone. How you can configure a server to make sure that it's compatible with the iPhone. And I'm going to talk about embedding movies on web pages. But first, I'm going to have my own little demo about what the iPhone web video experience is like. Again, we're using prerecorded movies.

Here's the start page, the start screen. Let's bring up the web browser and look at bookmarks. I have a bookmark here that will take us to a webpage that we set up that has the Mac World Keynote Presentation from January this year, where Steve introduced the iPhone. There's a little blue button in the corner. The blue button is how you bring up the video for playback. Let's listen to Steve for a sec.

Steve: This is a day I've been looking forward to for 2.5 years.

Okay. So let's have a look at what the elements on the screen are. At the top, there's a timeline so we can see where in the movie we are. At the bottom there's the familiar rewind, play or pause and fast-forward buttons and a volume control. Now we can rotate iPhone to go into landscape mode, which is often a better fit for a video.

We can let it play again in a moment. But first, I'm going to jump into middle by dragging that timeline slider. Now we just did something cool here. We did something terrific. We've skipped halfway through this movie. This move is about a gigabyte long and we've jumped way past the portion of the movie that we've already downloaded. This is here on the iPhone before you were able to do that on QuickTime on your desktop.

Another thing to have a look at, on the top right corner there's a little icon with two arrows pointing towards each other. This button is how you can toggle between a landscape, sorry, between a letterbox and a full screen view. So let's do that quickly. It turns out that with this particular content at this point in the movie, there are black bars at the side. So going to the letterbox means you see black bars all the way around, which isn't, perhaps, the right choice for this content right now.

So let's go to Amazon, and I love to go to the DVD section of Amazon and see what DVD's they're selling.

So, at this point, Steve is doing a live demo of the web browser on the phone. But I am showing you a movie of an iPhone. It's a little bit self referential, I apologize. We can rotate the video while it's playing, that's not a problem. So if we tap the screen, the heads up display comes back up and we can tap the done button in the corner to return back to the webpage. Okay. So that's a page that we set up. Although the content is the same content that you could download as a video podcast of that keynote.

But we constructed that page so we could have done anything. But there are oodles of web pages with video on them right out there right now and many of them work just fine. So let's go and visit a couple of those. . let's go and take a look at Tiki Bar TV. Tiki Bar TV is a humorous video podcast made up in Canada. Go Canada. Oh, this is a little bit rude.

Please don't do this. Please don't bring up JavaScript alerts asking your users to go and download software. You don't know whether or not they'll be able to. Certainly on the iPhone there is no Flash, and you're not going to be able to go to a new webpage and download a new version of Flash. Besides, I think somebody spelled Adobe wrong. It's spelled with fewer M's.

all right. Let's cancel out of this alert. Apart from that, this page works fine. Let's tap on that little blue play icon to focus in on the movie. Ah.

- It's a story of a guy and a girl and another guy and she builds a robot and it serves some drinks and it goes crazy. Everyone lives happily ever after. I'm just going to skip over, past to the end. Watch what happens when we play past the end of the movie.

Wacky Canadians. Okay. Let's visit another site. Let's go to Rocketboom.

Here's the page loading. The gray box is the media content. It's a gray box because there's not poster image but we can recognize that there's a player icon in the corner and if we hit that, we'll focus in on the video. Let's watch this for a moment.

How depressing. If only they'd let me vote. So we're not limited to just video podcasts. We can play audio podcasts from webpages as well. Let's go to the website for one of those. There's one called Escape Pod, which is short form, science fiction, spoken word short stories.

Like many podcasts, there's a website that has details about every episode. And we can go in and zoom in on this episode and see if we can find a link that'll let us play it. So here we go and we'll zoom in and then pan down and have a look. Ah, a download link, that'll do. Let's pop up that link. Listen to this.

Warning. Today's story is a children's story. There is no strong language, no adult content and very little violence. We recommend that mature audiences listen only with the direct supervision of a child.

Okay. Be warned, everything on the internet isn't safe for adults. So what have we seen? We've seen that lots of pages with video and audio content just work great on the iPhone right now. But there are some ways in which you can optimize the iPhone video experience for people coming and looking at your content.

Let's start out by talking about encoding. If you've used QuickTime Player Pro to encode video, you know that there is an export command in the file menu and there's a list of exporters that you can choose from. There are four exporters that you can use to prepare content for the iPhone. Two of these you're familiar with. There's the movie to iPod exporter and the movie to MPEG4 exporter and two of these are coming soon.

There's one that's called Movie to iPhone and one that's called Movie to iPhone-Cellular. Unfortunately these didn't make it into the Leopard scene. I apologize. But that makes this an excellent opportunity for me to plug the QuickTime scene program. If you'd like to apply to participate in our QuickTime Seeding, please send mail [email protected], mention the name of this session so they understand where you're coming from.

Let's talk about the supported formats in a little bit more detail. iPhone supports a broad array of codecs for video and audio file formats. It supports H.264. It supports AHC. It supports everything that can play on today's iPod video and then a whole bunch more. Talking about video codec jargon for a moment, for those of you who know, we support H.264 Baseline Profdile Level 3.0 up to 640 by 480 at 30 fps.

Now some of you may not know all of these details about H.264 spec. you don't have to know a whole lot about it, but what I want you to understand is that some of the technologies and tools we use to encode video for high def on the desktop are not supported by the baseline profile that the iPhone uses. In particular, B frames are not in the baseline profile and hence B frames are not supported in the video content that can be played on the phone.

We need to start thinking about bitrate a bit more than we have in the past when delivering content to the iPod. When you sync content to an iPod, you do so using iTunes and a fast USB cable. The bitrate basically only effects the size on the iPod's disc.

Now that would effect the number of movies you could jam onto your large iPod disk. If you were to try to transfer a movie that would seem complicated or too high of a bitrate, iTunes would step in and act as a kind of gatekeeper to protect you from transferring content that you wouldn't be able to play.

Now the iPhone is a widescreen video iPod. So it supports that to begin with. But it also adds this new model of the wireless web and being able to stream content. And in the streaming case, the bit rate determines the user experience. Because if the bitrate is too high, then the network is not able to deliver date in time, then we'll run out of data and we'll stall. Remember, like Richard said, the Edge network is a much smaller pipe than WiFi.

Another thing to think about is that if you encode video with the iPhone's screen size in mind, you'll get better looking results. The iPhone's screen is 480 by 320 pixels exactly. This is actually really easy to remember. It's exactly 160 pixels per in`ch and it's exactly two inches by three inches.

We recommend that you pick an encoded movie size within 480 by 360. this is the next four by three size upwards. Remember that users can choose a letterboxed view or a full screen view and the scaling choices between these. The scaling on iPhone's hardware acceleration is incredibly high quality. It looks terrific.

So let's go back and look at those four exporters again. What are the results we get out of those? From the new movie to iPhone exporter, that targets about one megabit, for WiFi connections. The new Movie to iPhone Cellular exporter targets Edge data rates at about 80 kilobits per second.

The existing Movie to iPod exporter targets 1.6 megabits. Be aware that even though it's a higher data rate than Movie to iPhone, you should get better results with the Movie to iPhone exporter, even though it's one megabit. If you're a wizard and you want to twiddle all the knobs, you can use the Movie to MPEG-4 exporter.

But you wizards, I want you to remember one thing, you have to make sure that your content will conform to the baseline profile and to do that you need to go to the H.264 video options dialogue, find the checkbox that says baseline, and make sure that's checked. Store that in your noggin wizards. Okay. So here's my Goldilocks slide.

All of these are the best choice for someone. On iPhone, over Edge, we want it to be a low data rate version of the movie. On iPhone in a WiFi network, you want to choose a one megabit version. On the desktop you probably want to use high technologies and maybe high def sizes.

Now, on your website you can have three links to these three different choices. But that's requiring the viewer, the user of that iPhone to know all of that stuff that I just explained to you. And it might be better, I put it to you, it might be better to make the iPhone make the decision for itself.

We have a technology that's been in QuickTime since QuickTime 3 that we've got for this called reference movies. A reference movie is a simple idea. It's a list of URLs to movies with a little decision tree to pick between them. And the tools in the decision tree include being able to detect the bitrate of the connection and the capabilities of the target device. We have added the ability to describe am I on the iPhone as a test.

So, with a reference movie you can have the iPhone detect when it's on Edge or WiFi and pick between a low data rate 1 megabit version of a movie stream and on the desktop it knows it's on my phone and I'll use another movie, or another selection of movies, because we can detect the network data rate there, too. There's a tool called make ref movie that we use and we have available to help make reference movies. We will be updating it to include the iPhone test fairly soon.

So let's move on to the second thing I was going to tell you about. That's server configuration. Now do you remember when I jumped half way through that long, long movie? It was a gigabyte long. How do we do that? Well there's a technology in HTTP1 spec, 1.1 spec, since 1999 called byte-range requests.

Also called content range or partial range, I think the spec is all of those names. A byte-range request allows a client to say hey, server, give me this file, but not the whole thing, I just want this little bit in the middle. We use byte-range requests on the iPhone to do random access feeds of the media file.

And in fact, it's so important to the mobile web content viewing experience that we require byte-range support. Let me say that again, it's quite important. The iPhone requires byte-range support from the server that's serving the media files. And if it doesn't find that it does have byte-range support, it'll just display an icon saying sorry, I can't play this.

So, the good news is byte-range support is in most HTTP 1.1 servers already. If you are anxious, and maybe you should be, and you're worried and you want to check whether or not your server supports there, you can do an easy experiment. Bring up a terminal window, use the call command line tool to download a short range at the beginning of the file and watch what happens.

Call tells you how much is downloading and how much it's doing, and if it seems to be saying I've just downloaded the first hundred bytes and I've stopped, that's great. But if it says I'm downloading the whole file, even though I asked for a little bit, then you should have a look at your web side and see if you can reconfigure or adjust it.

While you're tweaking your web server, another thing to check is that you have configured it to send the correct mime types for the movie file family suffixes. mp4, m4v, 3gpp, mov. Another thing to think about is whether or not your media web server supports movies over two gigabytes. iPhone does. For what it's worth, Apache 2 does, I believe, out of the box.

Okay, the third thing I was going to talk about was embedding video into web pages. This is just the same as you'd do it. Follow our best current practices for embedding video on web pages, we have a great tutorial called embedding QuickTime on Apple's website. If you haven't read it, check it out.

You remember how when we had a look at the two websites, we just saw a gray box when we were looking at the webpage? This is what you're going to get if you embed with the source pointing directly at a movie. Because we don't start decoding the video until we switch into that full screen playback mode.

An alternative is to set up a poster JPEG, which is a proxy that fills in that area inside the webpage on the desktop until you click and on iPhone until you transfer into the full screen playback. Many of you will be making JavaScript movie controls to have really advanced interfaces, movie on the web. Peter Graffagnino session yesterday afternoon showed an excellent example of this.

On the iPhone, this doesn't really fit the model. Because on the iPhone, to begin with you're looking at a webpage, which has your JavaScript running on it, and then you transition into full screen playback and at that point, your JavaScript isn't there because your webpage isn't there anymore. So since they never appear at the same time it's rather inconvenient for one to control the other. Now, you can still have JavaScript to do navigation in the web domain, you just can't use it to control the details of the playback of video or audio.

Finally, a reminder for podcasters, if you have a custom player on your webpage, I recommend that you also have a direct link to the media because a direct link will take an iPhone user straight into full screen media playback. So let's summarize what I've talked about. We have new QuickTime exporters coming on to you soon.

One of these targets a low data rate for Edge networks, when you're outside of the range of WiFi. Another targets WiFi data rates, also on the iPhone. Use reference movies to finesse the problem of using which and when and make sure that you automatically stream the best content for the current circumstance.

Configure your media servers to support byte-range requests, or the iPhone won't be able to play your content from them. Poster JPEGs improve the embedded experience. And if you have a custom player, also have a direct link to the podcast episode. You've got 17 days to prepare your content for iPhone's arrival. You may not need to do very much.

You can do a small amount and it can make a big difference. But this is going to be a terrific experience for you and for all of the people who buy this terrific new product. I think we should all be very excited. Richard, would you like to wrap up?

Sure.

Thanks a lot Sam. So we've seen that you really don't have to do very much at all, if anything, to make your content work well on iPhone both for the HTML the CSS and also for the media content. So, to summarize, there are some good design practices that are applicable both to the desktop and for the iPhone. Follow those practices. Column layout, think about how your page is laid out. Size really matters. The Edge pipe is pretty small, so design for that small pipe.

Use media queries to provide alternate style on your web content. And specifically for the iPhone, think about adding a viewport meta property to the top of your HTML. Think about double tap and text size adjustment. Think about how events and how the user will be interacting with your page. And finally, think about the media and coding that Sam talked about.

So for more information about the HTML and the CSS stuff that we talked about, you can contact Mark Malone, the Internet Technologies Evangelist, and there's a link, a few links here for more information. And on the media side of things, you can contact Allan Shaffer. And there are a few more links to things that Sam referred to.