One of the main differences between mobile applications and websites is that you can use the mobile app even if you’re offline, but you have to be online to use a website.
Right?
This is one of the paradigm shifts that Ember (and other front-end frameworks, notably React) is starting to address. Ember’s “Offline-First” approach stops treating offline as an error mode, and instead assumes the user may go offline at any time with minimal disruption to their interaction with the site.
When Are Your Users Offline?
Users aren’t always online! We know this, but most websites and web applications are still incapable of supporting a user who’s lost their connection.
If you (or your users) live in a region without a robust Internet infrastructure, you already know this. But even in places like our home base of Portland, Oregon, in the "Silicon Forest," there are plenty of situations where we lose Internet access.
Times users might need offline mode include: * In planes, trains, buses, and automobiles (where wifi may be unavailable or expensive) * In elevators or other building deadzones * During local network outages * Locations with an available but insecure network * Any time a user decides to go offline to avoid distraction, but still wants to use a specific application
And of course, anyone creating an application with users in regions that don’t have reliable Internet needs to consider the possibility that users will be offline for hours or days at a time.
What Do Your Users Need When Offline?
It’s time to consider offline functionality when building any website. Even if users lose connection:
Users shouldn’t be denied access to data they’ve already viewed.
- When several Argonistas went to EmberConf this year, almost a thousand people tried to use the convention center's wifi simultaneously to access the schedule on the conference website. Fortunately, the schedule had been created using the Offline First philosophy. Once a user accessed the schedule once on a device, it was available for the rest of the conference regardless of connectivity.
- Imagine looking up an address for a destination in a rural area, and then losing connection before you arrive. You still need the address!
Users shouldn’t have to repeat actions.
- Allow users to compose messages or forum posts while offline, and queue them up to send when connectivity is restored.
- Allow users to fill out a form and submit it later, instead of having to start all over from scratch when the connection is restored.
Users should be informed of the data and connectivity state.
- Notify the user whether a transaction completed before losing connection.
- Notify the user what their options are for a transaction if they lose connection.
Bonus Features
Beyond simply making content available when users are offline, Ember is also moving towards providing more advanced features for offline users. One of these is background synchronization, which allows an application to complete uploads, downloads, and other processes without requiring the user to remain on the original page where they initiated the process.
A little earlier, we recommended providing clear messages when a transaction fails to complete because of losing connection. But what if losing the connection didn’t matter? What if the form submission could be queued up in the background to be submitted to the server once connectivity was restored?
This is what background synchronization allows.
The good news is that background synchronization begins to change the landscape of web applications by allowing websites to behave more like desktop applications. The bad news is that right now there’s only partial browser support for the tools that allow background synchronization. That means background synchronization is going to be a “bonus feature” instead of a core feature for a while to come.
Another bonus feature is enabling push notifications to the browser. You may have seen these in action for Facebook, which uses the React framework and is able to push notifications that feel more like they belong to a desktop or mobile application, even though they’re being pushed to the browser. Push notifications are an important piece of the puzzle when making websites behave like native mobile applications, but as with background synchronization, the tools that enable them are still a work in progress.
Make It Happen
How are these wonders accomplished? And what are these tools we’ve been talking about that allow magical new features like background synchronization and push notifications? Let’s explore that at a high level.
Browser vs. Server Databases
Ember is able to work with a database (PouchDB) that lives in the browser, so that the application can store information on the client side when the user is offline. This means a user could navigate a site and even make changes (adding items to a shopping cart, for example, or filling out a form) without an Internet connection.
Ember has a framework adapter that provides tools for synchronizing a CouchDB database on the server with the PouchDB database in the browser. This allows the user to continue to interact with the application while offline, and then either manually trigger synchronization or have the application synchronize automatically in the background (depending on the tools we’re going to talk about in the next section).
Caching
There are two Ember tools for caching page data when a site is offline.
The older, more established one is the Application Cache API, or AppCache, which is the first API to facilitate offline experiences. (AppCache can be used with Ember aided by Broccoli Manifest.) AppCache has the widest browser adoption for tools of its kind, supporting most browsers except Internet Explorer 8 and 9, but the Ember community expects the newer Service Workers API to replace AppCache over the coming years.
The Service Worker API requires a secure HTTPS connection and offers features AppCache doesn’t have (e.g. push notifications, background synchronization, and geofencing), but currently doesn’t support Internet Explorer or Safari, which severely limits its application. (Service Worker can be used with Ember aided by Broccoli ServiceWorker.)
As of mid-2016, the generally accepted best practice among Ember developers is to implement both solutions, favoring Service Workers in contexts where it works and falling back to AppCache for the rest. Over time, as Service Workers gains coverage and AppCache shrinks, applications should be able to shift entirely to Service Workers.
Takeaways
If you’re building a new web application or considering retrofitting an existing one, have you thought about your users’ access to Internet and their needs around connectivity?
Think about your users and their potential issues with connectivity. Here are some questions to ask:
- Who are you developing for? Who’s relying on your services?
- Is it possible your users will exhaust their data cycle before the end of a billing cycle?
- Might your users have a limited data plan to begin with?
- Do your users lack regular access to wifi?
- Does your website provide information about critical services?
- Are your users taking a class or accessing educational content?
- How can your application provide value when the user is offline?
Tags: