Why Offline First?
Why Offline First?
You might have heard of Offline First. If you haven’t, the basic idea is that, as creators of software, we should plan for when our users have a bad internet connection. It’s kind of like the the concept of “Mobile First”: design for the most constrained environment — the smallest screen size — which is usually a mobile device. Then relax the constraint bit by bit, build upon the mobile-optimized design, handling larger and larger screen sizes as you go.
With Offline First, the constraint we’re designing around is network connection. First, design the app to work when there is no network connection. Then build up from there, designing the app to handle progressively faster and more reliable connections as they become available, from zero connection to a spotty cell signal to semi-okay coffeeshop wifi to sci-fi fast fiber optic.
Why would want to follow the Offline First pattern?
Gregor Martynus did a fantastic video on the benefits of Offline First. You should watch it — it’s quick, and very good. I took notes as I watched, and thought it might be helpful to share them here.
No sign-up
Users can start using the full feature set of your app immediately. No need to give an email address, come up with a password, or create an account. This reduces a huge barrier to entry: They can just get going right away. Later, once they’ve decided that they like your app, they can create an account. All their data from every previous session is synced. If you care about conversion rates, this is something to look into.
Continuous save
Since the data is stored locally, there is virtually no downside to persisting every keystroke. If the browser crashes mid-sentence, that half sentence will still be there when you reboot.
It still works when the server is down
When the server goes offline for maintenance — or if it’s struck by lightning and bandits — users can continue to use the app. They can’t push their changes to the server, of course, but all the other features of the app continue to work. In many cases, the user may not even know the server is down.
Speed
The idea behind content delivery networks is the closer the assets, the faster they load. Offline First pushes this idea to its endpoint: your app’s assets are stored right on the user’s machine. This means there is zero latency, which translates to a super-fast, super smooth user experience.
Security
Consider an app that runs only on a company’s private intranet. The intranet serves the app, so it doesn’t work once you leave the premises. That solves the security issue, but it means you can only be productive if you’re on-site. What happens when you’re traveling on business for two weeks? What if you need to make a business critical decision on the weekend, and you need to access information that lives in that app?
If the app is designed as Offline First, it can continue to function when you’re outside the private intranet. Since you’re not sending and receiving data, there’s no network risk. Additionally, you can encrypt the data locally. This means that if the server were ever hacked, the hacker would be rewarded with a pile of jibberish.
So you can be on an airplane, sign in, do work, sign out, and everything’s encrypted. When you come back on premises, everything is synced. Bam.
The video!
Again, check out Gregor’s video. It’s really good!
How do you get started?
There’s a wonderful and growing community around Offline First. A good place to start is the Offline First site. There are some great articles that go much more in depth than I did here. Check out the connect page for links to the Slack channel and GitHub. Not only is Offline First a smart design pattern, but it’s a community full of really cool people!
