Discussing this more with Laura, one thing that surprises me is how few digital authoring envs you'd want to "live in" all day for both prose and visual explanations. Your team can live in Notion, but then no visual expls; or live in Figma, but probably not write there.
OneNote was the only full-featured tool we could think of which seemed well-suited to both text and visual explanations, though it has its own downsides.
We're all still "separating by mode of production", per Tufte…
Yes, one can still embed Figma artboards as blocks inside Notion documents, but that's still separating by mode of production. Means you're unlikely to spontaneously create text<>visual interactions as you'd naturally do on paper / whiteboard.
I guess this is yet again a wistful yearning for OpenDoc and its ilk. I don't want a world in which Notion has to implement Figma's feature set!
The "Markdown representation" support of the Excalidraw Obsidian plugin is really quite compelling:
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!
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.
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.
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!
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.
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.
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