Offline UX Patterns(github.com)
github.com
Offline UX Patterns
https://github.com/Expensify/App/blob/main/contributingGuides/OFFLINE_UX.md
26 comments
> The user could have gotten logged out somehow, or maybe there's a rate limit or something
All your examples are retryable errors in which the prescription is the same: "keep the message queued until it's successful." And when all your failure modes are like this optimistic-no-feedback works. If you have non-retryable errors in your failure modes "Bad Request", "Gone" this pattern can't be used.
All your examples are retryable errors in which the prescription is the same: "keep the message queued until it's successful." And when all your failure modes are like this optimistic-no-feedback works. If you have non-retryable errors in your failure modes "Bad Request", "Gone" this pattern can't be used.
Sure they're retryable. But those retries might never succeed (user wipes their phone or uninstalls the app or logs out or clears local app data or a buffer fills up to come up with a few scenarios. Either the request didn't matter to the user at all, in which case sure whatever, or at some point they're going to discover that the thing they thought happened didn't actually happen.
Not being logged in is not a retryable error.
[deleted]
[deleted]
My error buckets and //TODOS with dreams of more refined implementations weren't all that lazy after all.
So what you are saying is that you don't think apps should work when offline?
Not at all. I'm saying that they should reflect the unereliability inherent in distributed computing rather than pretend it can't exist with such false notions as "retries will fix it" or "this call can't fail"
What are the other options?
The same options we've had literally since computers were invented. Unexpected and unrecoverable errors are as old as computing. This is not some new field of rocket surgery.
You use whatever mechanism is available in your language/framework to catch exceptions or errors, and you handle it. The program should do its best to recover, fail gracefully, and emit a useful message or log.
This is one of the core tenets of programming. Again, since the dawn of time.
You use whatever mechanism is available in your language/framework to catch exceptions or errors, and you handle it. The program should do its best to recover, fail gracefully, and emit a useful message or log.
This is one of the core tenets of programming. Again, since the dawn of time.
I find it interesting to read these UX patterns and ask myself "would the same UX pattern work for a local-first application?".
I find that in most cases, a local-first application would have a more predictable UX, because most actions need to be successful without a remote server to begin with.
Still, building the UX with an "offline-first" mindset is a giant leap forward when compared to all the networked applications I interact with.
I find that in most cases, a local-first application would have a more predictable UX, because most actions need to be successful without a remote server to begin with.
Still, building the UX with an "offline-first" mindset is a giant leap forward when compared to all the networked applications I interact with.
And yet as a user I sometimes find local-first applications harder to reason about. For some apps I know to force-quit and relaunch the mobile app after reconnecting to the network before opening the website, for example.
Distributed systems are just hard I guess, especially involving user systems.
Distributed systems are just hard I guess, especially involving user systems.
Local-first applications are much harder to reason about than server-driven apps or local-only apps, because there's now two sources of truth - the app and the server. Reconciling the two is much trickier than it looks.
This is my first time seeing Expensify's extensive open source work. Pretty cool and rare. Were they always open source? Anyone understand the strategy here or used the new App?
I’ve known them through their work on Wish List and Flash List. They’re one of the bigger supporters in work on list rendering in React Native (a vital, devilish, and often overlooked area).
I know that Expensify is one of the highest-ticket supporters of SQLite, because they (at least at one point, and probably still) have what is probably the world's largest SQLite database powering everything they do.
As a big fan of SQLite myself, I have to admit, this significantly raised their street cred in my eyes.
As a big fan of SQLite myself, I have to admit, this significantly raised their street cred in my eyes.
From casually browsing their GitHub, it seems that only their frontend is open source. I couldn't find the backend anywhere.
The names of patterns are extremely useful when you want to express to your coworkers "just update the view first and revert if the API fails" concisely.
This is my introduction to the word "Expensify". I assumed it meant something like "enshitify" eg: "enshitification".
It's an odd name. Nice of you to share on Github.
It's an odd name. Nice of you to share on Github.
It's a brand name, for everyone's context.
Assuming the happy path just leads to the app breaking in weird ways down the road.