Full Width 
FOCUS MODE
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Jim Nielsen’s Blog
Dismissing an idea because it doesn’t work in your head is doing a disservice to the idea. (Same for dismissing someone else’s idea because it doesn’t work in your head.) The only way to truly know if an idea works is to test it. The gap between an idea and reality is the work. You can’t dismiss something as “not working” without doing the work. When collaborating with others, different ideas can be put forward which end up in competition with each other. We debate which is best, but verbal descriptions don’t do justice to ideas — so the idea that wins is the one whose champion is the most persuasive (or has the most institutional authority). You don’t want that. You want an environment where ideas can be evaluated based on their substance and not on the personal attributes of the person advocating them. This is the value of prototypes. We can’t visualize or predict how our own ideas will play out, let alone other people’s. This is why it’s necessary to bring them to life, have them take concrete form. It’s the only way to do them justice. (Picture a cute puppy in your head. I’ve got one too. Now how do we determine who’s imagining the cuter puppy? We can’t. We have to produce a concrete manifestation for contrast and comparison.) Prototypes are how we bridge the gap between idea and reality. They’re an iterative, evolutionary, exploratory form of birthing ideas that test their substance. People will bow out to a good persuasive argument. They’ll bow out to their boss saying it should be one way or another. But it’s hard to bow out to a good idea you can see, taste, touch, smell, or use. Email · Mastodon · Bluesky
I refreshed the little thing that let’s you navigate consistently between my inconsistent subdomains (video recording). Here’s the tl;dr on the update: I had to remove some features on each site to make this feel right. Takeaway: adding stuff is easy, removing stuff is hard. The element is a web component and not even under source control (🤫). I serve it directly from my cdn. If I want to make an update, I tweak the file on disk and re-deploy. Takeaway: cowboy codin’, yee-haw! Live free and die hard. So. Many. Iterations. All of which led to what? A small, iterative evolution. Takeaway: it’s ok for design explorations to culminate in updates that look more like an evolution than a mutation. Want more info on the behind-the-scenes work? Read on! Design Explorations It might look like a simple iteration on what I previously had, but that doesn’t mean I didn’t explore the universe of possibilities first before coming back to the current iteration. v0: Tabs! A tab-like experience seemed the most natural, but how to represent it? I tried a few different ideas. On top. On bottom. Different visual styles, etc. And of course, gotta explore how that plays out on desktop too. Some I liked, some I didn’t. As much as I wanted to play with going to the edges of the viewport, I realized that every browser is different and you won't be able to get a consistent “bleed-like” visual experience across browsers. For example, if you try to make tabs that bleed to the edges, it looks nice in a frame in Figma, and even in some browsers. But it won’t look right in all browser, like iOS Safari. So I couldn’t reliably leverage the idea of a bounded canvas as a design element — which, I should’ve known, has always been the case with the web. v1: Bottom Tabs With a Site Theme I really like this pattern on mobile devices, so I thought maybe I’d consider it for navigating between my sites. But how to theme across differently-styled sites? The favicon styles seemed like a good bet! And, of course, what do to on larger devices? Just stacking it felt like overkill, so I explored moving it to the edge. I actually prototyped this in code, but I didn’t like how it felt so I scratched the idea and went other directions. v2: The Unification The more I explored what to do with this element, the more it started taking on additional responsibility. “What if I unified its position with site-specific navigation?” I thought. This led to design explorations where the disparate subdomains began to take on not just a unified navigational element, but a unified header. And I made small, stylistic explorations with the tabs themselves too. You can see how I played toyed with the idea of a consistent header across all my sites (not an intended goal, but ya know, scope creep gets us all). As I began to explore more possibilities than I planned for, things started to get out of hand. v3: Do More. MORE. MORE!! Questions I began asking: Why aren’t these all under the same domain?! What if I had a single domain for feeds across all of them, e.g. feeds.jim-nielsen.com? What about icons instead of words? Wait, wait, wait Jim. Consistent navigation across inconsistent sites. That’s the goal. Pare it back a little. v4: Reigning It Back In To counter my exploratory ambitions, I told myself I needed to ship something without the need to modify the entire design style of all my sites. So how do I do that? That got me back to a simpler premise: consistent navigation across my inconsistent sites. Better — and implementable. Technical Details The implementation was pretty simple. I basically just forked my previous web component and changed some styles. That’s it. The only thing I did different was I moved the web component JS file from being part of my www.jim-nielsen.com git repository to a standalone file (not under git control) on my CDN. This felt like one of the exceptions to the rule of always keeping stuff under version control. It’s more of the classic FTP-style approach to web development. Granted, it’s riskier, but it’s also way more flexible. And I’m good with that trade-off for now. (Ask me again in a few months if I’ve done anything terrible and now have regrets.) Each site implements the component like this (with a different subdomain attribute for each site): <script type="module" src="https://cdn.jim-nielsen.com/shared/jim-site-switcher.js"></script> <jim-site-switcher subdomain="blog"></jim-site-switcher> That’s really all there is to say. Thanks to Zach for prodding me to make this post. Email · Mastodon · Bluesky
Jason Fried writes in his post “Knives and battleships”: Specific tools and familiar ingredients combined in different ratios, different molds, for different purposes. Like a baker working from the same tight set of pantry ingredients to make a hundred distinct recipes. You wouldn't turn to them and say "enough with the butter, flour, sugar, baking powder, and eggs already!" Getting the same few things right in different ways is a career's worth of work. Mastery comes from a lifetime of putting together the basics in different combinations. I think of Beethoven’s 5th and its famous “short-short-short-long” motif. The entire symphony is essentially the same core idea repeated and developed relentlessly! The same four notes (da-da-da-DAH!) moving between instruments, changing keys, etc. Beethoven took something basic — a four note motif — and extracted an enormous set of variations. Its genius is in illustrating how much can be explored and expressed within constraints (rather than piling on “more and more” novel stuff). Back to Jason’s point: the simplest building blocks in any form — music, code, paint, cooking — implemented with restraint can be combined in an almost infinite set of pleasing ways. As Devine noted (and I constantly link back to): we haven’t even begun to scratch the surface of what we can do with less. Email · Mastodon · Bluesky
Conrad Irwin has an article on the Zed blog “Why LLMs Can't Really Build Software”. He says it boils down to: the distinguishing factor of effective engineers is their ability to build and maintain clear mental models We do this by: Building a mental model of what you want to do Building a mental model of what the code does Reducing the difference between the two It’s kind of an interesting observation about how we (as humans) problem solve vs. how we use LLMs to problem solve: With LLMs, you stuff more and more information into context until it (hopefully) has enough to generate a solution. With your brain, you tweak, revise, or simplify your mental model more and more until the solution presents itself. One adds information — complexity you might even say — to solve a problem. The other eliminates it. You know what that sort of makes me think of? NPM driven development. Solving problems with LLMs is like solving front-end problems with NPM: the “solution” comes through installing more and more things — adding more and more context, i.e. more and more packages. LLM: Problem? Add more context. NPM: Problem? There’s a package for that. Contrast that with a solution that comes through simplification. You don’t add more context. You simplify your mental model so you need less to solve a problem — if you solve it at all, perhaps you eliminate the problem entirely! Rather than install another package to fix what ails you, you simplify your mental model which often eliminates the problem you had in the first place; thus eliminating the need to solve any problem at all, or to add any additional context or complexity (or dependency). As I’m typing this, I’m thinking of that image of the evolution of the Raptor engine, where it evolved in simplicity: This stands in contrast to my working with LLMs, which often wants more and more context from me to get to a generative solution: I know, I know. There’s probably a false equivalence here. This entire post started as a note and I just kept going. This post itself needs further thought and simplification. But that’ll have to come in a subsequent post, otherwise this never gets published lol. Email · Mastodon · Bluesky
Jan Miksovsky lays out his idea for website creation as content transformation. He starts by talking about tools that hide what’s happening “under the hood”: A framework’s marketing usually pretends it is unnecessary for you to understand how its core transformation works — but without that knowledge, you can’t achieve the beautiful range of results you see in the framework’s sample site gallery. This is a great callout. Tools will say, “You don’t have to worry about the details.” But the reality is, you end up worrying about the details — at least to some degree. Why? Because what you want to build is full of personalization. That’s how you differentiate yourself, which means you’re going to need a tool that’s expressive enough to help you. So the question becomes: how hard is it to understand the details that are being intentionally hidden away? A lot of the time those details are not exposed directly. Instead they’re exposed through configuration. But configuration doesn’t really help you learn how something works. I mean, how many of you have learned how typescript works under the hood by using tsconfig.json? As Jan says: Configuration can lead to as many problems as it solves Nailed it. He continues: Configuring software is itself a form of programming, in fact a rather difficult and often baroque form. It can take more data files or code to configure a framework’s transformation than to write a program that directly implements that transformation itself. I’m not a Devops person, but that sounds like Devops in a nutshell right there. (It also perfectly encapsulates my feelings on trying to setup configuration in GitHub Actions.) Jan moves beyond site creation to also discuss site hosting. He gives good reasons for keeping your website’s architecture simple and decoupled from your hosting provider (something I’ve been a long time proponent of): These site hosting platforms typically charge an ongoing subscription fee. (Some offer a free tier that may meet your needs.) The monthly fee may not be large, but it’s forever. Ten years from now you’ll probably still want your content to be publicly available, but will you still be happy paying that monthly fee? If you stop paying, your site disappears. In subscription pricing, any price (however small) is recurring. Stated differently: pricing is forever. Anyhow, it’s a good read from Jan and lays out his vision for why he’s building Web Origami: a tool for that encourages you to understand (and customize) how you transform content to a website. He just launched version 0.4.0 which has some exciting stuff I’m excited to try out further (I’ll have to write about all that later). Email · Mastodon · Bluesky
More in literature
In his critical works, Samuel Johnson respected tradition if not reputation or even physical appearance. He could be eloquently brutish and write of Jonathan Swift: “The person of Swift had not many recommendations. He had a kind of muddy complexion, which, though he washed himself with Oriental scrupulosity, did not look clear. He had a countenance sour and severe, which he seldom softened by any appearance of gaiety. He stubbornly resisted any tendency to laughter.” Today we would frown on mocking a writer’s looks. It would be judged “insensitive.” I associate Johnson’s description of Swift with one of the late John Simon’s more amusing assaults on Barbra Streisand: “Miss Streisand looks like a cross between an aardvark and an albino rat surmounted by a platinum-coated horse bun. Though she has good eyes and a nice complexion, the rest of her is a veritable anthology of disaster areas. Her speaking voice seems to have graduated with top honors from the Brooklyn Conservatory of Yentaism.” That Streisand is a mediocre singer/actress endowed with a surfeit of self-esteem eases potential offense. The difference between Johson’s judgment and Simon’s being that the former mingles admiration with distaste: “It was from the time when [Swift] first began to patronise the Irish, that they may date their riches and prosperity. He taught them first to know their own interest, their weight, and their strength, and gave them spirit to assert that equality with their fellow-subjects to which they have ever since been making vigorous advances, and to claim those rights which they have at last established.” R.L. Barth has translated Martial’s epigram XI.99. As a satirist, Martial was no respecter of persons: “Whenever you stand up, I see your gown Treat you indecently, flat let you down. You pluck it with your left hand then your right— You’re positively groaning!—it’s held tight In the Cyanean straits of your huge butt. What’s my advice? Don’t sit. Don’t stand. That’s what.” Bob wrote to me on his approach to translation: “Translation can be a vexing problem if you let it be--or even if you don’t. For me, all that matters is that the translated poem makes a good English poem (or why bother) and that it stays as close to the original as this or that translator is able to keep it. However, I'm willing to vary, add, substitute, if it works for the poem and doesn’t violate the spirit of the original. I may not be as good a poet as Martial, but I’m pretty much his equal as a smart-ass, which helps my translations.”
A common phenomenon in the history of literature is couples writing together.
“The book of love is full of music,” sings Peter Gabriel. “In fact, that’s where music comes from.” The book of love is written in the language of wonder — our best means of loving life more deeply. To love anything — a person, a pond, the world — is to see the wonder in it, to hear the music in it. Both love and wonder are in mysterious conversation with the deepest substrate of us, the complete message of which is unintelligible to the analytical mind, inaccessible by any explanatory model. Both require a surrender to the musicality of… read article
The Louisiana poet Gail White published three poems in Peacock Journal, all freighted with serious thought and all skirting the charms of light verse. White avoids the failings of pretentiousness and mere silliness. Consider “Resemblances”: “Somewhere along the primrose path That led to my seventies, I lost the blithe agility Of the young springbok’s knees, “The swift gait of the wildebeest Running with its herd, And the keen eye of the crouching cat Under the nesting bird, “Retaining only the stoic love Of the elephant for its kin And the fierce desire of the salmon For the stream it was nurtured in.” Chronicling the losses and infirmities of aging can turn readily into a wallow in self-pity, which is ridiculous if you consider the alternative. Unspoiled youth is incompatible with longevity, and adults accept those inevitabilities with dignity and “stoic love.” White’s twelve-line, one-sentence poem reminds us that mortality is universal, what we share with the rest of the Earth’s fauna. We’re in the same boat (Noah’s ark) as nematodes and capybaras. White adds a prose statement to her poems: “Aquinas, who had a gift for concise definition, once said that ‘We call that beautiful which pleases the eye.’ It’s hard to improve on the simplicity of that. Pleasing the eye, which includes reading, has always been my goal, and aesthetics my primary value. From this comes a love of art museums, travel, living next to running water, poetry, the Victorian novel, and cats. (Few things please the eye as much as a good cat). It might have been more noble if my highest value had been unconditional love, but if I’m honest, I admit I’m stuck with beauty.” Not a bad place to be stuck. Beauty is one of the things that makes life worth enduring. In the final chapter of The Pleasure of Ruins (1953) – one of my favorite books -- Rose Macaulay reminds us to look at new buildings geologically, beyond the scale of a single human lifetime: “Very soon trees will be thrusting through the empty window sockets, the rose-bay and fennel blossoming within the broken walls, the brambles tangling outside them. Very soon the ruin will be enjungled, engulfed, and the appropriate creatures will revel.” It’s a chastening thought (and goes on for another half-page), like the Time Traveller’s view of the dress shop across the street from his lab in George Pal’s film of The Time Machine (1960). Macaulay gets even more apocalyptically inspired in her final sentences: “Ruin must be a fantasy, veiled by the mind’s dark imaginings: in the objects that we see before us, we get to agree with St Thomas Aquinas, that qua enim diminutae sunt, hoc ipso turpia sunt, and to feel that, in beauty, wholeness is all. But such wholesome hankerings are, it seems likely, merely a phase of our fearful and fragmented age.” Macaulay takes her Latin phrase from this passage in Summa Theologica (trans. T.C. O’Brien): “Beauty must include three qualities: integrity, or completeness--since things that lack something are thereby ugly; right proportion or harmony; and brightness—we call things bright in colour beautiful.”
