Full Width 
FOCUS MODE
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Jim Nielsen’s Blog
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
I’ve been reading listening to Poor Charlie’s Almanack which is a compilation of talks by Charlie Munger, legendary vice-chairman at Berkshire Hathaway. One thing Charlie talks about is what he calls “sit on your ass investing” which is the opposite of day trading. Rather than being in the market every day (chasing trends, reacting to fluctuations, and trying to time transactions) Charlie advocates spending most of your time “sitting on your ass”. That doesn’t mean you’re doing nothing. It means that instead of constantly trading you’re spending your time in research and preparation for trading. Eventually, a top-tier opportunity will come along and your preparation will make you capable of recognizing it and betting big. That’s when you trade. After that, you’re back to “sitting on your ass”. Trust your research. Trust your choices. Don’t tinker. Don’t micromanage. Don’t panic. Just let the compounding effects of a good choice work in your favor. Day Trading, Day Developing As a day trader your job is to trade daily (it’s right there in the job title). If you’re not trading every day — following trends, reacting to fluctuations, timing trades — then what are you even doing? Not your job, apparently. I think it’s easy to view “development” this. You’re a developer. Your job is to develop programs — to write code. If you’re not doing that every single day, then what are you even doing? From this perspective, it becomes easy to think that writing endless code for ever-changing software paradigms is just one develops websites. But it doesn’t have to be that way. Granted, there’s cold-blooded and warm-blooded software. Sometimes you can’t avoid that. But I also think there’s a valuable lesson in Charlie’s insight. You don’t have to chase “the market” of every new framework or API, writing endless glue code for features that already exist or that will soon exist in browsers. Instead, you can make a few select, large bets on the web platform and then “sit on your ass” until the payoff comes later! An Example: Polyfills I think polyfills are a great example of an approach to “sit on your ass” web development. Your job as a developer is to know enough to make a bet on a particular polyfill that aligns with the future of the web platform. Once implemented, all you have to do is sit on your ass while other really smart people who are building browsers do their part to ship the polyfilled feature in the platform. Once shipped, you “sell” your investment by stripping out the polyfill and reap the reward of having your application get lighter and faster with zero additional effort. A big part of the payoff is in the waiting — in the “sitting on your ass”. You make a smart bet, then you sit patiently while others run around endlessly writing and rewriting more code (meanwhile the only thing left for you will be to delete code). Charlie’s business partner Warren Buffett once said that it’s “better to buy a wonderful company at a fair price, than a fair company at a wonderful price”. Similarly, I’d say it’s better to build on a polyfill aligned with the future of the platform than to build on a framework re-inventing a feature of the platform. Get Out Of Your Own Way Want to do “Day Trading Development”? Jump tools and frameworks constantly — “The next one will solve all our problems!” Build complex, custom solutions that duplicate work the web platform is already moving towards solving. Commit code that churns with time, rather than compounds with it. Want to do “Sit on Your Ass Development”? Do the minimum necessary to bridge the gap until browsers catch up. Build on forward-facing standards, then sit back and leverage the compounding effects of browser makers and standards bodies that iteratively improve year over year (none of whom you have to pay). As Alex Russel recommends, spend as little time as possible in your own code and instead focus on glueing together “the big C++/Rust subsystems” of the browser. In short: spend less time glueing together tools and frameworks on top of the browser, and more time bridging tools and APIs inside of the browser. Then get out of your own way and go sit on your ass. You might find yourself more productive than ever! Email · Mastodon · Bluesky
More in design
Abel Design Group’s Waste Connections Level 6 Executive Suite in The Woodlands, Texas, harmoniously blends natural materials and sophisticated design...
Every great design has one organizing detail that unlocks everything else, and the best design leaders never stop looking for it. Every good piece of design has at least one detail that is the “key” to unlocking an understanding of how it works. Good designers will notice that detail right away, while most people will respond to it subconsciously, sometimes never recognizing it for what it is or what it does. These key details are the organizing principles that make everything else possible. They’re rarely the most obvious elements — not the largest headline or the brightest color — but rather the subtle choices that create hierarchy, guide attention, and establish the invisible structure that holds a design together. Sometimes those key details fall into place right away; they may be essential components of how an idea takes its form, or how function shapes a thing. But just as often, these keys are discovered as a designer works through iterations with extremely subtle differences. Sometimes moving elements around in a layout, perhaps even by a matter of pixels, enables a key to do its work, if not reveal itself entirely. Without these organizing details, even technically proficient design falls flat. Elements feel arbitrary rather than purposeful. Visual hierarchy becomes muddy. The viewer’s eye wanders without direction. What separates good design from mediocre design is often nothing more than recognizing which detail needs to be the key — and having the skill to execute it properly and the discipline to clear its path. Seeing the Key in Action Recently, a designer on my team and I reviewed layouts for a series of advertisements in a digital campaign. We’ve enjoyed working with this particular client — an industrial design firm specializing in audio equipment — because their design team is sophisticated and their high standards not only challenge us, but inspire us. (It may seem counter-intuitive, but it’s easier to produce good design for good designers. When your client understands what you do, they may push you harder, but they’ll also know what you need in order to deliver what they want.) The designer had produced a set of ads that visually articulated the idea of choice — an essential psychological element for the customer profile of high-end audio technology — in a simple and elegant way. Two arrows ran in parallel until they diverged, curving in different directions. They bisected the ad space asymmetrically, with one arrow rendered in color veering off toward the left and the other, rendered in white, passing it before turning toward the right. This white arrow was the key. It overpowered the bold, colored arrow by pushing further into the ad space, while creating a clear arc that drew the eye down toward the ad’s copy and call to action. It’s a perfect example of old-school graphic design; it will do its work without being understood by most viewers, but its function is unmistakable once you see it. In reviewing this piece, I saw the key right away. I saw how it worked — what it unlocked. And I also recognized that the designer who made it saw it, too. I could tell based upon his choices of color, the way he positioned the arrows — the only shapes, other than text, in the entire ad — and even the way he had used the curve radius to subtly reference the distinct, skewed and rotated “o” in the brand’s logotype. This kind of sophisticated thinking, where every element serves multiple purposes and connects to larger brand systems, separates competent design from exceptional design. The white arrow wasn’t just directing attention; it was reinforcing brand identity and creating a sense of forward momentum that aligned with the client’s messaging about innovation and choice. The Maturity Trap I’ve often heard it said that as a designer’s career matures, the distance between their responsibility and functional details grows — that design leadership is wielded in service of the “big picture,” unencumbered by the travails of implementation so that it can maintain a purity of service to ideas and strategy. I couldn’t disagree with this more. While it’s true that senior designers must think strategically and guide teams rather than execute every detail personally, this doesn’t mean they should lose touch with the craft itself. The ability to recognize and create key details doesn’t become less important as careers advance — it becomes more crucial for developing teams and ensuring quality across projects. A design director who can’t spot the organizing principle in a layout, or who dismisses pixel-level adjustments as beneath their concern, has lost touch with the foundation of what makes design work. They may be able to talk about brand strategy and user experience in broad strokes, but they can’t guide their teams toward the specific choices that will make those strategies successful. No Big Picture Without Details My perspective is that no idea can be meaningful without being synchronized with reality — as informed by it as it is influential upon it. There is no “big picture” without detail. The grandest strategic vision fails when it’s not supported by countless small decisions made with precision and purpose. No matter how one’s career matures, a designer must at least retain access to the details, if not a regular, direct experience of them. This doesn’t mean micromanaging or doing work that others should be doing. It means maintaining the ability to see how abstract concepts become concrete solutions, to recognize when something is working and when it isn’t, and to guide others toward the key details that will make their work succeed. Without that connection to craft, we become blind to the keys at work — we lock ourselves out of an understanding of the work that could help us develop our teams or ourselves. We lose the ability to distinguish between design that looks impressive and design that actually functions. We can no longer teach what we once knew. The best design leaders I’ve known maintain a hand in the craft throughout their careers. They may delegate execution, but they never lose their eye for the detail that makes everything else work. They understand that leadership in design isn’t about rising above the details — it’s about seeing them more clearly and helping others see them too. Great design has always been about the details. The only thing that changes as we advance in our careers is our responsibility for ensuring those details exist in the work of others. That’s a responsibility we can only fulfill if we never stop looking for the keys ourselves.
In the brand visual system of the online incense brand “TSUNRISE,” we employ a top-and-bottom zoning design approach to create...
This is Part 2 of my LLM series. In Part 1, I discussed how in just a few short years, we went from the childlike joy of creating “Pirate Poetry” to the despair that our jobs would disappear. My main message was to relax a bit, as companies abuse the hype cycle to distort what […]
Albertson’s Reserve offers a range of wines packaged in 4 Litre casks, carefully crafted for everyday convenience. Sourced from South...
