[HN Gopher] Offline UX Patterns
       ___________________________________________________________________
        
       Offline UX Patterns
        
       Author : notpushkin
       Score  : 103 points
       Date   : 2024-09-28 09:45 UTC (4 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | whoitwas wrote:
       | 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 wrote:
         | It's a brand name, for everyone's context.
        
       | Rygian wrote:
       | 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 wrote:
         | 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 wrote:
           | 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 wrote:
       | 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 wrote:
         | 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 wrote:
         | From casually browsing their GitHub, it seems that only their
         | frontend is open source. I couldn't find the backend anywhere.
        
       | yuliyp wrote:
       | 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 wrote:
         | > 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.
        
         | swah wrote:
         | What are the other options?
        
           | marcelr wrote:
           | handle the errors, ideally manually
        
           | mystified5016 wrote:
           | 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.
        
       | qbane wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2024-10-02 23:01 UTC)