Pro Yearly is on sale from $80 to $50! »

Offline First (Web) Apps

Offline First (Web) Apps

Presented at WebDirections Code 2014 in Melbourne

@espylaub / @hoodiehq

Abstract: Just assume for a minute that the technical side of building offline-capable (web) apps was really simple. Because it's getting easier every day, and it's obviously desirable: having a robust, reliable app instead of one that turns into a wonky disappointment when it's disconnected for a moment. But what does building apps offline first mean in terms of interfaces and experiences, in terms of your application's structure? What new things can you do? What problems can you solve? What problems does it cause? Is it too much trouble, or is it the future? A talk about patterns for offline UX, persistent local data, confident wording, pre-empting user needs, conflict resolution and ordering things in lists.

Video will be linked whenever it is available.


Alex Feyerke

May 02, 2014


  1. Offline-First BETTER (WEB) APPS Alex Feyerke / @espylaub WebDirections Code

    2014, Melbourne Good morning! This is „Offline First Web Apps“, my name is Alex, I‘m a web dev from Berlin, and as such I‘m very grateful to Maxine and John for inviting me all the way over here. I‘m part of the team that makes Hoodie:
  2. an open-source framework/library that lets you quickly build complete, data-

    driven web apps from the frontend. And these apps are offline capable by default, which is why we‘re so interested in this whole topic. Source:
  3. Offline-First Concepts Interfaces Experiences Problems So, first of all, what

    this isn't: a step by step guide to actually building offline first apps. For one, because John Allsop just held an all-day workshop about that the day before last, and, as I just said, hoodie‘s got the tech working already, so we‘re worrying more about what we can do with it. But first, let‘s talk about how we work.
  4. How we work IT‘S BASICALLY SCIENCE FICTION We make web

    apps. Or native apps, for our purposes, it doesn't make a difference. Many native apps are just web views anyway, talking to servers over http. But we make, and while we make, we imagine those things we make in their completed, working, usable state. We imagine them in the future, where all the cool people are using our stuff and making us rich and famous. Or at least internet famous. But there are other ways of imagining the future. Microsoft, for example, is a big system, and it loves imagining the future in elaborate ways. They regularly release a so-called "Productivity Future Vision", like this one, for 2011. The name sounds as if someone just pulled three human reources buzzwords from a hat, but let‘s take a look:
  5. Microsoft‘s Productivity Future Vision 2011 But it feels… wrong.

    It's too smooth. It's not normal enough. It‘s a choreography of wealth and status, and it‘s utterly improbable in its perfection. And maybe you noiced: the devices still have recognizable pixels, but none of them have battery or signal strength indicators. Source:
  6. Everyone's happy, nothing is broken or smudged. There is infinite

    wi-fi with infinite bandwidth, no batteries run out, no traffic, no delays. —Tobias Revell Critical Design / Design Fiction You should absolutely read those lecture notes, by the way. It's eye-opening and very well done, which is why I'm stealing a bit more from it. Look at this Google Glass promo:
  7. Google Glass Promo Video This is marginally better: there‘s

    normal stuff like playing with dogs or a flight being late, but the basic symptoms are the same: the people, the lives, the circumstances: most of them are outliers, all very privileged people in a kind of post-scarcity scenario where, as Revell puts it, "it's a classic case of everyone suddenly being an ice sculptor and flying around in balloons". It's also not normal. It's a fantasy, and as far as goals and dreams to work towards go, it's all a bit odd. But it‘s more nuanceed, too. It has some degree of normality, and it‘s implying something interesting: people are using glass in places without network connections, as in, you know, the sky. Unless that balloon in the beginning was one of googles top-secret internet balloons providing wifi to the skydivers and the flying club, I think the implication is they‘re expecting it to work offline. So: still improbable, but has hints of normality.
  8. Let‘s go back a bit This next one is from

    1969, with a vision of the 1990s. So I‘d just like you to picture that in your mind for a second. The future, seen from the 60‘s. You‘ve all seen the movies. Ok? Now consider that this was made by the British Post Office…
  9. Post Office in the 1960s - A glance 30

    years into the future from Dollis Hill Research Station It seems rather normal. Why is that? People aren't wearing futuristic clothing, doing extraordinary things, or even sitting at transparent desks with flashy lights everywhere. We see a normal man at a normal desk in an normal office. Also: the very first thing that happens: it doesn't work properly. The guy at the other end can‘t understand anything. And the weather's bad. It's London, Bad weather is normal. Listen: "suppose she makes an error". People don‘t make mistakes in Microsoft‘s future vision. Nobody asks „uh, Glass? Did you hear me?“ in the google thing. And the topics? Leases, bank statements, mortgages… normal normal normal. It's mundane, it's a bit wonky, but it's everyday life. Source: So thinking about the future is obviously a bit hard, because…
  10. […] for every miraculous iPad there are countless partly broken

    realities: WiFi passwords, connectivity, battery life, privacy and compatibility amongst others.
  11. The real skill of creating a compelling and engaging view

    of the future lies not in designing the gloss, but in seeing beyond the gloss to the truths behind it. —Nick Foster The Future Mundane Source:
  12. We‘re not normal I'm showing you all this because we,

    as, and I'm sad to have to say this from up here, as well-educated, well paid people in the tech industry in a super- wealthy country, we're also not normal.
  13. And the circumstances in which we work aren't normal, they

    usually bear little relationship to how and where our products will probably be used. We build from behind shiny macs with full-sized keyboards in well-equipped offices with fast connections, but the target environments are radically diverse and different.
  14. Our circumstances define our mindset We have the best tools

    and the best infrastructure available to us, and of course, that informs our mindset when we build all the new shiny future things.
  15. Build for a normal world Unless you have a super-specific

    elite audience, what you really want to do is build for a normal world.
  16. Build for a mobile world And the normal world, with

    all the normal people it, that have average budgets and average resources, that world, from your perspective, is overwhelmingly mobile. Phones are mobile, tablets are mobile, this thing is mobile. This is a mobile device. I was sitting in a burger joint on Bondi Beach two weeks ago, two completely normal university students were sitting there with their little lenovo laptops with 3G-USB sticks plugged in. They'll be moving around, switching connections, losing connections, running into battery trouble just like people with smartphones. Mobile is normal.
  17. Normality is imperfect And you all know this: it's imperfect.

    Normality is imperfect. The web is imperfect. The experience you're building? It's going to break for people, I guarantee it. It's also imperfect, and it's imperfect in ways you can't influence, mainly connection speed and reliability.
  18. But what you can do, now, is build experiences to

    accomodate this normality, experiences that go beyond your apps just breaking, becoming unresponsive, showing empty views, losing data, making people nervous with panicky error messages. You can now build your apps in ways that acknowledge the fact that the web is imperfect, that your connections to it are also imperfect, and provide good experiences regardless.
  19. Offline is not an error because Offline is not an

  20. Offline is a fact of mobile life

  21. A comparison: Mobile First is a design strategy to help

    cope with the vast, ungraspable variety of devices and capabilities, like these android screen dimensions here. In the same way, Offline First is a design strategy to help cope with the unknowable circumstances and connection states our users may find themselves in. We know next to nothing about them, and can take next to nothing for granted. Offline First is simply an acknowledgement that this lack of certainty extends a bit further than we previously thought.
  22. progressive enhancement vs. graceful degradation Offline first assumes nothing about

    the users‘ connectivity. It‘s just another form of progressive enhancement, really. Offline is the default state, connectivity is a bonus.Treat the network as a potential enhancement. And in this case, progressive enhancement is the preferred strategy, because adding offline capability after the fact is problematic: the architecture is necessarily quite different. So, before we continue, a small foray into…
  23. Offline-First Architecture offline-first archiecture. And because I promised this wouldn‘t

    be overly technical,
  24. Offline-First Architecture A SUPER SHORT OVERVIEW I‘ll keep it short.

  25. WHAT NEEDS TO BE OFFLINE? An App's offline capability is

    guaranteed through two separate aspects:
  26. • The app and its assets WHAT NEEDS TO BE

    OFFLINE? - the app itself and its assets must be available offline. This is done through Appcache or Serviceworker, or through a native wrapper such as phonegap or node-webkit
  27. • The app and its assets • The app‘s data

    WHAT NEEDS TO BE OFFLINE? - the app must handle data in a way that doesn't require a connection. This is best done by reading and writing through a local data store which syncs, when possible, to the server. Use Localstorage, localforage, PouchDB or, on a higher abstraction level, Hoodie. Let‘s see how hoodie handles this.
  28. Hoodie Sync Here‘s how Hoodie does offline, and, in fact,

  29. FRONTEND BACKEND Hoodie Sync

  30. FRONTEND App BACKEND Hoodie Sync

  31. FRONTEND App BACKEND Hoodie Sync The app only ever

    talks to the hoodie API, never directly to the server-side code, the database, or even in-browser storage.
  32. FRONTEND App localstorage BACKEND Hoodie Sync Feel free to

    replace localstorage with any in-browser storage of your choice. This, by itself, is enough for an app. Do you even need to store anything on the server apart from credentials? You might not. Your business model might even profit from not doing so. But let‘s assume you do:
  33. FRONTEND App localstorage Sync CouchDB REST BACKEND Hoodie Sync

    We can do this because each user has their own little private database which only they can access. So it‘s very simple to decide what gets synced. It‘s the user‘s private data. Of course it should be on their machine.
  34. FRONTEND App localstorage Sync Plugins (node.js) CouchDB REST BACKEND

    Hoodie Sync Explain a direct message moving through the system So we never have element talk directly to each other. They only leave each other messages and tasks, it‘s all very loosely coupled and event-based. Which means that it can be interrupted at any stage without breaking. Messages and tasks will be delivered and acted upon whenever possible. It‘s designed for eventual consistency.
  35. FRONTEND App localstorage BACKEND Hoodie Sync Sync Anyone home?

    Out for lunch, BRB The nice thing is: in most cases, the frontend doesn‘t care whether the backend is actually there or not. It will hang on to your data and sync whenever it can, and if your UI allows it, users can keep working without interruption.
  36. FRONTEND App localstorage Sync Plugins (node.js) CouchDB REST BACKEND

    Hoodie Sync So if you want true offline capability, your app can‘t try to talk to the server directly, only through sync, and you always want to keep a local copy in browser storage. And sync is hard. Really. Don‘t even think about implementing this yourself, there‘s just so much to get wrong.
  37. We trust the CouchDB for this. It‘s a database that

    replicates, which is exactly what we want for syncing.
  38. But there are others

  39. But there are others

  40. There‘s even JSGit! But whatever you do, don‘t do this

    by yourself. But remember: sync is the keystone of offline first:
  41. Getting into the offline mindset requires only one key realisation:

    when you leave the world of timely, reliable communication, the local database, not the server’s, must be the gateway for all persistent changes in application state. — Aanand Prasad Offline Support is Valuable, and You Can’t Add it Later Source:
  42. How do I make this offline magic work?

  43. //  Store  some  data'todo',  {name:  'fly  to  australia'}) Using

    Hoodie Store some data: use the API.
  44. //  Store  some  data'todo',  {name:  'fly  to  australia'}) //

     Sign  up  a  new  user hoodie.account.signUp('',  'secret'); Using Hoodie Sign up a new user: use the API
  45. //  Store  some  data'todo',  {name:  'fly  to  australia'}) //

     Sign  up  a  new  user hoodie.account.signUp('',  'secret'); //  Send  an  email  emailProperties  ) Using Hoodie Send an email: you know the drill.
  46. //  Store  some  data'todo',  {name:  'fly  to  australia'}) //

     Sign  up  a  new  user hoodie.account.signUp('',  'secret'); //  Send  an  email  emailProperties  ) Using Hoodie Wait, so how do I offline? 0_o So how do you make this work when it‘s offine?
  47. //  Store  some  data'todo',  {name:  'fly  to  australia'}) //

     Store  some  more  data!'todo',  {name:  'steal  a  wombat'}) //  Listen  for  store  events'add',  handleObjectAddition) Using Hoodie That‘s it. All you need to do is embrace the decoupled architecture of offline first. Talk to the api, let it sync for you, and listen to events from your browser store to see if new data has arrived. And that‘s it. It‘s not a special feature you have to explicitly invoke, it‘s how the entire architecture works. You get offline for free. Let‘s just see that in action:
  48. None
  49. Sweet. Now what? So, we felt like we'd solved a

    lot of the technical aspects, and now we were wondering: what opportunities does this gives us, exactly? Which problems can we now solve?
  50. Let‘s ask around We thought we had a pretty good

    topic here, and we decided to try and see if other people agreed.
  51. Gregor was on the Africa Hack Trip through Kenya, Uganda,

    Rwanda and Tanzania anyway, so he met a lot of people with interesting offline problems
  52. I wrote a blog post that got quite a lot

    of traction…
  53. …some great resonses on twitter and a surprisingly friendly hackernews

  54. None
  55. Then I wrote another one…

  56. Mozfest OFFLINE FIRST- WORKSHOP We also had an offline-first workshop

    at Mozfest London, with about 40 participants…
  57. …and another in Berlin a bit later. As we started

    asking developers from all over the world about these issues, we were surprised at how many people suddenly opened up about their offline troubles—realizing they’d had similar problems in the past, but never spoken to others about them. Most battled it out alone, gave up, or put it off, but all secretly wished they had somewhere to turn for offline app advice. People had veeeery interesting and specific problems, ranging from building, and I quote, „runkeeper for fish“, for anglers in the norwegian wilderness, to several people trying to build robust point-of-sale systems for places with bad connectivity. But we identified some central themes:
  58. Trust and reliability OFFLINE PROBLEMS But the first and most

    pressing issue people seem to have is that they can‘t trust their apps to do the right thing when the connection gets dodgy. You can summarize this with the following user story:
  59. As a mobile app user, I want to be sure

    that the data I need is actually there when I need it USER STORY And this is quite fundamental. It‘s so fundamental it probably gets forgotten most of the time. Of course users want this. But it used to be a painful problem, and it was easier to just fail, show errors and let people blame it on their networks. But in some cases, you can‘t do that.
  60. So here‘s the german railway advertising that you can apparently

    book tickets and use their app under any circumstances, even when free soloing in the alps (remember, in the tech future, everyone is into extreme sports and ice carving)
  61. vs. and then there‘s the normal world with this guy

    who can‘t access his ticket, because the app won‘t start up when the connection is bad. It‘ll work in airplane mode, but on an actual high-speed train, where the phone can connect to the occasional cell but not do anything with it, it fails, and it fails slowly. While the ticket inspector is breathing down your neck.
  62. Another symptom: screenshotting apps, because you can‘t trust them to

    retain their state. Lots of people do this. I went through the photos on my phone and found quite a few of these screenshots, where I was afraid that the data I‘d just fetched would vanish the next time I opened my phone. Because this kind of thing happens a lot:
  63. Those views were full of data just moments before I

    took these screenshots, but then I made the mistake of, I don‘t know, switching apps or putting my phone away for a minute. And what happens? The apps ditch any data they may have had, then fail at loading new data, and then the user suddenly has no data at all. That‘s just not cool.
  64. And even if an app stores stuff locally… how clear

    is this? How clear is it whether and which data is there, and will continue to be there, and under which circumstances? I can‘t trust this.
  65. More trustworthy and reliable apps OFFLINE FIRST OPPORTUNITY

  66. Always-online architecture OFFLINE PROBLEMS The second issue is that many

    apps are designed to only work while connected, even if there‘s absolutely no intrinsic requirement to do so.
  67. As a mobile app user, when I‘m offline, I want

    to be able to use features that don‘t require a connection USER STORY
  68. If you‘re only adding data yourself, why doesn‘t this just

    always work, online or offline? You should be able to add a meeting, mark a task as done, write a message, check in, post a picture… create stuff. Store now, sync later, but don‘t get in the way of getting things done if it isn‘t necessary. And again, this is an opportunity:
  69. More useful and more usable apps OFFLINE FIRST OPPORTUNITY This

    is directly linked to the next one:
  70. My data isn‘t with me OFFLINE PROBLEMS

  71. As a mobile app user, I want to have my

    personal data on my device at all times USER STORY It is my personal data, why should it not be on here? I might need it, and you don‘t know when. Plus, in most syncing scenarios, I‘m the authority over my data, so just let me keep a local copy. Granted, this gets problematic if your app is highly collaborative, but if you have a use case where user data is fairly well isolated, you can easily do this.
  72. Always-accessible personal data OFFLINE FIRST OPPORTUNITY

  73. Apps require advance planning OFFLINE PROBLEMS One more thing that

    frequently irked people: apps not being smart about what data they store locally. In short:
  74. As a mobile app user, I want apps to pre-empt

    my needs in a sensible manner USER STORY Because I don‘t know in advance when I‘ll need what
  75. Once out of bed, internet and apps are used almost

    constantly, peaking during the daily commute with 70 percent usage. — Ericsson Traffic and Market Report, June 2012
  76. RSS readers should already have new data in them when

    you open them With non-smart apps, you‘re regularly caught in the subway with day-old articles, because you explicitly have to fetch them yourself. But what else would you want in an RSS reader except new articles whenever you open it? When do people read on the go? While travelling. When are connections worst? While travelling. So the apps should fetch the data before you need it.
  77. Obviously important data should probably be stored locally Dropbox is

    good in this regard. Fave something on the phone? It‘s now on the phone, always. And that‘s a good assumption to make on their part. Now, i suppose that most of you are from australia, so you maybe didn‘t have this problem at this conference. But if you travel a lot, you‘d probably want this:
  78. Smart, offline maps WOULDN‘T THAT BE NICE So sure, you

    can have offline maps, but you need to know in advance. Get an offline maps app, or invoke a bizarre ritual to get google maps to cache your surroundings. Have you seen this?
  79. Go to the search box, enter „ok maps“

  80. exciting…

  81. even has a funky loading animation

  82. Great. Cached maps. It‘s obviously an experimental hack, but it‘s

    quite useful. But you could go further. Maps knows where you live, right? Imagine if it would pre-emptively download your surroundings as soon as it notices you‘re on wifi in a different country than usual. On the other hand, it nicely demonstrates some of the problems with caching local data: you need new UI elements, plus you need to answer some pressing questions: how long will the cached map be retained? Does it get flushed at some point? Can I remove it when I don‘t need it anymore? Can I cache more than one at a time, and if yes, is there some sort of limit? In short: how does it work and can I trust it?
  83. Smart apps that pre-empt user needs OFFLINE FIRST OPPORTUNITY Which

    brings us to:
  84. Offline-First Challenges It‘s becoming obvious that there are a number

    of new things you could be doing, and that these new things require new interfaces and in some parts even a new design language, because you have to communicate stuff to people you haven‘t had to communicate before
  85. save vs. sync How do we communicate the states data

    can be in? Stored locally, scheduled for sync, synced, possibly out of date, conflicting…
  86. We all know this is usually a lie. It means

    lots of things, but in the end it only means:
  87. You wouldn‘t understand… „I‘m not ready, and it‘s to complicated

    to explain why“. But we want to reassure users, remember? We need to find a good language, possibly visual, to do so
  88. If your app now behaves differently depending on whether it‘s

    connected or not, you‘ll have to make this clear somehow. Threema does this by displaying an always-visible connectivity stripe at the top, red for disconnected, yellow for connecting and green for connected, and teaches you beforehand what the consequences of each are.
  89. Save But you could just as well selectively disable, hide

    or re-phrase features. Imagine a save button that knows whether it‘s connected to the server, and changes accordingly:
  90. Save AND SYNC LATER Or you could just let users

    save either way and inform them about the state of things after the fact:
  91. Saved locally (offline, syncing later) There are loads of ways

    to solve this problem: be super-secretive and just handling everything in the background, or inform the users before, during or after they‘ve done something. Depends on the use case, who you‘re developing for, and how crucial the data is to them.
  92. Informing users about sync outcomes Lastly, informing users about sync

    outcomes. Not just whether they succeeded or not, but how and possibly why data has changed in their browser. This is probably one of the hardest UI problems related to sync, especially when it comes to chronologically sorted data, like chats or other streams/threads.
  93. 10:00 - Hi 10:01 - Yo A B 10:02 -

    Meet on Thursday? A 10:03 - Sure, I‘m free. B 10:04 - Ah wait, meant Tuesday. A Here‘s a fairly simple chat example. Now imagine that B‘s second message was written while one of the two was offline. On a train, in a tunnel or something.
  94. 10:00 - Hi 10:01 - Yo A B 10:02 -

    Meet on Thursday? A 10:04 - Ah wait, meant Tuesday. A … Then the offline user reconnects and the messages sync up again. A receives B‘s missing offline message. So where do you put it?
  95. 10:05 - Hey A 10:06 - Hi C C 10:07

    - Hey, you free on Tuesday? A 10:08 - Lemme see… 10:09 - I asked B too, btw A 10:04 - Ah wait, meant Tuesday. A A C You can put it in the chronologically correct place, which makes sense in a thread context, because the order carries meaning. But that might mean the message appears somewhere out of the user‘s current view, way up there somewhere. That‘s a new UI challenge in itself. Or you could do what Imessage sometimes seems to do: display it in the flow according to the time it arrives at.
  96. 10:00 - Hi 10:01 - Yo A B 10:02 -

    Meet on Thursday? A 10:03 - Sure, I‘m free. B 10:04 - Ah wait, meant Tuesday. A This guarantees that the message will actually be seen by A, but this approach has the potential to change meaning, because message order is meaningful. And this is only text-based, one-dimensional data. What to do with deleted items, things that can’t be organised in lists, objects that aren’t in themselves immutable? There‘s a lot of potential for complexity here, so that‘s something to beware of. It‘s not a magic bullet, by any means. But as we‘ve seen, there are a number of problems you can solve this way. And there are a couple of additional advantages, too.
  97. Offline-First Advantages Let‘s talk about those.

  98. • Performance OFFLINE-FIRST ADVANTAGES First: Peformance. We put stuff in

    CDNs to move it closer to the user, but the closest thing to me right now is this (phone in pocket). Move your app in here.
  99. • Performance ZERO LATENCY OFFLINE-FIRST ADVANTAGES That's zero latency for

    me. This is the way to the snappiest experience.
  100. • Performance ZERO LATENCY • Robustness OFFLINE-FIRST ADVANTAGES Robustness. Offline

    capability protects from service interruptions. Interestingly, we hadn‘t even anticipated this. We have a fairly large service running on Hoodie and had to briefly take it down for maintenance, and most people using the app at that moment didn‘t notice. It doesn‘t matter if your app can‘t reach the server because the user is on the subway, or because the server is down. It‘ll still work.
  101. • Performance ZERO LATENCY • Robustness SERVER DOWN? I DON‘T

    CARE OFFLINE-FIRST ADVANTAGES Also: want to swap your backend? You can. They‘re swappable commodities now. As long as they speak the same API, you can just… swap to another one anytime.
  102. • Performance ZERO LATENCY • Robustness SERVER DOWN? I DON‘T

    CARE • Better experiences OFFLINE-FIRST ADVANTAGES Better experiences. Apps don‘t lose data. Apps are more trustworthy. Apps are more usable and useful. Apps cause less frustration.
  103. • Performance ZERO LATENCY • Robustness SERVER DOWN? I DON‘T

    CARE • Better experiences SAVE ALL THE TIME OFFLINE-FIRST ADVANTAGES And remember, you‘re saving to a local store first. You can save after every single keystroke if you want, and sync to the server every couple of seconds. There‘s a lot to be gained from an offline-first architecture that‘s not completely obvious at first glance.
  104. Do you need your users‘ data? Plus, it gets you

    thinking more about the data you‘re collecting, since you have to decide upon syncing strategies. And you may even find that you don‘t actually have to or even want to store your users‘ data on your servers. This can do wonders for scalability and privacy concerns, and may even be a business benefit for you.
  105. So, is Offline-First worth it? You may be looking at

    all this and thinking: „this seems like a lot of work for a reeeally specific issue, and networks are getting denser and better all the time, so why bother?“
  106. Well: Think of your everyday mobile experience, in your wealthy,

    well connected first-world cities, think of your mobile experience in the countryside, while travelling, in other countries, and then realise that global mobile traffic is on this kind of growth curve, and we‘re just in the middle of that at the moment.
  107. There will be more and more active smartphones, and the

    cheapest ones are selling best. And each subscriber‘s data use is expected to multiply over the coming years. Source:
  108. 51 percent of smartphone users are very satisfied with their

    operator’s network and only 3 percent are outright dissatisfied, leaving almost half in a position where their satisfaction could easily be improved. — Ericsson Traffic and Market Report, June 2012 Half of everyone is already somewhat unhappy with their coverage.
  109. And admittedly, carriers are pushing HSPA like crazy, but they‘ll

    never reach full practical coverage. The graph shows population coverage, not actual connectivity. And even if your city is blanketed in cell towers, you won‘t always be in that city. And if you are, there will still be subways, dense buildings and other dark spots. There will still be travel, extortionate international roaming charges, uncovered countryside, boats, planes, an overpopulated radio spectrum… And people need the proper devices to take advantage of these new technologies, too. I live in the capital of one of the most developed nations on earth, and even with a modern 600€ phone, I frequently only get unresponsive EDGE connections, or none at all. And that‘s before I even start travelling anywhere. Source: traffic_and_market_report_june_2012.pdf
  110. Don‘t just wait it out and hope it will solve

    itself Because the networks aren‘t the only thing. Apps and web apps are popular. They‘re competing with old-school native desktop applications that save to disk in many fields. They can iterate quicker and cover more platforms. People are moving their stuff to the web and to web services in droves. It‘s only going to increase:
  111. Any application that can be written in JavaScript, will eventually

    be written in JavaScript. —Jeff Atwood „Atwood‘s Law“ Today we‘re collaboratively editing and syncing simple text between multiple devices, next year it might be something quite different. Graphics. Music. Data tables. Anything. And if it‘s in the browser, trust me, it‘s going to be used mobile, and it‘s going to be offline at some point.
  112. And the browser is the place to be.

  113. At some point recently, the browser transformed from being an

    awesome interactive document viewer into being the world’s most advanced, widely- distributed application runtime. —Tom Dale Progressive Enhancement is Dead It‘s a very attractive platform for developers for many reasons, and as web apps gain complexity and mobile native app usage increases further, users will simply expect a mature and solid experience. Waiting for more cell towers to be built won‘t help them. Source:
  114. We can’t keep building apps with the desktop mindset of

    permanent, fast connectivity, where a temporary disconnection or slow service is regarded as a problem and communicated as an error. So, in closing:
  115. We can and should do better

  116. It‘s early days, and there‘s a lot to talk and

    think about
  117. There are still many techncial challenges With Hoodie, we have

    a solution for data scenarios, but it may not be what you need. It‘s still early days, and more people will find new and different ways of solving the problem for different scenarios. When if comes to apps, serviceworker is still far from ready, and appcache is really quite painful.
  118. We still need a design language for offline first There

    aren‘t really any UI pattern libraries or established design metaphors for save vs. sync, sync states, connectivity states, simple conflict resolution etc.
  119. We need more awareness that this is a thing More

    awareness of the problems, especially those we ourselves may not be exposed to, more awareness of the technical possibilities, and more awareness of the opportunities of embracing this paradigm
  120. We started to start bringing people together on this.

    We‘ve got some discussions going on github, we hold workshops and talks and travel around and talk to people. We‘ve started collecting other resources and projects, as well as people‘s feedback, and we‘re aiming to add more. And we‘d like to invite you to add your own ideas and issues.
  121. Please join in! And also:

  122. Don‘t panic, use Hoodie And come talk to me if

    you want to know more
  123. Thanks! Please come see me for info and stickers! @espylaub

    And please check out ❤