Internet community architecture can be seen as a bi-level optimization design, similar to evolution or economics or war or reinforcement learning. There are fast and slow methods of interaction, and ideas or knowledge (or just ‘memes’) are created, varied, and selected on. These interactions happen inside discrete communities which are themselves created, varied, and grow. So, they are instances of multilevel selection.

Gwern, Internet Community Design: Slow To Fast

Motivations

I like forums

1. Their threaded nature make it ergonomic to pck up an existing topic and extend upon it in the future, compared to the “reply” feature in chat apps that result in multiple interleaved conversations.
2. Threads make for nice, self-contained units of sharing.
3. Replies are slow and substantial enough to turn on notifications for.

But it strikes me as a bad idea to make Yet Another Place To Have Conversations On; given how many there are already. On the other hand, many of them are dying, and new places struggle to be born. These things go in cycles, so maybe it’s time to move on from micro-blogging to mid-posting?

I would like a shared library

I like when people have bookshelves on their sites, I like Tom Critchlow’s Library JSON idea for a protocol for open bookshelves (even though I agree that it should just be RSS, lol).

And yet, the first community-sized books collection I ever heard of was Craig Mod’s A Good Book project, with features exactly the ones I was considering myself:

Since all the books are good books, the idea of “favoriting” was redundant. So popularity is based on engagement: How many notes / quotes a book has, and how many shelves it’s on. I tried to inject some whimsy. The more quotes a book has the more “tabs” poke out of the side.

Craig Mod, Go Knicks, A Better Goodreads, ‘Cheap’ Killer Films

Not that a library should limit itself to just books, of course. Custom views for other media would be nice. Seems quite useful to have a group-created version of https://worrydream.com/refs/, for example.

I like visual journals

A Better Journal 2.0 is about images, thanks to raw power of screenshots as a communication medium. Unlike text, which is incredibly lossy and requires painful effort to capture the right feeling, images almost just “are” the thing they’re talking about.

I liked the initial idea behind Campsite, as a place for WIP design to be shared with other people in the company. It was much like having an internal Twitter of sorts. Low effort enough to make a post, but because it’s a group with a specific topic focus it doesn’t really get noisy the way a wide open commons might.

Concepts

A forum

Classically designed for now, with replies + reactions + upvotes. Encourage personal projects to be turned into a thread so that they can be followed + commented on in one place.

A shared library

Custom designed views for each kind of media. Ideally with archiving the actual media too, both for preservatin reasons and to give members easy access. Piracy, hell yeah!

Rich user profiles

Links to current projects, long-term planning, wishlists, etc.

A feed

For posting to when something doesn’t deserve to be in a thread, but also every item added to the library shows up as an update in the feed. Maybe add a constraint that all posts should contain at least one image?

Misc.

• Events
• Online statuses
• Graphs of stats

References

• A Tool for Discussion | Oxide Computer Company
• Internet Community Design: Slow To Fast

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

The fact is, that we have written this book as a first step in the society-wide process by which people will gradually become conscious of their own pattern languages, and work to improve them. We believe, and have explained in The Timeless Way of Building, that the languages which people have today are so brutal, and so fragmented, that most people no longer have any language to speak of at all—and what they do have is not based on human, or natural considerations.

We have spent years trying to formulate this language, in the hope that when a person uses it, he will be so impressed by its power, and so joyful in its use, that he will understand again, what it means to have a living language of this kind. If we only succeed in that, it is possible that each person may once again embark on the construction and development of his own language—perhaps taking the language printed in this book, as a point of departure.

Understanding A Pattern Language

In this paper, we present the purpose, creating process, and overview of a pattern language for creating pattern languages, consisting364 patterns for pattern mining, pattern writing, and pattern symbolizing. For the past 10 years, we, Iba Lab, have created more than 20 pattern languages on various topics to describe human actions, consisting of more than 600 patterns in total. By creating these new pattern languages, we have studied and developed methodology to create pattern languages and to practice and modify them.

A Pattern Language for Creating Pattern Languages

A Pattern Language for Pattern Writing

This pattern language attempts to capture some of these “best practices” of pattern writing, both by describing them in pattern form, and by demonstrating them in action.

Very good!

Working with Patterns: An Introduction

Someone who develops a pattern language must outline certain aspects for the description and then stick to the outline selected. If necessary, it is always possible to expand and change it. What is important is that each piece of information has its precise place and that the different aspects are not mixed when deriving statements. This makes it easier for individuals and groups to collaborate, both in a particular field of application and across disciplines and topics.

Also very good!

Building an interaction design pattern language: A case study

Interaction design patterns are a proven way to communicate good design. However, current pattern collections are not sufficiently powerful and generative to be used as a guide for designing an entire application such as those used in complex business environments. This study shows how we built and validated interaction design patterns that serve as the specification for the redesign of an application. Additionally, they were integrated into a pattern language, as a ruleset for human–computer interaction (HCI) non-professionals to continue development of the application. We demonstrate how individual phases in the redesign of an application can be matched with the process of creating an interaction design pattern language. To facilitate the writing of individual interaction design patterns as well as the development of the pattern language as a whole, a combination of user interviews, controlled experiments and analytical methods has been applied successfully.

Examples of PLs

PATTERN LANGUAGES AS MEDIA FOR THE CREATIVE SOCIETY

This paper proposes new languages for basic skills in the Creative Society, where people create their own goods, tools, concepts, knowledge, and mechanisms with their own hands: the skills of learning, presentation, and collaboration.

Pedagogical Patterns

Pedagogical patterns try to capture expert knowledge of the practice of teaching and learning. The intent is to capture the essence of the practice in a compact form that can be easily communicated to those who need the knowledge.

Patterns for Decentralised Organising

This is a book about working in groups, based on 8 years experience in community projects and startups.

I’m not so interested in what you’re working on together, I’m just going to focus on how you do it. To my way of thinking, it doesn’t matter if you’re trying to build a better electric vehicle, or develop government policy, or blockade a pipeline; whenever you work with a group of people on a shared objective, there’s some stuff you’re going to deal with, some challenges. How do we decide what we’re working on? who does what? who can join our team? what are our expectations for each other? what happens when someone doesn’t fulfil those expectations? what do we do with disagreement? how do decisions get made?

An Everlasting Meal: Cooking with Economy and Grace

Workflow Patterns

The aim of this initiative is to provide a conceptual basis for process technology. In particular, the research provides a thorough examination of the various perspectives (control flow, data, resource, and exception handling) that need to be supported by a workflow language or a business process modelling language. The results can be used for examining the suitability of a particular process language or workflow system for a particular project, assessing relative strengths and weaknesses of various approaches to process specification, implementing certain business requirements in a particular process-aware information system, and as a basis for language and tool development.

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

This topic can often sound defeatist, because surely there is more to it than tricking yourself into the right state of mind for doing the work. Where is the beautiful relationship to the feeling of mastery? The rewarding fruits of the labour? The satisfaction of competence? Aren’t these supposed to be the Good Motivators that drive one forward with a pure energy that has no need for silly tricks?

In practice, it is both. If you neglect either one, you can end up in a bad place, believing that neither drivers are effective since they didn’t work in isolation. You can set out on a Great Work, and give up in a week because you didn’t have enough tricks for preserving momentum in your toolkit. Or you can know all the tricks to energy management, and fail to follow through because deep down you don’t actually care about the outcome.

Similarly, chemistry is slightly embarrassing to think about, but will absolutely dominate your outcomes in practice.

The first-line treatment for ADHD is stimulants. Everything else in this post works best as a complement to, rather than as an alternative to, stimulant medication. In fact most of the strategies described here, I was only able to execute after starting stimulants. For me, chemistry is the critical node in the tech tree: the todo list, the pomodoro timers, etc., all of that was unlocked by the medication.

…

Taking Ritalin with no plan for what you will do today/tomorrow/this week doesn’t work. Dually, an ambitious todo list will sit idle if your brain won’t let you execute it. So personal growth comes from using both internal and external changes, like a ladder with alternating left-right steps.

Fernando Borretti, Notes on Managing ADHD

You have to respect your chemistry because we are, in our mortal frames, as Fernando puts it: …automata, our minds are molecules in salt water. You can be driven forward by intrinsic fascination because you have a soul that can yearn and rejoice in the endeavour. But you will be tying it down with all kinds of ballast if you ignore the things that govern the chemistry of it’s body; even things that don’t need medication.

1. Isolation is the absolute worst. It will crush your body on a hormonal level almost instantly, but it also does direct damage to the soul.
2. Chemicals that go into your body become temporary but recurrent parts of it. In case it isn’t obvious, everything is a chemical.
3. Energy is a physical process that needs calories and rejuvenation, and is governed by external stimuli like vigorous activity or sunlight.

I want you to think of these things with the seriousness and impact that one very easily ascribes to the medication of debilitating conditions — and ignoring them as being akin to refusing a vaccination, or choosing to eat lead. Your soul needs it.

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

1. It had time tracking as it’s core feature. It turns out, I don’t care how exactly I’ve spent my time! It’s very important, of course, but I can just measure it by looking at a calendar. How many days of this year have passed? Simple as. The thing that does matter is output, being able to see what the time amounted to and judge if it was worth it.
2. It was based on text entries. I hate looking at plain text. It’s such an impoverished medium. I feel nothing when looking back on entries that describe something I’ve made or work I’ve tracked. I hate writing them even more, they don’t capture enough.
3. I was trying to make it easy to add entries. But that doesn’t matter if I never look back on it. Writing about past is just not that interesting. Intrinsically, it has no hold over my mind the way the present does. Nor is it worth thinking about, relative to the future.

   At first I thought the problem was friction: the higher the activation energy to using a tool, the less likely you are to use it. Even a small amount of friction can cause me to go, oh, who cares, can’t be bothered. So each version gets progressively more frictionless.

   …

   And yet I still don’t use it. Why?

   Fernando Borretti, Unbundling Tools for Thought

To improve over these problems will require a new approach that includes multiple representations that make it feel good to gather retrospectives material, and look at it later. Alongside solving this design problem, I would also like to find ways to add The Future to this application’s concept space.

Conceptual approach

When thinking about presenting information in ways that are resonant enough to look back on, while also avoiding the act of writing; a simple solution presents itself:

Images

In particular, screenshots — perhaps the most underrated digital record of our era given their ubiquity and sheer ease of use.

When thinking about media that can survive millenia, I’m more confident in diagrams that communicate through visual patterns than in any kind of digital file format that depends on a working decoder to be visualized, or in a single language as the chosen vehicle for information. The Rosetta Stone, through visually paired symbols, transmitted distant languages in a redundant format that could be deciphered in the far future with minimal context. If computation is the execution of algorithms on structured data, then screenshots may prove naive. But if computation is the shepherding of information through space and time, then they may prove essential.

During the opening of the conference, Omar honed in on the subversive nature of the screenshot. In popular computing, it circumvents the app siloes that define our contemporary digital ecosystems. A screenshot doesn’t need a log in, bypasses DRMs, and is interoperable between practically every single computational device. Even in the “high-culture” of computing, where text is dominant, screenshots prove subversive. The screenshot is unstructured information which must be parsed to offer the tidy data best suited to computer hacking. They are seen as verbose and unwieldly, despite universal adoption. The Tao of Unix is text files, not bitmaps.

cristóbal, tweeting

This supremacy is partly a result of the failures of the URL:

The dream of URLs—open, permissionless sharing—is fading. I can’t paste URLs into my AIs or send them to my friends and be sure that they’ll see what I see. But you know what does work? Screenshots! Screenshots are the successor to URLs. Open, permissionless sharing.

zooko🛡🦓🦓🦓 ⓩ, tweeting

And their “resonance factor” completely trounces text. Even without invoking the old adage about being worth a thousand words, just looking at a grid of images is a more pleasurable activity than if it was lines upon lines of uniform words. I have verified this empirically too: I actively enjoy looking back at my LOG note in Bear, which is can be thought of as version 0 of this app. When I just wrote text entries I never scrolled down to old ones.

So this new journal will use the image as it’s primary object. Outputs and in-process work can all be captured by screenshots. In fact, a series of screenshots can act a blink comparator of sorts, making it easy to feel the change.

Text may accompany the image to provide explicit narrative context, and also to enable…

Categorising through text search

As even a fledgling ontologist knows, tags are a dangerous thing. Unless carefully hatched in a context of use, they can spiral into infinite combinations of generic descriptors. They also (usually) need a relational database of some kind to implement well.

We will not be using tags; instead relying on fast text search across all entries in the journal. When I add entries like “Published worknote for Better Journal” and “Design first UI for Better Journal”, they are both trivially gathered into one project by the search term “journal”. The more tag-crazy among us might even resort to #journal hashtags, but I’m hoping the simple capabilites of a prose description proves enough to discourage them.

Of course, commonly searched terms can be saved as one-click actions, such that they feel as good as using tags.

Days as the unit of time

Because I’ve never found myself caring about anything more granular than that. In the long run, you will not care if you did something by 6pm or 6am, just the fact that it was done.

Predictions for calibration

How can one bring the future into a system that is focused on creating good pictures of the past? My answer is “calibration practice”.

You can create Predictions, entries dated in the future, that say “I will have done X by date Y”. On the day you make a journal entry about actually doing it, you can connect the prediction to it. This can be used to calculate a Brier-eqsue score for timeliness predictions in your personal life. Fun possibilities for graphs here, including being able to see if how your prediciton ability itself changes over time.

Implementation details

Interface

As always, iteration will prove invaluable. So even if my ideal client is a native Mac app, I will build it in Tauri first.

I will try to design + prototype at least 2 layouts per week, starting in September, and record all the design sketches here:

Data model

An entry is just a combination of text + image/video, and expressible in Markdown and frontmatter. Since days are the unit of time, we can put multiple entries in a “day file”. This also makes the order of entries simple, they’re just ordered top to bottom.

An example file (imagine it’s called 2026/09/04/entries.md) would look like:

id: a7f3
media: 
  - content-hash-041243hr3.png
  - content-hash-893f3fh42.mp4

Caption written as regular text, no need to worry about line breaks and quote rules, etc.

---

id: b9a8
media: 
  - can-also-be-manually-written.png

I'm really optimising for human readability here.

Predictions can be similarly minimal:

id: 2r82
prediction: "I will ship an intial version of A Better Journal, as a desktop app for MacOS"
date: 2026-09-12
confidence: 0.4
completed: a7f3

This simplicity is necessary to keep from spiralling into an everything app. If you don’t draw hard lines in the sand, you end up trying to build universal timelines and operating system interfaces based on time. They’re cool, but they don’t share my goals of far less ambitious goal of restrospection.

Honestly, all I’m doing is asking the question “what if Twitter was the best journalling app?”. Except, instead of threads, things are connected by searching for text terms instead. Or is “replying” worth it as a mechanism to connect progress specific events across time?

A simple data model encourages client freedom. So features like OCR, near-duplicate detection, color filters, etc. can be left up to clients instead of being added to the core data model.

A filesystem structure makes for clunkier sync than a custom database-backed protocol, but should not pose too much of an issue, given that it’s a single-user app. In the worst case, I’ll just do what Bear does (compare-and-swap, create a fork on conflict).

References

• Ping Practice

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

1. Live queries (arbitrary, requires a running server)
2. A pre-calculated subset of data (user’s working set)

Live queries are in most ways the superior way to do things. They combine the freedom of “just make an API request” with the performance a built-in local cache and the consistency of transactional updates. There’s only 4 (small) downsides with existing libraries:

1. They involve stateful servers for satisfying queries (usually pretty scalable read replicas of the main database), which have RAM requirements proportional to O(row results) instead of using the client as the data source.
2. Are usually tied to specific databases (often Postgres) or are a database too (Convex, Jazz). This is mostly a good idea, just constraining.
3. None of the existing solutions have support for SSR yet.
4. Only a couple of them support offline mutations.

I expect that LLMs will make the first two problems smaller over time, by rewriting the server code in more memory-efficient languages and make it trivial to add new database adapters.

Meanwhile, the downsides of a pre-calculated subset are many:

1. Obviously, it only works for apps where the data a user sees is a neat rarely-changing subset.
2. Data, once fetched, continues to build up on the client even if none of the UI is requesting it anymore.
3. Your subset-calculating code can contain bugs.
4. Most existing solutions use JSON document models instead of relational.
5. Most existing solutions require loading the user’s working subset the first time they open the app/site. This is untenable past a certain size of data.

So why work on it?

Linear is (to my knowledge) the only subset-based sync solution that also has efficient data loading. They do so by combining a fetch-when-needed (instead of load upfront) protocol with a change stream. My library will try to commoditise this capability. With support for SSR, unlike Linear.

In addition, the way my approach handles data fetching allows it to be used for arbitrary apps, not just ones that want a persistent local cache. Github, for example, is a mixture of arbitrary, temporarily-used data (when you visit a random repo) and well-defined subsets that could be cached locally (your own repos, your org’s repos) and something like that would be possible to build with SSSync. (Doing so would worsen a few consistency guarantees in the local database, but that’s what HTTP-based web apps do anyway).

Some other reasons:

1. Be able to make apps that have zero idle cost by running on serverless compute and storage.
2. Build things like fuzz testing, network failure simulation, etc. into the library dev tools.
3. Have an open source library of my own.

System components

Client query API

My requirements are:

• Ability to clearly know that something is a “fetch-by-id + relations” that can be sent to the server if not found locally.
• Easy to make performant on IndexedDB.
• Easy to build an efficient subscription system for.

This suggests two simple yet distinct query patterns:

// Get a single item, with nested relations
sssync.db.posts.byId([id], ["authors"])

// Get a range, filtered by a Javascript function
sssync.db.posts.all(() => a.date < TODAYS_DATE)

Client storage layer

IndexedDB has the most browser compatibility and least need for custom tooling or bundler complications. Especially for a v1, there’s no reason to reinvent storage yet. I will also avoid using indexes (Javacript-only filtering) and migrations (just blow away old databases and remake a new one in a new namespace each time).

I need to be careful about serialization though.

Data-fetching protocol

Fetch by id + relations

Most UI in apps is relational. The nice thing about “get by id, and relations of that item” is that it makes for a simple protocol. The server knows exactly what kind of requests to expect since they all look like:

{type: "posts", id: "uuid", related: ["authors", "comments"]}

It’s also super easy to cache. A request for an item can be conclusively satisfied just be checking if it exists in the local database, no invalidation needed. And relations can be tracked too, each time a server satisfies a relational fetch.

Named loader functions

But how do you build a cache around things fetched in arbitrary bunches, in truncated lists, or that use arbitrary server logic to put together?

I propose a simple system of named functions, producing cache keys that are a combination of the function name and args. These functions can be run once, on a debounce, or manually whenever the developer wants — and their results dumped into the local database.

// An example of a simple fetch()-based loader
sssync.loaders = {
  latestPosts: (user) => fetch("/posts/" + user)
}

// Component using the loader
function Posts (){
  const loaded = sssync.load.latestPosts({refresh: 3000})
  const posts = sssync.db.posts.all()

  return (
    <div>
      {posts.slice(0, 50).map(post => <h2>{post.title}</h2>)}
      {!loaded && (<div> This list might be stale! </div>)
    </div>
  )
}

Sync logic

The only sync path is an ordered stream of updates that the server is responsible for fanning out to clients. Given the last_sync_id from any client, it must return updates and a fresh last_sync_id in a single response. If it wants to batch the data into multiple responses, it may add a more_updates: true parameter to the JSON payload to tell the client to make more requests.

I need to finalise the shape of updates that must come back from a sync request. It should be possible to implement this protocol over Websockets and SSE too.

Write path

I prefer semantically named and versioned change objects because they force best practices while also solving the schema migration problem. Credit to Livestore for the inspiration.

postCreated: {
   name: 'v1.PostCreated',
   schema: object({ id: string(), text: string() }),
 })

sssync.write(
  "v1.postCreated",
  {id: NEW_UUID, title: "New post about SSSync"}
)

When triggered, these named changes will be immediately converted into actual state updates using projector functions on the client and broadcasted to the server in the background.

On the server, you can write whatever code you like to handle them. This approach to conflict management is called server reconciliation.

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

But I was using too many notes apps, one of which I’d built myself (tldraft.app), and wanted to consolidate and clean up my scattered words. I considered building a microsite of some kind for these work notes, or adding read-only sharing to tldraft itself so I could move them there.

Instead, I realised there was no reason to not add them to this site. The Workbench made for a suitable container, given that it already tracked the history of my focuses. It was time for it to also track their live notes.

So, worknotes are now a new content format, and two of them have been added to site already. Find them on the Workbench page, under the Display of Qualitative Information section.

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

I’m particularly proud of how the design has no links and doesn’t look like a strict grid of items. I originally planned to make it sortable, filterable and carefully ordered by value to money ratio; and realised none of that was necessary given the small number of items I actually had to display.

The font is Times New Roman btw.

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

what happens in real life stays in real life

Everything on the microsite would only deal with activities that happened on a screen. No biomarkers, personal milestones, or events with friends will be logged on here.

Something about trying to convert non-screen activities and happenings into computer bits feels off to me. I’ve never really liked photo or video either, except as a trigger for my own memory.

i only care about outputs + consequences

Do I really care how many times I worked out vs. how fit I actually feel day-to-day? In general, I find that input isn’t worth attention, and I especially dislike when it’s fetishized in terms of raw hours or reps instead of quality of outcome.

I also don’t care about time, especially standardised time:

Our modern sense of time is homogenous. It divided and measured in “units” to be filled. Clock time. These time units have no meaning themselves. They are empty containers, filled with meaning by us, through activities we do within them.

Gordan Brander, Time consciousness

Hell-bent on standardization; on Cartesian deliverance. Time is the primary socializing tool. Indelibly imprinted and structurally biased. We are domesticated creatures of technical abstraction. If rationalism/reductionism is our religion, then time keeping is our benediction

Buried Inside, Time As Surrogate Religion

viewer-friendly

The goal is for everything to come together in a browsing-friendly way, presenting information that is, first and foremost, useful to the reader.

One of the best ways to make something nice to look at is to make it a picture instead of text. Luckily, I can get a lot of mileage from the humble screenshot since most of my work is visual.

What do I want to log?

• Writing
  • Good tweets
  • Shareholder letters
  • joodaloop.com posts, including edits
  • Essays
• Microsite creation and redesigns
  • Updates to microsite content
• Client projects
  • Launches
  • Discarded concepts
• Personal project launches and updates
• Songs recorded

What do I want to measure?

• Vistors to my web properties, maybe their comments
• # of items in each category
• Word count

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

Exploring the future of the calendar

designing time — Aaron Lewis

Timekeeping is politics by other means

engineering write-ups / blogs / vids — Yihui H.

interesting write-ups / videos about engineering challenges, breakdowns and solutions. mostly iOS / web dev

thoughts in need of a home — Chris Beiser

this is where I put the thoughts I have which I don’t yet have a channel for, so that I can learn what they’re about. everyone on this website is so good at putting things in correct categories.

now that’s what i call a landing page — parker dot mov

—

Web design as architecture — Malte Müller

A call for more elaborate discourse and better metaphors for designing and building digital platforms.

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

• Gavin Leech’s Reading page
• Justin Duke’s Media section

Huh, that’s way less people than I’d expected. I guess personal websites need to start showing more love for media catalogues. Especially ones that take the trouble to rank things for visitors in useful ways.

I too, want to avoid just having a long list of items of everything I’ve ever consumed. Most of them are a “waste” of time. I want to instead only list the things worth recommending.

But wait, what if I want to dis-recommend something? Something I think is overrated (see: sort by controversy), and want to warn people off of? Should I even assume that authority?

Things I want to log

• Books
• Movies
• Music
• Internet writing
  • Essays
  • Websites
  • Tweets

Metadata

• Author
• Personal affection (star)
• “Rereads”
• Heftiness/length (1–3)

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

things i wouldn’t do as a designer

thread of dishonest design

interfaces that make text a first class citizen

ai

work data

thread of types of reactions from programmers to LLM progress

misc.

tradeoffs thread

“indicators of continued childhood”

instances of failureship bias

ideas that make for good “solve for equilibrium” problems

thread of fun temporary underclass activities

thread of nice wood things

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

This stability has allowed me to focus on small refinements and new features. And enough of these changes have happened in the last few months to merit a version bump. Introducing, joodaloop.com v4.6, now with…

• Offline browsing through a Service Worker that caches all page content for instant page loads after the first visit.
• The ~~~ page debuted with a new tweet-like format — the need for which was covered in “An ontology of microblogging”.
• Site-wide title search can be brought up by hitting ⌘ + K on any page. It’s a particularly nice experience due to the fact that pages load instantly.
• Frames, Focuses & Frontiers is a new section on the Workbench page that tracks my personal history of, well…those 3 things.
• A custom collapsible was designed using the <details> element in order to compress that list to a practical length. And found further use on…
• The new Writing page layout, which now consists of essays (segmented by platform) and Notes, Lists & Guides (split into more focused categories).
• Backlinks now show up in the INFO section of post pages.
• Invitation to email me is appended to the end of all posts, including RSS feed entries.
• An LLM-coded linter was built to support content and build output correctness across the site. Dozens of typos were caught, and missing page metadata added. You are invited to try it yourself.
• Analytics were brought back using Counterscale, which I recommend.
• Images have improved styling, including a max-height to prevent overly long blocks, and a neat fallback for when they fail to load.
• Dark mode readability improved as a result of picking a lighter shade of blue for the site’s theme color (#040c5b -> #141c6b), in response to critique by a particularly impassioned user.
• The home page “STUFF” section now gives each of my major projects it’s own callout box instead of using plain lists.

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

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 and upload the site directly myself. As a bonus, it’s really fast. A change to a single post page goes live in ~3 seconds, compared to the 10+ seconds taken by the old git push → Github → Netlify → CDN workflow.

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 with other people, like Twitter.

The medium and the message and me have yet to exhaust all possible combinations of formats and workflows — hence the space for ~~~ as a new entrant. 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

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”, 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.)

For a more nuanced critique of transclusion, see Transclusion is limited by the data model’s composability by Andy Matuschak.

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.

Spatial/ambient computing

Hardware issues aside, I’m not on board with the idea that we need dozens of screens floating around, Minority Report-style. Nor that we should be using grandiose gestures to move things around instead of efficient keyboards. Great work has been done on typewriters, there’s no evidence that a single laptop screen is a limiting factor for creative potential.

Attention, on the other hand, does seem to matter. And a dozen focus points, especially the kind promised by “ambient computing” seem more like adversaries than aids to attention preservation. Also, screens are kinda lame, really.

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.

There is a time and place for magic, but it ought to happen in full view of the user, and at moments where user intervention would be unpleasant anyway.

My favorite part of Google Maps isn’t the fact that it gets you where you want to go, but this:

When you take a wrong turn or go the wrong way, it doesn’t break down or tell you to take a u-turn (unless you REALLY messed up). Usually it just updates the route from where you are right now to get you where you need to go. Driving is stressful and it takes away the stress of making a wrong turn and just reroutes you instead of making you stop and re-evaluate or start over (i.e. the more interventionist solution)

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.

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.

I think it’s important for every designer to notice when they wince, and teach others how to wince and notice, too.

Marcin Wichary, “Houston, we have 1 problem(s).”

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.

One move we could make is a single inbox for calmer triage, but most apps just show multiple dots all over their interface instead.

Heaviness

It comes in two forms:

1. Latency: Loading spinners, perceptible gaps between a click and resulting action, a frozen interface — all of these are an unsettling game of “guess what happens next?”. A page scrolling slower than your mouse wheel 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

Some retreats from visual heaviness end up in the arms of naive minimalism. Look at this coffee machine panel (source, worth reading) for example: it’s minimalism results in it hiding information.

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

In many apps, it makes for a series of nervous back-and-forth jumps between multiple screens. In absence of unambiguous tooltips/labels/descriptions, you receive no clue as the where your next click is going to take you.

This is what plagues hyperlinks, which are a tool for indirection that often don’t provide any hints as to where they’re going. Transclusion is another offender, requiring users to think about every transcluded instance 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, ⌘ + 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 each other’s rules that relying on the anything starts to feel impossible).

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.

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 with their trust burned. Once bitten, forever shy.

It’s not just changes to the product that can have this effect. Veteran users of software can smell the desperation in a rebrand. They can sense the upcoming product pivot that finally casts their specific needs aside.

Powerlessness

For the longest time, the black box of social media 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.

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 ⌘ + 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 bad thumbnail images

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. They are largely a relic of the nonsense SEO recommendations of the 2010s. 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, or use a consistent illustration style. They look really nice, even when 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 short URLs that look as neat as domain.com/post-url by quickly typing them out from memory.

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 the canvas is such a singular medium, you’re encouraged to put every detail of your project 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 each page as a single, specific artifact. Like a birthday card.

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 shape-bound arrows are amazing too. 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) will be a weak one due to the variety of idiosyncratic usage patterns. It defeats the point of being a wide open space, 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 worse 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.

• Read (mostly on my e-reader).

• Add writing or design improvements (see Changelog) to this site.

• Sketch new interface ideas in tldraw.

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

• Go lounge around at a friend’s place.

• Talk to an LLM about sync engine architectures.

• Go through the tabs in my reading backlog.

• 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

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

• Browse the Commoncog Forum.

• Doomscroll Twitter, sometimes Bluesky.
  I use write-only clients for both these apps, no timeline to scroll.

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

• Prune my unused notes in Bear or the drafts section of this site.
  No longer necessary, I have banished all my non-active notes to the archive.

• 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.
  Not my goal anymore.

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. There’s also one from tldraw, optimised for their use case.

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.