iPhone Tech Talks, on October 12th 2007 (at Washington D.C.'s JW Marriott)
Well, what is this and why did I go? The iPhone Tech Talk is a focused look at what the iPhone can do; and how it might be leveraged to achieve its potential for web applications. Coincidentally, this talk also covers the sibling product, the iPod Touch (in fact anywhere below where I'm referencing iPhone, it's safe to assume that the same applies to the iPod Touch). And, in my opinion, it covers a whole movement away from WAP and other mobile web technologies toward the Internet as it will be seen in the future on almost every mobile device. The cell phone industry is about to embrace the software industry; and it's all Apple's fault.
Mozilla just announced they'll catch up to Opera and Safari with real mobile browser technology, soon. (I'm honestly not sure where MicroSoft's Internet Explorer is in the mix, if you know leave a comment below. Does Windows Mobile have a full-fledged browser?) Other phones are already popping up that aspire to Apple's groundbreaking approach to mobile internet delivery. The fact is, the internet is starting to grow beyond the desktop (and laptop) to ever smaller devices, but with the same content quality. While retaining many familiar capabilities, there are some trade-offs and exceptions; more on that later.
Back to the Talk. The Tech Talk was very well organized, into three main categories. A technical overview, a user experience discussion, and a deep dive into technology focused on data delivery (think not just HTML, but video, as well) combined with data synching services (email, bookmarks, addresses, and calendaring).
The technology overview covered many aspects of web development that apply to specific capabilities found in Safari 3.0. There are several properties of CSS3 found in Firefox too, and in both Safari & Firefox these properties are usually preceded with -webkit or -moz, respectively. A search for CSS3 + -webkit + -moz, will turn up a handful of properties you can use to efficiently style your site's page or your web application's look and feel so that it looks at home on an iPhone. The real meat of the web technology overview centered around additional iPhone specific nuances in Safari 3; like the ability to detect and react to the orientation of the browser (landscape versus portal). There are some event handlers like on onOrientationChange which can be used to test for orientation values. For exampole, when window.orientation = 0 you're holding the iPhone upright (in portrait orientation), other values include 90 for landscape counterclockwise, -90 for landscape clockwise, and 180 which indicates portrait viewd upside down. I haven't had a chance to build a page to test this out yet, but it's easy to see how some iPhone games have already been built leveraging these capabilities. Only a few manufacturer's have built desktop monitors with a rotating base that let's you view in portrait mode, but while Windows & OS X understand a display's orientation desktop browsers don't have the ability to leverage this as easily as an iPhone does -- though you could use JavaScript to address this.
The usability (or user experience) lecture was, for me at least, just as intriguing as the development lecture. You might think that despite the iPhone's capabilities, it would make great sense to build lots of iPhone specific (or alternate user interfaces) similar to the way in which web developers used to have the "click here if you're using Netscape" link. The usability representative from Apple was quick to point out that striving for a singular experience should always be the primary objective. Including a link to an alternate use experience that is lightweight & fits better on a smaller screen resolution is just a nice have. I really got the impression that bandwidth should dictate more about when to give in and start building a smaller mobile specific view of a website. Though, he was a huge fan of Facebook's alternate UI for the iPhone; so maybe it's really just case-by-case. If you have a compelling reason to enhance the experience an iPhone visitor might have, go for it. It's also worthwhile considering how to reduce dependencies on things like Flash and Java (which still aren't ready for the iPhone). Other usability issues you'll want to consider include things like hover states (there are none, since the iPhone has no sense of where your finger is about to be). This seems trivial at first; but has serious implications when a site's navigation is only preview-able as onmouseover.
The technical deep dive portion of the day was almost information overload with lots of minute details on everything from browser specs to Quicktime. In no specific order, here's my top ten tidbits:
-- Don't assume JavaScript is "on", on an iPhone; it's a Setting that can be turned off.
-- Popup blocker is there & on by default, window.open() without user initiation won't fly.
-- Use object detection, e.g. if("showModalDialog"), in lieu of user-agent sniffing. User-agents, if searching for the wrong string ... like "Apple" or "Safari" won't help since the browser is the real deal; and since the iPod Touch and iPhone do have distinct user-agent strings.
-- The CSS3 properties available include device-width & height ... those will be useful!
-- JavaScript has a 5 second limit to execute; after that it bails.
-- Use JavaScript's alert(), prompt(), and confirm() ... they were redesigned & should get implemented as often as necessary.
-- JavaScript's window.console.log() or .warn() or .error() now reports to a feature in safari settings called "Developer," meaning you can debug on the iPhone itself.
-- Supported documents that can be displayed INSIDE the browser include: Excel, Word, & PDF. Note that even complex Excel documents should be viewable.
-- Some URLs get auto-detected (like maps.google.com & youtube.com/watch) & launch their respective iPhone applications automatically
-- Custom protocols like tel:// exist, research what you're linking to, to know if you're providing an optimal experience; chances are there's an easy way to leverage the iPhone's applications for many basic operations.
During the usability lecture (and during the other speeches as well) a lot of information was shared about scaling web applications properly for the iPhone. So here's smaller list of considerations that just apply to the size and spacing of elements.
-- Know these Terms: Tap/Dbl Tap, Pan, Flick, 2 Finger Pan (for scrollable iframes & divs), Pinch, Rotate ... they're pretty obvious, but when you read through Apple's documentation online, this what you'll "hear."
-- Be aware of white space, too much is bad (or wasteful); BUT leave enough margin and padding for fingers to do their work (40px around objects is highly recommended).
-- The iPhone honors scaling for xhtml-mobile / .mobi domain names
-- Use device-width to apply specialized stylesheets:
<link media="only screen and (max-device-width: 480px)"
href="small-device.css" type="text/css" rel="stylesheet" >
-- Other content values include: initial-scale, minimum/maximum-scale, user-scalable=yes/no
-- Multiple values can be comma delimited content="width=320,user-scalable=no:
-- Also, use constants, e.g. content="width=device-width-constant"
-- CSS3 also can be of assistance, via text scaling -webkit-text-adjust:none or auto or some percentage.
-- Scrolling is different, divs or object w/ scrolling work but are not good experiencxes since scrollbars are "invisible."
So that's everything I can remember. There's nothing really top secret, or juicy, to report about the iPhone's future, though I suspect that software updates to the browser and OS will not only improve performance but will add some features we know have to be on Apple's hot list ... and some we can't even imagine. The current iPhone doesn't use full fledged Leopard or Safari 3 GM, that's actually good if you're "in like" as much as I am with your iPhone. Apple offered no details about the possibility of a "real native app" SDK at the conference, but before I finished writing this up, Steve Jobs had announced just such offering -- to be available in early '08. I don't think Apple intended to force developers toward web based applications; they just needed time to do their SDK right. No one knows for sure how many of Apple's competitors wished they had the backbone to resist dropping poorly design SDKs & products on the market; but Safari (and especially offering Safari for Windows) was a pretty ingenious stopgap.
Additional resources:
Sphere: Related Content