Hacker News new | ask | show | jobs
by branksy 4603 days ago
> We can’t keep building apps with the desktop mindset of permanent, fast connectivity...

That's just silly. A lot of apps are rightly useless without normal connectivity, like checking the weather [edit: for current conditions], or sending e-mails, or Facebook, or shopping on Amazon. There's no reason for these to work offline.

I mean, an app is pretty much online-only, or mostly offline (like most games, for example).

I don't see a big middle ground between the two where online apps need to be made to work better offline. And the few which do (which involve syncing data), seem to work fine.

So... I don't get it. What is "Offline first" trying to accomplish in the real world?

9 comments

> A lot of apps are rightly useless without normal connectivity, like checking the weather, or sending e-mails,

Except that thinking leads to really shitty behaviour from apps. Like weather apps that refuse to show you the data cached from the last time they checked, or e-mail apps (I'm looking at you here iOS GMail) that are feeble-to-useless at letting me read offline. Facebook: I should be able to check my events calendar offline, or look again at favourite photos.

The set of apps that consume online data is much, much larger than the set of apps that are usable if and only if they have absolutely live information.

By not thinking offline-first, too many apps behave like they're in the second set.

Responding to you and everyone else using weather as an example:

NO, I don't EVER want cached weather data! In fact, it drives me nuts that when I look up the weather on my iPhone to see what the current temperature is outside, I have no idea if it's accurate or 20 degrees wrong, because it just assumes that cached data from 1am is good enough, until it happens to get a connection again. For people who live in places where the temperature can vary 40 degrees in a day, this is really important.

[Edit: why is this being downvoted? Is it not clear that I'm talking about current weather conditions, as opposed to 3-days-out? And that having my phone present stale data as current data can be harmful? Many people use their weather app for current conditions, not forecasts.]

Your weather app generally is able to show around a week of data in advance, so if I check weather today and am offline tomorrow, it should be able to show me a reasonable approximation.

Also you generally want to see what the weather is in the future, and its always a best guess, if you want an accurate way to know precisely if it is raining right now, look out the window.

And you asked for an explanation of why you are being downvoted, you are obviously trying very hard to make an example of a counter point for something that doesnt make sense '12 hours ago we thought the weather would be X' is unarguably better that 'this application is offline', but you are attempting to argue it. Even if you did find a single counterpoint it doesnt add anything to the conversation, not absolutely everything is going to have an offline use case, but its clear that we could do better providing offline capability (and to be clear, I didnt downvote)

Surely all that takes is a "last updated x hours ago" label and you have the best if both worlds?

Just because the current designs have flaws for your use cases doesn't mean we can never design around them.

You're being downvoted because based on a single, arguably marginal, use case ("I only ever want to know the exact temperature right this very second and everything else is useless to me") you're a claiming that there's no need for anybody to consider the much more important and larger use case of "I need my phone not to instantly become a dumb brick when it loses reception"

I saw elsewhere that you think mobile apps are already doing the right thing here. The reaction to you - and the point of the OP - is that they're not. Proper offline support is often a poor second in application design, if it's considered at all. We should change that.

> "A lot of apps are rightly useless without normal connectivity, like checking the weather, or sending e-mails, or Facebook, or shopping on Amazon."

They aren't fully functional without fast connectivity, but they aren't useless. It is shocking how many ways apps break when offline.

- If I'm offline I should still be able to view the last weather report I got. Many apps simply refuse to work and throw up an unhelpful "you're offline" screen instead.

- If I'm offline I should still be able to type out a reply to emails. In fact, I should be able to queue it for sending, and my device should intelligently take care of it at the next connection opportunity.

- Similarly, if I'm offline I should still be able to view emails that I have seen recently.

There are a lot of ways people can interact with apps while experiencing no/poor connectivity. I believe the essay is simply saying that some basic affordances should be built into your apps - that features which don't strictly require a network connection shouldn't fail in ugly ways when the network is down. It is atrocious how many mobile apps have only one reaction to a loss of connectivity: completely shut off all access to everything.

But... phone apps already do all those things, so I don't get what you're complaining about. My point is, apps already seem to be doing the right things. So what's some kind of new manifesto needed for? What is supposed to be changed?
I just downloaded the first 4 results for 'weather' on my iphone. 2 refused to show any data offline, one showed cached data without saying it was, and one showed a needlessly verbose error about being offline, then showed cached data with an indication of how stale it was.

So no, not all apps are already doing the right thing.

Phone apps might, most web apps do not. Hence this post.
We are trying to get people to talk about offline-first app design for when it makes sense.

Weather is a great example, being offline could communicated as an error, leaving the user with an abysmal experience. Or some older content could be shown with the note that it is likely that the accuracy is off, but if the user just needs a general idea of the weather, that suffices and is not at all an “error” in the networking sense.

We have no common UX/UI language for these things and we’d like to change that. ;)

Good luck. Anecdote: after finding a small scorpion on the bathroom wall in the Honduran jungle, I had a huge compulsion to tear everything apart to make sure there's no nest. The only thing that calmed me down was access to offline, text-only Wikipedia on my Nokia n800. It was 2 a.m., slept like a baby when I found out this species was harmless. To this day, I never travel without it. (Edit: Wikipedia, not the n800 ;)
We got by with weather information that was hours old on the past, shouldn't be a problem now.
I disagree.

Many parts of the world have reasonably accurate weather forecasts for 24-48 hours out -- you'd only need to have five minutes of connectivity at the beginning of the morning; the rest of the day the app should work just fine. And if you're stuck without connectivity for longer, it can show the right part of the 7-day forecast in many locales (albeit with lower certainty). If you need to know the weather _right now_, many phones ship with a barometer sensor, or you can just look out the window.

Sending e-mails was a mostly offline process in most of the 90s; you'd only connect to your dial-up connection to actually send and receive messages to your ISP's SMTP/POP servers.

Facebook already displays old news feed items when you're offline, and with a bit of work, it could decide to cache comments and likes offline when you interact with news feed items. Similarly, it could place photo uploads and status updates in a queue and sync them when the connection does come online.

Amazon predicts items you might want to see based on prior shopping history. While you wouldn't be able to do a search or see real-time pricing/availability information, it could happily show you pictures and product description in a carousel while offline.

If my mobile email client didn't have good offline functionality I'd be looking for another one. Reading and queuing emails to send should generally not require a connection.

Weather is another strange example for you to pick. Yes, the more recent a forecast, the more useful it is. But if I checked the weather this morning, and then want to reference that again in the afternoon (to make a plan for the weekend, for example), that should work without a subsequent connection.

And really, there's no reason I shouldn't be able to check Facebook updates and comment when it's convenient for me. Inherently asynchronous activities like this are well suited to offline scenarios.

Shopping is a better example, but you're 1 for 4 here, in my opinion.

Being able to read, organise and draft reply to emails, being able to see my facebooks profile / contact information, in every app where you need to be online, being able to view history (or precache future data) when offline would always be useful.

I am most certainly not the only person that has had an important page shown on my phone etc and accidently clicked some link and suddenly lost all that information.

Most applications have a very large middle ground between offline and online capability, I think the reason its hard to see is that as developers we are so terrible at doing it well right now

> or sending e-mails

Better mail applications allow you to "send" the mail with no connectivity and then simply hold onto it until there's a network connection. At which point the mail is actually sent out. But for the user it's transparent. He or she hits send and (at some point), the mail goes out. I wish more phone apps did this (looking at you, Twitter).

This actually was my everyday experience back in the nineties with Pine on Debian 2.x

I liked that.

Mobile apps that are really online-only could do a lot better job though. The biggest examples would be to queue and store data to be posted and also to handle larger caches of downloaded info.

If ¥ou look at Instagram, it does not store much in the way of old photos in your feed, your old likes, or even older photos of your own profile. It's probably done in to part to simplify the experience, so you know the comments/like-count on photos are up-to-date, and it also keeps the app's footprint smaller. The percentage of time you are not connected and want to use Instagram is small, but it would be nice as disk space increases, to have more functionality available.

Apple's shared photostream is a good example of a similar use case (photos) where data is permanently cached and available offline ( to a degree) and you can still interact and 'post' to it where it'll wait and perform the action when network connectivity returns.

> like checking the weather, or sending e-mails, or Facebook, or shopping on Amazon.

* You don't need to check the weather every time. It's enough if you show me the data you fetched this morning or maybe just 2 hours ago (maybe so the time of the last successful request somewhere)

* Just let me write (and read...) my emails, change the label of the send button and put them in a queue when i click it. Actually send the mails when i get online again. (Fun fact: I am already doing that on my laptop, i write a lot of mail offline and msmtp queues them until i got a connection again. Useful on train rides and flights with spotty or no connection.

* I do not use facebook, but i hear that a lot of people also use it as an addressbook, for example. At least some of that data (names, telephone numbers, addresses,...) should be available offline if possible. Depends of course...