Latest Posts (20 found)
Jim Nielsen 4 days ago

What’s an Icon in 2026?

As icons continue to change across Apple’s platforms, I have thoughts. They mainly revolve around two perspectives: Let’s see if I can articulate my thoughts. In “Create icons with Icon Composer” from WWDC 2025, Lyan Bewry from Apple’s Design Team gives the rationale for why developers should use Apple’s new Icon Composer: Icon design is moving from a past of simply static images, to a future of expressive, multi-layered artworks that respond to user input and adapt between appearances. They’ve become a much richer and more integrated experience on-device. Catch that? Icons are moving from a “static” past to an “expressive, multi-layered […] much richer” future. You may have noticed this in some of Apple’s latest OS releases, how lighting effects, customizations, etc., can all affect what an icon looks like at any given moment within the operating system. So what are these files made by Icon Composer? In the Accidental Tech Podcast episode 699 “Not the Correct Squircle” John Siracusa talks about some of the technical details and differences between app icons in macOS 26 (Tahoe) and 27 (Golden Gate): These files, this format that Apple came up with, it’s a bunch of resources and a recipe. So it’s like bitmaps, vector images, layers, recipes and effects. That’s what it is. And these icons are assembled on the fly by the operating system. It doesn’t burn up bitmaps of them. I take your ingredients, I assembled them, I composite them, I apply your layer effects, and then eventually it renders a bitmap that it keeps in memory somewhere. Who is thinking about backwards compatibility in their icons? Tahoe’s effects are different than 27’s effects […] And also, 27 has effects that 26 doesn’t support. And 26 won't even read the files from 27, which makes everything complicated. Complicated indeed. As noted, the days of a single, static image for icons are over. An app icon is no longer a PNG file. It’s a bit of a Schrödinger’s icon if you will. There’s no longer a universal answer for “What does your app icon look like?” An icon is simultaneously light, dark, glass, tinted, etc.. Only once it is “observed” — that is rendered at runtime on a device with settings applied (user preferences, device angle, etc.) — can you really know what it looks like. An icon now has a runtime. I don’t know. Icons are effective because of their ability to be quickly recognizable and memorable. Visual simplicity and consistency support that. Making something more “expressive” and “richer”, to me, means conveying more. But icons are meant, to a degree, to convey less. Only the essential. That’s what makes them effective. There’s definitely a point where, the more they convey, the less effective they are at their purpose. The more you move away from a singular, visual representation, the more room there is for confusion and greater cognitive effort for discernment. Take, for example, Apple’s Phone app. What’s the icon for it? Can you picture it in your head? It’s a green icon with a white phone glyph. That’s what it was in the original iPhone keynote (and it’s what the Phone app will always be to me). Iconic! But wait! Now it’s also a black icon with a green phone glyph if you’re in dark mode. And there’s more! It’s a clear glass icon with a phone glyph if you’re in clear mode. And! It’s [insert color here] with a phone glyph if you’ve tinted it. Consistent color is a strong ingredient in aiding memorability and recognizability. Look at Coke: Simplicity matters. It aids recognizability and memorability. If you start making it more complicated and more varied, you lose what made it simple, recognizable, and memorable to begin with. And what are app icons but visual tools for immediate recognizability? Anyway, now that app icons have a runtime and will increasingly vary in their appearance, I’m not sure how to archive them anymore. This story is still developing… Reply via: Email · Mastodon · Bluesky What I think of icons as a long-time user of Apple’s platforms. What I think of icons as a digital collector and physical archivist of icons. Red can? Coke Black can? Coke Zero Silver can? Diet Coke

design Design web Web ai AI
0 views
Jim Nielsen 1 weeks ago

Family Feud: Mac-assed Mac App Edition

“We asked 100 people: What are the top three companies on earth best positioned to make a world-class Mac-assed Mac app ?” Survey says: Yes! Apple at the number one spot. Makes sense. Who better to make the very definition of a great Mac app than the people who make the Mac? No brainer, I suppose. Granted, they’ve had some misses , but nobody bats 1000. Ok, let’s keep going. “We asked 100 people: What are the top three companies on earth best positioned to make a world-class Mac-assed Mac app?” “Anthropic!” Survey says: Wow, that’s odd huh? You’d think Anthropic would be right there at number two. Not only do they have billions of dollars, but they also develop, maintain, and control the super intelligence we’ll all soon be subservient too, right? Surely if anyone (besides Apple) is well positioned to make a world-class Mac app, it would have to be Anthropic — right? And yet, here we are with Claude Desktop as an Electron app . Ok, let’s keep going. “We asked 100 people: What are the top three companies on earth best positioned to make a world-class Mac-assed Mac app?” Maybe not . Not so much . I’m sorry, but that’s three strikes. Apparently it’s a mistake to assume that a big company with piles of cash is well poised to make a great Mac app — even if they are enabled by hyper-super-intelligence. “Well who cares? It just goes to show you don’t have to make a good Mac app to be obscenely successful in terms of revenue!” Well, maybe that’s true. Actually, come to think of it, it kinda does seem like the bigger you get and the more money you make, the more likely it is you’re making an Electron app. There seems to be a correlation between “Mac-assed Mac app-edness” and “Company size/revenue”. Why is that? I’ll leave that as an exercise for the reader (though my mind is leaning towards something to do with care ). Thank you for playing reading this game of family feud. Reply via: Email · Mastodon · Bluesky

business Business
0 views
Jim Nielsen 1 weeks ago

Making a Shuffle Button

I made some updates to my notes blog , including a change to how my “Shuffle” feature worked. Figured I’d blog about it. At the time of this writing, I have 974 “notes” that I’ve published. For fun, I have a “shuffle” button that digs up a random note from the past. I like to press it from time to time and re-encounter some insight from the past. It’s like going through an old album, pulling out a random photo, and thinking, “Oh yeah, I remember this! Good times.” Like old photos, there’s also the occasional “that didn’t age so well”. But I find it fun to randomly dig up old insights from others and continue to be inspired. Since my site is built and hosted as static files without a runtime server, this feature required JavaScript to work. Every page had a snippet like this: Essentially: inject every note ID into every HTML page and, when the shuffle button is clicked, randomly grab one and navigate the user to it. Not the most elegant thing, but it worked. The problem was that every time I published a new post, every single page had to be re-uploaded to Netlify because every file’s hash would change and its etag/cache was invalidated. This made my builds slow. It also made it difficult, from a development perspective, to ensure refactors didn’t result in unexpected changes to output (using from my SSG web origami ). So I decided to make a change. Because I love to see if I can make things work without JavaScript, I had the thought to randomly write the at build time using my SSG, which would result in output like this: And every time I re-build my site, just have this logic run on the static site generator so that it’s different for every page, every time. I decided I didn’t want to do this, so on to JavaScript! My first thought was to create a single JSON file that contained all my note IDs. Then when the “Shuffle” button gets clicked, I fetch that, grab a random ID, and navigate the user, e.g. This would work. It localizes the caching issue to a single file, so only one file has to be invalidated/re-uploaded across builds. But in playing with it a little more, I decided to try something a little more...unconventional. I’ve written before about having lots of little HTML pages and I thought, “Can I put this functionality in a single HTML page rather than a JSON file?” And what I ended up with was a link, e.g. That when clicked navigates the user to a new page. That page has all the JS logic embedded in it, e.g. There are a few things I like about the experience this implementation provides. First: shuffle is a route , so I can navigate to it directly without using the GUI, e.g. notes.jim-nielsen.com/shuffle Second: I handle the UI/X with a slight delay to make it appear like something is happening when you click the button. If you click the button and it immediately jumps to the next, randomized page, it almost seems to happen too fast. Like you’re left with this feeling of “What just happened?” But in this scenario, it navigates you to the “Shuffle” page, the button you just clicked turns into a spinner + text indicating something is happening, and there’s a slight (intentional) delay before the JS executes and sends you to a randomized note. I know it’s a bit weird. “Introduce artificial slowness? Are you crazy?” But I like it. It feels like the shuffle feature on an old music player. I remember one of my CD players had a “Shuffle” feature. When I’d click the button, it would display “Shuffling…” on the little black and white screen and you’d encounter this brief state where (I presume) the lens inside the hardware would move along the physical track to the spot where it would start reading a new, random song from the CD. The hardware constraints necessitated this kind of an experience, but I always liked it because it felt like the CD player was “thinking” about what track to pick next. This state clearly conveyed to me that my intent to shuffle was received and being followed. I liked that feedback, and it’s exactly what I wanted to do on my notes site (even though it was completely unnecessary). I like having that brief moment of feedback where it’s very clear that your intention was received and being followed, vs. having it happen so fast you can’t even perceive precisely what happened. Here’s a video to show it in action: I know that’s a lot of information for something so small — and, arguably, unnecessary. But I still enjoy writing about how I make decisions when I build things for myself. Hence this post. Reply via: Email · Mastodon · Bluesky Doesn’t require JavaScript Doesn’t require a server (request-time logic) File hashes change across builds (even if there’s no new content or template changes, every HTML page now has a different for the shuffle link for every build ). This makes deployments way slower because Netlify has to redeploy every file on every build. Plus Etags change so caching is basically ineffectual.

html HTML json JSON programming Programming javascript JavaScript
0 views
Jim Nielsen 2 weeks ago

This Page Left Intentionally Blank

I was popping off about negation being an act of creativity, when Blake Watson introduce me to the idea of the “This Page Intentionally Left Blank”-Project (Internet Archive) : In former times printed manuals had some blank pages, usually with the remark “this page intentionally left blank”. In most cases there had been technical reasons for that. Today almost all blank pages disappeared […] [this project] tries to introduce these blank pages to the Web again […] to offer internet wanderers a place of quietness and simplicity on the overcrowded World Wide Web Ahead of its time. In our age of generative AI, a blank page is a deliberate act! So I went ahead made my own . Go ahead and crawl that bots. I don’t use , but I’m thinking of making one specifically to say “Make sure you don’t miss this page Botty Bot.” Reply via: Email · Mastodon · Bluesky

programming Programming
0 views
Jim Nielsen 2 weeks ago

Notes from Bryan Cantrill’s “Intelligence is not Enough”

I quite enjoyed this talk from Bryan Cantrill where he discusses the difficult engineering problems they overcame while working on their company Oxide . Some of the problems they ran into were bugs. But these weren’t any ordinary bugs, they were company-destroying bugs: bugs that, if they couldn’t be fixed, would sink the entire company. And the difficulty in solving these bugs was that they had no precedent. Any documentation or knowledge they could find around the symptoms of the problem was actively incorrect. In fact, Bryan says that the team’s breakthroughs on these bugs were solutions that an artificial super intelligence would’ve never suggested because they ran against all known and available reasoning, documentation, and knowledge. His point being: intelligence isn’t everything. Human values are still incredibly important. Intelligence alone does not solve problems like [the ones we encountered]. Our ability to solve these problems had nothing to do with our collective intelligence as a team. We’ve got a terrific team, but it’s a lot more than just intelligence. And in particular for these [kinds of] problems, and many like them, we had to summon the elements of our character not our intelligence. Our resilience. Our teamwork. Our rigor. Our optimism. […] We talk about super intelligence, but is anyone talking about super collaboration or super teamwork? We absolutely needed teamwork [at Oxide]. If human values like curiosity are what led to breakthroughs — not the application of synthetic intelligence — why is there so much emphasis on intelligence these days? Bryan has a curt analysis: This infatuation with intelligence comes from people who just don’t get outside enough. He notes how intelligence isn’t everything in a job interview. Like, you don’t hire people by giving out an exam and taking whoever scores highest. You try to suss out other aptitudes. Nobody looks at applicants who lack values like teamwork or optimism and says, “Well, they can’t work with anyone and they’re incredibly unpleasant to be around, but their intelligence is great — let’s hire them!” Intelligence is great, but it’s not everything. We do a disservice to our own humanity when we pretend that [AI] can engineer autonomously. A cogent case for the values of our humanity. More like this please. Reply via: Email · Mastodon · Bluesky

career Career business Business
0 views
Jim Nielsen 3 weeks ago

My Om Malik Story

If you have’t heard, Om Malik passed away . People are sharing stories of their graceful encounters with him. This one is mine. Back at the beginning of 2021, I set a goal to write 72 blog posts . I was puttering along, publishing whatever came to mind, mostly figuring that nobody was reading any of it. But that was ok. The process was therapeutic and it helped clarify my professional thinking, so I kept going. One day on Twitter I got a DM from someone with the handle . “I don’t know who this is,” I thought, “but damn that is a great handle!” Then I peaked at the follower count: over 1 million! “WTF? Who is this???” I thought. I’d never — then or since — been contacted by someone with such a high profile online. How was I even on this person’s radar? I continued on to his message: Jim I wanted to thank you for your blog. I am neither a developer or a designer but appreciate the web, the open web and in general normal, common sense writing from experts. I have quietly enjoyed your work — and hope you hit the target of 72 posts in 2021. My highly selfish ask, as I know it will feed my brain good important stuff. Have a wonderful weekend and a great writing year I was flabbergasted. Who was this person with such a high follower count saying such kind words and I’d never heard of him? I quickly went to Google. He had his own Wikipedia . “Om Malik…tech writer…founded Gigaom!” Ah-ha! I knew Gigaom the company/blog . It shaped a lot of my early exposure to the tech beat. I devoured it. I can still picture the logo in my head! Now I knew the man behind it. Knowledge unlocked! I thanked him graciously for taking the time to send a message whose importance seemed incredibly lopsided in my favor. I quote his message here because I still think about it on occasion. His words then (as well as later ones ) continue to lift me up on days when I feel like an imposter. They remind me of the power of a small act of kindness, even within such a vast world wide web. I still think about his words. I still think about him . I’m sure many will for some time. And that is a legacy. Reply via: Email · Mastodon · Bluesky

journalism Journalism writing Writing career Career
0 views
Jim Nielsen 3 weeks ago

Blogging Can Just Be Stating The Obvious

John Gruber writes about those annoying popups every website seems to have now and while he does a great job tearing into these ubiquitous, user-hostile patterns, one of the things that stood out to me about his piece was this meta commentary on blogging. Here’s John: If you visit a website you should ... see the website . See its content. Be able to read the article whose page you are attempting to visit. Showing a “subscribe to our newsletter” or “accept our fucking cookies” dickover to someone trying to read an article on the web makes no more sense than sending out an email newsletter that only contains a link to read the newsletter on a webpage. A webpage should show the webpage. An email should show the email. I should not have to explain this. It’s funny how often blogging feels like being the little child in the story of The Emperor’s New Clothes . You’re just stating what seems obvious to you. I often look at my own posts and think, “There’s nothing novel, or important, or deep in here at all — is this even worth saying?” A post’s point can seem so glaringly obvious to me (and thus, I presume, others) it feels like a waste of time to even say it. As John says: A webpage should show the webpage. An email should show the email. I should not have to explain this. But then real-world examples of annoyance pile up around you and nobody talks about it, so you finally just have to say it in a post and bring receipts . You feel like someone gone mad: “Is anyone else seeing the same thing I’m seeing? And we’re just ok with this?” Very often, those are the best posts I read from others. So it must be that a key ingredient to blogging is simple: have a willingness to state something that seems obvious to you but nobody else is saying it. Or if someone else is saying it, just link to them and say, “Yes!!! This!!!” Reply via: Email · Mastodon · Bluesky

writing Writing media Media
0 views
Jim Nielsen 3 weeks ago

Consistency, But in Excellence Not Appearance

Consistency serves a purpose in visual design, but it seems to have become the purpose of a lot of visual design. Look no further than these evolutions of macOS icons ( image courtesy of BasicAppleGuy ): The Creator Studio icons are undeniably consistent visually: rounded rectangles, controlled gradients, simplified forms, restrained depth, etc. In contrast (and by modern standards) the originals seem heretically inconsistent. They lack coherence in visual details like shape, material, and lighting. But what they lack in visual consistency between one another, they make up for in excellence individually. In fact, their aversion to familial visual consistency almost seems like an intentional choice — a deliberate augmentation of individual purpose. What purpose? To be singularly representative and deeply iconic. Icons that are iconic . To be iconic, by definition, is to be famously distinctive. None of the Creator Studio icons, especially when held up as a suite, are iconic. None are atypical, they’re merely typical. All in pursuit of what, consistency — amongst each other and across platforms — as the overriding goal? This over-emphasis on “systems” design seems endemic to modern software. Systems prescribe rules because they are the easiest attributes to document, enforce, and automate — “All icons must use this shape, this lighting, this stroke.” Excellence, by contrast, is harder to systematize. It requires judgment, taste, care, experience, and a sensitivity to context — all in service of meaning and purpose, not superficial similarity. When you strive for consistency across a suite, individual elements lose their ability to be exceptional and iconic on their own terms. Consistency for the group becomes a ceiling on individual excellence. But if you flip that, if you make excellence the goal for each individual element, something interesting can happen: excellence becomes your motif of consistency. It’s no longer a consistency of shapes and gradients, but one of quality and intention that serves a deeper meaning and purpose than superficial visuals. Give me a consistency of excellence any day over a consistency of appearance. Reply via: Email · Mastodon · Bluesky

design Design
0 views
Jim Nielsen 3 weeks ago

Full Page Paralysis

You’ve probably heard the term. It’s meant to convey how difficult it can be to start something. “Blank page paralysis”. But for my money, beginning is easy. Finishing is the hard part. In software, they call it “the last 90%”. In logistics, they call it “the last mile”. It’s that final stretch that’s disproportionately hard. Finishing makes something real and finite, subject to judgment. As I near completion, there’s a little voice in my head that says, “As long as it’s unfinished, there’s nothing wrong with it. It’s still potentially perfect!” I don’t struggle with blank page paralysis. But I am paralyzed in the face of a full page ready for publishing. Reply via: Email · Mastodon · Bluesky

career Career writing Writing
0 views
Jim Nielsen 1 months ago

Being “Good” at Things

Golf content on social media is my online junk food and the other day I came across a video interviewing professional golfers that asks: “What does an amateur golfer have to shoot to be considered good?” It’s a leading question because the phrasing implicitly frames a number as the answer for a qualitative measurement , but I digress. All the pros give their answers. Some say you gotta shoot a number in 90’s. Others say the 80’s. Some even say the 70’s. Then along comes Collin Morikawa: I don’t think there’s a number, but I think you have to be able to finish out every hole without, like, picking up a two-footer. Love it! I don’t want to go too deep on a social media golf interview clip, but… I love how he breaks out of the question’s implicit framing and really strikes at the heart of the qualitative question: “What does it mean to be good at golf?” Being “good”, in his eyes, is not shooting a specific number. Numbers are standardized proxies for measurement across a wide variety of players, skill levels, and — to be quite frank — degrees of honesty. Anyone who has played golf knows that scores can be easily manipulated. On a casual outing amongst friends, my “82” may be very different than the “82” of the players in front of me — or even the players in my own group. It all depends on how you play the game. So saying “if you can shoot number ___” is a very lossy picture of what it means to be “good” at golf — at least for amateurs. That’s why I love Morikawa’s answer: if you finish every hole and don’t get a double bogey, you’re “good” at golf. Because guess what? Finishing is the hard part. The consistency. Showing up to every hole, finishing out based on the actual rules of the game, not taking mulligans, not picking up a two-footer and saying “That’s good.” (Or even missing a two-footer and re-putting and giving yourself the make.) Relieving yourself of the exacting burden of the reality of the game is the easy way to play, but it doesn’t make you a better golfer. I think that’s true of so many things we do as humans: programming, design, writing, etc. If you want to be “good” at what you do, do the hard, little things that others gloss over. Do them consistently and well, with discipline and perseverance. If you do, then I’d say you’re “good” at what you do because “good” isn’t a number. It’s quality. A disposition. A way of being. Reply via: Email · Mastodon · Bluesky

sports Sports
0 views
Jim Nielsen 1 months ago

Coding Is Designing

Code isn’t just a way to implement a design, it’s a way to find one. With an interface, you have to use it, feel it, interact with it, and poke at it to see the relationships between things . Change X, see Y react. If it doesn’t feel right, tweak it. Change X again, now Y reacts differently. Keep tweaking — this here, that there, until the relationships of all the disparate elements fall into place as a single whole. Design is “how it works” and code is the tool to specify how it works. Reply via: Email · Mastodon · Bluesky

design Design web-development Web Development
0 views
Jim Nielsen 1 months ago

An Ode to the Exacting Pedantry of Computers

The very first computer programming class I ever took introduced me to the idea of there being different kinds of numbers, like integers, floats, and doubles (it was a C++ course). “You mean, when I assign a variable, I have to say up front what kind of number this is?” It was such an odd concept to me. A number is a number. Why do I have to say it’s this kind of number or that kind of number? I dropped out of that class. A few years later, I decided I wanted to try programming again. So I took another intro class. This time they were teaching with Python instead of C++, so you can imagine my excitement to learn that I didn’t have to think of numbers in this way anymore! It felt like the computer was meeting me partway. Over time, I came to learn how pedantic computers are. They require a kind of exacting precision in saying what you want them to do. And they’ll only ever do exactly what you tell them to do, nothing more, nothing less. If there was a bug in your program, that wasn’t because the computer was doing something you told it not to. The computer was only ever doing exactly what you told it to do. A “bug” was very likely a flaw in your conception of how the program should execute, not the actual execution. It was a failure on your part to be more precise, to imagine a scenario where something happened that you didn’t anticipate — and therefore didn’t tell the program how to handle. “Do what I mean, not what I say!” But now, with LLMs, that kind of exacting precision in language and thought is disappearing. You can have a thought, ask the LLM to build it, and it will fill in all the details you didn’t specify or anticipate. All those pesky details which previously would’ve made you reflect, “Oh, I didn’t think of that. Maybe I should design this differently…” Or, “Oh, well now that I have to think about this some more, I can see that it might not actually be a very good idea…” The pedantic friction, which seemed like such a nuisance, was actually acting as a kind of tool for sharpening and improving your thinking and output. The exacting nature of the computer required you to think more. LLMs, however, have significantly lessened that friction. You can think less and move faster. And yet, that feels like our job as software makers: to think, to anticipate, to explicitly articulate intent. As a software user, I’d rather folks spend more time thinking so that I, in turn, have better experience. This is preferable to giving me more stuff faster that’s only partly conceived. As an industry it feels like we’re headed in a direction where we think it’s better to ship more faster and fix the effects of half-conceived intent later, than to spend more time upfront discovering, sculpting, and specifying intent. That’s one thing writing code by hand has taught me: intent — what you want to build and how you want it to work — is shaped through the act of articulating it. That hard work is not required of us anymore. The LLM will fill in the details. The exacting pedantry of the computer is going away, and in its place are assumptions about intent — many of which we don’t even know about until our users run into their effects. Reply via: Email · Mastodon · Bluesky

python Python ai AI c++ C++ programming Programming
0 views
Jim Nielsen 1 months ago

Book Notes: “Poor Charlie’s Almanack”

I’ve been slowly listening to Poor Charlie’s Almanack: The Essential Wit and Wisdom of Charles T. Munger . I like his practicality. He’s never trying to be overly academic, as if he needs to prove how smart he is. He says Berkshire’s success doesn’t come from them solving hard problems, but from spending their time knowing what a simple solution looks like — and acting on it when they see it! We’ve succeeded by making the world easy for us, not by solving the world’s hard problems. Munger analogizes their approach to investing like jumping a fence. They don’t spend all their time trying to figure out how to jump a seven-foot tall fence. Instead, they find a spot where the fence is only a foot tall, jump it, and take the reward on the other side. The approach he articulates for investing, in fact, seems broadly applicable to any kind of problem solving: Whenever people ask him for advice (as if somehow he could bestow upon them some kind of knowledge that will save them the pain and hardship of experience) he seems anathema to the idea that you can live life without making lots of mistakes. To paraphrase Charlie: “I don’t want you to think that we have a method of learning that will prevent you from making mistakes. The best you can do is learn to make fewer mistakes than others. And then, when you inevitably do make mistakes, learn to acknowledge them and fix them quickly.” Straightforward. Practical. No bullshit. No ego. (Basically the opposite of everything I see on social platforms.) I quite enjoyed his perspective. Reply via: Email · Mastodon · Bluesky Quickly eliminate the universe of what not to do. Follow up with a multi-disciplinary attack on what remains. Act decisively when — and only when — the right circumstances appear.

career Career books Books
0 views
Jim Nielsen 1 months ago

Something’s Rotten in the State of macOS Icon Design

This is an iconic observation : If you put the Apple icons in reverse it looks like the portfolio of someone getting really really good at icon design This isn’t, however, just the story of Apple’s Creator Studio icons. It’s the unfolding story of icon design across the entire macOS platform. For example, take a look at some of Apple’s other apps like iMovie : Or Remote Desktop : Apple sets the standard (and the rules) for how icons look on the Mac. Wherever they go, so goes the ecosystem — and they’re taking the entire ecosystem along down with them. It’s fast becoming the case that if you put any Mac app’s icons in reverse, it looks like the portfolio of someone getting really, really good at icon design. Even Microsoft — not exactly a bastion of design — starts to look pretty decent with their icons the further back you go. For example, with OneNote , the app icon’s progression looks like it went something like this: Some 3rd-party apps continue to fight a good fight, even as Apple’s definition of what an icon should be — or what’s even possible — shrinks all around them. Apps like Capo (remember, these are reverse chronological ): Or BBEdit : Or Fantastical : Or Cot Editor : Everyone’s being put in a box squircle. The imposition is real. I don’t blame any of the 3rd-party app makers. Their designs have to play by Apple’s rules (or end up in icon jail ). World-class designers like Matthew Skiles or The Iconfactory are still out there striving for excellence, even as they’re hamstrung by the Mac’s latest rules. When it comes to icon design on the Mac, the sky is no longer the limit: Apple’s icon design sensibilities are. They set the examples of what world-class icon design should look like, but what do you do when the examples are no longer exemplary? Reply via: Email · Mastodon · Bluesky “I made this with AI” “I tried to make the AI one, but by hand myself” “I don’t need to be constrained by this squircle” “Hey, I’m getting better at this”

design Design
0 views
Jim Nielsen 2 months ago

Building Software Requires Digestion

Here’s Scott Jenson in his insightful piece “The Ma of a New Machine” : the chatbot interface [makes us] feel like deep cognitive work is happening. But the interface is fundamentally reactive. It spits complex text at you, you skim it quickly, and you immediately type a reaction to keep the momentum going. My hypothesis is that the very structure of the chatbot interface (type, read, type again) actively discourages reflection. When you are moving too fast, you get stuck in a groove. You literally need to take a break, step back, and basically step out of this groove so you can view the problem from a new angle. We’ve all walked away from a tough problem only to have the solution arrive unbidden into our thoughts later in the day. In my decades+ experience designing and developing software, I can’t count the number of times I’ve stepped away from a problem at the computer only to return and find the problem magically resolved in my brain. But the human-computer interaction of prompting doesn’t encourage the use of that skill in our subconscious. In fact, I think it actively discourages it (our tools shape us). Scott talks about this Japanese concept called “Ma” which is about deliberately creating pauses between things. He quotes Studio Ghibli director Hayao Miyazaki who says “if you just have non-stop action with no breathing space at all, it’s just busyness.” Here’s Scott (emphasis mine): Ma provides a framework for understanding that a pause is not a lack of work As humans we need pauses. We need space to breathe. We need time to digest. Pausing, breathing, synthesizing, digesting — these are all necessary work . “Digestion” is an interesting word here. Putting food in your body is merely the beginning of feeding yourself. Our bodies must digest that food, break it down, absorb it, and get rid of the waste. But that’s all happening mostly without our attentive oversight, so I guess it’s not “real” work — right? Building good, healthy software requires digestion. Reply via: Email · Mastodon · Bluesky

career Career programming Programming design Design
0 views
Jim Nielsen 2 months ago

Out With the JS, In With the HTML

I’ve been posting about how you can make lots of HTML pages and leverage navigations over in-page, JS-dependent interactions . Now I’m gonna post another example. On my icon sites, I have a little widget that allows you to resize the icons you’re looking at. Previously, I implemented this functionality as a web component that looked something like this: The attribute corresponded to an enumeration like which mapped to actual pixel dimensions like 64×64 or 512×512. When the little widget was clicked to render icons at a different size, JavaScript changed the attribute on the custom element. From there, the web component’s JS took over changing the dimensions of the children elements, their attributes, etc. It all worked pretty well. However, because that was a client-side solution to my otherwise entirely pre-rendered static site, it required some templating logic and data be duplicated and sent over the wire to every client. I didn’t love that for various reasons — like “Crap, I updated this one small part of how my icon list renders on the server, but forgot to tweak it on the client, so things are slightly broken now.” Then one day the thought hit me: instead of relying on JS to make that interaction work (click, execute JS, modify in-page DOM to a new list), what if I just made that interaction a navigation? Click, navigate to a new list. Instead of “every list of icons ships with some JS that allows them to re-render at four different sizes” I could do “every list of icons ships in four different sizes”. So I tried it. And guess what? Once I added some code to support CSS view transitions, I got a cool effect amongst the icons for free — that’s right, by removing code! Works nice on mobile too! I know I’m not doing anything particularly novel here, but as we continue to get new, powerful primitives on the web — like CSS view transitions — I find it really interesting to revisit basic patterns and explore what’s possible now that wasn’t previously. It’s fun to ask yourself: “Could I remove some client-side JS and get a better overall experience?” If the answer is yes, I’ll bet you the development experience (and maintenance burden) is much improved too! Reply via: Email · Mastodon · Bluesky Previously: one page, like , with JS to re-render the icon list based on user interactions. Idea: four pages, like , each a different icon list size.

javascript JavaScript css CSS web-development Web Development html HTML frontend Frontend
0 views
Jim Nielsen 2 months ago

Reminder: You Can Stitch Together Lots of Little HTML Pages With Navigations For Interactions

I wrote about building websites with LLMs — (L)ots of (L)ittle ht(M)l page(s) — and I think it’s time for a post-mortem on that approach: I’ve tweaked a few things from that original post but the underlying idea is still the same, which I would describe as: Avoid in-page interactions that require JavaScript in favor of multi-page navigations that rely on HTML and are enhanced with CSS view transitions (and a dash of JS if/where prudent). As an example, on my blog I have a “Menu”. It doesn’t “expand” or “slide out” or “pop in” or whatever else you can do with JS. Instead, it navigates to an entirely-new page that is focused on just the menu options of my site. I say “navigates” because it’s just a link — — and it functions like a link, but the navigation interaction is enhanced by CSS view transitions. Have a newer device with a modern browser? Great, you get a nicer effect. Have an older device, or an older browser, or JS disabled, Et al.? It’ll still work. If you can follow a link — which is the most fundamental thing a browser can do — it will work. So how’s it all work under the hood? In essence, all the pages have a link to the menu (except the menu page). When you navigate to the menu, that link is changed to an “X” which “closes” the menu. The closing is still just a link (back to ) but it’s enhanced with JS to actually do a “back” in the browser history. This makes it so “opening/closing” the menu doesn’t add an entry to your browser history. As a simplified example, the code looks like this: The checks whether we came to this page as a navigation (mostly likely from within the blog itself) or via a direct visit (i.e. somebody typed it into the URL bar, unlikely but possible) which is how I suss out whether there’s a meaningful run or not. Here’s a video of how it all works, if that’s your thing: While this solution seems simplistic, it was not a simple thing to arrive at. It required me to spend time thinking about what was essential to navigation, how that interaction could work across multiple pages, and how I could ensure page size stayed small so the interaction was both fast and robust while remaining intuitive to use. In other words, the approach shaped the design. Turns out, if you have a website and you think of the browser as a way to navigate documents — rather than a runtime to execute arbitrary code and fetch, compile, and present them — things can be a lot simpler than our tools often prime us to make them. Reply via: Email · Mastodon · Bluesky

frontend Frontend web-development Web Development css CSS tutorial Tutorial html HTML
0 views
Jim Nielsen 2 months ago

Collective Speed Is Not the Summation of Individual Speed

I’ve been thinking about speed which is why Chris Coyier caught my attention in his latest piece discussing how AI might be 10✕ing the speed with which we code, but it’s not making our software 10✕ better: Faster individuals don’t make a fast company My mind immediately went to the 4✕100 relay at the Olympics. (Not sure which race that is? Watch the London 2012 one .) Imagine you were put in charge of winning the 4✕100 relay. All you gotta do is find the four faster sprinters in your country — right? I’m no track and field expert, but I doubt it’s that simple. In a relay race, the baton is arguably the most critical element. Passing it cleanly is vital because if you fumble it you’re easily behind a few meters or maybe even disqualified. So, one could argue, a sprinter’s ability to pass and receive the baton is more important than speed because all the speed in the world won’t help you overcome a dropped baton. (There are other considerations too, like which leg each runner takes, which sequence works best given individual pairings and rapport, and whether a slower veteran might perform better in the heat of the moment.) Faster runners won’t guarantee a faster team. And faster coders won’t guarantee a faster company. Like a relay race, it might be worth giving some thought to the relationships and interfaces between people. Reply via: Email · Mastodon · Bluesky

business Business
0 views
Jim Nielsen 2 months ago

Hook It Up to the Machine

In the early 2000’s, my parents took us on a road trip to Glacier National Park in Montana. We made the journey in our new (used) family van: a green Dodge Caravan whose reputation was soon to become “a lemon”. I was a teenager and didn’t pay a lot of attention to the details of what was happening around me, but I do remember how the van kept overheating. It ran fine on the interstate, but anything under 40MPH had the car’s temperature gauge rising into unsafe zones. I remember stopping in some small town in Montana to get it checked out by a mechanic. He checked it out, took it for a test drive, etc., and told my Dad the reason the car was overheating was because the idling fan wasn’t turning on. At higher speeds, like on the interstate, that was fine because there was enough airflow to keep the engine cool but at lower speeds the car would overheat. The mechanic said he didn’t know why the fan wasn’t turning on. There was nothing wrong mechanically from what he could see. But he couldn't fix it. He told my Dad that this was one of those increasingly common “computerized” cars that you have to hook up to another computer to diagnose the source of the issue. And he didn’t have one of those computers. So we continued on our way. The rest of the trip required my Dad taking “the long way around”, like back roads where he could keep up his speed in order to avoid the car overheating. It was all very amusing to us as kids, almost thrilling because Dad had a legitimate excuse to drive fast (suffice it to say, Mom did not like this). Once the trip was over and we returned home, my Dad was able to get the car in to a dealer where they hooked up the car’s computer to another computer to diagnose and fix the issue. I don’t really remember the specifics, but the issue was seemingly some failed digital sensor that prevented the idling fan from turning on. Once the sensor was replaced, things worked again. Computers talking to computers. Growing up in an era that shifted so many things from analog to digital, mechanical to electronic , I’ve thought about this trip a lot. And I’m thinking about it again in this new era of building software with LLMs. I think about that mechanic. This guy who grew up around mechanical cars that could be physically inspected, diagnosed, and repaired. So much of his experience and knowledge unusable in the face of a computerized car. You can tell when a mechanical switch has failed with your eyes, but not a digital one. You need a computer to help you understand the computer. Will this be my future? If a codebase was made with the assistance of an LLM, will its complexity and bugs only be inspectable, understandable, diagnosable, and fixable with an LLM? “Hey, can you help me, there’s a problem with my codebase?” “Ok, I can confirm the issue, but I can’t fix it without hooking your codebase up to an LLM.” Reply via: Email · Mastodon · Bluesky

Electronics Automotive hardware Hardware
0 views
Jim Nielsen 3 months ago

Speed is Not Conducive to Wisdom

Speed has become the primary virtue of the modern world. Everything is sacrificed to it. Move fast (and break things, not as a goal but as a consequence). Wisdom requires allowing yourself to be undone by experience: Experiencing these can be slow and uncomfortable, but if you keep up your speed you can outrun them — never reflecting on what happened in your wake. Speed is how you avoid reckoning. It guarantees you miss things, and you can’t learn from what you don’t notice. Wisdom’s feedback loop is slow. Wise people I’ve met seem unhurried. I don’t think it’s because they’re slow thinkers or actors. I think it’s because they’ve learned that important things take the time they take, no amount of urgency changes that. Wisdom is chasing all of us, but we’re going too fast to notice what it’s trying to teach us. Reply via: Email · Mastodon · Bluesky An opinion dismantled by reality. An artifact torn apart by the real world. An idea destroyed by its own shortsightedness.

career Career culture Culture
0 views