Developing for the iPhone

DEVELOPING FOR THE IPHONE TIM LUCAS EDGE OF THE WEB, PERTH AUS NOVEMBER 6, 2008

Sorry, but I won’t be covering how to make $20,000/day selling lightsabers on the iTunes App Store

I'm going to talk about developing _websites_ for the iphone

I’m cofounder and senior-developer at Agency Rainford, where we build beautifully engineered web applications. By beautiful I mean designed from the interface ﬁrst, and engineered to be well tested, solid and best-practice.

I worked with Pete Ottery, the paper cutout Ben Buchanan is holding onto here. Pete’s one of the awesome designers at News Digital Media

we built the iphone version of news.com.au

and not long after that I launched the iphone version of webjam.com.au alongside Pete and I’s talk at Web Directions. It gave me more room to explore best practices and test some opinions I’d been forming about the best way to build iphone sites.

the JOY of mobile 1.0 I’ve never had the pleasure of developing for old-school mobile devices before. After my web directions presentation I guy told me he wanted to punch me in the face when I said that, so it’s nice I’ve managed to avoid this type of development which is obviously anger inducing.

COMMON MISTAKES #1 DEVELOPING FOR ONLY THE IPHONE

hype photo by Mark Cohen ﬂickr.com/people/rageman http://www.ﬂickr.com/photos/rageman/2677718167/ Hype is reason #1 to get caught thinking that it’s all about the iphone

opportunism photo by hey mr glen ﬂickr.com/people/glenscott the other, is opportunism. There’s a lot of marketing buzz around the iphone and people are http://www.ﬂickr.com/photos/glenscott/2040303671/ keen to be shown as innovators and secure their place in the market.

ignorance IGNORANCE photo by Sebastian Fritzon ﬂickr.com/people/sebastianfritzon and ignorance. This is the only phone on the consumer market with huge traction with these http://www.ﬂickr.com/photos/sebastianfritzon/2185196203/ kind of capabilities, we’ve got nothing else yet in front of us to remind us.

You should not make sites for the iPhone - and that includes the URL. Lars Gunther rightly pulled us up on this shortly before Pete and I’s WSG presentation with this comment.

we’ve all seen problems like this before

widen our focus photo by Hyaground ﬂickr.com/people/71428150@N00 so if we were to widen our focus, what are we developing for? http://www.ﬂickr.com/photos/ 71428150@N00/2240097942/

mobile 2.0 photo by William Hook ﬂickr.com/people/williamhook It’s what many call Mobile 2.0. Ss cheesy as this term can sound I think it’s an important shift http://www.ﬂickr.com/photos/williamhook/2830319467/ of focus to make if you’re thinking about iPhone website development.

Mobile 2.0: Design and Develop for the iPhone and Beyond by Brian Fling Web 2.0 Expo, San Francisco, April 22, 2008 Copyright © 2008 Brian Fling. All trademarks and copyrights remain the property of their respective owners. Brian Fling’s been travelling the world for the past year talking about Mobile 2.0. He’s got a great workshop on slideshare with 353 slides that go into much detail about the concept of Mobile 2.0 covering all the jargon and everything you need to know.

“Don’t Build for Just One Device” ROSS HARMES - FLICKR from Lessons Learned while Building an iPhone Site http://code.flickr.com/blog/2008/10/27/lessons-learned-while-building-an-iphone-site/ Ross from Flickr echoed this on a recent code.ﬂickr blog post from his experience developing the new mobile version of ﬂickr.

COMMON MISTAKES #2 USING AN IPHONE FRAMEWORK

iUI CiUI WebApp.Net photo by Scot Campbell flickr.com/people/randomurl There’s a couple of these frameworks floating around. iUI is the primary one, created by Joe http://www.flickr.com/photos/randomurl/2558566674/ Hewitt who created the most awesome firebug; as well as CiUI, WebApp.Net and others.

goals of iUI GOALS OF IUI Create Navigational Menus and iPhone interfaces No knowledge of JS required Provide a more “iPhone-like” expererience the goals of iUI are 1) Create Navigational Menus and iPhone interfaces, 2) No knowledge of JS required, 3) Provide a more “iPhone-like” experience

device-specific design looks like ass. Does anybody remember this? Who else thought it looked like complete ass? Guess how long ago this was? Only 12 months ago!

so let’s take your iphone looking site and fast-forward 1 month, December 15 when the ﬁrst Android phone comes out in Australia

goals of iUI GOALS OF IUI Create Navigational Menus and iPhone interfaces No knowledge of JS required Provide a more “iPhone-like” expererience so removing the OS-speciﬁc goals we’re left with: no knowledge of JS required

no knowledge of JS? photo by jaymce ﬂickr.com/people/cowboyneal who here is responsible for a large JS site but doesn’t know JS? Scary position to be in. The http://www.ﬂickr.com/photos/cowboyneal/444393190/ disadvantage of this goal is that because it’s noob-friendly it’s very intrusive, hijacking every link etc. Chances are its not how you’d do things.

goals of iUI GOALS OF IUI Create Navigational Menus and iPhone interfaces No knowledge of JS required Provide a more “iPhone-like” expererience so that’s every goal out the window... for website development. The only place I see it being really useful is prototyping native applications in the browser before building them.

do-it-yaself! original, timeless design jquery is ok (YUI, maybe not) progressively enhance photo by ClintJCL ﬂickr.com/people/clintjcl go frameworkless! http://www.ﬂickr.com/photos/clintjcl/235522670/

WHAT’S DIFFERENT? so what’s similar and what’s different to developing for the desktop?

same, but smaller photo by backpackphotography ﬂickr.com/people/backpackphotography Everything is smaller. Smaller screen real estate, less memory and CPU, less precision when http://www.ﬂickr.com/photos/backpackphotography/ using your thumb, less bandwith. 2317264717/

320 416 The ﬁrst big difference is screen size. On an iphone you’re looking at 320x...

320 416 Which looks more like this on the physical phone because of high density screen, 160DPI vs 72DPI on a normal desktop screen.

“ Visiting Web sites that have been redesigned for the iPhone is often a quicker and more pleasing experience than it is on those increasingly cinema-style desktop displays...” JOHN MARKOFF - NYTIMES from On a Small Screen, Just the Salient Stuff http://www.nytimes.com/2008/07/13/technology/13stream.html Ross from Flickr echo’d this on a recent code.ﬂickr blog post from his experience developing the new mobile version of ﬂickr.

the current news.com.au homepage, which is pretty clean and attractive.

and the iphone version, which I admit looks a little clunky at full desktop width

but at a smaller width, much nicer!

and here’s the webjam site. I helped with the design and build of this puppy, so it’s hard to criticise.

but the iphone site IMO is deﬁnitely much simpler and clearer, albeit lacking functionality the main site has.

“ By stripping down the Web site interface to the most basic functions, site designers can focus the user’s attention and offer relevant information without distractions.” JOHN MARKOFF - NYTIMES from On a Small Screen, Just the Salient Stuff http://www.nytimes.com/2008/07/13/technology/13stream.html

strip it down to the core photo by Jeff Kubina ﬂickr.com/people/kubina http://www.ﬂickr.com/photos/kubina/2091368266/

and not only is it smaller, but the user can rotate it at anytime they want. Not many desktop users do this. Need to design for two screen modes.

liquid layouts photo by Vilhelm Sjostrom flickr.com/people/mureena Take the opportunity to use liquid layouts. Don’t fix the width at 320px. Everyone used to http://www.flickr.com/photos/mureena/1532325221/ doing liquid layouts can rejoyce!

thumbs photo by horizontal.integration ﬂickr.com/people/ebolasmallpox the next biggest difference that affects how you design is the thumb. http://www.ﬂickr.com/photos/ebolasmallpox/240477265/

We take this for granted. 1px cursor.

on a touchscreen we’re talking about a 50px thumb cursor

with some padding for error

Read more Read more and this is what a 12px link looks like under your thumb. Luckily Mobile Safari tries to help to pick which link you want, but you’d have to click above or below these links to really differentiate between them.

this example is thanks to Pete Ottery from our Web Directions 08 presentation. Case in point is the iPhone keyboard. Easy to start to use, hard to truely master and become efficient. The keys not ﬁtting into the 50px grid really makes it difficult.

get fat GET FAT photo by *phototristan ﬂickr.com/people/mediahound so the trick with anything requiring user interaction is to get fat.

big clickable areas make sure all the clickable areas are nice and big

buttons, not links

large hit zones the photo browsing on the webjam event page show’s how you might use hit zones.

large hit zones we have small UI elements, smaller than 50px, which afford clicking.

large hit zones though if you click anywhere on the left of the photo you’ll activate the button. We’re keeping things simple and clean but as forgiving as we can.

less power So another big difference is less power. Try browsing the main news site on mobile safari... it might crash, or just goes as slow as a dog... yet it’s completely ﬁne on a normal desktop browser.

slower pipes high bandwith but high latency photo by stevegarfield flickr.com/people/stevegarfield another major difference, slower pipes. From my completely unscientific analysis most of the http://www.flickr.com/photos/stevegarfield/493037500/ time we’re dealing with high bandwith high latency. It takes a while to connect to a server but once the connection is made the transfer speed is quite good.

SERVER How does this affect website design for these devices? Everytime the browser needs to fetch something from the server there will be some lag (latency), the red arrow above. Once the connection is made the transfer back of information is fast.

SERVER so the more things the browser needs to fetch the more delay. 3 things = 3 times as long (well, the browser can grab multiple things at once, but only up to 3 at a time... 6 images, 9 images etc)

SERVER the goal is to have a smaller number of connections, but larger transfers

lots of small pipes bad. photo by hockadilly ﬂickr.com/people/hockadilly in summary http://www.ﬂickr.com/photos/hockadilly/2910737768/

fewer but bigger pipes good. photo by stevegarfield flickr.com/people/stevegarfield in summary http://www.flickr.com/photos/stevegarfield/493037102/

css sprites use techniques like CSS sprites to combine images so it’s one larger ﬁle rather than many small ﬁles

mobile-photo-navigator.js mobile-photos.js all-mobile.js bundling same as your CSS and JS ﬁles. Combine them together (as well as minifying/packing them to make them as small as possible). Most platforms have some automated way of doing this for you before you send your ﬁles to the server.

Use yslow

and webkit inspector (above is from the webkit nightly)

page fragments and onto page fragments. Page Fragments is a technique used to load fractions of pages rather than a whole page at a time. The news iphone app uses this technique.

“Load Page Fragments Instead of Full Pages” ROSS HARMES - FLICKR from Lessons Learned while Building an iPhone Site http://code.flickr.com/blog/2008/10/27/lessons-learned-while-building-an-iphone-site/ Ross from Flickr, in that same blog post, recommends this technique.

the way browsers work link gets a click event give feedback gracefully handle network errors caching and memory management history management show the page photo by andrei.vassiliev ﬂickr.com/people/andreivassiliev Normally when you click a link the browser gives the user feedback, handles network errors, handles caching and memory managment, changes the URL in the location bar and adds the new URL to the history allowing back button etc.

make your own browser link gets a click event give feedback gracefully handle network errors caching and memory management history management show the page photo by andrei.vassiliev ﬂickr.com/people/andreivassiliev but when you use page fragments you’ve gotta DIY. All you get is the click event.

reinventing urls, the core of the web and one of the biggest probs... reinventing URLs. This can screw with bookmarking, emailing, and all the other millions of things URLs are used for.

real performance gains? FULL STORY PAGE 3.5KB VS STORY PAGE FRAGMENT 2.7KB gzipped Ross mentioned some numbers in the ﬂickr blog post, but he ignored gzip compression. In reality, you’re looking at this sort of gain (from the news iphone site)

to save 0.8KB ? photo by fenlandsnapper ﬂickr.com/people/32834218@N00 is it reasonble to be sacriﬁcing all these standards-based kittens to save 0.8KB?

smarter interactions No blanket solutions are going to help you improve the performance of your app. What you need is good hard thinking and good interaction design. For example I spent a lot of time making the photo browsing experience on the webjam iphone site as snappy as possible.

use what you know photo by Here's Kate ﬂickr.com/people/thedepartment rather than use a “framework”, use what you know. http://www.ﬂickr.com/photos/thedepartment/137413905/

“The first design rule is to use web standards.” from Safari Web Content Guide for iPhone OS https://developer.apple.com/webapps/docs/ Interestingly the very ﬁrst paragraph of Apple’s guides for creating content of the iphone says to use standards. Apple gets it, we’ve gone off on our own little tangent of recreating the native experience.

WHERE DOES IT LIVE? so having now built a site, how does it live with the existing site?

on the news site (pre the new design) the page looked like this: 1.109MB. An iphone stylesheet wouldn’t help an iphone user on a 3G connection.

sub-domain so we created a completely separate site.

.mobile pages on webjam it’s integrated into the site with “.mobile” pages (note: this isn’t any sort of standard, it’s just a convention I adopted to different the mobile 2.0 optimised pages, just like .rss or .xml signals a different version of the same page.

HOW DO THEY FIND IT? build it and they will come?

redirect from / photo by kinetic ﬂickr.com/people/kinetic On the home page of the main site detect the user agent and redirect to mobile 2.0 site. http://www.ﬂickr.com/photos/kinetic/185409979/ There’s various ways to do the detection.

on a page that isn’t the homepage, *don’t* redirect them. The link may have been emailed to them, synced from a bookmark etc... show them the original page they were expecting... but provide a fat link make to the mobile site, or even better, the mobile equivalent of the page they’re looking at.

/webjam8 -> /webjam8.mobile the webjam site simply links to the URL of the mobile version of the page, or if failing that the mobile version of the homepage.

and you also have to link from the iphone site back to the old site.

-> /?no-mobile-redirect=true

if you’ve seen the twitter mobile site, they have a similar thing in the footer.

modes via cookies photo by Esti Alvarez ﬂickr.com/people/esti the biggest problem is that it uses cookies. When you you hit the button labelled standard it sets a cookie, and if you hit back and refresh, or back and click on a link, you get the regular big site. The only way to turn off the mode is to pinch, scroll and zoom your way down to the mobile button on the footer of the standard page. The user is not really in control. The solution is to simply use URLs, just like the webjam site’s .mobile pages.

IPHONE AND WEBKIT GOODIES

Huzzah!

Helvetica and it comes with this baby... it’s even the preferred font for mobile safari optimised sites.

CSS 2.1 .multiple.classes :first-child :first-of-type input[type=submit] h1 + h2 Huzzah!

ul.group li:first-of-type a.item { -webkit-border-top-left-radius: 5px; -webkit-border-top-right-radius: 5px; } ul.group li:last-of-type a.item { -webkit-border-bottom-left-radius: 5px; -webkit-border-bottom-right-radius: 5px; } .content h2 + ul.group { margin-top: -0.8em; } this group of buttons on the webjam site uses the following markup for its rounded corners. Adjacency selectors come in handy with h2’s against h3’s, or headings against this group of buttons (which you can faintly see above)

a.button { border: 1px solid; border-color: #fB3E30 #6B0E00 #6B0E00 #fB3E30; background-color: #BB0E00; color: #fdd; padding: 0.5em 0.6em; text-shadow: #3B0E00 1px 1px 2px; -webkit-border-radius: 5px; text-decoration: none; } here we have some text-shadow and border-radius to get an image-less but thumbable button

and lots more... multiple backgrounds <canvas> multi-touch events http://www.westciv.com/iphonetests/

http://au.youtube.com/watch?v=-XKb8We_uzg here’s an example of using the multi-touch events with CSS transforms... all done in the browser. No plugins required. This is mobile-safari stuff.

Apple docs are a great place to start: web app development center (unfortunately Apple are a PITA and everything is behind user registration)

a demo of the iPhone Emulator, which ships with Apple’s free iPhone SDK (available again, from the apple web dev center). You’ll need a Mac.

./emulator and ﬁnally, a demo of the android emulator. This app is for windows, mac and linux which is great, but isn’t very user-friendly. There’s no application icon, I boot it up from a terminal window. Hopefully this will change.

Developing for the iPhone

1 comments

Notes on slide 1

29 Favorites & 1 Group