Detailed Summary

1. You own your data, in spite of the cloud. <br /> Section summary: <br /> Local-fist software tries to solve the problem of ownership, agency and data lock-in present in cloud-based software, without compromising cross-collaboration and improving user control.

Section breakdown<br /> §1: SaaS<br /> Pros: Easy sync across devices, real-time collab Cons: loss of ownership and agency; loss of data is software is lost.

§2: Local-fist software<br /> - Enables collaboration & ownership - Offline cross-collaboration - Improved security, privacy, long-term preservation & user control of data

§3 & §4: Article Methodology<br /> - Survey of existing storage & sharing approaches and their trade-offs - Conflict-free Replicated Data Types (CRDTs), natively multi-user - Analysis of challenges of the data model as implemented at Ink & Switch - Analysis of CRDT viability, UI - Suggestion of next steps

2. Motivation: collaboration and ownership<br /> Section summary: <br /> The argument for cross-device, real-time collab PLUS personal ownership

Section breakdown<br /> §1: Examples of online collabs<br /> §2: SaaS increasingly critical, data increasingly valuable<br /> §3: There are cons<br /> §4: Deep emotional attachment to your data brings feeling of ownership, especially for creative expression<br /> §5: SaaS require access to 3rd party server, limitation on what can be done. Cloud provider owns the data.<br /> §6: SaaS: no service, no data. If service is shut down, you might manage to export data, but you may not be able to run your copy of the software.<br /> §7: Old-fashioned apps were local-disk based (IDEs, git, CAD). You can archive, backup, access or do whatever with the data without 3rd party approval.<br /> §8: Can we have collaboration AND ownership?<br /> §9: Desire: cross-device, real-time collab PLUS personal ownership

3. Seven ideals for local-first software<br /> Section breakdown<br /> §1: Belief: data ownership & real-time collab are compatible<br /> §2: Local-first software local storage & local networks are primary, server secondary<br /> §3: SaaS: In the server, or it didn't happen. Local-first: local is authoritative, servers are for cross-device.

3.1.1 No spinners<br /> SaaS feels slower because if requires round-trip to a server for data modification and some lookups. Lo-Fi doesn't have dependency on server, data sync happens on the background. This is no guarantee of fast software, but there's a potential for near-instant response.<br /> 3.1.2 Data not trapped on one device <br /> Data sync will be discussed in another section. Server works as off-site backup. The issue of conflict will also be discussed later.<br /> 3.1.3 The network is optional<br /> It's difficult to retrofit offline support to SaaS. Lo-Fi allows CRUD offline and data sync might not require the Internet: Bluetooth/local Wi-fi could be enough.<br /> 3.1.4 Seamless collabs<br /> Conflicts can be tricky for complex file formats. Google Docs became de facto standard. This is the biggest challenge for Lo-Fi, but is believed to be possible. It's also expected that Lo-Fi supports multiple collab.

TBC

A great article on the history of reading online that might just nudge me into trying out and eventually becoming a Reader paid subscriber.

Great. I love this local-first, Markdown-based design.

Local-first has most responsive UX due to operations being performed locally, as opposed to sending them to the server.

(NB: this is in response to the question Why not just use wordpress + wysiwyg editor similar to *docs, and you're done?.)

This is a good of an explanation as any for local-first software.

A natural response (to potatolicious's comment) is, "Well, somebody has to maintain these no-code Web apps, too, right? If there's someone in the loop maintaining something, the question still stands; wouldn't it make more sense for that something to be e.g. a WordPress instance?"

Answer: yeah, the no-code Web app model isn't so great, either. If service maintenance is a problem, it should be identified as such and work done to eliminate it. What that would look like is that the sort of useful work that those Web apps are capable of doing should be captured in a document that you can copy to your local machine and make full use of the processes and procedures that it describes in perpetuity, regardless of whether someone is able to continue propping up a third-party service.

There's an unnecessary dichotomy here between uses JS and page is served as HTML. There's a middle ground, where the JS can do the same thing that it does now, but it only does so at edit time—in the post author's own browser, but not in others'. Once the post author is ready to publish an update, the client-side generated content is captured as plain HTML, and then they upload that. It still "uses JS", but crucially it doesn't require the visitor to have their browser do it (and for it to be repeated N times, once per page visit)...

Meanwhile, not only does the scope of this tool not merit the Big Sur requirement, it doesn't even require a Mac. It interaction style is so free of intracies that it could be developed (and distributed) as a single HTML file with a text input and some script blocks.

This tool should be a "codebook"—a downloadable document meant to be stored in an offline copy e.g. on the user's local disk, a la PDF (except still actually HTML, as here). I shouldn't need to "go to" anywhere to use it; that should only be necessary to get it the first time.

Wordle's spread on social media was enabled in part by its low-tech approach for e.g. sharing scores.

One low-tech approach that could've been used here for data persistence would be to generate and prompt the user to save their latest scorecard in PDF or Word format—only it's not a PDF or Word format, but instead "wordlescore.html" file, albeit one that they are able to save to disk and double click to open all the same. When they need to update their scorecard with today's data, you use window.open to show a page that prompts the user to open their most recent scorecard (using either Ctrl+/Cmd+O, or by navigating to the place where they saved it on disk via bookmark). What's not apparent on sight alone is that their wordlescore.html also contains a JS payload as an inline script. When wordlescore.html is opened, it's able to communicate with the Wordle tab via postMessage to window.opener, request the newest data from the app, and then update wordlescore.html itself as appropriate.

Desired workflow:

1. I navigate to the APL login page https://austin.bibliocommons.com/user/login
2. I invoke a bookmarklet on the login page that opens a new browser window/tab
3. In the second tab, I navigate here—to a locally saved copy of (a facsimile of) my library card
4. I invoke a bookmarklet on my library card to send the relevant details to the APL login page using window.postMessage
5. The bookmarklet set up in step 2 receives the details, fills in the login form, and automatically "garbage collects" the second tab

Some other thoughts: We can maintain a personal watchlist/readlist similarly. This document (patron ID "page") itself is probably not a good place for this. It is, however, a good place to reproduce a convenient copy of the necessary bookmarklets. (With this design, only one browser-managed bookmarklet would be necessary; with both bookmarklets being part of the document contents, the second bookmarklet used for step 4 can just be invoked directly from the page itself—no need to follow through on actually bookmarking it.)