Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Jim Nielsen’s Blog
So here I am playing with CSS view transitions (again). I’ve got Dave Rupert’s post open in one tab, which serves as my recurring reference for the question, “How do you get these things to work again?” I’ve followed Dave’s instructions for transitioning the page generally and am now working on individual pieces of UI specifically. I feel like I’m 98% of the way there, I’ve just hit a small bug. It’s small. Many people might not even notice it. But I do and it’s bugging me. When I transition from one page to the next, I expect this “active page” outline to transition nicely from the old page to the new one. But it doesn’t. Not quite. Did you notice it? It’s subtle and fast, but it’s there. I have to slow my ::view-transition-old() animation timing waaaaay down to see catch it. The outline grows proportionally in width but not in height as it transitions from one element to the next. I kill myself on trying to figure out what this bug is. Dave mentions in his post how he had to use fit-content to fix some issues with container changes between pages. I don’t fully understand what he’s getting at, but I think maybe that’s where my issue is? I try sticking fit-content on different things but none of it works. I ask AI and it’s totally worthless, synthesizing disparate topics about CSS into a seemingly right on the surface but totally wrong answer. So I sit and think about it. What’s happening almost looks like some kind of screwy side effect of a transform: scale() operation. Perhaps it’s something about how default user agent styles for these things is animating the before/after state? No, that can’t be it… Honestly, I have no idea. I don’t know much about CSS view transitions, but I know enough to know that I don’t know enough to even formulate the right set of keywords for a decent question. I feel stuck. I consider reaching out on the socials for help, but at the last minute I somehow stumble on this perfectly wonderful blog post from Jake Archibald: “View transitions: Handling aspect ratio changes” and he’s got a one-line fix in my hands in seconds! The article is beautiful. It not only gives me an answer, but it provides really wonderful visuals that help describe why the problem I’m seeing is a problem in the first place. It really helps fill out my understanding of how this feature works. I absolutely love finding writing like this on the web. So now my problem is fixed — no more weirdness! If you’re playing with CSS view transitions these days, Jake’s article is a must read to help shape your understanding of how the feature works. Go give it a read. Email · Mastodon · Bluesky
I’m currently looking to add a search feature to my blog. It’s a client-side approach, which means I was planning on using my favorite progressive-enhancement technique for client-side only search: you point a search form at Google, scope the results to your site, then use JavaScript to intercept the form submission and customize the experience on your site to your heart’s content. <form action="https://www.google.com/search"> <input type="text" name="q" placeholder="Search" /> <input type="hidden" name="as_sitesearch" value="blog.jim-nielsen.com" /> <button type="submit">Search</button> </form> <script> document.querySelector("form").addEventListener("submit", (e) => { e.preventDefault(); // Do my client-side search stuff here // and stay on the current page }); </script> However, then I remembered that Google Search no longer works without JavaScript which means this trick is no longer a trick. [1] But have no fear, other search engines to the rescue! DuckDuckGo, for example, supports this trick. Tweak some of the HTML from the Google example and it’ll work: <form action="https://duckduckgo.com"> <input type="text" name="q" placeholder="Search" /> <input type="hidden" name="sites" value="blog.jim-nielsen.com" /> <button type="submit">Search</button> </form> <script> document.querySelector("form").addEventListener("submit", (e) => { e.preventDefault(); // Do my client-side search stuff here // and stay on the current page }); </script> Yahoo also supports this trick, but not Bing. You can point people at Bing, but you can’t scope a query to your site only with an HTML form submission alone. Why? Because you need two search params: 1) a “query” param representing what the user typed into the search box, and 2) a “site search” param to denote which site you want to limit your results to (otherwise it’ll search the whole web). From a UI perspective, if a search box is on your site, user intent is to search the content on your site. You don’t want to require people to type “my keywords site:blog.jim-nielsen.com” when they’re using a search box on your site — that’s just silly! That’s why you need a second search parameter you can set yourself (a hidden input). You can’t concatenate something onto the end of a user’s HTML form submission. (What they type in the input box is what gets sent to the search engine as the ?q=... param.) To add to the q param, you would need JavaScript — but then that defeats the whole purpose of this exercise in the first place! Anyhow, here are the search parameters I found useful for search engines that will support this trick: DuckDuckGo: Query: q Site search param: sites Yahoo Query: p Site search param: vs I made myself a little test page for trying all these things. Check it out (and disable JS) if you want to try yourself! Not only that, but the as_sitesearch search param doesn’t seem to work anymore either. I can’t find any good documentation on what happened to as_sitesearch, but it seems like you’re supposed to use the “programmable search” now instead? Honestly I don’t know. And I don’t care enough to find out. ⏎ Email :: Mastodon :: Bluesky #progressiveEnhancement
Hidde de Vries gave a great talked titled “Creativity cannot be computed” (you can checkout the slides or watch the video). In his slides he has lots of bullet points that attempt to define what art is, and then in the talk he spends time covering each one. Here’s a sampling of the bullet points: Art isn't always easy to recognize Art has critics Art is fuzzy Art can make us think Art can make the artist think Art can make the audience think Art can show us a mirror to reflect Art can move us Art can take a stance Art can be used to show solidarity Art can help us capture what it's like to be another person I love all his bullet points. In fact, they got me thinking about websites. I think you could substitute “website” for “art” in many of his slides. For example: Art is repeated So are websites. Think of all those websites that follow the same template. Art may contain intentions Like the intent to purposely break best practices. Art can show us futures we should not want Or the present we currently have. Art doesn’t have to fit in You can make any kind of website. It gives you agency to respond to the world the way you want, not just by “liking” something on social media. Me personally, I’ve made little websites meant to convey my opinion on social share imagery or reinforce the opinion I share with others on the danger of normalizing breakage on the web. Each of those could’ve been me merely “liking” someone else’s opinion. Or I could’ve written a blog post. Or, as in those cases, I instead made a website. Art can insult the audience It doesn’t have to make you happy. Its purpose can be to offend you, or make you outraged and provoke a response. It can be a mother fucking website. Of course, as Hidde points out, a website doesn’t have to be all of these. It also doesn’t have to be any of these. Art — and a website — is as much about the artist and the audience as it is about the artifact. It’s a reflection of the person/people making it. Their intentions. Their purpose. How’d you make it? Why’d you make it? When’d you make it? Each of these threads run through your art (website). So when AI lets you make a website with the click of a button, it’s automating away a lot of the fun art stuff that goes into a website. The part where you have to wrestle with research, with your own intentions and motivations, with defining purpose, with (re)evaluating your world view. Ultimately, a website isn’t just what you ship. It’s about who you are — and who you become — on the way to shipping. So go explore who you are. Plumb the bottomless depths of self. Make art, a.k.a make a website. Email :: Mastodon :: Bluesky
Quoting myself from former days on Twitter: Businesses have a mental model of what they do. Businesses build software to help them do it—a concrete manifestation of their mental model. A gap always exists between these two. What makes a great software business is their ability to keep that gap very small. I think this holds up. And I still think about this idea (hence this post). Software is an implementation of human understanding — people need X, so we made Y. But people change. Businesses change. So software must also change. One of your greatest strengths will be your ability to adapt and evolve your understanding of people’s needs and implement it in your software. In a sense, technical debt is the other side of this coin of change: an inability to keep up with your own metamorphosis and understanding. In a way, you could analogize this to the conundrum of rocket science: you need fuel to get to space, but the more fuel you add, the more weight you add, and the more weight you add, the more fuel you need. Ad nauseam. It’s akin to making software. You want to make great software for people’s needs today. It takes people, processes, and tools to make software, but the more people, processes, and tools you add to the machine of making software, the less agile you become. So to gain velocity you add more people, processes, and tools, which…you get the idea. Being able to build and maintain pliable software that can change and evolve at the same speed as your mental model is a superpower. Quality in code means the flexibility to change. Email :: Mastodon :: Bluesky
More in design
Why Icons Alone Aren’t Enough I’m a firm believer in text labels. Interfaces are over-stuffed with icons. The more icons we have to scan over, the more brain power we put toward making sense of them rather than using the tools they represent. This slows us down, not just once, but over and over again. While it may feel duplicative to add a text label, the reality is that few icons are self-sufficient in communicating meaning. The Problems that Icons Create 1. Few icons communicate a clear, singular meaning immediately It’s easy to say that a good icon will communicate meaning — or that if an icon needs a text label, it’s not doing its job. But that doesn’t take into consideration the burden that icons — good or bad — put on people trying to navigate interfaces. Even the simplest icons can create ambiguity. While a trash can icon reliably communicates “delete,” what about the common pencil icon. Does it mean create? Edit? Write? Draw? Context can help with disambiguation, but not always, and that contextual interpretation requires additional cognitive effort. When an icon’s meaning isn’t immediately clear, it slows down our orientation within an interface and the use of its features. Each encounter requires a split-second of processing that might seem negligible but accumulates across interactions. 2. The more icons within an interface, the more difficult it can be to navigate. As feature sets grow, we often resort to increasingly abstract or subtle visual distinctions between icons. What might have worked with 5-7 core functions becomes unmanageable at 15-20 features. Users must differentiate between various forms of creation, sharing, saving, and organizing - all through pictorial representation alone. The burden of communication increases for each individual icon as an interface’s feature set expands. It becomes increasingly difficult to communicate specific functions with icons alone, especially when distinguishing between similar actions like creating and editing, saving and archiving, or uploading and downloading. 3. Icons function as an interface-specific language within a broader ecosystem. Interfaces operate within other interfaces. Your application may run within a browser that also runs within an operating system. Users must navigate multiple levels of interface complexity, most of which you cannot control. When creating bespoke icons, you force users to learn a new visual language while still maintaining awareness of established conventions. This creates particular challenges with standardized icon sets. When we use established systems like Google’s Material Design, an icon that represents one function in our interface might represent something entirely different in another application. This cross-context confusion adds to the cognitive load of icon interpretation. Why Text Labeling Helps Your Interface 1. Text alone is usually more efficient. Our brains process familiar words holistically rather than letter-by-letter, making them incredibly efficient information carriers. We’ve spent our lives learning to recognize words instantly, while most app icons require new visual vocabulary. Scanning text is fundamentally easier than scanning icons. A stacked list of text requires only a one-directional scan (top-to-bottom), while icon grids demand bi-directional scanning (top-to-bottom and left-to-right). This efficiency becomes particularly apparent in mobile interfaces, where similar-looking app icons can create a visually confusing grid. 2. Text can make icons more efficient. The example above comes from Magnolia, an application I designed. On the left is the side navigation panel without labels. On the right is the same panel with text labels. Magnolia is an extremely niche tool with highly specific features that align with the needs of research and planning teams who develop account briefs. Without the labels, the people who we created Magnolia for would likely find the navigation system confusing. Adding text labels to icons serves two purposes: it clarifies meaning and provides greater creative freedom. When an icon’s meaning is reinforced by text, users can scan more quickly and confidently. Additionally, designers can focus more on the unity of their interface’s visual language when they’re not relying on icons alone to communicate function. 3. Icons are effective anchors in text-heavy applications. Above is another example from Magnolia. Notice how the list of options on the right (Export, Regenerate, and History) stands out because of the icons, but the text labels make it immediately clear what these things do. See, this isn’t an argument for eliminating icons entirely. Icons serve an important role as visual landmarks, helping to differentiate functional areas from content areas. Especially in text-heavy applications, icons help pull the eye toward interactive elements. The combination of icon and text label creates clearer affordances than either element alone. Finding the Balance Every time we choose between an icon and a text label, we’re making a choice about cognitive load. We’re deciding how much mental energy people will spend interpreting our interfaces rather than using them. While a purely iconic interface might seem simple and more attractive, it often creates an invisible tax on attention and understanding. The solution, of course, isn’t found in a “perfect” icon, nor in abandoning icons entirely. Icons remain powerful tools for creating visual hierarchy and differentiation. Instead, we need to be more thoughtful about when and how we deploy them. The best interfaces recognize that icons and text aren’t competing approaches but complementary tools that work best in harmony. This means considering not just the immediate context of our own interfaces, but the broader ecosystem in which they exist. Our applications don’t exist in isolation — they’re part of a complex digital environment where users are constantly switching between different contexts, each with its own visual language. The next time you’re tempted to create yet another icon, or to remove text labels, remember: the most elegant solution isn’t always the one that looks simple — it’s the one that makes communication and understanding feel simple.
Challenge: Create a private label for the legendary sixth-floor Food Hall at KaDeWe — also known as the culinary heaven...
Last semester at university we were given a really cool task. We had to choose an existing company that distributes...
Check out the light in my office right now 🤩 . AI effectively, but to understand how it fits into the larger patterns of human creativity and purpose. That’s a good thing — designers are good observers. No matter what the tech, we notice patterns we notice the lack of them. So in the midst of what is likely a major, AI-driven transition for us all, it’s worth considering that the future of design won’t be about human versus machine, but about understanding the pattern language that emerges when both intelligences work together in a system. As Christopher Alexander and his cohort might have said, it will be about creating a new kind of wholeness — one that honors both the computational power of AI and the nuanced wisdom of human experience.
