I recently came across a post discussing how offline first, even before mobile first. The idea is that you don’t know if a resource can be reached until you request to reach it. You need a plan for when you can’t.
Surrounding this is the idea of low, spotty, or no connectivity. Low connectivity is often described as something that happens in a developing country or rural area. However, it’s quite a common occurrence in developed, urban, well-connected areas. Ask anyone on a subway, airplane, or hotel. When I read this article and the supporting commentary around it, it got me thinking a couple things:
- Yes! Definitely we need to figure this out.
- How do we describe low connectivity situations without adding in judgement about those situations?
As I suggest above, low connectivity is often associated with poor, rural, developing areas. As a result, it can be unintentionally pejorative. Instead, it should be viewed as a common occurrence regardless of where you are. First we need to stop assuming everyone has reliable, high-speed connections at all times. That’s the basic premise of offline first. Secondly, I wonder if we need a name that doesn’t assign pejorative associations and relegate a common situation to something that happens only to “others”.
- “low connectivity situations”
- “connection-scarce situations”
- “variable-connection environments”
- “slow or variable connection environments”
- offline … slowline … variline
I think the name needs to capture impermanence of the connection, regardless of location. You can experience poor connections in Africa, rural America, or a hotel/home in San Francisco. There’s no guarantee that the connection will be stable regardless of your location. Slow connections can befall even the fastest connections from time to time. Similarly, all connections can be unreliable or impermanent. What is a fast network normally (say Verizon LTE in a big city) can become entirely useless when enough people are on the network (say at a sporting event).
The state of your connection can change during use. Once you’re online, the speed and availability of the connection can (and often will) vary, particularly at the lower end of the online scale. By nature, this case is unstable – slow requests, timeouts, etc. It’s important to recognize that speed and availability are different. You can have a slow connection that is always on or a fast one that comes and goes.
Many apps assume internet access and fail when it’s not present. I use transit apps a lot when I’m traveling. One thing I’ve seen become more prevalent is that all parts of the app require an internet connection, and the apps fails to load anything (even your last state) when the connection is gone. For instance, if your app offers a network map, why cannot this be included as part of the app package instead of downloaded upon request? It could become out of date, but that timeframe is usually lengthy. Additionally, you could check if a new map is available, and, if so, download it to replace the one you have in your app. This way, the user always has some information available. For information that doesn’t change frequent (like less than once a year in the case of transit maps), there’s no reason these can’t reside in the app.
Another example relates to something that is more temporal. While online you set up a trip in the app or on the site. That info should be available even if you don’t have an internet connection or if you go into a low signal area like a tunnel. Most certainly the app should not go dead, particularly if you have the app open. I’ve seen plenty of apps that go dead or try to reload the page when it’s reopened. Webpages don’t do this by default * you have to make them do it * and apps could learn a lot from this behavior. This is particularly relevant as you create ‘web apps’ like Forecast, which behave like apps, but load themselves each time you open them. Is there no cached version that could show up if you don’t have a connection? I might not need the exact temperature at the moment, but I could easily use the forecast.
I look forward to building and using apps that take consider offline first and build in ways to hand cases where connections are absent or flaky. We need more resilience in the things we build because we have no clue what’s going to happen to our connection to the network while we’re using your site/app.