Offline apps and user intent

The next problem being solved for the web is not having the network: apps that work offline. I think when designing such apps, we should consider user intent, and in particular what a user intends to be available offline.

Web apps that work offline will download themselves into a user’s cache: their assets, their core app code, et cetera (see also: service worker). When the app itself is offlinified, the next choice is: which content should we make available offline? I think we should consider letting our users decide.

My newspaper app lets me download newspapers and requires no further connectivity once the download is completed. As a user, this allows me to download a newspaper to my tablet before I leave home, take a seat in a local train and start reading. Great for commuting. It lets me not worry about the network. In theory, my tablet might have 3G, or could connect to the train’s WiFi system. In reality, that would probably result in me struggling to get any data when the train is in a tunnel, or trying to battle the train WiFi’s registration page. The alternative, downloading the paper on my home WiFi, which I know works, is much better. For this to go smoothly, it is crucial the newspaper app has a ‘download for offline usage’ button.

A music subscription service I use, offers me the ability to have some music available offline. I use this feature a lot. If I need to catch the airport bus, I want to listen to that new album that came out. I know which. If I’m going for a long drive, I might make a playlist to listen to whilst driving in the UK’s beautiful, but not always well-networked country side. I create the playlist at home, and want it to be available on the go. So I think my music app with offline capability should let me choose what to make available offline. Spotify has a toggle that sets playlists to ‘available offline’, but it does not have UI to let a user download specific music (it behaves more or less like a hint). It will decide, based on how much connectivity and storage the device has. This makes sense, as often connectivity and storage are big uncertainties for the developer that builds the app, but it gets in the way of user intent.

Some apps choose to offlinify the last x items (eg a news site), or the content that the user has visited (eg an encyclopedia). The latter is a form of user intent, the former is unrelated to it. Naturally, depending on context, these can be a good strategies, too.

For the news and music player examples, honouring user intent can hugely improve a user’s experience. It may very well be possible to let the app decide what to offlinify when, but maybe your user just wants a particular thing to be offline. Today’s newspaper. Or, for that matter, last Tuesday’s issue, because their grandmother appears in it. This artist’s new album. This episode of that podcast. This A List Apart article.

Technically, it is far from trivial to do for a web app. Without going into too much detail: you don’t know if your user/their browser will have cleared their/its cache, or how much storage they have available.

In summary, I think if our app makes itself available for offline use, we should consider giving our users a choice in which content to make available offline.