Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Designing for the mobile web

A4000ed18dacadbd1ca36aec726816ad?s=47 makenosound
September 27, 2011

Designing for the mobile web

Given at Swipe 2011. An iOS and Mac development conference.



September 27, 2011


  1. Max Wheeler Icelab Designing for the mobile web

  2. None
  3. I am designer.

  4. I am designer. (web)

  5. Sorry .

  6. I have designed: * the Water Storages app for the

    Bureau of Meteorology * Decaf Sucks
  7. St a te of the mobile web * Rapid change

    * Pre-iPhone, poor HTML/CSS support
  8. WML, basic HTML/CSS. * Wireless Markup Language * Last 4

    years we have gained enormous set of in-browser functionality
  9. Canv as, video & A udio, geoloca tion, Orient a

    tion, CSS3, Transition, Anima tions, Transforms (2d+3d), Hardware accel, localstorage, offline support, SVG, History API, Media queries, Touch events. * Some of the features available in Mobile Safari. * New things
  10. WebGL 3d drawing, File API, Web workers, Device camera API.

    * These features are ready for prime time * No legacy of older browsers, it’s a golden age
  11. HTML & CSS. * Why aren't we building our mobile

    experiences in web technologies rather than Objective-C. * HTML/CSS very powerful * Cocoa/UIKit sucks for styling (esp. mixed content areas)
  12. HTML & CSS. (yay!)

  13. Do you really need an app for tha t? *

    We need something shiny for the CEO/minister * Consider real purpose * Will people use it?
  14. Maybe. * Maybe * You *need* a mobile web site/app

    * Customers will come with their devices, you don’t know what they are * iOS can’t be your only choice
  15. 1. Switch to the App Store 2. Click buy 3.

    Enter their p assword 4. Wait for it to download 5. La unch it You’re asking them to 1. Switch to the App Store 2. Click buy 3. Enter their password 4. Wait for it to download 5. Launch it
  16. Apps are not websites. App are not websites.

  17. Nada. * Do nothing * We can do better

  18. Go responsive. * Responsive design is the future * Use

    media queries to TRANSFORM your content based on device capabilities
  19. None
  20. Jon Hicks’ site: hicksdesign.co.uk

  21. Jon Hicks’ site: hicksdesign.co.uk

  22. Jon Hicks’ site: hicksdesign.co.uk

  23. Food Sense: foodsense.is

  24. Food Sense: foodsense.is

  25. Food Sense: foodsense.is

  26. Swipe! swipeconference.com.au

  27. Swipe! swipeconference.com.au

  28. Swipe! swipeconference.com.au

  29. @media  screen  and (max-­‐device-­‐width:  320px)  {    /*  iPhone  specific

             stuff  goes  here.  */ } * Simple example: checking device screen width
  30. * Get your mitts on Ethan Marcotte's book "Responsive web

    design" * The right way: device and resolution agnostic * Problems: you’re reshaping content, if you want a different experience, you need a separate “app” * m.domain.com
  31. Build web apps. The original promise of the iPhone app

    ecosystem *was* the web.
  32. – Steve jobs, wwdc 2007 “The full Safari engine is

    inside of iPhone. And so, you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services. They can make a call, they can send an email, they can look up a location on Google Maps.... ...And guess what? There’s no SDK that you need! You’ve got everything you need if you know how to write apps using the most modern web standards to write amazing apps for the iPhone today. So developers, we think we’ve got a very sweet story for you. You can begin building your iPhone apps today.” * MobileSafari is still the best mobile browser * iOS gives developers features that can make web apps feel at home * Surprise surprise: Apple’s focus is on their own platform
  33. Gmail * Lots of work to make it feel at

    home on iOS * Touch not mouse events * More natural scrolling * Pull down to refresh
  34. Facebook has multiple mobile sites * m.facebook.com * touch.facebook.com *

    Doesn’t overreach: it’s a website
  35. Gowalla * m.gowalla.com * Geolocation API Why are we building

    native apps?
  36. Ceci n'est p as une applica tion. * Ceci n’est

    pas une application * Using these apps in earnest, they break quickly * Gmail loses state a lot of the time, shows old data, refreshes poorly and logs out often. * It’s getting better * People expect their browser to function in a certain way
  37. 22px 60px 44px * You’re in the context of a

    real native app: the browser * Interface you can’t avoid
  38. “Add to home screen” * Add to homescreen * iOS

    the only platform that offers this. Some Android devices let you in bookmarks.
  39. <meta  name="apple-­‐mobile-­‐web-­‐ app-­‐capable"  content="yes"  /> * Uses <meta> tags *

    No browser chrome * Icons * Splash screen
  40. * UIWebView sans-browser chrome

  41. if(window.navigator.standalone)  {   //  Do  stuff } * Exposed as

    a JavaScript object * Web apps can have the same weight and presence on Springboard * I’m skeptical * How many of you use a web app that’s pinned to your homescreen? * I use one. That I built.
  42. A little help from my friends. * iOS bred a

    series of libraries that attempt to replicate the look, feel and feature set of native apps.
  43. None
  44. None
  45. None
  46. None
  47. None
  48. None
  49. * There are literally hundreds of them * And by

    and large they all fail * “nearly” native
  50. Uncanny V alley * We end up in the Uncanny

  51. * The concept of the “Uncanny Valley” applies to any

    attempt to replicate the appearance or experience of something else. * If it looks like an native app, quacks like a native app, but doesn't move like a native app... * Break expectations * Users become frustrated, confused and afraid
  52. Tom Hanks in Polar Express = Mobile web app that

    pretends to be native
  53. Tom Hanks in Polar Express = Mobile web app that

    pretends to be native
  54. Tom Hanks IRL = Native app

  55. Tom Hanks IRL = Native app

  56. mobile.twitter.com * Looks great, feels odd * The hierarchy in

    a native app isn’t the same as on the web * Back/forward buttons do unexpected things
  57. * Clicking on the status bar does the wrong thing.

  58. None
  59. * One of thousands of articles that ring the death

    knell of the App Store and Apple's ecosystem at the hands of HTML and CSS
  60. “HTML5 will kill the App Store”

  61. “Mobile Web spells doom for Apple” * Blah blah blah

    blah * It hasn't happened
  62. * The dream of cross-platform * Business centric, not user

    centric * A fallacy to begin with: you’ll have to fork your code
  63. Bridges. JavaScript bridges to Objective-C: * Titanium: http://appcelerator.com/ * NimbleKit:

  64. * Take JavaScript and compile it down into Objective-C. *

    Lure is strong * Fool’s errand
  65. None
  66. * Writing Objective-C: Panic and run away. * Memory management,

    square brackets * Can never be as good as a native app * Icelab tried it, got burnt * How long will it take Titanium to support iCloud APIs?
  67. Striving for grea tness. We want to create great things.

  68. * This is true: the App Store is full of

    rubbish, and the web is filled with rubbish * It doesn’t mean either platform is broken * Bridges are a half-baked approach * I don’t want to be “good enough”
  69. – Freeman Dyson “There is a great satisfaction in building

    good tools for other people to use.”
  70. “Don’t Half-ass a fea ture”

  71. * Currency.io * Built by ab+c * Simple, standalone web

    app * Quick quick quick * Feels responsive
  72. * Booki.sh * Vastly more complex * Web-based ebook reader

  73. * Save books to homescreen * Offline caching * All

    the features of a native reader * An ENORMOUS amount of work * Faster to build native apps for all platforms? * Business model means they can’t go native
  74. * Financial Times * Readability * Basecamp * Netflix *

    Side-stepping the App Store is a great reason to choose the web * 37Signals do what they’re good at * Netflix consolidating their code and knowledge base * Make a *conscious* choice
  75. Monkey see, Monkey do. * Web developers jumping to the

    app store remind me of print designers doing the same
  76. * Fail by trying to replicate their original medium

  77. None
  78. Apps that get it right: * Flipboard * The Age/SMH

  79. * Native wrapper * Mostly web views * Uses native

    controls for fluidity, uses the web (HTML/CSS/JavaScript) for what it’s good at
  80. * It’s easy to compartmentalise * Native app therefore “A”

    * Website therefore “B”
  81. How I learned to stop worrying and love the web.

    * These technologies can work in concert * Our technologies choices don’t have to be dogmatic
  82. How I learned to stop worrying and love the web.

  83. Do the right thing. * It's OK to build hybrid

  84. The mobile web is ready . * Mobile browsers are

    catching up * iOS is not a stationary target * We’ll be waiting a while for iCloud access via JavaScript API * Accept the things your technology choice is good (and bad) at. * Your tools are your tools and that's fine, they’re not necessarily the right tools for every situation
  85. Thanks.