We’ve got a website for that HTML5 and the future of the mobile web

No content

In the beginning, there was the web And the web was Good.

The Web Free Open Interoperable Accessible Unregulated Uncontrolled Co-operative

No content

The web has transformed our lives. Now we need that stuff on the move.

1999: WAP . Seriously?

2001: BlackBerry. Now we’re talking. (except ironically we’re not talking because Blackberry wouldn’t add phone capabilities for another 3 years)

2007: iPhone. Cracked it.

2008: Apps arrive. Web largely forgotten.

Apps Paid Proprietary Platform specific Inaccessible Regulated Controlled Uncooperative

But wait, what exactly is an app, anyway?

Adaptive design •  Completely flexible viewport size •  Use ALL of the space on the screen •  Nothing partial, everything balanced •  Like it was designed to fit your screen

Adaptive interface •  Mouse and keyboard •  Touchscreen •  TV remote •  Games console controller •  3D motion capture •  Speech •  Thought

People built apps because their websites weren’t adaptive to the new touch interfaces

No content

But an ‘app strategy’ is questionable

So, couldn’t we just make a website do all that app stuff?

Challenges •  Layout •  Navigation and interaction •  Offline use •  Rethink backend architecture

Flowed columns

Flowed columns

Flowed columns •  CSS columns not good enough •  We measure content and cut it into positioned containers using JavaScript – Deal with fixed elements first – Columnflow library to be open sourced soon

Content balancing

Classifying devices by resolution

Swiping between sections

Fastclick •  Touch is instant, but click requires ~300ms linger •  Some taps are shorter •  'Fastclick' layer to detect very brief taps, and convert to clicks •  Used for devices that fire touch events •  Used eg. for tapping through pages of an article •  Disables interactions like double tap to zoom •  Open-sourced by Assanka, assanka.net/fastclick

Offline use •  Launching the app offline •  Making text content available offline •  Storing content images offline •  Analytics

Booting •  Every page needs to be able to initialise using old code, then update itself •  Not all users will see the same thing – We still have some running 6 month old code! •  Don’t break the web – remember you have pages, not a monolithic single page app. – Avoid tedious start-up sequence on every real pageload.

Offline technologies •  Application cache (manifest) is: –  used for bootstrap page and static files –  seriously flakey. Use sparing. –  extremely annoying. Set a dynamic comment or auto- change manifest when resources change •  WebSQL / SQLite / IndexedDB is: –  used for indexed content, articles, images etc. –  slow. Consider local storage instead. •  Local storage is: –  used for key/val storage, app settings, config, prefs –  fast and relatively reliable

Rethink the backend •  Build an API framework •  Use the API from your JS application •  Multiple API requests per HTTP request •  Multiple ways of requesting a page: – Fully wrapped – Fragment – API request

Unresolved problems •  SSL/padlock: We tell you it's secure, and, er, you trust us. •  Social media integration: Twitter/FB SSO mechanism can't be integrated into a one-page app •  Offline adverts: No clicks, no live impression recording, no advanced targeting •  Automated QA: Many times more complex than desktop apps

Useful tools •  Charles – www.charlesproxy.com •  WeinRE – phonegap.github.com/weinre/ •  WebDriver for mobile browsers – http://code.google.com/p/selenium/wiki/ WebDriverForMobileBrowsers

In summary •  Ease of use is critical. Adapt, adapt, adapt. •  The web can do this •  Web approach retains all the benefits of the web that you give up when building native.

“Don’t build native apps, build web apps” -­‐  Tim  Berners-­‐Lee  

Questions? •  Andrew Betts •  andrew.betts@assanka.net •  You should follow me on twitter here: – @triblondon •  Build this stuff: – assanka.net/jobs