Building Offline First applications with Backbone

Slide 1

Slide 1 text

Offline First Applications with Backbone Gregor Martynus @gr2m BackboneConf 2014, Boston Good Afternoon! ! ! This is „Building Ofﬂine First Applications with Backbone “, my name is Gregor, I‘m a web developer from Zurich, and as such I‘m very grateful to Claire, Adam, Bocoup and everyone else who made this event possible and invited me all the way over here BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 2

Slide 2 text

I‘m part of the community that makes Hoodie: an open-source web server that lets you quickly build data-driven apps with frontend technologies only. It does that by providing a fronted API, so you never have to talk to the server directly. Think jQuery, but not for the DOM, but for your apps’ backend. And Hoodie apps are ofﬂine capable by default, which is why we‘re so interested in this whole topic. ! ! Source: http://hood.ie BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 3

Slide 3 text

Demo first™ Let’s build an Offline First app with Backbone and Hoodie We gave lots of talks in the past about Offline First, and usually we talk a lot about where Offline First comes from, and why it is important. Some of these talks are online, I really, really recommend to watch Alex Feyerke from the Hoodie community on this matter. If you ever need to persuade clients or other decision makers, you’ll find all the arguments there.! ! Today, I’d like not to push you because it’s the right thing, but actually make you excited about it, because there really is no reason not to. It’s a lot of fun, and full of new opportunities and interesting challenges.! ! Let’s dive right in. BackboneConf - Offline First.key - 15 Dec 2014

Slide 4

Slide 4 text

This is a very simple Backbone Application which is using a RESTful API as its backend, and a hardcoded user authentication, just for demo purpose. ! As you can see, every change on a contacts triggers a request to the server. I can sign in, make changes, create a new contact, sign out, sign back in, and my changes are still there. ! It only uses on Backbone Collection and one Backbone Model, and a view Views. The code is on Github, I’ll link it in the presentation notes. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 5

Slide 5 text

This is how you create a Hoodie app, once you installed the command line interface. You do “hoodie install yourappname”, which usually takes a while as the required packages get downloaded from the internet. I made this screencast to make sure it works … offline :) ! Once the app has been created, I cd into the new folder, and install the backbone plugin. ! Once done, copy & paste app assets, adjust Model / Collection and index.html BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 6

Slide 6 text

$"hoodie"new"myapp"&&"cd"myapp" myapp$"hoodie"install"backbone" #"paste"static"app"assets"into"www/" myapp$"hoodie"start Recap " hoodie"="new"Hoodie() Contact"="hoodie.backbone.Model.extend({"…"})" Contacts"="hoodie.backbone.Collection.extend({"" ""model:"Contact" }) To recap what I just did ! 1. I’ve created a new Hoodie app and pasted the app assets into its www/ folder 2. I’ve loaded the hoodie.js API 3. I’ve used the Hoodie Backbone Model & Collection classes BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 7

Slide 7 text

myapp$"hoodie"install"appcache Recap hoodie.appCache.start() //"UI"sugar" hoodie.appCache.on('updateready',"function()"{" ""$(‘#updateQnotification').fadeIn()" }) To recap,! ! 1. I installed the Hoodie appcache plugin! 2. I’ve started the automatic checks for updates! 3. I added a notiﬁcation to inform the user when there is an update BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 8

Slide 8 text

Congratulation! Offline First in 2min. Congratulations! It barely took me two minutes to take an example Backbone application with a traditional REST API Backend and make it Offline First. And not only was that super simply, it already brings some really cool beneﬁts. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 9

Slide 9 text

Offline First eats CDNs for breakfast. ! Nothing beats zero latency. It’s the ﬁnal frontier. First of all, it’s super fast! We put so much energy into CDN networks trying to put our assets as close to the user as possible. But the closest thing is and always will be the device that I’m using BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 10

Slide 10 text

Offline First skyrocks conversion rates. ! Sign up later™  (if you want) Another less obvious beneﬁt: there is no sign in any more. As user you can jump right into the app, and only sign up if you want to access your data from different devices. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 11

Slide 11 text

Offline First is The Crazy Nastyass Honey Badger. ! No connection? Server down? The Honey Badger doesn’t care. But above all, the experience ist just really good. No matter the connection between my device and the server, it’s always super responsive, there is no lacking, no freezing UIs, no loaders, nothing. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 12

Slide 12 text

Offline First works everywhere. ! Internet connection becomes a progressive enhancement. The app works always and everywhere, not only in trains, plains and foreign countries without a data plan, in case of server issues. An internet connection becomes feature that get’s used when available, but the experience does not get affected when not. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 13

Slide 13 text

Offline First is a driver for the decentralised web. ! Think private networks, but apps that work everywhere. This is not something that comes to our mind when we think about Offline Architectures, but it’s the aspect the has the biggest potential for a positive impact. ! There is a conflict between the user’s expectation to have all data available everywhere, and the security and privacy concern of centralised, corporate owned data stores. ! Offline First can resolve that conflict. The apps backend could be in a secure network where changes get synched. But when leaving it, the app would still work. ! But this will only work if … BackboneConf - Offline First.key - 15 Dec 2014

Slide 14

Slide 14 text

Hoodie is so much fun! ! Think of all the things that you don’t have to do. it is easy and enjoyable to work with. This is the reason why we put so much effort to hide away all complexities behind Hoodie’s APIs. Just think about all the things that we did not do. ! -not a single line of backend code -no database setup & schema deﬁnition -no user account management ! Sky’s the limit. Hoodie can be endlessly extended for all imaginable functionalities using plugins. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 15

Slide 15 text

Offline APIs Hoodie style. So, how does all this work? BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 16

Slide 16 text

Contact"="hoodie.backbone.Model.extend({"…"})" Contacts"="hoodie.backbone.Collection.extend({"" ""model:"Contact" }) Offline First Backbone App with Hoodie Backend contacts.create(properties) contacts.on('add"change"remove"reset',"view.render) hoodie.account.signUp(username,"password) hoodie.account.on('signout',"goToHome) There is nothing special to it. You can use Backbone models & collections as you’d do with traditional applications. Hoodie and its plugins provide additional APIs, for example for user authentication, which is being used in the example app. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 17

Slide 17 text

Contact"="hoodie.backbone.Model.extend({"…"})" Contacts"="hoodie.backbone.Collection.extend({"" ""model:"Contact" }) Offline First Backbone App with Hoodie Backend contacts.create(properties) contacts.on('add"change"remove"reset',"view.render) hoodie.account.signUp(username,"password) hoodie.account.on('signout',"goToHome) Wait, where is the offline? 0_o When you look at this, you probably wonder: where is the ofﬂine? BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 18

Slide 18 text

Offline First Backbone App with Hoodie Backend hoodie.store('contact').add(properties) hoodie.store.on('change"clear',"view.render) hoodie.account.signUp(username,"password) hoodie.account.on('signout',"goToHome) Wait, where is the offline? 0_o Even if we look at the API that the Hoodie Backbone plugin uses internally, there is no sign of anything that would tell that data gets stored locally and synced as needed. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 19

Slide 19 text

Offline First Backbone App with Hoodie Backend hoodie.account.signUp(username,"password) hoodie.account.on('signout',"goToHome) That’s it. hoodie.store('contact').add(properties) hoodie.store.on('change"clear',"view.render) And that’s exactly it, there really is nothing new to it. You can just go and start building offline apps today. There are additional APIs of course, for example to determine if the user is currently online or not, if there are local changes or to handle conflicts. But these are only to improve the experience of your app.! ! Even if you don’t have offline compatibility as a requirement. BackboneConf - Offline First.key - 15 Dec 2014

Slide 20

Slide 20 text

Offline First Architecture Let’s see how the magic works behind the API. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 21

Slide 21 text

WHAT NEEDS TO BE OFFLINE? An App's ofﬂine capability is guaranteed through two separate aspects as I’ve shown in the demo! BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 22

Slide 22 text

1. The app and its assets WHAT NEEDS TO BE OFFLINE? - the app application logic and its assets must be available ofﬂine. In the example app I used appCache. ServiceWorker is an alternative that will be available soon. Other ways would be native wrappers like Phonegap or node-webkit. In a native app, this is a given. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 23

Slide 23 text

1. The app and its assets 2. 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, Hoodie.! ! Let‘s see how Hoodie handles this. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 24

Slide 24 text

Hoodie Sync Here‘s how Hoodie does ofﬂine, and, in fact, everything. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 25

Slide 25 text

FRONTEND BACKEND Hoodie Sync BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 26

Slide 26 text

FRONTEND App BACKEND Hoodie Sync BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 27

Slide 27 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. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 28

Slide 28 text

FRONTEND App hoodie.store localstorage BACKEND Hoodie Sync This, by itself, is enough for an app. Do you even need to store anything on the server? You might not. Your business model might even proﬁt from not doing so.! ! But let‘s assume you do: BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 29

Slide 29 text

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. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 30

Slide 30 text

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.! ! You can think of it like ! like passive-agressive roomates that only communicate through post-its. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 31

Slide 31 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 tasks, and sync whenever it can, and users can keep working without interruption. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 32

Slide 32 text

FRONTEND App hoodie.store localstorage BACKEND Hoodie Sync Sync I don‘t care! Out for lunch, BRB This is what makes Offline First apps 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, and everywhere, really: robust and fault-tolerant.! ! Anyway, the point was:! BackboneConf - Offline First.key - 15 Dec 2014

Slide 33

Slide 33 text

FRONTEND App hoodie.store localstorage Sync Plugins (node.js) CouchDB REST BACKEND Hoodie Sync If you want true ofﬂine 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. You don‘t want to be implementing this yourself, there‘s just so much to get wrong. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 34

Slide 34 text

We trust the CouchDB for this. It‘s a database that replicates, which is exactly what we want for syncing. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 35

Slide 35 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. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 36

Slide 36 text

Remotestorage has a one-backend-per user approach that also works ofﬂine and syncs. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 37

Slide 37 text

And there‘s even JSGit! ! ! And other projects claim that they are working on Offline-APIs as well, like Drupal, and I as far as I now Firebase is working on offline support as well, you can ask Clément about that, who’ll give his talk on real-time apps tomorrow.! ! But whatever you do, don‘t do this by yourself. But remember: sync is the keystone of offline first: BackboneConf - Offline First.key - 15 Dec 2014

Slide 38

Slide 38 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/ofﬂine/ BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 39

Slide 39 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? BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 40

Slide 40 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. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 41

Slide 41 text

I was on the AfricaHackTrip through Kenya, Uganda, Rwanda and Tanzania last year, where I met a lot of people with interesting ofﬂine problems BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 42

Slide 42 text

I wrote a blog post that got quite a lot of traction… BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 43

Slide 43 text

…some great responses on twitter and a surprisingly friendly hackernews discussion BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 44

Slide 44 text

Then I wrote another one… BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 45

Slide 45 text

Mozfest OFFLINE FIRST- WORKSHOP We also had an offline-first workshop at Mozfest London, with about 40 participants… BackboneConf - Offline First.key - 15 Dec 2014

Slide 46

Slide 46 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.! ! BackboneConf - Offline First.key - 15 Dec 2014

Slide 47

Slide 47 text

Trust and reliability OFFLINE PROBLEMS The ﬁrst 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: BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 48

Slide 48 text

As a mobile app user, I want to be sure that my data 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 the network provider. ! ! But you can often do a lot better, and offline first is the way to go. But first, let me illustrate the problem: BackboneConf - Offline First.key - 15 Dec 2014

Slide 49

Slide 49 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 BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 50

Slide 50 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. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 51

Slide 51 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: BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 52

Slide 52 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. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 53

Slide 53 text

More trustworthy and reliable apps OFFLINE FIRST OPPORTUNITY BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 54

Slide 54 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. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 55

Slide 55 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 BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 56

Slide 56 text

If you‘re only adding data yourself, why doesn‘t this just always work, online or ofﬂine? 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: BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 57

Slide 57 text

More useful and more usable apps OFFLINE FIRST OPPORTUNITY This is directly linked to the next one: BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 58

Slide 58 text

My data isn‘t with me OFFLINE PROBLEMS BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 59

Slide 59 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. ! ! 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 beneﬁt is: BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 60

Slide 60 text

Always-accessible personal data OFFLINE FIRST OPPORTUNITY Super fast, always available and simply reliable. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 61

Slide 61 text

Apps require advance planning OFFLINE PROBLEMS One more thing that frequently irked people when we talked to them about their ofﬂine woes: apps not being smart about what data they store locally. In short: BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 62

Slide 62 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 ofﬂine. If we always knew that, a lot of this wouldn‘t be a problem. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 63

Slide 63 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. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 64

Slide 64 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. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 65

Slide 65 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…! ! BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 66

Slide 66 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. BackboneConf - Offline First.key - 15 Dec 2014

Slide 67

Slide 67 text

Smart, offline maps ALSO A BIT SPOOKY 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 ﬂushed 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? BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 68

Slide 68 text

Smart apps that pre-empt user needs OFFLINE FIRST OPPORTUNITY Which brings us to: BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 69

Slide 69 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 BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 70

Slide 70 text

save vs. sync How do we communicate the states data can be in? Stored locally, scheduled for sync, synced, possibly out of date, conﬂicting… BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 71

Slide 71 text

We all know this is usually a lie. It means lots of things, but in the end it only means: BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 72

Slide 72 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 ﬁnd a good language, possibly visual, to do so BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 73

Slide 73 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. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 74

Slide 74 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: BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 75

Slide 75 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: BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 76

Slide 76 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. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 77

Slide 77 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.! ! Here‘s a fairly simple chat example that illustrates some of the things you‘ll have to keep in mind: BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 78

Slide 78 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 ofﬂine. On a train, in a tunnel or something. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 79

Slide 79 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? BackboneConf - Offline First.key - 15 Dec 2014

Slide 80

Slide 80 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 ﬂow according to the time it arrives at. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 81

Slide 81 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. ! BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 82

Slide 82 text

Because the web platform is becoming more an more powerful and capable. Here‘s a sweet 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 ofﬂine, though. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 83

Slide 83 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 ofﬂine, and that‘s a disadvantage in comparison to native apps. ! ! So there‘s much more complex stuff on the horizon already, and we have no proper strategies for dealing with it. ! ! BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 84

Slide 84 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: BackboneConf - Offline First.key - 15 Dec 2014

Slide 85

Slide 85 text

• Performance • Robustness • Better experiences OFFLINE-FIRST ADVANTAGES faster, more robust, and more trustworthy apps. And while you can optimistically hope for more cell towers, you can‘t really argue with that list, in my opinion. ! ! So. In closing:! ! ! BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 86

Slide 86 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. BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 87

Slide 87 text

We can and should do better BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 88

Slide 88 text

It‘s early days, and there‘s a lot to talk and think about BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 89

Slide 89 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. It‘s still early, and more people will find new and different ways of solving the problem for different scenarios. ! ! But it works, right now. For example, for a recent project we’ve built a 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 a 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: BackboneConf - Offline First.key - 15 Dec 2014

Slide 90

Slide 90 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: BackboneConf - Offline First.key - 15 Dec 2014

Slide 91

Slide 91 text

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 BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 92

Slide 92 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. BackboneConf - Offline First.key - 15 Dec 2014

Slide 93

Slide 93 text

Please join in! And also: BackboneConf - Ofﬂine First.key - 15 Dec 2014

Slide 94

Slide 94 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 :) BackboneConf - Offline First.key - 15 Dec 2014

Slide 95

Slide 95 text

Thanks! Please come see me for info and stickers! @gr2m ! checkout http://hood.ie BackboneConf - Ofﬂine First.key - 15 Dec 2014