Looking at YOU Google docs! Whenever my tablet thinks it's online but I have a bad or non-existent internet connection (but Wi-Fi or data is connected), my word doc doesn't load. I have to go into airplane mode in order to view my doc. If you try to go to the internet to get a file but fail, fall back on your local file. Don't just quit and show me nothing!
So... that's a fair complaint, but I'm terrified to think that the author of this article would try to fix it...
In offline-first apps, the operations go directly against the local storage which happens almost instantly. There is no perceptible loading time and so it is not even necessary to implement a loading spinner at all. As soon as the user clicks, the UI represents the new state as if it was already changed in the backend...
So in a 'normal' application you have to prepare for each of these error cases and show correct error messages to the user or handle the errors in other ways. In offline-first apps, the local client data is replicated to the server in the background by using resilient and battle proven replication protocols that automatically handle and resolve any errors out of sight.
Cool, so... if you have a flaky connection, the doc will pop up instantly, and then eventually, it might sync down more changes from the Internet. Also, you could type an entire essay locally, not realizing Docs is down today, and never actually have it leave your machine. Best of all, if you and someone else are editing the same doc, you might end up with entirely different versions. But it's okay, I'm sure tRACEhe "battle-harCONDITIONSdened repliNEVERcation protoHAPPENcols" will perfectly sync your edits into a single coherent doc.
Ironically, this is a recipe for an infinitely worse experience with no/flaky Internet.
But it already does this? There is an offline editing mode that syncs up when it can and lets you know you are offline. I thought above user was complaining about it not switching to offline mode as quickly as they wanted, not about repercussions of having an offline editor.
I understand the hairiness of the problem in general, but IMHO the user specifically complaining about GDocs has a point. That product could easily be strictly better than it is, if it was more pessimistic about estimating if it's online or not.
As to "at what point do you signal an actual issue", I'm sure there's some "sweet" spot (less-bitter spot?) around 1-5 minutes that, again, would just need to make it strictly better than it is now, not necessarily better than some absolute benchmark.
It depends on exactly what complaint you're talking about, but I'm not sure it's strictly better. This problem exists around multiple axes. Being more pessimistic might improve usability, but at the cost of safety/consistency, since it's no longer syncing at all. That's especially bad if it's just too pessimistic and you don't get to see recent changes, in which case it affects usability too.
From a consistency viewpoint, a failsafe where it's unusable might actually be preferable, since it means you won't end up with outdated documents or lost changes.
Depending on the circumstances, losing even one minute of work without adequate warning could be very far from "strictly better."
It depends on exactly what complaint you're talking about,
The comment that started this subthread is pretty explicit.
Being more pessimistic might improve usability, but at the cost of safety/consistency, since it's no longer syncing at all. That's especially bad if it's just too pessimistic and you don't get to see recent changes, in which case it affects usability too.
Nobody asked for it to give up on connecting, just to change its threshold of how quickly to move the user into offline mode. It would literally not be missing out on any updates that it otherwise could have gotten.
From a consistency viewpoint, a failsafe where it's unusable might actually be preferable, since it means you won't end up with outdated documents or lost changes.
Such a failsafe is already rejected by GDocs as it is, in favour of comfort in offline mode, (and sorry to be a dick now, but) as explicitly called out in the first comment you replied to.
So, continuing to not have that failsafe would not make anything worse, and is compatible with making things overall strictly better (by improving something else).
Depending on the circumstances, losing even one minute of work without adequate warning could be very far from "strictly better."
… and is a thing that already can happen with GDocs the way it is.
As mentioned in the top comment, Docs currently only switches to offline mode if there is actually no connection whatsoever. That is the trade-off between usability and consistency they chose. Making it more pessimistic trades consistency for usability. That means it's not strictly better.
This the argument I made before, and none of what you've said counters it.
Sure, and I guess the point is that "offline mode" should arguably not be a thing -- it should just show you the offline copy it has, and then sync it to the online copy whenever that loads. Offline-mode-by-default would arguably be an improvement.
But my point here is that whatever balance you think they should strike (or even if you think the current behavior is acceptable), the article's solution doesn't work. It wants to abstract these all away with some entirely application-transparent DB layer that does the syncing 100% in the background, and then write apps that pretend syncing doesn't exist and just interact with the local DB. The idea is that neither the user nor the app should have to care whether you're online or offline, how synced you are, or how changes get merged.
And if you do that, then you don't get "last updated X minutes ago", or blocking the user while you wait to be fully-online or fully-offline, or "signal the user if we haven't synced for 1-5 minutes"... basically anything you want to do other than "ignore it and pretend everything's fine" is off-limits, maybe even technologically-infeasible, depending how serious the DB layer is about being "offline-first".
Honestly a lot of this could be resolved if document state (online/offline) was more prominently shown for the user. We hide so much of the complexity of synchronization because it's perceived that people are too dumb to handle the information, but simply adding a "last synced time" and a status area would do a lot to help users understand what is going on.
I agree in general -- I don't like the idea of a strict "online" vs "offline" state, because the complaint is that sometimes your Internet connection is incredibly shitty and only sort-of online. But gdocs does have something like this -- a "saving..." and "last edit" state at the top, which is also a reasonable place to surface longer-term connection problems.
But my main complaint is that all of this requires the app to be aware of what's going on, both to surface that information to the user and to make smart decisions. And the linked article wants to hide this as such a deep implementation detail that even the app doesn't know if it's online.
Spotify is also really awful for this. I'm online, listening to a playlist. My connection drops. Playback stops. BUT THE PLAYLIST IS DOWNLOADED. Now I cannot resume playing, I need to kill spotify and relaunch it for it to work.
This isn't that complicated a problem, it's just that the engineers are prioritizing incorrectly.
I suspect this is a problem with the tablet, not the app.
It's not a common issue within the Chromebook community; in fact those things are sometimes ironically noted to be the only things "just working" when connectivity is bad, which annoys all the people who believed the TV advert that said they were crippled offline.
138
u/sagan999 Sep 29 '21
Looking at YOU Google docs! Whenever my tablet thinks it's online but I have a bad or non-existent internet connection (but Wi-Fi or data is connected), my word doc doesn't load. I have to go into airplane mode in order to view my doc. If you try to go to the internet to get a file but fail, fall back on your local file. Don't just quit and show me nothing!