Tweet
Tweet

Slide 1

Slide 1 text

Offline-First BETTER (WEB) APPS Alex Feyerke / @espylaub Fronteers 2014, Amsterdam Good afternoon! This is „Offline First Web Apps“, my name is Alex, I‘m a web designer from Berlin, and I‘m very grateful to Flurin and the fronteers team for inviting me here. I‘m part of the team that makes Hoodie:

Slide 2

Slide 2 text

an open-source server that lets you quickly build complete, data-driven web apps from the frontend. It‘s like jquery for data storage. And Hoodie is a bit special, because these apps are offline capable by default, meaning they won‘t break when the connection goes down, and this is basically why we‘re so interested in this whole topic. Source: http://hood.ie

Slide 3

Slide 3 text

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. I don‘t want to stand here and explain to you how this one thing works at this moment, I‘d much rather spend time showing you what it means, and getting you interested in the general idea. [read slide] But before we get started, let‘s talk about how we work.

Slide 4

Slide 4 text

How we work IT‘S BASICALLY SCIENCE FICTION We make web apps. Or native apps, for our purposes, it doesn't make a difference. 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. Maybe just Kickstarter famous.

Slide 5

Slide 5 text

Maybe you‘ve seen plastc, this „20 credit cards in one“-thing, and like most pre-order/crowdfunding people, they have a vision, and they have a video. And it‘s basically a tiny slice of science fiction, a year in the future: „here‘s how we imagine real human beings behaving in the near future“. And, of course, the technology that goes with it. It‘s small and specific and mainly related to how people pay for things. [plastc.com]

Slide 6

Slide 6 text

But there are other ways of imagining the future. Microsoft, for example, is a big monolith of a company, and it loves imagining the future in more 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 resources buzzwords from a hat, but let‘s take a look:

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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. [source: http://blog.tobiasrevell.com/2013/12/critical-design-design-fiction- lecture.html] Look at this Google Glass promo:

Slide 9

Slide 9 text

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.

Slide 10

Slide 10 text

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…

Slide 11

Slide 11 text

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…

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

And I just said this when speaking about this product sci-fi: „here‘s how we imagine real human beings behaving in the near future“ But what I really mean, and what you really want, is „here‘s how we imagine something utterly normal happening in the near future“

Slide 15

Slide 15 text

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.

Slide 16

Slide 16 text

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.

Slide 17

Slide 17 text

It used to be that if your device could consume the web, it could also make it. That‘s no longer true. First, you had to learn that people‘s devices were different than your dev machine, and now you realize that their circumstances are also very different, and require a bit of an empathic leap.

Slide 18

Slide 18 text

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. An extreme example: If you take a google bus to work, you don't get the usual public transport experience. You've got free corporate wifi. Your commuting experience is far, far removed from that of basically everyone else. That‘s probably your baseline now. But in a way, we‘re all on the google bus. And we frequently forget that we have to…

Slide 19

Slide 19 text

Build for a normal world Normality is where most of life happens.

Slide 20

Slide 20 text

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 as a developer, is overwhelmingly mobile. Phones are mobile, tablets are mobile, this thing is mobile. This is a mobile device. There are, right now, hundreds of university students sitting in cafes with their little 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. The big grey box is a relic. Mobile is normal.

Slide 21

Slide 21 text

Normality is imperfect And you all know this: it's imperfect. Normality is imperfect. The web is very, very 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.

Slide 22

Slide 22 text

But what you can do, now, is build experiences to accommodate 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 you can provide good experiences regardless.

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Offline is a fact of mobile life and therefore…

Slide 25

Slide 25 text

Offline is a fact of normal life It‘s just a state your app can be in. And a fairly likely one at that. It‘s not exactly an edge case. So here‘s the basic idea behind Offline First:

Slide 26

Slide 26 text

Treat the network as an enhancement OFFLINE-FIRST IN A NUTSHELL So again, this comparison to something you know already:

Slide 27

Slide 27 text

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, and provide good experiences regardless. Offline First is simply an acknowledgement that this lack of certainty extends a bit further than we previously thought.

Slide 28

Slide 28 text

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 really is the way to go, because adding full offline capability after the fact is a bit difficult: the architecture is necessarily quite different. At least we think it should be. So, before we continue, a small foray into…

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

• 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. In a native app, this is a given.

Slide 33

Slide 33 text

• 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, IndexedDB, WebSQL, PouchDB or, on a higher abstraction level, something like Hoodie. This, to us, is the more interesting bit. Let‘s see how hoodie handles this.

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

FRONTEND BACKEND Hoodie Sync

Slide 36

Slide 36 text

FRONTEND App BACKEND Hoodie Sync

Slide 37

Slide 37 text

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.

Slide 38

Slide 38 text

FRONTEND App hoodie.store localstorage BACKEND Hoodie Sync [explain slide] As far as this concept goes, feel free to replace localstorage with any in- browser storage of your choice. This, by itself, is enough for an app. You can wrap that in node-webkit and sell it to people who don‘t trust the cloud. But let‘s assume you want more, you want user management and syncing.

Slide 39

Slide 39 text

FRONTEND App hoodie.store localstorage Sync CouchDB REST BACKEND Hoodie Sync [explain slide] We can do syncing 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, and we can easily keep people‘s data separate on the server.

Slide 40

Slide 40 text

FRONTEND App hoodie.store localstorage Sync Plugins (node.js) CouchDB REST BACKEND Hoodie Sync So, how does it work? [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, like passive aggressive roommates. 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.

Slide 41

Slide 41 text

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.

Slide 42

Slide 42 text

FRONTEND App hoodie.store localstorage BACKEND Hoodie Sync Sync I don‘t care! Out for lunch, BRB offline first apps are the web's honey badgers: they don't care, they just do their thing. Bees, tunnels, bad connectivity: the offline badger just keeps on going. It's how things should be on the internet: robust and fault-tolerant. Anyway, the point was:

Slide 43

Slide 43 text

FRONTEND App hoodie.store localstorage Sync Plugins (node.js) CouchDB REST BACKEND Hoodie Sync If you want true offline capability, your app shouldn‘t try to talk to the server directly, only through sync. And you always want to keep a local copy in browser storage. That‘s really the central point: the user‘s data on the user‘s device, always. Sync is pretty hard. Really. You probably don‘t want to be implementing this yourself, there‘s just so much to get wrong.

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

But there are others, and we‘re currently working on using PouchDB locally instead of localstorage, because it‘s fantastic, cross-platform and speaks couchy. Which is nice when we‘re syncing data back and forth.

Slide 46

Slide 46 text

Remotestorage has a one-backend-per user approach that also works offline and syncs.

Slide 47

Slide 47 text

And there‘s even things like JSGit! Whatever you do, try and find someone who‘s already solved this particular bit. But remember: sync is the keystone of offline first:

Slide 48

Slide 48 text

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/ So then, the big question:

Slide 49

Slide 49 text

How do I make this offline magic work? Magiiiiiiic

Slide 50

Slide 50 text

//  Store  some  data hoodie.store.add('todo',  {name:  'fly  to  amsterdam'}) Using Hoodie Nah, just a line of code. This is what using hoodie looks like. You use the api to store stuff, and when you add stuff, it expects a type (todo) and an object with data in it.

Slide 51

Slide 51 text

//  Store  some  data hoodie.store.add('todo',  {name:  'fly  to  amsterdam'}) //  Sign  up  a  new  user hoodie.account.signUp('[email protected]',  'secret'); Using Hoodie Sign up a new user: use the API

Slide 52

Slide 52 text

//  Store  some  data hoodie.store.add('todo',  {name:  'fly  to  amsterdam'}) //  Sign  up  a  new  user hoodie.account.signUp('[email protected]',  'secret'); //  Listen  for  store  events hoodie.store.on('add',  handleNewObject) Using Hoodie Want to know when something changed so you can update the UI? Listen to events from the library

Slide 53

Slide 53 text

//  Store  some  data hoodie.store.add('todo',  {name:  'fly  to  amsterdam'}) //  Sign  up  a  new  user hoodie.account.signUp('[email protected]',  'secret'); //  Listen  for  store  events hoodie.store.on('add',  handleNewObject) Using Hoodie Wait, so how do I offline? 0_o So how do you make this work offine?

Slide 54

Slide 54 text

//  Store  some  data hoodie.store.add('todo',  {name:  'eat  stroopwafels'}) //  Sign  up  a  new  user hoodie.account.signUp('[email protected]',  'secret'); //  Listen  for  store  events hoodie.store.on('add',  handleNewObject) 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 Hoodie 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:

Slide 55

Slide 55 text

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?

Slide 56

Slide 56 text

Let‘s ask around We thought we had a pretty good topic here, and we decided to try and see if other people agreed.

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

Then I wrote another one…

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

…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:

Slide 64

Slide 64 text

Trust and reliability OFFLINE PROBLEMS 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:

Slide 65

Slide 65 text

As a mobile app user, I want to be sure that my data is actually available 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 the telekom. But you can often do a lot better, and offline first is the way to go. But first, let me illustrate the problem:

Slide 66

Slide 66 text

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)

Slide 67

Slide 67 text

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 tower but not do much with it, it fails, and it fails slowly. While the ticket inspector is breathing down your neck. The solution would be to store personal data and tickets locally, and not make the initial communication with the server blocking.

Slide 68

Slide 68 text

Another symptom: screenshotting apps, because you can‘t trust them to retain their state. Who here does this? 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:

Slide 69

Slide 69 text

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. So, we can use offline first to get…

Slide 70

Slide 70 text

More trustworthy and reliable apps OFFLINE FIRST OPPORTUNITY

Slide 71

Slide 71 text

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. This is a relic from the age of the big grey box, of the terminal and the thin client, where all the computing power was probably far away from you. Now it‘s in your pocket, and we can do things differently.

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

If you‘re only viewing your own data, or 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:

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

My data isn‘t with me OFFLINE PROBLEMS It‘s probably on a server in the US somewhere, if you‘re lucky it‘s on a CDN on the same continent as you.

Slide 76

Slide 76 text

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. Or rather, your server only gets to back up my data. 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. So, the potential benefit is:

Slide 77

Slide 77 text

Always-accessible personal data OFFLINE FIRST OPPORTUNITY Super fast, always available and simply reliable.

Slide 78

Slide 78 text

Apps require advance planning to be useful OFFLINE PROBLEMS One more thing that frequently irked people when we talked to them about their offline woes: apps not being smart about what data they store locally. In short:

Slide 79

Slide 79 text

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 be offline. If we always knew that, a lot of this wouldn‘t be a problem.

Slide 80

Slide 80 text

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 When are connections worst? Right. While travelling. In the subway.

Slide 81

Slide 81 text

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. This is one of the experience driven facets of Offline First. Just making good offline experiences in general.

Slide 82

Slide 82 text

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. You could take this further though…

Slide 83

Slide 83 text

Smart, offline maps WOULDN‘T THAT BE NICE So sure, you can have offline maps, but you need to know that in advance. Get an offline maps app, or get google maps to cache your surroundings. But… 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.

Slide 84

Slide 84 text

Smart, offline maps ALSO A BIT SPOOKY And on the other hand, this nicely demonstrates some of the issues 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? Or, for you as a developer: can you make it trustworthy while hiding all the complexity? Interesting questions, but a cool opportunity:

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

save vs. sync How do we communicate the states data can be in? Stored locally, scheduled for sync, synced, possibly out of date, conflicting… possibly out of date is a state you‘ll get quite often in offline-capable apps, and you‘ll have to decide how crucial the age of data is, and how you communicate it. Because old data can still be useful while potentially being wrong. Think train schedules. Could be wrong, but communicate intent. And that‘s valuable.

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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.

Slide 91

Slide 91 text

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:

Slide 92

Slide 92 text

Save AND SYNC LATER Or you could just let users save either way and inform them about the state of things after the fact:

Slide 93

Slide 93 text

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.

Slide 94

Slide 94 text

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.

Slide 95

Slide 95 text

Informing users about sync outcomes So, I said that if users only add data, why not always just let them do that and sync later? Well, it turns out that things aren‘t quite as simple, and that context really matters. Here‘s a fairly simple chat example that illustrates some of the things you‘ll have to keep in mind:

Slide 96

Slide 96 text

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 Now imagine that B‘s second message was written while one of the two was offline. On a train, in a tunnel or something.

Slide 97

Slide 97 text

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?

Slide 98

Slide 98 text

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.

Slide 99

Slide 99 text

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. A simple chat, one of the simplest examples I could think of. 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.

Slide 100

Slide 100 text

Because the web platform is becoming more an more powerful and capable. Here‘s a photo editor. It‘s not photoshop, nor is it trying to be: it‘s quick, easy, no installation, cross-platform, auto-updates, and does most of the things you want in a simple photo editor. You‘d probably want it to work offline, though.

Slide 101

Slide 101 text

This is an experimental collaborative multitrack recording app, with synths and drumkits and audio, and it runs in the browser. This is part of a masters thesis by Jan Monschke, and it‘s really bleeding edge, but just imagine where this tech will be in a year. Cross-platform garage band? That‘s pretty damn cool. But again, it can‘t be used offline, and that‘s a disadvantage in comparison to the native apps it competes with. So there‘s much more complex stuff on the horizon already, and we have no proper strategies for dealing with it.

Slide 102

Slide 102 text

That sounds complicated And it is. But there‘s a second point to this escalation in complexity: Offline First isn‘t just going to be a nice-to-have feature for commuters. When you‘ve got web apps that rival native apps in functionality, they really have to be offline-capable to be competitive. In many cases, it‘s going to be a necessity. But there‘s more to offline first that bad networks and competing with native apps: there are a lot of advantages and opportunities besides that:

Slide 103

Slide 103 text

Offline-First Advantages So let‘s talk about those.

Slide 104

Slide 104 text

• Performance OFFLINE-FIRST ADVANTAGES First: Performance. 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). Put your app in here. Put your data in here.

Slide 105

Slide 105 text

• Performance ZERO LATENCY OFFLINE-FIRST ADVANTAGES That's zero latency for me. This is the way to the snappiest experience. The data may be old, but at least it‘s there. And in many cases, time isn‘t doesn‘t even invalidate the data, so there‘s still a benefit to having it.

Slide 106

Slide 106 text

• 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 very moment didn‘t notice. Turns out: 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.

Slide 107

Slide 107 text

• 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.

Slide 108

Slide 108 text

• 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. Forget save buttons altogether. There‘s a lot to be gained from an offline-first architecture that‘s not completely obvious at first glance. And you can start asking yourself new, exciting questions:

Slide 109

Slide 109 text

Do you need your users‘ data? 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.

Slide 110

Slide 110 text

The web platform is amazing And this is just the start. Image manipulation, maturing web audio APIs, and there‘s a lot more to come. At JSConf EU this year, there was a lot about ServiceWorker, client side storage and web crypto: all just coming in to existence, but wildly promising. By this time next year, we‘ll have these tools. We‘ll build apps that encrypt user data before it gets backed up to the server, and there‘ll be new business opportunities and markets for that. We‘ll build apps that use service worker to deliver fantastic offline experiences. And offline first will be the underlying paradigm for many of them.

Slide 111

Slide 111 text

Any application that can be written in JavaScript, will eventually be written in JavaScript. —Jeff Atwood „Atwood‘s Law“ And if it‘s in the browser it‘s going to be used in a mobile context, and it‘s going to be offline at some point. And it‘s not just about increased mobility any more:

Slide 112

Slide 112 text

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 The web is 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. Your apps have to work regardless of the circumstances. Source: http://tomdale.net/2013/09/progressive-enhancement-is-dead/ So. Let‘s recap.

Slide 113

Slide 113 text

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? We could just do what we‘ve always done.“ Well, let‘s start with networks:

Slide 114

Slide 114 text

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.

Slide 115

Slide 115 text

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. I live in the capital of one of the richest, 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 traveling anywhere. My provider wants to charge me 80 cent per MB while I‘m here. So I‘m offline. And yes, that will probably change in the coming years thanks to EU regulations, but…

Slide 116

Slide 116 text

Don‘t just wait it out and hope it will solve itself Because the networks aren‘t the only thing. 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:

Slide 117

Slide 117 text

As I said, the web platform is amazing. But you‘ll increasingly be competing with native capabilities. And that means working offline, too. Plus, with offline first, your apps benefit from being…

Slide 118

Slide 118 text

• Performance • Robustness • Better experiences OFFLINE-FIRST ADVANTAGES faster, more robust, and more trustworthy. And while you can optimistically hope for more cell towers, you can‘t really argue with that list, in my opinion. So. In closing:

Slide 119

Slide 119 text

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.

Slide 120

Slide 120 text

We can and should do better At the same time…

Slide 121

Slide 121 text

It‘s not magic, it has a spectrum of usefulness Offline First won‘t make everything wonderful for everyone, nor is it an all-or- nothing solution: it starts with not forgetting data, and ends with full sync and using the user data in the browser as the definitive copy. And there‘s a lot you can do in between that, too. But you‘ve seen the opportunities you already have right now. But…

Slide 122

Slide 122 text

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

Slide 123

Slide 123 text

There are still many technical challenges With Hoodie, we have a solution for some data scenarios, but it may not be what you need. To be honest, what you need may not even exist. People want weird stuff. But as time passes, more people will find new and different ways of solving the problem for different scenarios. And one of them might be you!

Slide 124

Slide 124 text

There are still many technical challenges But it basically works, right now. I just finished a prototype web app that works completely offline, it has offline maps, and it can even take photos while offline and store them until you‘re back online. It runs well on my wonky 2 year old Samsung android phone. It‘s only going to get easier, faster and more stable from here on out. But we need to worry about more than just tech:

Slide 125

Slide 125 text

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. And finally:

Slide 126

Slide 126 text

We need more awareness that this is a thing People need to get used to their browsers working while offline. Like Email works when offline. Nobody thinks about that anymore. But it‘s also awareness among developers: 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.

Slide 127

Slide 127 text

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.

Slide 128

Slide 128 text

Please join in! And also:

Slide 129

Slide 129 text

Don‘t panic, use Hoodie And come talk to me if you want to know more about hoodie or offline first. I‘ve also got really sweet hoodie stickers :)

Slide 130

Slide 130 text

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