Why “Offline Mode” should be more than just a line-item in your software’s feature grid

Photo by Aaron Dowd on Unsplash

I live on an island.

Not in the metaphorical or transcendental sense.

I actually live on a fucking island.

Bainbridge Island is a quaint little rock 35 minutes across the water from downtown Seattle. If you’ve never visited Seattle, you should. And if you live in Seattle but have never taken a ferry ride, Jibbers Crabst what are you waiting for?

It’s fantastic. Best commute in the nation.

But it does leave a few things to be desired…

  • You “live and die” by the ferry schedule.
  • Tourist season can be challenging — c’mon, folks, remember that this is a daily commute for many of us, so maybe pause on the selfies and clear the way. Oh, and, you’re in my seat.
  • The coffee is… hot.
  • Most of all, internet connectivity during the crossing is mediocre, at best. Most times, it’s a dead-zone. And no, there’s no wi-fi on the ferries. Used to be, but it was basically a glorified 4G hotspot that never really worked.

And yes, I know that 5G is coming. Hopefully soon.

And yes, always-on-connected-everywhere is the fashionable trend.

And yes, I mostly am on-board with that (boat pun!)…


While I’ve traditionally used my offline time on the boat to catch up on reading, scrub my inbox, or write pithy little posts like these, lately I’ve been experimenting with mind-mapping, decision-frameworks, and flow-focus techniques — and trying out various SW tools that facilitate those techniques.

Most of them (at least the ones that don’t cost $200/year to use) suffer from one key flaw from my perspective: NO. TRUE. OFFLINE. MODE.

Look, I get that always-on-connectivity is the “in” thing right now. But not everyone who wants to use your tool will be online 100% of the time. Some people’s jobs require them to travel to remote locations for extended periods of time, while others may experience only brief periods of 4G signal loss but encounter them twice a day on a ferry across Puget Sound.

Joining Zonar Systems has given me a new perspective on the importance of providing software tools that deliver real value without relying on the not-always-omnipresent Cloud.

Some of the companies we support have to send humans and machines into remote locations, or into areas where a disaster has knocked out power or connectivity. Others have vehicle operators that cross through connectivity dead-zones as part of their regular routes or work-shifts. But all of these companies have safety and legal compliance standards that must be upheld at all times — and “no signal” is no excuse.

The tool you’ve built provides a service. And that service should be accessible to those that need it, in the scenarios they need it in, regardless of the technical limitations. It’s why even cell phones that haven’t been initialized for service and have not been assigned a number can call 911. As long as the cell phone can be powered up and locate a network, it can connect to 911 services.

To quote Microsoft’s Inclusive Design Toolkit:

Mobile technologies can make situational limitations highly relevant to many people today. Mobile puts in focus questions like: Are we forced to adapt to technology, or is technology adapting to us?

So, if you’re going to promote “offline mode” as a legit feature for your Cloud-based productivity tool, then at least make sure it’s providing parity-of-experience to the online state of your tool before rolling it out. Take into account not just the diversity of your user population, but the diverse scenarios in which they may use your tool.

Categorized as UX

Leave a comment

Your email address will not be published.