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.

Transcript

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:
   

   View Slide

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: http://hood.ie
   

   View Slide

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.
   

   View Slide

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:
   

   View Slide

5. https://www.youtube.com/watch?v=a6cNdhOKwi0
   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: https://www.youtube.com/watch?v=a6cNdhOKwi0
   

   View Slide

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:
   

   View Slide

7. https://www.youtube.com/watch?v=v1uyQZNg2vE
   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.
   

   View Slide

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…
   

   View Slide

9. https://www.youtube.com/watch?v=ONESDY9KMes
   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: https://www.youtube.com/watch?v=ONESDY9KMes
   So thinking about the future is obviously a bit hard, because…
   

   View Slide

10. […] for every miraculous iPad there are
    countless partly broken realities: WiFi
    passwords, connectivity, battery life,
    privacy and compatibility amongst
    others.
    

    View Slide

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: http://www.core77.com/blog/columns/the_future_mundane_25678.asp
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

19. Offline is
    not an error
    because Offline is not an error.
    

    View Slide

20. Offline is
    a fact of mobile life
    

    View Slide

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.
    

    View Slide

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…
    

    View Slide

23. Offline-First
    Architecture
    offline-first archiecture. And because I promised this wouldn‘t be overly
    technical,
    

    View Slide

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

    View Slide

25. WHAT NEEDS TO BE OFFLINE?
    An App's offline capability is guaranteed through two separate aspects:
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

28. Hoodie Sync
    Here‘s how Hoodie does offline, and, in fact, everything.
    

    View Slide

29. FRONTEND BACKEND
    Hoodie Sync
    

    View Slide

30. FRONTEND
    App
    BACKEND
    Hoodie Sync
    

    View Slide

31. FRONTEND
    App
    hoodie.store
    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.
    

    View Slide

32. FRONTEND
    App
    hoodie.store
    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:
    

    View Slide

33. FRONTEND
    App
    hoodie.store
    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.
    

    View Slide

34. FRONTEND
    App
    hoodie.store
    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.
    

    View Slide

35. FRONTEND
    App
    hoodie.store
    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.
    

    View Slide

36. FRONTEND
    App
    hoodie.store
    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.
    

    View Slide

37. We trust the CouchDB for this. It‘s a database that replicates, which is exactly
    what we want for syncing.
    

    View Slide

38. But there are others
    

    View Slide

39. But there are others
    

    View Slide

40. There‘s even JSGit!
    But whatever you do, don‘t do this by yourself. But remember: sync is the
    keystone of offline first:
    

    View Slide

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: http://aanandprasad.com/articles/offline/
    

    View Slide

42. How do I make this
    offline magic work?
    

    View Slide

43. //  Store  some  data
    hoodie.store.add('todo',  {name:  'fly  to  australia'})
    Using Hoodie
    Store some data: use the API.
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

47. //  Store  some  data
    hoodie.store.add('todo',  {name:  'fly  to  australia'})
    //  Store  some  more  data!
    hoodie.store.add('todo',  {name:  'steal  a  wombat'})
    //  Listen  for  store  events
    hoodie.store.on('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:
    

    View Slide

48. View Slide

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?
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

52. I wrote a blog post that got quite a lot of traction…
    

    View Slide

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

    View Slide

54. View Slide

55. Then I wrote another one…
    

    View Slide

56. Mozfest
    OFFLINE FIRST-
    WORKSHOP
    We also had an offline-first workshop at Mozfest London, with about 40
    participants…
    

    View Slide

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:
    

    View Slide

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:
    

    View Slide

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.
    

    View Slide

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)
    

    View Slide

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.
    

    View Slide

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:
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

65. More trustworthy
    and reliable apps
    OFFLINE FIRST OPPORTUNITY
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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:
    

    View Slide

69. More useful and
    more usable apps
    OFFLINE FIRST OPPORTUNITY
    This is directly linked to the next one:
    

    View Slide

70. My data
    isn‘t with me
    OFFLINE PROBLEMS
    

    View Slide

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.
    

    View Slide

72. Always-accessible
    personal data
    OFFLINE FIRST OPPORTUNITY
    

    View Slide

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:
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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:
    

    View Slide

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?
    

    View Slide

79. Go to the search box, enter „ok maps“
    

    View Slide

80. exciting…
    

    View Slide

81. even has a funky loading animation
    

    View Slide

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?
    

    View Slide

83. Smart apps that
    pre-empt user needs
    OFFLINE FIRST OPPORTUNITY
    Which brings us to:
    

    View Slide

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
    

    View Slide

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…
    

    View Slide

86. We all know this is usually a lie. It means lots of things, but in the end it only
    means:
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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:
    

    View Slide

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:
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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?
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

97. Offline-First
    Advantages
    Let‘s talk about those.
    

    View Slide

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.
    

    View Slide

99. • Performance
    ZERO LATENCY
    OFFLINE-FIRST ADVANTAGES
    That's zero latency for me. This is the way to the snappiest experience.
    

    View Slide

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.
     

     View Slide

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.
     

     View Slide

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.
     

     View Slide

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.
     

     View Slide

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.
     

     View Slide

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?“
     

     View Slide

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.
     

     View Slide

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: http://www.ericsson.com/res/docs/whitepapers/wp-wcdma.pdf
     

     View Slide

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.
     

     View Slide

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: http://www.ericsson.com/res/docs/2012/
     traffic_and_market_report_june_2012.pdf
     

     View Slide

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:
     

     View Slide

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.
     

     View Slide

112. And the browser is the place to be.
     

     View Slide

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: http://tomdale.net/2013/09/progressive-enhancement-is-dead/
     

     View Slide

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:
     

     View Slide

115. We can
     and should
     do better
     

     View Slide

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

     View Slide

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.
     

     View Slide

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.
     

     View Slide

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
     

     View Slide

120. We started offlinefirst.org 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.
     

     View Slide

121. Please join in!
     And also:
     

     View Slide

122. Don‘t panic,
     use Hoodie
     And come talk to me if you want to know more
     

     View Slide

123. Thanks!
     Please come see me for info and stickers!
     @espylaub
     And please check out http://hood.ie
     ❤
     

     View Slide