"Export considered harmful"

Because software rarely operate on "files in folders" anymore, "export" is increasingly the way software exposes data. But usually you don't want a dead snapshot; you want to "use this data elsewhere"—which requires repeatedly exporting & reconciling.
Say I make an app for annotating papers. An old-fashioned way to do this would be to make a desktop app which views PDF files and writes annotations into the file. Now Spotlight can see them; Zotero can display them; etc. But SaaS must "import" the PDF and "export" annotations.
But "export annotations" is not the same as "save annotations" because now if I add more annotations to the PDF, I must export them again, and then reconcile that new export with whatever downstream tools used the old data. This gets much worse in the bi-directional case!
Consider also Zotero: it's native software, but it's designed to manage your papers' files internally. You can export individual PDFs elsewhere, but changes made to that PDF won't be reflected within the app. Contrast this with "Zotero is a viewer for a (nested) folder of PDFs".
The "old-school" way to do this is to design well-structured file formats which multiple pieces of software can operate on. TimBL proposes bringing this to the SaaS world via SOLID and modern flexible schema formats. Web3 folks have related proposals.
Another angle: I'm intrigued by the possibility of a "lens file": what if my PDF annotator can "save a Markdown lens" which contains my annotations. The difference from an export, though, is that the lens would be "live", with a bidi scheme for handling changes.
That is, if I add new annotations in my PDF annotator, they're added to the .md (without disturbing other content in the file); if an annotation is altered in the .md, that's reflected in the viewer app.

(Doing this well requires careful format design! Maybe Cambria could help?)
Now, there are lots of problems with the "files and folders" paradigm. Lots of people have trouble understanding it, even decades after its introduction! But they do seem to understand app silos. There's probably a good abstraction to be discovered here which mixes the worlds.
The typical web answer here is APIs, but APIs are much worse than standardized file formats: each pairwise edge needs its own impl. N^2 vs N. Pity poor Readwise's engineers; worse, if you have a different idea for a Readwise-alike, you must build all this to achieve parity.
Anyway: I get annoyed every time I see "export" offered as a workflow solution, particularly for "critical path" knowledge work stuff, because I know that I'll have to do lots of manual schlepping of data, and inevitably, I'll end up with different versions in different places.
(Thanks to @kirkbyo_ for conversation on export which inspired this rant!)

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Andy Matuschak

Andy Matuschak Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @andy_matuschak

22 Oct
Really exciting talk from @JoelChan86 demonstrates an interface for incrementally generating semi-formal "discourse graphs" (X supports Y, Z informs W) through naturalistic note-taking structures:

The loose structure and incrementalism seem really key!
I've been creating these sorts of relationships informally in my own note-writing processes, and it's been really interesting to see synthesis (sometimes) emerge from the noise.

Not yet sure how useful formal structures ("discourse graphs") are, vs. relatively simple queries.
Probably more formal and machine-readable structures are essential if one aspires to network this work across many scholars, as Joel does.
Read 5 tweets
11 Oct
One fun way to think about extended cognition is in terms of creating unrecognizably alien mental states.

eg: someone who has never used Hindu-Arabic numerals can't imagine what is going on in the mind of someone using them to solve a problem. Unrecognizably alien mental states!
Ditto musical notation: someone who's never used it can't imagine what's going on in the mind of a composer who has.

But also, Lisp does this to how I think about representing data; drum machines do this to how I think about rhythm; probably a Bloomberg terminal qualifies; etc.
In general, the more transformative the environment, the more unrecognizable—alien; magic!—the mental states it produces.
Read 5 tweets
11 Oct
Following up: several people mentioned the original 1987 Apple Human Interface Guidelines, which I'd not read. It's not a comprehensive primer on interface design, but it is an extraordinary read—a huge amount of detail on *why* things are as they are. And a great bibliography!
It's surprisingly difficult to find a PDF of the 1987 edition online, so here you go: andymatuschak.org/files/papers/A…
If you've only read "modern" HIGs, I definitely recommend reading the 1987 edition! It's *very* different. It is amusingly difficult to imagine this passage in a contemporary Apple text.
Read 5 tweets
9 Oct
Have been experimenting with this unusual Dasung portable e-ink display for park working sessions. It's surprisingly responsive—plenty good enough for writing, coding, studying. HDMI driven, weighs about 1.5lbs, sits in front of my normal display (& uses much less power, ofc).
Working on the reMarkable is pretty nice, but it makes me feel so passive. The device makes it so hard to write while I read, to jump around, to synthesize—I'd rather use paper most of the time.
Part of the trouble, I guess, is that this use case is too niche to get a really thoroughly-developed software stack. So things like the Kindle, reMarkable, Boox etc feel awfully "unserious" about workflows compared to my laptop. It's nice to just use my "full" setup in the park.
Read 5 tweets
23 Sep
Why are there no "standard texts" on designing software interfaces? (or tell me I'm wrong?)

If you want to learn to *build* software, there are excellent and complete texts on the subject. It's not just a tech-vs-art thing: there are standard texts on type, drawing, color, etc.
Of course, there are lots of great books peripheral to (and useful for learning) the topic of software interface design: Inmates…, Design of Everyday Things, Tufte, etc. But these don't aspire to be complete introductory guides to the subject, like How to Design Programs.
Some close contenders:

* About Face: great coverage of broader design product process, but concrete details on interface design quite limited

* Don't Make Me Think: focused on web sites and info arch, not much discussion of interactive interfaces
Read 9 tweets
10 Sep
A bit of fun: this GIF is a "legendary" @robin_____sloan Amulet (8 8's).

base64: R0lGODdhBgAJAPEAAEeEqvij+U6wk386YSwAAAAABgAJAAACD4RvERciC9pjMDooq0KoAAA7

hash: B36F0888888889A57D77E14E9B8D4B95E11C6B6C0B48FB0D7F5E634B2D129623

@robin_____sloan I was unable to reveal the amulet via the smart contract, alas, since the text is specified via `string` rather than `bytes`, and UTF-8 encoding rules muck up the string. But/so:

Title: "A picture worth a thousand words"
Carbon offset URL: dashboard.cloverly.com/receipt/202109…
@robin_____sloan (Hope you don't mind the subversion, Robin… can a GIF be poetry?)
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!