The University of Washington emerging technology group briefly posted details from an Apple developer conference session on writing Web content for the iPhone, but took it down out of concern it would violate Apple non-disclosure rules.
I hope the UW didn’t remove the blog entry because it had sassy comments like this:
“No flash and No Java of course this means no Microsoft Silverlight”
Since it’s already out in the wild, I might as well share the rest of the entry here:
Apple WWDC iPhone Development, Tony Chang, 18 Jun, 2007, published in Uncategorized
The intro slide for this session is called Designing Web Content for the iPhone. Notice it doesn’t say developing iPhone client applications for the iPhone. So the first thing the speaker says is that developing for the iPhone is easy as cake, just develop for Safari. A web browser that no one uses and hasn’t been in the wringer like IE7 or Firefox in terms of security vulnerabilities. Steve Jobs touts that Safari is the fastest web browser in the world by running a precanned demo of one website.
So what does the iPhone offer for websites. Lets take a look at what Apple has to say:
1. developing websites for the desktop and in most cases it will just work on the iphone
2. browsing the web with iphone is easy thru Safari
3. scroll using two fingers
4. double tap for zoom in on content
5. the page view feature lets you look at multiple websites and documents by scrolling thru them one after another
6. full support for PDF
The speaker goes thru a bunch of popular websites to show that many websites are already good to go for the iPhone so ideally only limited tweaks are required. However I dont know if those sites have already been prepped to work well with iPhone prior to the WWDC.
Pageview is a feature in iPhone to help you view webpages and documents. Since the iPhone does not have windows it uses page view to allow users to see the content.
The speaker then talks about Safari and its capabilities.
— it supports all latest internet standards
– 10MB max html size for web page
– 8 documents maximum loaded on the iPhone due to page view limitations
– Quicktime used for audio and video
No flash and No Java of course this means no Microsoft Silverlight
Good design practices for iPhone:
– separate html and css
– use well structured and valid html
– size images appropriately dont rely on browser scaling
– tile small images in backgrounds
– dont use large backgroung images
– avoid complicated framesets, better yet dont use framesets at all
– iPhone supports both EDGE and WiFi. EDGE pipe is smaller then WIFI pipe so think about bandwidth when developing.
– XHTML mobile documents supported
– stylesheet device width:480px
– apply different css for the iPhone. For example displaying a one column page for iphone vs a 3 column page on a desktop.
– there are no scroll bars or resize knobs. the iphone will automatically expand the content
– avoid them if you can
– scrollable frames are automatically expanded to fit the content
– frames exploded to the full scale and then fit to the screen
Safari User Agent for iphone:
Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A538a Safari/419.3
Without any addition coding on your website the iPhone automatically offers these features to your website.
– double tap for zoom in
– one finger as a mouse used to
– pan page
– press and hold to display the information bubble
– two fingers as a mouse used to
– pinch content to shrink – zoom out
– pan page
– scroll wheel events
– new telephone links allows you to integrate phone calls directly from your webpage. remember this is only on safari.
– built in google maps client for integrated mapping from your website
Encode content for iPhone: (Sorry guys I know almost nothing about video and audio stuff so I tried my best just to jot down stuff verbatim but it might not make sense to everyone)
H.264 baseline profile level 3.0 up to 640 x 480 fps
– with iphone content can arrive over net
– bitrate determines whether playback will stall
– iphone screen size 480 x 320
– encode move size 480 x 360
– Move to iphone
– Movie to iphone (Cellular)
– Movie to ipod
– Movie to MPEG-3
Reference movies types
– list of urls for your movie on your website and create a decision tree to pick them
– detect the bitrate and choose capabilities of the device
– iphone with media playback requires byte range support from http server
– supported by most http 1.1 servers
– also known as content-range or partial-range support
May need MIME types for .mp4, m4v, .3gp
Embedding Video into webpages
– embedding quicktime on webpages link to article on apple websites
Links to movies on a web page will take users directly to video full screen playback
– Use new quicktime exporters
– provide low-bitrate versions of content
– use reference movies to auto stream best verson
– setup your media server to support byte-range required
– use poster jpegs
– provide direct links to podcast episodes
Here is some information from David Cox to shed some light on what this means for UW servers.
There is a little more info about the requirements of the iPhone, and it has me thinking about an old issue.
It looks like the iPhone will NOT support streaming media from the streaming media servers (at least at launch). They will require the media to be installed on HTTP accessible servers (such as Homer or Dante). But I don’t think Homer or Dante are going to work very well under their current configuration.
The problem is that these systems do not know the mime type for most of the file types that the iPhone will be able to play. I am guessing that the iPhone will have the same issue that Safari has when this happens. Safari does not assume that it knows better than the server when it comes to file types. If the server says that a mimetype is not known, then Safari will not try to figure out what to do with the file extension. Rather, it will try to show the data as a text file, or download the file, depending on what the servers “default type” is (for homer and dante, it shows the links as big text files).
The iPhone (as well as Safari on both Mac and Windows) should be able to handle .mov and .mp3 files on homer and dante, as the mimetypes seem set for those media files. But .mp4 .m4a .m4b will probably result in a long wait followed by a large page of text being given to the client.
When I have mentioned this in the past, the feeling was that the Streaming Media Servers were the place for such files, and that the HTTP servers were NOT the place for such files. I can fully see the tech reasons for this, but I wanted to point out this new data point (a high profile media centric device that will NOT work with our media streaming servers) before we see them in the wild.
As a quick work around, users can create .htaccess files to provide support for these mime types on a site-by-site instance (as people have had to do to support individual download options for ‘non-mp3′ podcasts hosted on depts/staff/student accounts for a while now). It is not ideal, but a good work around :).