←back to thread

Local-first software (2019)

(www.inkandswitch.com)
863 points gasull | 1 comments | 05 Jul 25 14:45 UTC | HN request time: 0.228s | source
Show context
arendtio ◴[05 Jul 25 21:08 UTC] No.44475558[source]▶
Regarding the no-spinners: I think it is the wrong approach to argue that just because you have data locally, you don't need any spinners.

Whether you need a spinner or not should be decided by the User Experience (e.g., when the user has to wait for more than 100ms, show a spinner), and not by the location of the data. I am a big fan of local-first apps and enjoy building them myself. However, sometimes your app takes a moment to load. With local-first, you eliminate the network as a source of delays, but there are other factors as well, such as large data sets or complex algorithms.

For example, when you have a project planning software and want to plan 100 work packages with multiple resource combinations in an optimal way, depending on the algorithm, this can take some time. In that case, a spinner or a progress bar is a good thing.

replies(3): >>44475653 #>>44475800 #>>44475820 #
JFingleton ◴[05 Jul 25 21:44 UTC] No.44475800[source]▶
A properly designed app would leverage multi threading to place any long running jobs in the background, allowing the user to carry on with other tasks.

Spinners should not exist in a local first app.

replies(1): >>44478503 #
1. arendtio ◴[06 Jul 25 07:07 UTC] No.44478503[source]▶
You are aware that 'local-first' does not mean 'no-network'. Having a sync mechanism that runs in the background without user notification can be quite disconcerting.

I mean, I did it, I built an app with a transparent background sync. Then I added a special page, 'sync center'.

In reality, mobile devices don't always have perfect network connections. Therefore, when the user is unsure whether the device is in sync or if the sync is in progress but encounters an obstacle, they might perceive the app as unreliable.

Banning spinners is dogmatic, not user-centric.