Building Offline First applications with Backbone

Video:
https://www.youtube.com/watch?v=Zb01eNS6-no&list=PLlgxAbM67lYIGw8DnANC7VgREbzJRQged&index=5

For more background information on Offline First, make sure to watch https://fronteers.nl/congres/2014/sessions/alex-feyerke-offline-first-faster-more-fun-and-more-robust-web-apps

The example Backbone app with a REST backend is here:
https://github.com/gr2m/backbone-addressbook-example

The Hoodie-fied Offline First version is here:
https://github.com/gr2m/BaBoCoCo

If you have any questions, please don't hesitate to reach out <3

Transcript

1. Offline First Applications with Backbone Gregor Martynus @gr2m BackboneConf 2014, Boston Good Afternoon! ! ! This is „Building Offline 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 - Offline First.key - 15 Dec 2014
2. 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 offline capable by default, which is why we‘re so interested in this whole topic. ! ! Source: http://hood.ie BackboneConf - Offline First.key - 15 Dec 2014
3. 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
4. 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 - Offline First.key - 15 Dec 2014
5. 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 - Offline First.key - 15 Dec 2014
6. $"hoodie"new"myapp"&&"cd"myapp" myapp$"hoodie"install"backbone" #"paste"static"app"assets"into"www/" myapp$"hoodie"start Recap <script"src="_api/_files/hoodie.js"></script>" <script>hoodie"="new"Hoodie()</script> 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 - Offline First.key - 15 Dec 2014
7. 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 notification to inform the user when there is an update BackboneConf - Offline First.key - 15 Dec 2014
8. 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 benefits. BackboneConf - Offline First.key - 15 Dec 2014
9. Offline First eats CDNs for breakfast. ! Nothing beats zero latency. It’s the final 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 - Offline First.key - 15 Dec 2014
10. Offline First skyrocks conversion rates. ! Sign up later™
 (if you want) Another less obvious benefit: 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 - Offline First.key - 15 Dec 2014
11. 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 - Offline First.key - 15 Dec 2014
12. 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 - Offline First.key - 15 Dec 2014
13. 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
14. 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 definition -no user account management ! Sky’s the limit. Hoodie can be endlessly extended for all imaginable functionalities using plugins. BackboneConf - Offline First.key - 15 Dec 2014
15. Offline APIs Hoodie style. So, how does all this work? BackboneConf - Offline First.key - 15 Dec 2014
16. 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 - Offline First.key - 15 Dec 2014
17. 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 offline? BackboneConf - Offline First.key - 15 Dec 2014
18. 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 - Offline First.key - 15 Dec 2014
19. 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
20. Offline First Architecture Let’s see how the magic works behind the API. BackboneConf - Offline First.key - 15 Dec 2014
21. WHAT NEEDS TO BE OFFLINE? An App's offline capability is guaranteed through two separate aspects as I’ve shown in the demo! BackboneConf - Offline First.key - 15 Dec 2014
22. 1. The app and its assets WHAT NEEDS TO BE OFFLINE? - the app application logic and its assets must be available offline. 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 - Offline First.key - 15 Dec 2014
23. 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 - Offline First.key - 15 Dec 2014
24. Hoodie Sync Here‘s how Hoodie does offline, and, in fact, everything. BackboneConf - Offline First.key - 15 Dec 2014
25. FRONTEND BACKEND Hoodie Sync BackboneConf - Offline First.key - 15 Dec 2014
26. FRONTEND App BACKEND Hoodie Sync BackboneConf - Offline First.key - 15 Dec 2014
27. 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 - Offline First.key - 15 Dec 2014
28. 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 profit from not doing so.! ! But let‘s assume you do: BackboneConf - Offline First.key - 15 Dec 2014
29. 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 - Offline First.key - 15 Dec 2014
30. 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 - Offline First.key - 15 Dec 2014
31. 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 - Offline First.key - 15 Dec 2014
32. 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
33. FRONTEND App hoodie.store localstorage Sync Plugins (node.js) CouchDB REST BACKEND Hoodie Sync 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. You don‘t want to be implementing this yourself, there‘s just so much to get wrong. BackboneConf - Offline First.key - 15 Dec 2014
34. We trust the CouchDB for this. It‘s a database that replicates, which is exactly what we want for syncing. BackboneConf - Offline First.key - 15 Dec 2014
35. 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 - Offline First.key - 15 Dec 2014
36. Remotestorage has a one-backend-per user approach that also works offline and syncs. BackboneConf - Offline First.key - 15 Dec 2014
37. 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
38. 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/ BackboneConf - Offline First.key - 15 Dec 2014
39. 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 - Offline First.key - 15 Dec 2014
40. 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 - Offline First.key - 15 Dec 2014
41. I was on the AfricaHackTrip through Kenya, Uganda, Rwanda and Tanzania last year, where I met a lot of people with interesting offline problems BackboneConf - Offline First.key - 15 Dec 2014
42. I wrote a blog post that got quite a lot of traction… BackboneConf - Offline First.key - 15 Dec 2014
43. …some great responses on twitter and a surprisingly friendly hackernews discussion BackboneConf - Offline First.key - 15 Dec 2014
44. Then I wrote another one… BackboneConf - Offline First.key - 15 Dec 2014
45. 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
46. …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
47. 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: BackboneConf - Offline First.key - 15 Dec 2014
48. 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
49. 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 - Offline First.key - 15 Dec 2014
50. 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 - Offline First.key - 15 Dec 2014
51. 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 - Offline First.key - 15 Dec 2014
52. 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 - Offline First.key - 15 Dec 2014
53. More trustworthy and reliable apps OFFLINE FIRST OPPORTUNITY BackboneConf - Offline First.key - 15 Dec 2014
54. 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 - Offline First.key - 15 Dec 2014
55. 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 - Offline First.key - 15 Dec 2014
56. 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: BackboneConf - Offline First.key - 15 Dec 2014
57. More useful and more usable apps OFFLINE FIRST OPPORTUNITY This is directly linked to the next one: BackboneConf - Offline First.key - 15 Dec 2014
58. My data isn‘t with me OFFLINE PROBLEMS BackboneConf - Offline First.key - 15 Dec 2014
59. 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 benefit is: BackboneConf - Offline First.key - 15 Dec 2014
60. Always-accessible personal data OFFLINE FIRST OPPORTUNITY Super fast, always available and simply reliable. BackboneConf - Offline First.key - 15 Dec 2014
61. Apps require advance planning 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: BackboneConf - Offline First.key - 15 Dec 2014
62. 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. BackboneConf - Offline First.key - 15 Dec 2014
63. 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 - Offline First.key - 15 Dec 2014
64. 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 - Offline First.key - 15 Dec 2014
65. 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 - Offline First.key - 15 Dec 2014
66. 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
67. 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 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? BackboneConf - Offline First.key - 15 Dec 2014
68. Smart apps that pre-empt user needs OFFLINE FIRST OPPORTUNITY Which brings us to: BackboneConf - Offline First.key - 15 Dec 2014
69. 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 - Offline First.key - 15 Dec 2014
70. save vs. sync How do we communicate the states data can be in? Stored locally, scheduled for sync, synced, possibly out of date, conflicting… BackboneConf - Offline First.key - 15 Dec 2014
71. We all know this is usually a lie. It means lots of things, but in the end it only means: BackboneConf - Offline First.key - 15 Dec 2014
72. 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 BackboneConf - Offline First.key - 15 Dec 2014
73. 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 - Offline First.key - 15 Dec 2014
74. 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 - Offline First.key - 15 Dec 2014
75. 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 - Offline First.key - 15 Dec 2014
76. 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 - Offline First.key - 15 Dec 2014
77. 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 - Offline First.key - 15 Dec 2014
78. 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. BackboneConf - Offline First.key - 15 Dec 2014
79. 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
80. 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. BackboneConf - Offline First.key - 15 Dec 2014
81. 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 - Offline First.key - 15 Dec 2014
82. 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 offline, though. BackboneConf - Offline First.key - 15 Dec 2014
83. 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 native apps. ! ! So there‘s much more complex stuff on the horizon already, and we have no proper strategies for dealing with it. ! ! BackboneConf - Offline First.key - 15 Dec 2014
84. 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
85. • 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 - Offline First.key - 15 Dec 2014
86. 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 - Offline First.key - 15 Dec 2014
87. We can and should do better BackboneConf - Offline First.key - 15 Dec 2014
88. It‘s early days, and there‘s a lot to talk and think about BackboneConf - Offline First.key - 15 Dec 2014
89. 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
90. 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
91. 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 - Offline First.key - 15 Dec 2014
92. 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
93. Please join in! And also: BackboneConf - Offline First.key - 15 Dec 2014
94. 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
95. Thanks! Please come see me for info and stickers! @gr2m ! checkout http://hood.ie BackboneConf - Offline First.key - 15 Dec 2014
96. BackboneConf - Offline First.key - 15 Dec 2014
97. BackboneConf - Offline First.key - 15 Dec 2014
98. BackboneConf - Offline First.key - 15 Dec 2014
99. BackboneConf - Offline First.key - 15 Dec 2014