When I finally opened my eyes to the truth of how these things work (spoiler: it’s just moving strings around from one set of files to another), the fear abated. But I still held on to a sense of “purity” — I would get by with as little fiddling as possible.

But this week, I wanted my site to use a Service Worker to provide an instant navigation experience across pages, even in the absence of a network connection. As per first instinct, I went looking for the Hugo-blessed way to do this and…didn’t find one. It turns out, I’d need a post-build script. The horror! (if I was still a coward)

But I’m not anymore, and I have the LLMs to write the script and Makefile so I don’t need to learn the syntax. Nor do I have to live with a sense of “dear Netlify, please build my site from my Git push, thank you so much”, because I can build the site myself and upload it directly with the Netlify CLI. As a bonus, it’s around 50% faster than the old Git commit → Github → Netlify → CDN workflow I had earlier.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

One Big Markdown File where new entries are appended to the top.

The hope is that I practice writing things down more often, in a place where it doesn’t feel like I’m “notifying” people, or writing to an audience at all. There is no effortless way to link to entries, there is no RSS feed, and there is no organisation other than the chronological. It as an attempt to move things that look like personal notes into a public-facing page. Inspired, in no small part, by Nadia’s (recently taken down!) Notes pages.

While designing this new publishing location, I was forced into thinking about all the existing formats on my website; now grown from 2 items to 3…

• Evergreen writing (lists, notebooks, or essays) that require real investment into polish and maintenance.
• Riffs, which are temporal publications, used primarily to wonder aloud in brief or send out announcements.
• ~~~, which I almost named “Stream”, “Flow”, and “Flux”, but ultimately decided I had enough named sections on my website. Used for thoughtdumps.

One might well ask “why aren’t you using Streams for this?”, seeing as I made and maintain a service for microblogging. As all good questions, it leads to a fruitful line of enquiry — culminating in the taxonomy below, which I think covers all the things one can achieve with a microblog.

1. Quick capture
2. Glib phrases & jokes
3. Journalling
4. Commentary
5. Shower thoughts
6. Thread-length extempore posts
7. Personal/project updates
8. Conversation
9. Signal boosting/curation/recommendations
10. In-group signalling!

I will continue to use Streams for #1 (which makes sense, given that’s what it was built for), but I don’t think the other uses are suited to it. For example, I prefer to write Riffs in a proper text editor and over a period of many minutes. Not as a hurried message into a Telegram channel. Conversation, jokes, updates and recommendations are similarly all best done in places that have the capability for interaction.

The medium and the message and me have yet to exhaust all possible combinations of formats and workflows — with ~~~ as the latest addition to the set. My guess is that it’s primary roles will be journal, commentary, and thought-posting, which are currently underserved by existing outlets (believe it or not, I try to restrict my commentary on Twitter out of respect to my followers).

And I think it’s particular combination of features (self-ownership, low effort bar, personal/limited audience) is sufficiently novel that you should try adding one to your site!

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

I no longer remember which of us began the discussion, but the question at hand was about technology that is often looked upon as a mistake in hindsight, or has dystopic vibes.

• DDT
• Thalidomide
• Microplastics
• Leaded gas/pipes
• Asbestos
• CFCs/HCFs
• Lobotomy
• Biological weapons
• Nuclear weapons
• Cloning

There are two reasons for me resurfacing this old list. The first is that I happened to be cleaning up my drafts and scattered notes (as part of a focusing exercise re. my career, but that’s another story). The second is because I find Robin Sloan’s “this is the best it will ever be” sentiment to be brutally real-headed.

It’s interesting and useful to imagine — really visualize — the chatbots and agents in ten years or twenty … barnacled with gunk … locked in a permanent cat-and-mouse game with their adversaries … just as a platform like Google is today. In 2036, you send your AI agent out into the internet, and it returns battered, bedraggled, inexplicably enthusiastic about a bargain flight to Bermuda.

Felt like a congruent enough set of things to make a small post about. It’s easy to miss the bad for the good when it comes to technological “progress”, and sometimes we’re not lucky enough to be able to walk back things that could be reassessed (see: smartphones).

So, cheers to all the times we’ve been wise enough to take the one step back. And pour one out for the things we lose when we’ve decided not to. I fear this is one of those times.

P.S: Since it is now 2026, I can of course ask the bots to expand on Imp’s excellent list. Here’s Claude’s attempt at doing so.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

You would assume that people do live collaborative work on the same document. In practice, they get on a video call and one of them edits, the rest watch.

My memory of something Sunil Pai once said

I really like stateless systems with few moving parts. Static sites are so simple, I can host hundreds of them for free. I adore edge functions of all kinds (especially Cloudflare Workers) – being able to spin up microseconds of cloud compute on demand is lovely. Object storage like S3 is so cheap, people choose to build entire databases atop it. We now have serverless streams that I expect to be similarly amazing.

Realtime sync is often more complicated. I won’t deny that it’s cool to make a change in one tab, and watch the app update in a different tab/window/device, but recently I’ve been asking “is that really necessary?”. Do you really need to provision stateful servers and always on sync systems just to make people’s cursors move around a screen in realtime?

Figma is the poster child of realtime syncing, they spent ~3 years designing the whole thing. You’ll hear some people say that this let them beat Adobe and Sketch in the design tool arena. I don’t buy this narrative. The decisive feature was “share your design files with a URL”, not the ability for two people to move rectangles around together.

To me, the need for realtime editing in applications is greatly exaggerated. Think about how rare it is to:

• get two people to be in the same place at the same time
• have a task where more than one person makes changes at a time
• want other people peering over their shoulder while they work

And that’s if your synced app is multiplayer at all. For many apps, the only person I’m collaborating with is myself. I’m certainly not holding my phone and laptop open at the same time, frantically typing into each, expecting edits to sync across as I do so. If we have a future where more people make apps for themselves, it would be nice if they used cheap, simple systems to move data around. Sync is good, it doesn’t always have to be live.

But with agents, things might change. They are unrelenting daemons, ready to join in at a moment’s notice, and stay working for as long as you pay them to. I can imagine applications where having them keeping up with realtime changes is a big deal. Especially if there’s multiple agents all working really fast. They might just be the killer app for sync engines.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

“Transactions: myths, surprises and opportunities”: The best explanation of the various consistency and isolation levels in database I’ve ever seen.

Is Kafka a Database?: I was already bought into single-threaded event streams (as opposed to Raft, etc) as a way to do writes in an application, this talk just confirmed I was right to do so.

Good thing we’re not writing a database: A useful perspective on what Automerge is, and what it’s not trying to be.

Serverless primitives for the shared log architecture: Re. S2.

Writing

The Git Parable: Most of the interesting ideas in databases can be found in Git — hashes, immutable data structures, branching, distributed state, etc.

Building a BFT JSON CRDT

Data Synchronization: Patterns, Tools, & Techniques

A Primer on Database Replication

Log Structured Merge Trees

Notes on Distributed Systems for Young Bloods

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

What is less forgivable however, is the concept of displaying time as an isolated, static pair of numbers. As a general rule, I avoid numbers when visualizing quantities. I prefer a graphic that can convey the scale of the quantity instead (like the impact bars I added to items of the Frontier 2025 site). Symbols are indirection, and it’s hard to feel quantities by looking at their numerical representation.

I prefer my numbers to be placed within a narrative; the steady climb of a progress graph, a series of comparable lines, as squares of varying brightness. Especially when dealing with time, a quantity so linked to change that some people like to define it as a measure of such. It feels silly that I have to compare 4:00 PM and 8:00 PM through mental arithmetic instead of being able to simply see the difference.

And the subtractions are numerous and happening all the time. How much time until bed? When is the next meal? How much time has passed since I last picked up my phone? Somehow doing the subtraction in my head and arriving at an abstract number (2 hours on Twitter…) doesn’t feel as visceral as a physical representation.

I’ll admit I also hope that a 24-hour bar will add firmer bounds to a “day”…

We have a few famous bars and grids for tracking progress through the year, a Japanese timer progress bar, and a ridiculous abuse of the clock metaphor for existential risk. But nobody wants to give me a 24 hour progress bar that I can pay money for and have delivered to my house. The best I could find were:

• this mock image (from a seemingly adulterous husband?) at #14 on, uh…the 24 Geekiest Clocks Ever Made.
• an Instructables page for a DIY progress bar clock made form 3D-printed parts and LEDs.
• a single Reddit post from 2015 asking for the same thing as me
• an overpriced circular clock that is kinda a progress bar

P.S: I do have a particular design in mind (see my Workbench page), but the more variety the better.

P.P.S: It’s slightly sad how most of the popular time-related progress bars are about scarcity (years left in an 80-year lifespan, days left in a year), because those clocks run out once and then it’s all over. A daily clock is much less cruel because it will refresh again the next morning! You get to see the hours fill up today, but with the knowledge that there will be new ones soon.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

So I hope you read these as just another calibrative data point, not as dictums. Also, I hope you give me credit for turning this into one long list instead of milking it for multiple short riffs.

Indirection

Recently, my personal design work has coalesced around the prevention of interface anxiety. An extra click, a different screen, and the expectance of latency between them are all experiences that add up to a fragile-feeling environment.

But there’s a more subtle version, that of abstraction and spooky action at a distance. Tying things together (i.e. complexity) in vague and shadowy ways is the surest way to build a confusing system.

Back in 1984, explanations of the original Mac interface to users who had never seen a GUI before inevitable included an explanation of icons that went something like this: “This icon represents your file on disk.” But to the surprise of many, users very quickly discarded any semblance of indirection. This icon is my file. My file is this icon. One is not a “representation of” or an “interface to” the other. Such relationships were foreign to most people, and constituted unnecessary mental baggage when there was a much more simple and direct connection to what they knew of reality.

[many sentences later] Even the smallest disconnection shatters the illusion, turning what was once an utterly convincing and understandable world of files and folders into an arbitrary heap of windows, full of icons and widgets, signifying nothing.

John Siracusa, “About the Finder…"

Hyperlinks

I love them enough to use them all over my site, but i do not love:

1. …how they jump to a completely different context with no hint re. where you came from or intended to do.
2. …how most browsers don’t provide even a hint of where a link you intend to click will lead to. I’m not asking for speculative interfaces or a completely new browser – a simple link preview showing up on hover is enough to prevent every navigation from being a blind leap. My browser of choice, Arc, does this really nicely:

For similar reasons, I (and Jake Archibald) dislike footnotes on the web. But I do think that popup and margin notes are a fine substitute – anything that doesn’t jump you away from the text you were reading.

Transclusion

There are valid uses for “pulling content from a source file into a destination file without copying it, so changes to the source automatically update all instances” out there, like documentation or embedding a view of a live feed. But for everything else, I’m not a fan.

My main objection is philosophical: Facts are temporal.

A document is a thing that reflects information as it existed at the time. Inserting it elsewhere now ties together two things that probably have different update schedules. You now have something that’s alive in two different places. Each interaction requires you to keep track of those two contexts. How does changing this thing in front of me affect every other place that it’s present?

My preferred solution is just copying and pasting the necessary content to its new location. Redundant, but robust. This is similar to the folk practice of posting screenshots of tweets instead of quoting them, making them immune to editing, deletion, or privacy settings. This is also what Gwern does for his popups, creating a manual copy of Wikipedia pages or other documents.

Even the usage patterns for transclusions are often rather finicky:

In Obsidian, when users create a block link, a hexadecimal identifier is inserted into the referenced block. This identifier creates a more stable link than our snippet references. But many of our test users mentioned that they don’t use Obsidian’s block references because they find these identifiers messy, and because they worry about accidentally “losing” the identifier when editing the file.

Latticework

(I recommend reading the whole thing, it’s one of the few examples of a design case study that’s actually good.)

Ideological mistakes

The unfortunate consequence of holding notions of “purity” or “simplicity” above goals that are real and present. Clinging to the initial version of a vision, refusing to accept the lessons of Worse is Better. Letting your decisions be guided by raw ideas instead of the gentle pushback of reality.

Liquid glass

I don’t have much of a problem with “liquid” materials on smartphones, provided they animate quickly and smoothly. I do have a problem with heavily padded floating buttons, sidebars and other UI elements stealing valuable screen real estate on my Serious Computer, the Macbook.

And I’m not a fan of background content showing through overlays either, I really wish the “glass” part of the aesthetic was something more robust (like metal perhaps, ferrofluid is cool).

I wish more apps took a strong stance against it. There is nothing forcing developers to deviate what they think best suits their brand and functionality. Third-party software for serious work (Blender, Musescore) will have nothing to do with the trend, and I’m hoping Apple’s own power tools (Logic Pro, Final Cut) continue to stick with what’s best.

P.S: I would put $50 on Apple walking back most of this design direction by 2028. Unless they ship a touchscreen Macbook, which would be the beginning of the end for fine-grained pointing devices.

Poor data ink ratios

I am an unapologetic Tufte graphics and Magic Ink shill. If software must manifest as pixels, let us make them useful pixels. I dislike attempts to go against this principle for no good reason:

• A forced “technical” aesthetic: Excessive skeuomorphism, borders, visual noise, etc. are real problems, no matter what the nostalgia heads will tell you.
• Plaintext supremacy: Never send a bunch of words to do the job that one well-made graphic could do. Typography is very pretty, but that doesn’t absolve one from trying to do better.

Even choice of words can make a difference here, a subtitle here or long heading there might make for a more “balanced” layout, but it’s often better to just ditch those words completely.

Xanadu

Gwern’s critique exists and is thorough. My own comment is simply that Nelson & Co. were just not very good designers. They were ideologically married to particular features and means of achieving a goal. They talked a big game about “new forms” of media but Xanadu was just a literature nerd’s stubborn ideal for interconnected computers.

Personal software

Yes, the future will have many more barefoot developers with home-cooked apps than we’ve had before. Yes, more internal tools will replace some SaaS products. And yes, there will be more truly personal software.

All of this is not something I’m very excited about. I’d even say I detest this attitude of software as an insular pleasure. The Memex is one of these ideas that has refused to go away, especially now, with the idea of combining AI with a personal knowledge store.

McConaughey gets at something that seems obvious to me but few say. I don’t want a mind aligned to some gestalt of the collective psyche to steer me towards median ideas. I just want to talk to a smarter and better informed version of me who can tell me what i, specifically, would think if i were cleverer and better read.

@loquitur_ponte

I can think of few things less interesting or antisocial. To quote @zetalyrae’s post I Wish People Were More Public, which in turn quotes Dante:

You may say reading in public is performative. I say reading in private is solipsistic. Dante, in De Monarchia, writes:

All men on whom the Higher Nature has stamped the love of truth should especially concern themselves in laboring for posterity, in order that future generations may be enriched by their efforts, as they themselves were made rich by the efforts of generations past. For that man who is imbued with public teachings, but cares not to contribute something to the public good, is far in arrears of his duty, let him be assured; he is, indeed, not “a tree planted by the rivers of water that bringeth forth his fruit in his season,” [Psalms 1:3] but rather a destructive whirlpool, always engulfing, and never giving back what it has devoured.

Make things for groups! For the web! For strangers and enemies! And make these things as open and cross-compatible and publicly as possible.

See also: Self Hosting is selfish

Concierge attitudes

Software that uses words like “automagically” or “in the background” rarely makes for a reliable tool. It is a mistake to start from “users shouldn’t have to do X”, instead of “let’s observe usage and see where the real bottlenecks are”. Tasks can be made easier, batched, before resorting to removing them completely.

One of the best ways to raise the background anxiety level of a system is to have it do things the user can’t see, and present the (oft-broken) final results with no explanation.

Lazy patterns

Things where the decision is made simply by asking “what does everyone else do?” with no concern for differentiating factors. The opposite of design, really. The person on the other end of your software suffers to save you a little extra thinking.

The “above the fold” holy grail

This is part of a general complaint against the landing page cargo cult of “single sentence value proposition”. People can read more than 6 words, they can even read multiple paragraphs if you write them well enough. If you actually know what you’re trying to do, just say that, in as many words as are necessary.

When it comes to CTAs though, there is lots of sense in making sure the main action is easy to take. Put your signup button in the navigation bar, and make it easy to see. But stop expecting people’s first action on opening your site to be “get started”. If that was true, you didn’t need a website in the first place.

Infinite canvases

I have a longer critique of this pattern, but it can be summarized as…

Freeform placement is very useful (nodes & wires, Indesign, moodboards, Powerpoint) but it doesn’t have to be infinite to do so. The freedom to do anything comes at the cost of having to do everything (arranging, cleaning up, sorting) and the infinite expanse makes for an uncertain navigational experience (everyone has their own way of arranging things).

Modals

Don’t steal focus unless completely necessary. I have never felt myself thinking “yes, please block my view of the screen, preventing me from clicking anything else behind your stupid popup confirmation box”.

Don’t ask me to move my mouse away from where it currently is, just to have to move back once I close the popup. Toasts are similarly annoying, and often implemented to be even more so (they disappear after a while so it’s possible for users to miss important messages completely if they happen to look away). But at least the industry has started to realize that.

Bento boxes

I call it “the layout for when you have nothing important to say”.

The lovely thing about linear text is that you’re force to prioritize things for the reader; it’s a marvelous focusing exercise. The neat thing about two columns is how you can play related things off of each other; a dichotomy can have more narrative than just a list, and allows for the evergreen framings of “vs.” and “yes, and…”.

But a box of randomly positioned squares? It has neither narrative nor a history of usage. It is new and bad – the worst kind of bad. It’s not entirely coincidental that Apple was the one to bring them into popular usage, right around the time their marketing became “hey! here’s one big list of small features”. Lazy designers love anti-design, anti-design loves bento boxes.

Sidebars

I understand the temptation to add them, trust me I do. They do a few really useful things:

• They make apps feels like Apps
• Provide a stable visual anchoring point across every page in the app
• They can fit more navigational links

But you can provide other stable reference points, like a floating menu button. Or a breadcrumb trail, which is more useful and explicit.

As for navigation, what percentage of a user’s time is spent in the act of navigating from one page to another? What percentage of that percentage is spent navigating to a place they already know the name of, and could jump to directly using a search?

To quote my friend Manav, “No one uses their computer like this anymore because minimum window sizes are too large”:

Notice how none of those apps have sidebars, leaving more space for content, and as a result they remain usable at small window sizes.

i wish to expand on the “data-ink ratio” idea with the “live pixels ratio”

measured by how much an interactive item on a screen achieves (frequency x power) relative to how much vital space it takes up

@joodalooped

If you think about it, you’ll realize sidebars have a pretty terrible live pixels ratio.

Fuzzy/semantic search

Please pick/tune good fuzzy find algorithms. If I’m looking for “head”, there’s no reason that I should see “padding” in the list of results. It just doesn’t feel right, even if your code says they’re basically the same thing.

Semantic search based on embeddings, done well, can make for powerful retrieval/classification engines. But when dealing with person-sized data, regular search is usually all you need:

And more importantly, the hybrid results sometimes failed the “why on earth did this result show up?” test. For example:

Looking for a recipe I typed “bread” and I got an AI paper with nothing highlighted… oh wait, I see… there’s a paragraph in this AI paper that mentions croissants. Are croissants semantically related to bread?

Opaque semantic matches can sabotage user trust in search results. In a keyword search, if I search a keyword, I either get results that contain those words or I don’t. It’s clear. With semantic search, you sometimes get results that are “kind of” related to your query, but without any obvious indication why. That can be frustrating.

Pao Ramen, Local-first Search

Digital gardens

I have seen very, very few of them that didn’t make for a painful experience, one of them is Szymon Kaliski’s notes. Notice that it contains a complete index of every note, ordered by time, and with descriptive titles. He has also taken some care to only publish notes that are worth reading.

The “digital garden” as a design pattern usually does the opposite. They exist to provide authors with a dumping ground for unorganized information. Which is all well and good if you’re said lazy author, but the lack of grounding, order, ranking or quality control makes for a fatiguing reading experience. Studies have consistently found that people are much better at memorizing information when it’s presented in narrative form. “Atomic notes” encourage putting tiny bits of content at each URL, forcing clunky jumps through half-completed personal notes.

Now, the lovely thing about the web is that you’re free to do as you like, my demands are mere suggestions in practice. But if the browser is a printing press, I think it deserves a healthy publishing mindset.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

A sense of chronic unease or acute worry experienced while interacting with a software system.

This post exists because I’ve recently realized that a good 70% of my application development work is based around minimizing this feeling (a rather quaint concern in a world of “agent-first software”, I admit). If I have to use something I’ve made, I can’t live with it being subtly painful.

While a good test of a system’s value proposition is how much anxiety people will deal with to continue using the service, I would much prefer to never be the subject of such a test.

It’s possible that my sensitivity is a unique personal symptom of screen-induced ADHD. But it feels more true that I am just defining and describing a feeling that most people share. In any case, I believe that noticing and focusing on this emotion does contribute to better design.

The definition itself, being quite simple (tautological, even), doesn’t convey anything useful. That’s what the rest of this page is for; an attempt to describe it’s facets through example:

Notifications

The little red dot has the most ridiculous size-to-effect ratio of any element we’ve ever come up with. This should have led to careful usage, instead it has meant alerts everywhere, for everything.

The dots don’t even mean anything specific! Users have primitive levels of control over what becomes a notification, they’re freely abused for marketing nonsense (or worse), unread badges don’t ensure you’ve actually dealt with the message, etc. Every dot looks the same, and could mean a dozen different things.

Within apps, the least we could have done is a single inbox for better triage, but most apps just show multiple dots all over their interface instead.

Heaviness

It comes in two forms:

1. Latency: Loading spinners, a perceptible gap between a click and the resulting action, a frozen interface – all of these are an unsettling game of “guess what happens next?” If a page scrolls slower than your mouse wheel does, it feels like being stuck in molasses.

One underrated aspect of network-based latency is that the delay could be anywhere between imperceptible and…forever. Each click is a painful roulette game.

It is harder to trust the system as a whole when parts of it will randomly let you down. The trust that follows from consistent speed is why the best software is fast, and vice versa.

2. Visual noise: To the degree that software is about information design, it ought to guide the eye, and thus make it easy to skim each screen. Dividers, colors, icons, and density are all tools to make this easier, but are easily overused to achieve the opposite effect. And a poor data ink-ratio is almost as bad as…

Uncertainty

Visual heaviness cannot be solved by naive minimalism. Look at this coffee machine panel (source, worth reading) for example: it is minimal but it hides information from you.

An absence of information asks you to fill in the gaps, to memorize things. Ambiguity leads to hesitance, by way of anxiety.

In many apps, it makes for a series of nervous back-and-forth jumps between multiple screens. This is what makes hyperlinks dangerous, because they are a tool for indirection. Transclusion is another offender, requiring users to think about everything that might be affected by a change to a source document.

Non-standard behaviour

Interfaces deserve to be innovated on. But only when existing patterns fall short, and only while respecting the standards of the operating system/browser.

Don’t break URL navigation, tabbing through items, common shortcut => action mappings, CMD + F, etc. just because you can. Your novel patterns will not do that much better than the most tried and true defaults. (Unfortunately, so many applications break those rules that even relying on the defaults starts to feel anxious)

Even when adding them, a naive way would be to use them for infrequent or otherwise unpopular sections of the interface. But this is doubly bad. When users finally decide to do an action they don’t normally do, they will be confronted by a more-alien-than-usual interface. They have had no time to practice, and just want to get it over with.

Instead, use novel patterns for more common actions, for two reasons:

1. A core action is used often, giving it the chance to graduate to the comfortable familiarity of muscle memory.
2. It forces you and your users to use the action often enough to receive feedback about it’s effectiveness. Too many bad ideas are left alive through hiding.

Powerlessness

For the longest time, algorithms have taken (deserved) flak for this, but it doesn’t stop at there. Most systems have things that they will just do, whether you approve or not.

• Crash, and lose your work
• Stop working in the absence of perfect internet connectivity
• Auto-magically “fix” problems through a misguided concierge attitude
• Silently restart in the background, losing your context

When it happens, it might look like a specific moment of frustration. But from the first time onwards it sets in motion a permanent background discomfort. Users will spend as little time as they can in this environment of anxiety, but be unable to point out why. They will use your software defensively — writing drafts outside the app and only pasting in when ready, spam-clicking “Save” before leaving a page.

I pay Bear $15/year to give me Markdown notes with sane conflict resolution (choose between the two conflicting version) instead of Apple Notes’ terrible approach (brutally overwrite). Once bitten, willing to pay to never be bitten again.

Change

Memorization, once achieved, is a form of lightness. It frees you from looking. It enables fluency, which is the opposite of anxious usage.

So when things are rearranged, lost, or otherwise modified, the pain is felt most by the power users. They are deprived of their shortcuts, their buttons are moved out of familiar tap territory. Back to square one, this time with their trust burned. Once bitten, forever shy.

Furthermore, veteran users of software can smell the desperation in every rebrand. They can sense the upcoming product pivot that finally casts their specific needs aside.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

Calibration cases are business narratives that teach you to see. A calibration case is simple: it is merely a narrative of a specific business situation. What makes calibration cases special is how they are meant to be consumed: they are organised in sequence according to concept, so you are able to do rapid case comparisons across the same concept. This exercise helps you calibrate your expectations of the business concept in question.

If you haven’t heard me rant about how much of interface design is done by people saying insightful/stupid-sounding shibboleths, you can follow my Twitter.

Maybe they have their reasons to be so non-specific, but it means that most advice is scarcely better than personal opinion. “Form follows function. Make apps fun again! Make apps look old again!” I can’t recommend that to learn from.

Instead, I used to say something like “just look at lots of good designs and use many apps” to people who asked me for a how-to guide or direction of study. Because reading Refactoring UI can only give you a few simple rules, that can nearly always be safely applied. How do you become good enough to learn/break those rules?

I now think the I wasn’t far off with my original answer, you have to gather a corpus of cases in your head. Luckily there is more than one way to do this for design:

• Make something and watch someone use it
• Find good design writeups (like this one), but those are very rare
• Spend time using apps that are considered to be good
• Read someone else’s experience with specific software

I believe that the “organised in sequence according to concept” part of the process can be done without, because design doesn’t really have that many distinct concepts. [Typography], spacing, hierarchy, and content is the majority of what I do.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

The chronological weblog won, and every site twists to fit it’s structure, with information architecture and reader experience suffering for it. Things don’t have to be this way.

As a push in the right direction, here are my demands suggestions:

Don’t paginate

Moving information out of view creates more interface anxiety than it’s worth. Unless you have a few hundred posts, there’s no reason to not list them all in one page. (And even if you do, a long list works fine anyway). It allows the browser’s CMD + F search to work as a full-site search.

One of my favourite examples of laying out a small collection of essays:

Having your page be a long list of post titles and descriptions has the useful effect of forcing you to pick good titles, for your reader’s sake. Make it easier for them to decide which links to click on.

Prefer one level of navigation

Navigation levels mean something. One level means “you can see everything by opening these 5 links”, and two levels means “you might need to visit 5 * N links to see everything” where N is an unknown number – asking the user to do much more work to truly browse a whole site. Don’t do that, choose to have a single /blog list page instead of multiple /blog/year pages.

The only thing worse than two or more levels of navigation is no navigation. You can find that particular horror in the recent trend of “digital gardens”, where the user crawls their way through a site clicking on obfuscated links in incomplete pages and placeholder posts. Thanks a lot, Obsidian Publish & Co. 😒

Avoid thumbnail images

A relic of the nonsense SEO recommendations of the 2010s. Think back to the last great essay/post/stack you read and realise that you didn’t care about the thumbnail or cover image at all. AI-generated ones look especially terrible unless you take great care to make them consistent and styled to match your publication.

Even for social media cards I recommend just having one image that represents your site, and let it show up for all your posts, it’s perfectly alright. If you really want something different for each post, add a nicer view of your post title, like so:

Note: I must confess that I do like blogs where the thumbnail images are photos taken by the author themselves. They look really nice, even if they’re not particularly relevant to the content of the post.

Make categorisation useful

The traditional blog is ordered by time, which is a decent way to do things when the content consists of personal updates, but a poor experience if you’re writing more evergreen and/or domain-specific content. Instead, prefer organisation that complements your content and prolificacy (or lack thereof).

Topic

Don’t make topics too granular to start with (a simple “culture” section is better than a handful of sub-categorical tags). Only add them once you find that there are in fact multiple posts that fall under a tag. Few things are more disappointing for a reader than clicking on a tag and seeing a grand total of 2 posts.

Quality

There are two measures of this that I like:

• Most popular: The greatest hits and most shared posts. What was well-liked will probably still be worth reading.
• Personal favourites: A space to surface content you think is somewhat underrated or worth checking out (perhaps due to how different they are from your regular fare).

Length

It’s somewhat useful to give readers an expectation of how long a particular piece is, so that they can adjust their actions accordingly. Depending on length of individual posts and the site-wide average, they might:

• Save things to a read-it-later service
• Browse the whole site in one sitting
• Open certain posts in new tabs
• Decide to subscribe to your RSS feed

Use more content formats

My site has 3 main ones, which is what I recommend for most people.

• Lists: Evergreen collections that I update over time.
• Guides: Pieces of some heft, where I speak with some authority.
• Riffs: Short temporal posts, closest to the classic blog.

There are also Notebooks, but those are closer to “basket of links and excerpts that might lead to proper posts”, and not considered real publications.

But you can also have special sections for a bookshelf (with reviews?), media galleries, blogchains, etc. etc.

Use short URLs, if you can afford to

There’s nothing wrong with having your posts live at domain.com/posts/2025-12-25/post-url but there’s something really nice about being able to share URLs that look as neat as domain.com/post-url by quickly typing them out.

Let things feel like paper

Don’t scrolljack, don’t animate too much, don’t use WYSIWYG slop (if you can help it). Try to avoid Javascript-based nonsense (every time I see Next.js being used for a personal site, I say a silent prayer for the author’s soul), let webpages load like webpages.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

But if they are going to do it, I have a humble suggestion: lighten the icons so that the text is emphasized instead.

When lightened, the visual stating point shifts to the text itself, with the icon being demoted to an ornament instead of content. Which is what they always were – providing very little information compared to just reading the text. Especially when there are multiple densely packed icons that all look the same!.

Which leads me into some grumpy commentary re. Apple’s design failings of late. They have gone too far down the path of “ornament”, which is terrible way to approach something as fundamental as a desktop OS.

Dye had no background in user interface design — he came from a brand and print advertising background. Before joining Apple, he was design director for the fashion brand Kate Spade, and before that worked on branding for the ad agency Ogilvy.

A Bad Dye Job

Print is not a terrible attitude to bring to software (especially websites!), but it needs to be a tool applied in the latter stages of the process, not the starting point for “this is our new look”. Screens have flux, they’re more than paper.

The guidelines could have been “only add icons that have an unambiguous meaning, to items that would benefit from standing out in a list of actions”. Not that you need icons to do this, bold text would work just as well, but we’re being generous here.

But that’s not what they did. The idea is clearly just “ADD PRETTY PICTURES NEXT TO WORDS, THANK YOU!”. A case of graphic designer envy if I’ve ever seen one.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

1. Being the simplest ZUI: They used to be all the rage, these zoomable user interfaces, back when larger screens were the more popular device size. They let you fit large things into the viewport (provided that the smallest meaningful unit does actually fit into the viewport), they let you see everything at once, from far away. Every modern map app is a ZUI, and the interface is a perfect fit for them.

2. Workflows with lightweight branches: You’ll hear people refer to this kind of usage as “non-linear”, and make claims about semantic spaces and linking. I’m not a huge fan of those ideas, and instead believe that the main value comes from providing intuitive branching, and the speed of iteration that comes from exploring options through quick duplicating and parallel editing. In some canvases, this lets you see the history of the work in a satisfying way. But if you get into serious branching usage it often devolves into visual chaos. More on that later.

3. Freeform element placement: One could argue that this is nothing special, since diagram tools have been around forever (the streets will never forget MS Paint, and consultants will never escape Powerpoint). But being able to place things where you want them is a hard problem in the world of multiple screen sizes, so the canvas is one of the few places that offers that capability anymore.

Infinite canvases and me

I first encountered serious usage in Excalidraw, followed by Muse, Figma, then tldraw. The popular usage pattern for all of them is “design tool”, and ranges between rough sketches to exact mockups. When I started work on my own app, the goal was quite different.

My initial desire was fairly straightforward: I wanted a digital workbench to keep track of multiple projects/artifacts that was better than a simple list (where most items would be pushed below the fold) and with a better interface than a spreadsheet. At the time, I used Scapple, which was near-perfect apart from the fact that it didn’t have a web app.

So I decided to re-make Scapple, but in the browser. Even going so far as to name my project Scrapple to make the lineage obvious. Doing so would require building an offline-first canvas with rich text elements, visual customization of said elements, arrows, and simple media handling.

As I prototyped and used the thing, I started to see that many of those features were not really in service of the initial goal of 2D organiser, and what I was making was closer to a publishing tool. Soon enough, I realised that I actually cared more about the publishing part (this is now part of my general attitude towards design: encouraging more public-facing things).

But the majority of infinite canvas apps are built with a single user in mind; usually yet another insular notes app. Good publishing tools ought to enforce norms that readers can learn easily, and provide constraints that the author must work within. The canvas…does not do that.

“fast creative iteration….the generated work is never the final product” is almost the opposite of a publishing tool.

All of which is to say, I realised that the canvas was the wrong medium for my goals, which is why I switched to making a multi-column rich text editor instead. It satisfies both my “have multiple lists on the screen” and “make a webpage builder” desires, while being much more amenable to power user patterns like keyboard-first usage. Thus, Scatterpad was born.

Also, had I stuck with the canvas, most of my effort would have ended up equal to “tldraw but with rich text”, a feature which they added less than two years later.

But the outcome of all this wandering in canvas land is that I have a bunch of thoughts about them, not as many as Mr. Nulls or Jess, but a fair number nonetheless.

The problems, and a few speculative suggestions

Fair warning, almost any solution that is merely suggested instead of actually being implemented somewhere will likely suffer from “too clever by half syndrome”. Aspirational concepts which only show their flaws in implementation.

They invite messes

One of the few design questions I care about, especially w.r.t software, is “what behaviour does this thing encourage?”. With canvases, it seems to be: messiness and no cleaning up until its too late.

Because they’re such a singular medium, almost nothing can go in or out in a meaningful way, so you’re encouraged to put everything into a single board. And the resulting mess forces you to hold the system in your head while you’re using it. Which isn’t something I like my interfaces to do.

One of the solutions I’d like to see tried is a windowing system to have multiple canvases open at the same time, being able to drag and drop to transfer things across them. Or secondary spaces like sidebars, panes, and shelves, so less is done on the canvas. If you must have everything in one place, at least provide focusing patterns, like hiding and showing non-essential elements as appropriate.

To be even more prescriptive, perhaps a max item count per page to encourage using pages for a single, specific artifact. Like birthday cards.

Side note: I’ve always found it funny how Figma’s engineering team works on incredible technical solutions to make really large pages work, and each improvement just encourages users to make pages even larger.

The hell of eternal adjustments

Being able to place things where you want them includes paying the price of having to do all the placing yourself. Including, but not limited to:

• Making space for new items
• Creating and maintaining groups
• Aligning items relative to each other
• Spacing things out equally (especially when nested)

Some of these problems have half-decent solutions. Like auto-distribute to space things equidistantly, or showing alignment lines while dragging. But these are ways to make the positioning work easier, not actually getting rid of the work itself.

Muse, for one, has a neat solution for the text editing experience, they call them “text blocks” and they work by putting each paragraph into it’s own block within a vertical list. So you can drag items out and slot them into other places, while ensuring alignment isn’t a manual process.

Oh, tldraw’s arrows are amazing though. We need more stuff like them. Amelia Wattenberger has a few ideas that might be worth trying.

Mobile-unfriendliness

On narrow screens, there are only two choices for UI: become a list, or become unusable. It’s a tragic constraint, but a strict one. Canvases definitely do not fit into lists. On the very devices built for pinching, swiping, and tapping, the canvas is decidedly a second-class citizen.

We can try to tame them, but any rule (e.g. list items in order from top-left to bottom-right) breaks due to the variety of idiosyncratic usage patterns. It defeats the point, really.

They do not situate

Again, they’re made to be non-linear, which means there’s no real start and end points standardised by the format. If you don’t do a ton of organisational work, it turns into a mess that makes sense to nobody but yourself from <10 minutes ago.

Even if you do organise, it’s fairly arbitrary. Because an infinite canvas has no borders, it’s not like your desk anymore. There is no “spatial memory” to be leaned on because there is no enforced permanence at all. Things can be in a completely different location the next time you look for them, nothing’s going to stop you from shifting things around.

Yes, you can carve out named zones, or hope your tool provides a grouping primitive (like line dividers, or stacks), that’s a good start. You could even be able to create deep links to said zones on your canvas to share specific things with people without asking them to navigate the chaos. But the chaos still exists.

Again, Muse has some good ideas here:

• Boards are anchored in the upper-left
• The board is always the size of its content
• Prevent scrolling to completely empty space
• They don’t allow zooming, to maintain a single scale level

The interaction mechanics are meh

Panning is natural on a touchscreen, bearable with a trackpad, painful with a mouse. Zooming follows a similar order, but the scroll wheel is perhaps better than the trackpad. But in any case, the order of those lists shows how the most productivity-focused devices have the least affordances for canvas navigation.

Which is funny, because the fine-grained pointers of those devices are more suited to item manipulation than clumsy fingers (where dragging and scrolling are the same gesture) on touch devices.

Point being, there just isn’t an interaction paradigm that is optimised for both parts of the canvas’ demands. Compared to our regular grid and list-based interfaces, “it’s not as good for drunk users”.

But if you’re going to make one anyway…

Think about if something else would serve your needs better than a literal canvas. For me it was multi-columns, I’d encourage you to find something like that too.

If you still want to do a canvas, think again. Are you absolutely sure you can’t come up with a different thing? No? Alright then.

Use tldraw.

Despite their recent license change for tldraw v4.0 onwards, they’re as good as it gets. I plan to stick with using v3 myself when I eventually add a diagram tool to Scatterpad.

And if you really want to make one from scratch, here’s some stuff that I wished I’d read before I started doing things in a “I’ll figure it out” way. Oh, also, if your canvas doesn’t need rotation, that simplifies many of the interactions.

• Creating a Zoom UI, and every other post on Steve’s blog
• Dynamically rotating mouse cursors, because why not?
• Pointer handling
• The tldraw source code and docs
• Linear algebra/trigonometry (same thing)

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

• Sketch new interface ideas in tldraw

• Prune my unused notes in Bear/Craft, or even the draft posts for this site.

• Binge-read the classic DC comic series on Read Comics Online.

• Go lounge around at a friend’s place.

• Talk to Gemini 3.1 Pro about sync engine architectures.

• Go through the designs on Dead Simple Sites to see what simple ways of laying out text I can make possible in the Scatterpad editor.

• Rewrite my todo lists to clean up/reprioritise them.

• Go through the tabs in my reading backlog (which is a personal Telegram channel).

• Emptying my Twitter bookmarks. Which means either making use of the information in those tweets, quotetweeting them, and/or adding them here, before unbookmarking them in the app.

• Tweak the CSS or do a minor refactor for one of my apps. Lately, that app has been Scatterpad.

• Put on a random episode from a podcast/channel, based purely on the title and person being interviewed. Usual suspects: localfirst.fm, Dialectic, Manifold, Ryan Carniato’s streams

• Doomscroll Twitter, sometimes Bluesky.

• Draw up plans for a new microsite, or think about ways to improve an existing one.

• Browse the Commoncog Forum.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

Wait a minute… did I say v6?

Yes, there were two versions after the site you’re looking at now, that I built but never started using because I realised I liked what I already had. Which is why all I did was launch version 4.5 of the current design. But you can see those failed redesigns at v5 and v6 if you like. They’re not terrible.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

But I always run into the following annoyances as soon as more than one page is involved:

• Any shared components (like navigation bars and footers) need to be manually duplicated across pages manually.
• I would often forget to update the <meta> tags (page title, social media cards) for each page to the correct values.
• How does one add an RSS feed? By hand??
• After one too many <p> tags I would start to miss the ability to write in Markdown.
• I’d have to go find a CSS reset and typography stylesheet from one of my previous projects.

I’ve been told this is the moment when people turn to the dark side, and write their own static site generator — one that finally has the perfect, simple feature set and intuitive syntax. Luckily for all of us, I decided to double down on the site generator I already use: Hugo

So I put together Hugoloop, a starter that uses the simplest possible site structure for a Hugo site, and contains all the things mentioned in the list above. And everything that one might need is linked to in the README. To quote it’s introduction:

…the amount of Hugo-specific detail you need to understand is kept to a minimum. Your experience should feel as close to “edit some HTML, write some Markdown” as possible.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

Good list here.

Fractional indexing

Found through Evan Wallace’s blog post, and used a naive integer-based version for the v0.5 of Scatterpad. The sorting things on a canvas video from tldraw provides a more robust algorithm, using lexographic order instead of infinitely dividing numbers.

I personally use the jittered-fractional-indexing library, which in turn forks the original from the lovely folks at Rocicorp.

Hashing

The first time this really clicked for me was when I saw a hash of a schema being used to invalidate an old store. A hash is a way to give a name to something after the fact!

Signals

Encountered through Signia, and from then on I wrote all my apps with these as the foundation whenever possible. Solid’s component model (or should I say, lack of one) is probably the best example of the ideas in action.

Idempotency

https://lightfoot.dev/why-arent-you-idempotent/

Binary search

https://drmaciver.substack.com/p/how-to-find-things-an-intro-to-binary

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

The design will probably change slightly in the future; but the more interesting questions are around what parts of the conversation I choose to display. Do I include random messages above/below the relevant slice? Do I preserve typos and “hmmm"s and “huh"s? How should privacy-preservation work?

Here’s an apt example (w/ Anjali):

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

Gift exchange flip the Lemon Market problem upside down, because of the particular social rules around gift-giving and celebrating intent. Gift culture has sacred protocol: if you’re offered a gift, you must accept the gift, and you must reciprocate either in return or by paying it forward. If I offer you a gift, saying, “Here is all this information, promise and potential”, then by the rules of gift exchange, you are obligated to take it seriously, and you are obligated to offer some potential in return, for a window of time.

And this tweet:

I’ve talked to a lot of ambitious elders about this and the general shape of the answer i found was that those who were most fulfilled were those who gave back to others. they’re proud of the difference they made to people, not the artifacts they produced or awards they won

@visakanv

I might eventually collect enough material to turn this into it’s own page someday, but for now it exists because it’s a good summary of how I try to live.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

The Writing page was the only one that really changed to accomplish this. It turned into a dense 2-column page with sorting by topic instead of post type. The other pages only received small layout touch ups and tiny typography fixes. Oh, and the dark mode blue got darker. But that was all.

Edit: I also added a new “chats” format right before I shipped this version.

Which is good! This website has been through 4 designs in total, and this latest version has lasted as long as all the others combined. Not that I haven’t tried to replace it. v5 and v6 redesigns happened in the background, but turned out to not be worth shipping. The current version is, in fact, close to perfect. Who would have thought?

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

But you’re welcome to do it for fun (and share them!).

Metadata

Do we throw out metadata, then?

Of course not. Metadata can be quite useful, if taken with a sufficiently large pinch of salt. The meta-utopia will never come into being, but metadata is often a good means of making rough assumptions about the information that floats through the Internet.

Certain kinds of implicit metadata is awfully useful, in fact. Google exploits metadata about the structure of the World Wide Web: by examining the number of links pointing at a page (and the number of links pointing at each linker), Google can derive statistics about the number of Web-authors who believe that that page is important enough to link to, and hence make extremely reliable guesses about how reputable the information on that page is.

This sort of observational metadata is far more reliable than the stuff that human beings create for the purposes of having their documents found. It cuts through the marketing bullshit, the self-delusion, and the vocabulary collisions.

Taken more broadly, this kind of metadata can be thought of as a pedigree: who thinks that this document is valuable? How closely correlated have this person’s value judgments been with mine in times gone by? This kind of implicit endorsement of information is a far better candidate for an information-retrieval panacea than all the world’s schema combined.

Cory Doctorow, Metacrap: Putting the torch to seven straw-men of the meta-utopia

Metaphor

In fact, metaphors were central to the XP methodology. A metaphor “helps everyone on the project understand the basic elements and their relationships.” And they are especially useful for high-level design:

Architecture is just as important in XP projects as it is in any software project. Part of the architecture is captured by the system metaphor. If you have a good metaphor in place, everyone on the team can tell about how the system as a whole works.

Instead of exhaustive design, Beck wanted just enough design. His system metaphor was something that could be explained in a moment, and was robust to change. It was a pane of frosted glass, a locus.

Zach Tellman, the death of the architect

processes vs. things

We challenge the widespread presumption that matter and objects are ontologically prior to processes and events, and also the less widespread but increasingly popular view that processes and events are ontologically prior to matter and objects. Instead we advance a third view according to which each of these pairs of categories is ontologically dependent on the other. In particular, taking a cue from an ontology of devices, we identify the object as an interface between those processes which are internal to it and those which are external to it and which it may be said to enact, thereby linking objects intrinsically to the processes in which they are involved as well as providing a more powerful determinant of object identity than more traditional, non-dynamic criteria based on demarcation from the environment. The internal processes are themselves external processes in relation to the components of the object which enact them, leading to a potentially open-ended recursive decomposition of both objects and processes in a complex web of mutual interdependency.

Antony Galton and Riichiro Mizoguchi. The Water Falls but the Waterfall does not Fall: New perspectives on Objects, Processes and Events

Whereas Humans view computers as tools below them to which they give orders and that do their bidding, Houyhnhnms view computing as an interaction within a system around them that extends their consciousness. Humans articulate their plans primarily in terms of things: the logical and physical devices they build (sometimes including tools to make more tools), in the lower realms of software and hardware. Houyhnhnms weave their conversations foremost in terms of processes: the interactions they partake in, that they attempt to automate (including these conversations themselves), which always involves wetware first. In short, Humans have computer systems, Houyhnhnms have computing systems.

François-René Rideau, Chapter 1: The Way Houyhnhnms Compute

alt-systems

• Johnny Decimal

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

The goal was to keep initial setup as straightforward as possible (you should be able to run this without creating a local copy of the code), and I plan to make all future features work the same way. There’s tension between minimalism and demoing a full-featured app though.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

Built with Hono and Drizzle, hosted on Cloudflare Workers with their D1 database acting as the storage layer. To start with it just has a simple 6 message context window, but I have a few more ideas that I want to try later.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

Sarah Hannan

The Water Falls but the Waterfall does not Fall: New perspectives on Objects, Processes and Events

Antony Galton and Riichiro Mizoguchi

DBSP: Automatic Incremental View Maintenance for Rich Query Languages

Mihai Budiu, Tej Chajed, Frank McSherry, Leonid Ryzhyk, and Val Tannen

DIGITAL TYPOGRAPHY

Donald Knuth

Categorizing Variants of Goodhart’s Law

David Manheim, Scott Garrabrant

Strong Inference

John R. Platt

Expressing Temporality in Graphical User Interface

Taner Olcay

What does it mean to represent? Mental representations as falsifiable memory patterns

Eloy Parra-Barrero and Yulia Sandamirskaya

OnePassword Security Design

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

• design is the second derivative of just plain doing stuff
• Christopher Alexander: A Primer

A computer is a general-purpose machine: it can do pretty much anything — or at least, software could be created to make it do pretty much anything. Therefore, in theory, a user “entering” an application for the first time must assume that they can do anything in it but then learn very quickly where the application’s limits are. Thus, making software useable is as much about designing what can not be done as it is about designing how to do things.

Christoph Locher, Screen As Room: An Architectural Perspective on User Interfaces

The practice of Design is commonly considered to have emerged during the Industrial Revolution. (p. 24) During this era, the Designer supplanted the craftsperson, whose role was the “hand-making of furniture, tools, pottery or buildings, according to traditional methods and forms”. (p. 25) The craftsperson does not develop new forms, but inherits the ones that have evolved over a long time of subtle modifications. Through the Industrial Revolution the division of labor was introduced. In this process the Designer holds a special role: They are now the only one to consider the item as a whole.

Christoph Locher, Notes from Glenn Parsons’ The Philosophy of Design

Have you been forced to accept compromises?
I don’t remember ever being forced to accept compromises but I have willingly accepted constraints.

What do you feel is the primary condition for the practice of Design and for its propagation?
A recognition of need.

Charles Eames, The Definition of Design

Let me read you The Road to Hell, a series of questions that become more difficulty the deeper you go. The first couple are easy, would you—

1. Design a package to look larger on the shelf?
2. Do an ad for a slow-moving, boring film to make it seem like a lighthearted comedy?
3. Design a crest for a new vineyard to suggest that it’s been in business for a long time?
4. Design a jacket for a book whose sexual content you find personally repellent?
5. Design an advertising campaign for a company with a history of known discrimination in minority hiring?
6. Design a package for a cereal aimed at children, which has low nutritional value and high sugar content?
7. Design a line of T-shirts for a manufacturer who employs child labor?
8. Design a promotion for a diet product that you know doesn’t work?
9. Design an ad for a political candidate whose policies you believe would be harmful to the general public?
10. Design a brochure piece for an SUV that turned over more frequently than average in emergency conditions and caused the death of 150 people?
11. Design an ad for a product whose continued use might cause the user’s death?

Ambiguity & Truth

Process

• Everything that turned out well in my life followed the same design process
• Copying (is the way design works)

Draft, then polish. When you draft, it is still crucial to get right the key details. The utmost is to stay faithful to the meaning. At the end of the day, both design and writing are ways to communicate. For communication clarity is important, and there are rules to guarantee it. Unclear design, as well as unclear speech, can become dangerous.

Designer as Writer

Practice

• The Ink-data ratio (tables)
• Frank Rausch – Good Typography, Better Apps
• Magic Ink
• Web Design is 95% Typography

I was talking to one usability expert and he was describing how they measure task completion. Did the user press the buttons in the right order? Their ideal app resulted in new users completing tasks 100% of the time. This isn’t exploratory learning. You need to be able to fail and explore the possibility space of a particular tool. Through repeated failure and success, users build up robust skills that can be applied successfully in a wide variety of situations.

Users are not dimwitted Users are not dimwitted monkeys They are intelligent human beings Sure there are monkeys. They are intelligent human beings. Sure, there are limitations, but for the most part we are wired to be problem solvers. Our brains are flooded with lovely chemicals like dopamine and endorphins when we figure something out on our own. That’s fun at it’s heart: Our brains telling us that we grokked something interesting. When you build applications that let users be smart, they love you for it. The secret to good game design is simple. Set up situations where there is a problem that must be solved and let the user solve it. Give them subtle clue, but don’t take away that aha moment.

Building a Princess Saving App

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

For the very fair price of $750 American, it comes with excellent P90s, stainless steel frets, a carbon fiber reinforced and satin-finish neck, and lovely build quality everywhere else.

If that wasn’t enough, Yamaha also ships it with Elixir Nanoweb strings and a well-padded soft case. Good stuff!

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

But it was simple enough for me to use when I first started out making websites, when I didn’t know what a config file did, or what a server was. So there’s that.

Note: I’ve created a really minimal Hugo starter site example, the most barebones example of how I structure my sites.

What makes it worth learning + using? For me the answer is three-fold:

1. It doesn’t break: Once have the binary downloaded, you’ll never have to install anything else again, it’s all self-contained. It’s also “finished software”, you can stick to your current version and never upgrade.

   When I make sites for clients, I don’t want them to deal with fix broken stuff months down the line, the fewer moving parts the better. Having just one part? Bliss.

2. Ease-of-use: Once you’ve done the hard work of creating the site, it’s really simple for other people to use. They clone the repo, install Hugo, run hugo serve and…that’s it. No annoying ’npm install’ commands, or running a database process. “i’m so scared of package managers and build systems”

3. It’s light: I say this often, but it’s so nice to work with something that’s just a simple binary. No plugin downloads or package upgrades, no need for a runtime environment, no slow build times, and the Hugo server’s hot reloading is fast.

I’m not going to try to teach you how to use Hugo in this post, I’ll only recommend this tutorial, Googling stuff when you’re stuck, and this guide. Heck, if you run into a problem, feel free to DM me and I’ll help you if I can.

Instead, this post is about documenting what is best described as the “folk practices” around how I work with Hugo.

The command line

The only command I run is “hugo server”. It’s what starts up the site preview that I can use for both writing and development. One of my favourite things about Hugo is that, unlike most other generators, this command doesn’t create an output directory each time (which clutters up my file searches), it just serves pages from memory.

Edit: As of February 2024, this is no longer true. You need to pass the –renderToMemory flag to “hugo serve” in order to avoid writing to disk.

To create a new post I just make a new .md file myself in my text editor and save it to the relevant folder.

Even creating a new site is a process of simply copying over one of my previous sites, and editing the template files in there.

Site structure

I don’t use themes, none of my sites even have a “themes” directory. I don’t want to work with or depend on someone else’s code.

I store my templates and static files directly in the root, so my site structure looks like this.

This is all you need. Really. Even the “resources” folder is empty, it’s just generated by Hugo.

Content

Try to only use the bare minimum frontmatter fields. For me these are title, description, and date. I prefer YAML over TOML.

Write all your posts in Markdown, dropping down to HTML when necessary. Hugo let’s you use them within the same file if you have unsafe set to true in your config file. Don’t use shortcodes, these are generator-specific constructs that reduce portability.

Processing

Hugo does provide a bunch of processing functionality, but I don’t use any of it. Stylesheets are plain CSS, images are optimised before I add them, not during the build step.

Deployment

All my static sites are deployed on Netlify, they have a very generous free tier for static sites. It rebuilds the site whenever I push to the Github repo, and handles builds according to a netlify.config file. This is what mine looks like:

baseURL = "/"

[[headers]]
  for = "/*"
    [headers.values]
      Access-Control-Allow-Origin = "*"

[build]
  command = "hugo"
  publish = "public"

[build.environment]
  HUGO_VERSION = "0.105.0"

[[redirects]]
  from = "/*"
  to = "/404.html"
  status = 404

[[headers]]
  for = "/*"
    [headers.values]
    Cache-Control = "public, immutable, max-age=900"

[[headers]]
  for = "/fonts/*"
    [headers.values]
    Cache-Control = "public, immutable, max-age=31536000"

[[headers]]
  for = "/css/*"
    [headers.values]
    Cache-Control = "public, must-revalidate, max-age=300000"
    ETag = "unique_value"

[[headers]]
  for = "/media/*"
    [headers.values]
    Cache-Control = "public, immutable, max-age=31536000"

Power tools

Render hooks

Hugo lets you hook into the generation process for certain Markdown elements, so that you can customise the output HTML. At the moment, there are hooks available for headings, links, images, and code blocks.

Here’s an example of using the link render hook (/layouts/_default/_markup/render-link.html) to set only external links to open in a new tab.

<a href="{{ .Destination | safeURL }}"{{ with .Title}} title="{{ . }}"{{ end }}{{ if strings.HasPrefix .Destination "http" }} target="_blank" class="external-link" {{ end }}>{{ .Text | safeHTML }}</a>

Forum

I’ve found most answers to my questions from Googling “how to do X in hugo” and following one of the links to a similar question Hugo forum. Many answers come directly from the creator and chief maintainers.

Template functions

There are a ton of useful functions and methods in Hugo’s templating language. It isn’t a pretty one, nor is it particularly beginner-friendly (it uses Polish notation) but it can do way more than any other templating language I’ve used.

Simple example of fetching pages from the “guides” section of my site.

{{ range where .Site.RegularPages "Section" "guides" }}
    <p>
        <a href="{{ .Permalink }}"> {{ .Title }} </a>
    </p>
{{ end }}

In-built functionality

There’s a syntax highlighter, a bunch of processing functions, the ability to add classes to Markdown elements with Markdown attributes, templates for RSS feeds, and help for multi-lingual sites.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

Objective Development

Many Tricks

Low Tech Guys

Panic

retina studio

Micropixels

Sindre Sorhus

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

Ideas and implementations that I arrived at independently. Since it is impossible to claim true novelty, I can only make a softer claim of newness: when I came up with these things, I hadn’t seen them before.

Messages to accompany phone calls

Some calls are “would be nice if you answered”, while some are “PLEASE PICK UP”. Phone calls should contain a small text message that shows up on the receiver’s UI, as a way to communicate urgency.

When: circa 2022

A foolproof method for hand-based fly-killing

Sneak up to the fly, and smash your palms together around 3 inches above the fly. It will fly right into your hands.

When: Sometime in middle school

Horizontal table of contents

Viewable at nickarner.com/books. Saves lots of space for long ToCs in a single-column layout while still providing a navigable summary of the post.

When: August 2023

Monthly shareholder letters to friends

Write the most official-sounding monthly update possible. Add stats and figures and challenges. Anybody invested in you in any way deserves a shareholder letter.

When: June 2024

Font-switcher for a personal website

As seen in the top-left corner of this site.

When: January 2024

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

Go play Nand2Tetris. It’s a fun game, doesn’t need you to learn any syntax, and gives you the assurance that you computers are, in fact, built on very understandable basic components.

Canon

• Hexing the Technical Interview
• E. W. Dijkstra Archive
• What is Code?
• Modern Functional Programming: Part 2
• SomethingNew
• Ask HN: What are some great posts or articles about history of computing?

Fundamentals

• The Missing Semester of Your CS Education
• Putting the “You” in CPU
• The Elements of Computing Systems, and the Nand2Tetris game
• The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets
• Data Compression Explained
• The Git Parable
• Teach Debugging
• Computer Science for The Busy Developer
• What To Know Before Debating Type Systems
• Computing History Hub

Databases

I have a special Databases page because they’re so fun, just a never-ending source of interesting ideas.

• “Transactions: myths, surprises and opportunities”
• Log Structured Merge Trees

PL Theory

• Functors, Applicatives, And Monads In Pictures
• Crafting Interpreters

Crypto / Auth

• API Tokens: A Tedious Survey

Languages

• Go by Example
• Clojure for the Brave and True
• Learn You Some Erlang (for greater good)

Building abstractions

• Locality of Behaviour
• Writing good programming abstractions
• A Philosophy of Software Design – PDF
• CUPID—for joyful coding
• The Twelve-Factor App
• The Law of Leaky Abstractions

Code janitor tips

• Making Wrong Code Look Wrong
• HTTP API Design Guide
• Best Practices for Designing a Pragmatic RESTful API
• Parse, don’t validate
• Teach Debugging
• Thinking in Data

Data modelling

• https://www.notion.so/blog/data-model-behind-notion

Misc.

We need visual programming. No, not like that.

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.

Brideshead Revisited

Axiomatic

The Everything Music Composition Book

Language: The Unknown

Piranesi

Invisible Cities

Language and Literature

Lord of Light

The Lady Tasting Tea

Neuromancer

the making of karateka

Fall Revolution

Piranesi

Ra by qtnm

Swimming Across

High Output Management

The Raw Shark Texts

Hyperion

Watchmen

The Name of the Rose

The Girl with All the Gifts

Use of Weapons

The Mark and the Void

Annihilation

All the Light We Cannot See

Unsong

Red Plenty

Piranesi

A Heartbreaking Work of Staggering Genius

Theses on the Philosophy of History

In the Vineyard of the Text

This Is How They Tell Me the World Ends: The Cyberweapons Arms Race

The Quantum Thief

Anthem

Pascal’s Apology

Gambling on Development

Rhythms of the Brain

Human, Forever

Hacker’s delight

Accelerated Expertise

The Hedgehog & The Fox

The Feather Men

The Mind-Body Problem

A Complicated Kindness

The Book of the New Sun

Diaspora by Greg Egan

Against Rousseau

Husserl’s phenomenology

Agnar Mykle and Knut Hamsun

Music: A Subversive history

V.

The Open Society and its Enemies

Lacan

Gravity’s Rainbow

The unwomanly face of war

Axiomatic

Ficciones

Bleak House

Dean Koontz’s “Elsewhere”

Dusk (James Salter)

Two Cultures

These Precious Days

The Farther Reaches of Human Nature

The Origin of Wealth

Chronic City

Recursion

The Glass Hotel

Too Loud a Solitude

Principles of Population Genetics

A Gentleman in Moscow

Anathem

Player of Games

The History of Scarcity

Naked Economics

Life: A users manual

On food and cooking

Caro

The Mystery of Capital

Ethics

The Present Age

Down and Out in London and Paris

Oglivey on Advertising

White by Kenya Hara

Conversations With Friends

A Good Man Is Hard To Find

A Grief Observed

Money And Government

Second Nature

Operating Systems: Three Easy Parts

Why We Talk

Euclid’s Elements

The Waves

Godel, Escher, Bach

The Moon Is A Harsh Mistress

Things Hidden Since the Foundation Of The World

The Mote in Gods Eye

The Origin of Consciousness in the Breakdown of the Bicameral Mind

The Unfolding of Language.

A Splendid Wickedness

The Dream-Child’s Progress

The Experience of God

Capitalism and Freedom

Development as Freedom

In Service of the Republic

From Third World to First

Knowledge and the Wealth of Nations

How Asia Works

Stubborn Attachments

Ringworld

Orality and Literacy

Snow Crash

If you feel like commenting on this post, send me an e-mail at judah@joodaloop.com. I check all mail.