5 ms·

Offline UX Patterns

124 points by notpushkin 2y ago

whoitwas 2y ago
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.
- martijnarts 2y ago
  It's a brand name, for everyone's context.
Rygian 2y ago
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.
- iudqnolq 2y ago
  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.
  - yen223 2y ago
    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.
rgbrgb 2y ago
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?
- hiAndrewQuinn 2y ago
  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.
- miki123211 2y ago
  From casually browsing their GitHub, it seems that only their frontend is open source. I couldn't find the backend anywhere.
- qazxcvbnm 2y ago
  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).
yuliyp 2y ago
I loathe the over-abundance of "Optimistic Without Feedback Pattern". It is used as a crutch for "I don't want to bother implementing error cases". Even the pinned chat example they use is just a bug factory. Stating "this particular API request has almost no way of failing, and we know what the server will return in advance" is extremely naive. The user could have gotten logged out somehow, or maybe there's a rate limit or something, or the server's overloaded, or they're offline and going to use the app on another device that is online before you can sync, or whatever. Assuming the happy path just leads to the app breaking in weird ways down the road.
- Spivak 2y ago
  > 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.
  - deleted 2y ago
    [deleted]
  - deleted 2y ago
    [deleted]
  - ben-schaaf 2y ago
    Not being logged in is not a retryable error.
    - Spivak 2y ago
      Sure it is, why wouldn't it be? Keep it stored and queued until they log in again. It's the same as being offline.
      - xbjfk 2y ago
        What if someone else logs in?
qbane 2y ago
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.

124 points by notpushkin 2y ago

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.

martijnarts 2y ago
It's a brand name, for everyone's context.

Rygian 2y ago

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.

iudqnolq 2y ago
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.
- yen223 2y ago
  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.

rgbrgb 2y ago

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?

hiAndrewQuinn 2y ago
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.
miki123211 2y ago
From casually browsing their GitHub, it seems that only their frontend is open source. I couldn't find the backend anywhere.
qazxcvbnm 2y ago
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).

yuliyp 2y ago

I loathe the over-abundance of "Optimistic Without Feedback Pattern". It is used as a crutch for "I don't want to bother implementing error cases". Even the pinned chat example they use is just a bug factory. Stating "this particular API request has almost no way of failing, and we know what the server will return in advance" is extremely naive. The user could have gotten logged out somehow, or maybe there's a rate limit or something, or the server's overloaded, or they're offline and going to use the app on another device that is online before you can sync, or whatever. Assuming the happy path just leads to the app breaking in weird ways down the road.

Spivak 2y ago
> 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.
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
- ben-schaaf 2y ago
  Not being logged in is not a retryable error.
  - Spivak 2y ago
    Sure it is, why wouldn't it be? Keep it stored and queued until they log in again. It's the same as being offline.
    - xbjfk 2y ago
      What if someone else logs in?

qbane 2y ago

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.