With the apparent ubiquity of internet connection, more applications not only support online functionality, but require it. When perform an update of an application a month ago, I decided to keep an instance of the previous application in place. The new application, though it retained the old functionality in some sense, moved that functionality to a web service. As a frequent traveler, I’m no stranger to finding myself withing an internet connection. Whether it is on a plane with no or failed Internet, in some building that acts as a faraday cage, or on an Internet connection that blocks access to services that are not white-listed, I sometimes am in situations where there is no open data pathway between my computer and a necessary service. Those these scenarios might sound specific to me, there’s another scenario that may be more generally familiar to people. Many people have experienced impacts from Azure or AWS services going offline.

I understand there are some services for which there is no failure mode for being offline, such as an application used to order food or a ride which require establishing communication or coordination of parties, or a service that can’t be implemented locally due to licensing or computational restrictions. But there are some really bad examples of applications that don’t work offline. About any game published by “Netflix” is a great example. Connect to a network that blocks access to Netflix or lose connection, then you cannot play solitaire. As I write this, I just got done making a stub implementation of a service just so that I could run a developer tool offline.

One of the earliest encounters I remember for failed connection assumptions was when Microsoft was announcing the Xbox One before release as an always-online console that had no need for an optical drive. That announcement wasn’t welcomed. There were groups that didn’t welcome that for varied reasons. Some were soldiers, who knew this translated into just not being about to use the Xbox One in certain locations where their connections were limited for security reasons. Microsoft also figured that people didn’t need large storage. If the drive got full, the console could just erase a game and download it again when the user wanted to play. Of course, this assumed that the user could have establish a connection of sufficient bandwidth. It also overlooked that not everyone has unlimited internet connections. I’m in a market for which there are 2 Internet providers (AT&T and Xfinity/Comcast) that have monthly data quotas. Going over the quotas results in overage fees. There was a game for which I had to pause the download and wait a few days to finish because the download of that one game alone would use over a half of the transfer bytes that I was allowed in a month. While outcries against it were heard, I think they primarily only delayed the transition and did not prevent it.
When online applications were becoming more common, there was consideration given to offline modes. Microsoft even had a publication called “Smart Clients::Patterns and Practices” that had design patterns for making applications that were resilient to unstable and failed connections. Though this publication contained older wisdom, I don’t think that it is completely outdated. In the book, , connections are treated as less than 100% reliable. Applications were treated as “occasionally connected,” working from cached data and queuing request when a service isn’t available, sending information to a service and getting responses when they are available. Microsoft Outlook was one of the examples of an applications that was made with this philosophy.

In making applications for client, connection failure modes are tested. The most basic of which is simply turning off the Internet connection and seeing whether the application is able to maintain some subset of its functionality. For example, a digital signage application that shows performance schedules has those schedules stored locally, updating its local copy with information from a CMS on some interval. If the connection to the CMS fails, it still has a local copy of the schedule to present. When a connection fails, reservation functionality might be replaced with a screen directing someone to the location of a ticketing booth or a phone number to get more information. The application doesn’t become completely non-functional all-together. Functionality degrades with the loss of a connection, but it doesn’t flat line.

Whether it is a game, a utility, or something else, I wish that some bit of offline functionality would be retained. I fear this will not happen. Between modern trends and the availability of computer RAM, solid state storage, and GPUs becoming more constrained as the needs of data centers and AI entities consume them, access to equipment is progressing in the direction of being scarce with laptops taking on more features one would expect from a netbook. Functionality being hosted in the cloud and streamed to a user has become one of the solutions for the lack of access to hardware for affordable prices.

I don’t imagine that this will change, but I wish some consideration were given to to keeping an application at least partially functional when a connection cannot be established.

Mastodon: @j2inet@masto.ai
Instagram: @j2inet
Facebook: @j2inet
YouTube: @j2inet
Telegram: j2inet
Bluesky: @j2i.net