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
* Designing the User Interface: huge breadth of coverage, but surprisingly little detail about how to actually go about designing a user interface, concretely; academic perspective feels disconnected from actual industry practices
Some theories:
* "You can't teach that in a book." It's probably not the ideal medium, but I don't buy the argument. c.f. Drawing on the Right Side of the Brain, Elements of Typographic Style, Gradus ad Parnassum, Interaction of Color, etc
* "It's too new to have a good book." a) Not really: you could write a good book about the concepts in the 1984 Macintosh interface. b) Even if you insist on starting from the multi-touch era: there are already outstanding books about, say, deep learning.
* "Writing a canonical book wouldn't be valued by that culture (socially, economically, etc)." Maybe… but even if you believe "most designers don't read much," they sure value audiovisual media. Where's the 3blue1brown / minutephysics / vihart of interface design?
* "All the knowledge is locked up in golden handcuffs and NDAs. It's all in the Apple HI people who've been there for 20 years." Partially true, but not enough. Four of the best interface designers I knew at Apple left since in the past eight years.
* "Why write a book like this when you could spend your time actually designing interfaces and earning $X00k/yr?" A fair question, but it also applies to e.g. programming texts, and there are tons of canonical works there.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
@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:
One reason we don't have more interesting, quality structured text editors: it's *really* hard to implement table-stakes editing operations well, particularly on web.
In this video, I attempt to arrow up/down and shift+up/down to select inter-line in 8 outliners. Very yikes.
Roam was the only web outliner which got arrow up/down navigation mostly right, though with some unexpected glitches at EOLs.
None of the web outliners support interline selection. OO doesn't either. Bear does great but ofc isn't really structured. And org-mode wins the day.
This sounds so nit-picky and trivial, but I think the difficulty of getting basic editing ops done well in simple outline UX illustrates just how painful it is to make a structured text editor nice enough to live in.
There'd be a lot of value in finding a good abstraction here.
@metaLulie Not a solopreneur but similar situation. Trying to work non-coercively, I’ve found it useful to understand my monkey-brain proclivities. Monkey has inertia, finds it hard to get started, easy to continue. Monkey wants easy gratification in the moment, meaningfulness in hindsight.
@metaLulie Very concretely: I find routine incredibly helpful. I’m not rigid about it—I’m happy to change it upon reflection—but everything is easier with well-considered defaults. It’s simply *true* that if I start my morning on Twitter, I will p>0.7 get no deep work done that morning.
@metaLulie I’ll regret it: in hindsight, Twitter was fun for the first 10m, then I got unwittingly sucked in, and it wasn’t really that fun. So I start my day with the internet off. Sounds like coercion, but doesn’t feel that way in the moment. It feels like “oh, right… thanks, past me.”
Funny how much sheer pleasurability and inspiration matter for habits. Ever since I got a new piano, my old practice time goals (which I often struggled to meet) feel comically low. Now somewhat effortlessly 3 months ahead of target… gotta ratchet up the goal!
Making the habit more pleasurable is an oft-suggested strategy. I think it'd be pretty enabling to assemble a wiki-style database of per-habit pleasure/inspiration-increasing strategies!
Something about this feels wrong. Like: why should I come up with ways to make myself to want to play the piano more? Shouldn't I just naturally want it?
Yet: deliberate practice is unpleasurable! (Ericsson et al '93) *Playing* is, but need much of the former to get the latter.
Interesting to consider when this is an effective strategy. In many design tasks, simply being able to generate (& discard) more alts will produce better results. But…
… this is probably only true when the problem can be solved with something like pre-existing approaches. Inventing wholly new representations needs 2x-good > 2x-fast.
In most software tasks (but often not the interesting ones), 2x-fast is usually higher-leverage than 2x-good.
Reminds me also of experiences learning piano. For years, was trying to move as fast as possible onto harder repertoire. Then had a great teacher who made me slow way down, play stuff from years ago, focus on musicality. 2x good was much more rewarding than 2x fast.
It’s quite rare for software to offer both a real local file format and also substantial cloud/SaaS behavior (ie other than syncing). Usually it’s one or the other—if the cloud has active behavior, apps are thin clients which don’t expose an accessible on-disk format (eg Notion).
I recently finished re-architecting @withorbit to expose an on-disk format, thought I’d write a bit about what I learned.
@withorbit It’s hard to pull this off, as I&S describe. You need to design a file format which syncs efficiently and reliably, which is already tough. Gets tougher when your SaaS is an active replica with its own public API, and when you layer on indexing/querying, migration, sparsity.