Jim NielsenModify

2025-11-13 03:00:00

This post is a continuation of Paul Kafasis’ post “Tahoe’s Terrible Icons” where he contrasts the visual differences across a number of Apple’s updated icons in macOS Tahoe (a.k.a. the Liquid Glass update).

While Paul’s post mostly covers icons for the apps you’ll find in the primary /Applications folder, there’s also a subset of possibly lesser-known icons in the /System/Library/CoreServices folder which have suffered a similar fate.

When I first got a Mac back in college, one of the things I remember being completely intrigued by — and then later falling in love with — was how you could plumb obscure areas of the operating system and find gems, like the icons for little OS-level apps. You’d stumble on something like the “Add Printer” app and see the most beautiful printer icon you’d ever seen. Who cares what the app did, you could just stare at that icon. Admire it. Take it in. And you’d come away with a sense that the people who made it really cared.

Anyhow, enough reminiscing. Let’s get to the icons. I’m saving these pre-Tahoe icons for posterity’s sake because they’re beautiful. On the left is the pre-Tahoe icon, on the right is Tahoe.

(Psst: I’ve got a long-running collection of icons for iOS and macOS if you want some eye candy.)

/System/Library/CoreServices/AddPrinter

/System/Library/CoreServices/AppleScript Utility

System/Library/CoreServices/Automator Application Stub

/System/Library/CoreServices/Applications/Directory Utility

/System/Library/CoreServices/Erase Assistant

/System/Library/CoreServices/Applications/Expansion Slot Utility

/System/Library/CoreServices/Applications/Folder Actions Setup

/System/Library/CoreServices/Install Command Line Developer Tools

/System/Library/CoreServices/Installer

/System/Library/CoreServices/Setup Assistant

/System/Library/CoreServices/Spotlight

/System/Library/CoreServices/Applications/Ticket Viewer

/System/Library/CoreServices/Widgetkit Simulator

/System/Library/CoreServices/Applications/Wireless Diagnostics

Reply via: Email · Mastodon · Bluesky

2025-11-10 03:00:00

Whenever Apple does a visual refresh in their OS updates, a new wave of icon archiving starts for me.

Now that “Liquid Glass” is out, I’ve begun nabbing the latest icons from Apple and other apps and adding them to my gallery.

Since I’ve been collecting these icons for so long, one of the more interesting and emerging attributes of my collection is the visual differences in individual app icons over time.

For example: what are the differences between the icons I have in my collection for Duolingo? Well, I have a page for that today.

That’ll let you see all the different versions I’ve collected for Duolingo — not exhaustive, I’m sure, but still interesting — as well as their different sizes.

But what if you want to analyze their differences pixel-by-pixel? Turns out, There’s A Web Component For That™️.

Image Compare is exactly what I was envisioning: “A tiny, zero-dependency web component for comparing two images using a slider” from the very fine folks at Cloud Four. It’s super easy to use: some HTML and a link to a script (hosted if you like, or you can vendor it), e.g.

<image-compare>
  <img />
  <img />
</image-compare>
<script src="https://unpkg.com/..."></script>

And just like that, boom, I’ve got a widget for comparing two icons.

For Duolingo specifically, I have a long history of icons archived in my gallery and they’re all available under the /comapre route for your viewing and comparison pleasure.

Wanna see some more examples besides Duolingo? Check out the ones for GarageBand, Instagram, and Highlights for starters. Or, just look at the list of iOS apps and find the ones that are interesting to you (or if you’re a fan of macOS icons, check these ones out).

I kinda love how easy it was for my thought process to go from idea to reality:

• “It would be cool to compare differences in icons by overlaying them…“
• “Image diff tools do this, I bet I could find a good one…“
• “Hey, Cloud Four makes a web component for this? Surely it’s good…”
• “Hey look, it’s just HTML: a <script> tag linking to compiled JS along with a custom element? Easy, no build process required…“
• “Done. Well that was easy. I guess the hardest part here will be writing the blog post about it.”

And I’ve written the post, so this chunk of work is now done.

Reply via: Email · Mastodon · Bluesky

2025-11-08 03:00:00

Over the years, I’ve been chewing on media related to nuclear weapons. This is my high-level, non-exhaustive documentation of my consumption — with links!

• 📖 The Making of the Atomic Bomb by Richard Rhodes.
  • This is one of those definitive histories (it’s close to 1,000 pages and won a Pulitzer Prize). It starts with the early discoveries in physics, like the splitting of the atom, and goes up to the end of WWII. I really enjoyed this one. A definite recommendation.
  • 📖 Dark Sun: The Making of the Hydrogen Bomb by Richard Rhodes is the sequel. If you want to know how we went from atomic weapons to thermonuclear ones, I think this one will do it. It was a harder read for me though. It got into a lot of the politics and espionage of the Cold War and I fizzled out on it (plus my library copy had to be returned, somebody else had it on hold). I’ll probably go pick it up again though and finish it — eventually.
• 📖 The Bomb: A Life by Gerard J. DeGroot
  • This one piqued my interest because it covers more history of the bomb after its first use, including the testing that took place in Nevada not far from where I grew up. Having had a few different friends growing up whose parents died of cancer that was attributed to being “downwinders” this part of the book hit close to home. Which reminds me of:
  • 🎥 Downwinders & The Radioactive West from PBS. Again, growing up amongst locals who saw some of the flashes of light from the tests and experienced the fallout come down in their towns, this doc hit close to home. I had two childhood friends who lost their Dads to cancer (and their families received financial compensation from the gov. for it).
• 📖 Command and Control: Nuclear Weapons, the Damascus Accident, and the Illusion of Safety by Eric Schlosser
  • Read this one years ago when it first came out. It’s a fascinating look at humans bumbling around with terrible weapons.
  • 🎥 Command and Control from PBS is the documentary version of the book. I suppose watch this first and if you want to know more, there’s a whole book for you.
• 📖 Nuclear War: A Scenario by Annie Jacobsen
  • Terrifying.
  • 🎥 House of Dynamite just came out on Netlify and is basically a dramatization of aspects of this book.
• 📖 The Button: The New Nuclear Arms Race and Presidential Power from Truman to Trump by William J. Perry and Tom Z. Collina
  • How did we get to a place where a single individual has sole authority to destroy humanity at a moment’s notice? Interesting because it’s written by former people in Washington, like the Sec. of Defense under Clinton, so you get a taste of the bureaucracy that surrounds the bomb.
• 🎧 Hardcore History 59 – The Destroyer of Worlds by Dan Carlin
  • First thing I’ve really listened to from Dan. It’s not exactly cutting-edge scholarship and doesn’t have academic-level historical rigor, but it’s a compelling story around how humans made something they’ve nearly destroyed themselves with various times. The part in here about the cuban missile crisis is wild. It led me to:
  • 📖 Nuclear Folly: A History of the Cuban Missile Crisis by Serhii Plokhy is a deep look at the Cuban Missile crisis. This is a slow burning audiobook I’m still chewing through. You know how you get excited about a topic and you’re like “I’m gonna learn all about that thing!” And then you start and it’s way more than you wanted to know so you kinda back out? That’s where I am with this one.
• 🎥 The Bomb by PBS.
  • A good, short primer on the bomb. It reminds me of:
  • 🎥 Turning Point: The Bomb and the Cold War on Netflix which is a longer, multi-episode look at the bomb during the Cold War.
• 📝 Last, but not least, I gotta include at least one blog! Alex Wellerstein, a historian of science and creator of the nukemap, blogs at Doomsday Machines if you want something for your RSS reader.

Phew!

This isn’t exhaustive, but if you’ve got recommendations I didn’t mention, send them my way.

Reply via: Email · Mastodon · Bluesky

2025-11-03 03:00:00

Authentication on the web is a complicated problem. If you’re going to do it yourself, there’s a lot you have to take into consideration.

But odds are, you’re building an app whose core offering has nothing to do with auth. You don’t care about auth. It’s an implementation detail.

So rather than spend your precious time solving the problem of auth, you pay someone else to solve it.

That’s the value of SaaS.

What would be the point of paying for an authentication service, like workOS, then re-implementing auth on your own? They have dedicated teams working on that problem. It’s unlikely you’re going to do it better than them and still deliver on the product you’re building.

There’s a parallel here, I think, to building stuff in the browser.

Browsers provide lots of features to help you deliver good websites fast to an incredibly broad and diverse audience.

Browser makers have teams of people who, day-in and day-out, are spending lots of time developing and optimizing their offerings.

So if you leverage what they offer you, that gives you an advantage because you don’t have to build it yourself.

You could build it yourself. You could say “No thanks, I don’t want what you have. I’ll make my own.”

But you don’t have to. And odds are, whatever you do build yourself, is not likely to be as fast as the highly-optimized subsystems you can tie together in the browser.

And the best part? Unlike SaaS, you don’t have to pay for what the browser offers you.

And because you’re not paying, it can’t be turned off if you stop paying.

@view-transition, for example, is a free API that’ll work forever.

That’s a great deal. Are you taking advantage?

Reply via: Email · Mastodon · Bluesky

2025-10-27 03:00:00

I was watching Alex Petros’ talk and he has a slide in there titled “Incantations that make HTML work correctly”.

This got me thinking about the basic snippets of HTML I’ve learned to always include in order for my website to work as I expect in the browser — like “Hey I just made a .html file on disk and am going to open it in the browser. What should be in there?”

This is what comes to mind:

<!doctype html>
<html lang="en">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1.0">

Why each?

doctype

<!doctype html>

Without <!doctype html>, browsers may switch to quirks mode, emulating legacy, pre-standards behavior. This will change how calculations work around layout, sizing, and alignment.

<!doctype html> is what you want for consistent rendering. Or <!DOCTYPE HTML> if you prefer writing markup like it’s 1998. Or even <!doCTypE HTml> if you eschew all societal norms. It’s case-insensitive so they’ll all work.

html lang

<html lang="en">

Declare the document’s language. Browsers, search engines, assistive technologies, etc. can leverage it to:

• Get pronunciation and voice right for screen readers
• Improve indexing and translation accuracy
• Apply locale-specific tools (e.g. spell-checking)
• And more…

Omit it and things will look ok, but lots of basic web-adjacent tools might get things wrong. Specifying it makes everything around the HTML work better and more accurately, so I always try to remember to include it.

meta utf-8

This piece of info can come back from the server as a header, e.g.

return new Response(
    "<!doctype html><h1>Hello world</h1>",
    {
        status: 200,
        headers: { "Content-Type": "text/html; charset=utf-8" },
    }
);

But I like to set it in my HTML, especially when I’m making files on disk I open manually in the browser.

<meta charset="utf-8">

This tells the browser how to interpret text, ensuring characters like é, ü, and others display correctly.

So many times I’ve opened a document without this tag and things just don’t look right — like my smart quotes.

For example: copy this snippet, stick it in an HTML file, and open it on your computer:

<!doctype html>
<h1>Without meta utf-8</h1>
<dl>
  <dt>Smart quotes</dt>
  <dd>“” and ‘’</dd>
  <dt>Symbols</dt>
  <dd>©, ™, ®, etc.</dd>
  <dt>Ellipsis</dt>
  <dd>…</dd>
  <dt>Emojis</dt>
  <dd>👍</dd>
  <dt>Non-latin characters</dt>
  <dd>é, ñ, etc.</dd>
</dl>

Things might look a bit wonky. But stick a <meta charset="utf-8"> tag in there and you’ll find some relief.

Meta viewport

<meta name="viewport" content="width=device-width,initial-scale=1.0">

Sometimes I’ll quickly prototype a little HTML and think, “Great it’s working as I expect!” Then I go open it on mobile and everything looks tiny — “[Facepalm] you forgot the meta viewport tag!”

Take a look at this screenshot, where I forgot the meta viewport tag on the left but included it on the right:

That ever happen to you? No, just me? Well anyway, it’s a good ‘un to include to make HTML work the way you expect.

Last But Not Least…

I know what you’re thinking, I forgot the most important snippet of them all for writing HTML:

<div id="root"></div>
<script src="bundle.js"></script>

Lol.

Reply via: Email · Mastodon · Bluesky

2025-10-25 03:00:00

Chris Coyier wrote about it.

Now it’s my turn.

Last week I’m flying home.

My flight gets delayed in air, then lands late so I miss my connecting flight…

[Skip over all the stuff about airline customer support, getting rebooked, etc.]

It’s ~10pm and I’m stranded overnight. I need a last-minute hotel room.

I figure I’ll try HotelTonight because that’s their shtick, right? “Incredible last-minute hotel deals” says their homepage hero banner.

I find the closest hotel, click “Purchase” it takes me to checkout, I do the whole Apple Pay thing, then it says “failed to book” because there are no more rooms left.

Ok? Would’ve been nice to know that before going through all the checkout stuff, but ok. I’ll find another.

Two more hotels, same deal. Click through, checkout, blah blah blah, payment won’t go through. It says there are no more rooms left.

No I’m getting frustrated. I’ll try one more time…

Same flow. Finally! Payment goes through. Confirmation number and all — I’m good to go!

I leave the airport and get a rideshare to the hotel.

Go up to the desk. “Yes, I’m checking in please.” They ask for my name. I give it.

They can’t find me.

“Oh, no…” I think.

“Do you have a reservation number?”

Hell yes I do! Right here in the email HotelTonight sent me.

I give it to them.

It’s not in their system.

“Ok well, can you get me a room?”

Nope, they are completely full for the night.

Knowing that I booked through a third-party system, and it’s not in the first-party system, I know there’s no chance I’m getting a room.

So now it’s 10:30pm. I’m in the lobby of the hotel for which I have a bogus confirmation and I begin my search for the next-closest hotel.

I know at this point I’m not using anything internet-based to make a reservation. Over-the-phone only!

I call a bunch of nearby hotels. Every one is giving me their automated phone system — “If you want to book a reservation, press 1. If you want to…”

I sit through the first couple calls and eventually connect to a human: “Do you have any rooms available tonight?”

“Yes sir, can you confirm which location you are calling for?” They don’t know because this isn’t someone at the hotel. This is a call center somewhere.

I quickly realize this ain’t gonna work.

New rule: if the number online is a centralized number that gives me your automated phone system, I’m out. Next hotel.

I just need to connect to a human at a front desk.

I call maybe 12 hotels. About two give me humans at the front desk. Both of those are booked solid for the night.

But you know what? Props to those hotels for having direct lines to a human. YUGE props.

A direct line to a human feels like the ultimate luxury at this point.

“Hey you got any rooms tonight? No? That’s ok. I appreciate you being there to answer my call, friend. You have a good night.”

Eventually I find a hotel 20 minutes down the road where somebody at the front desk answers and says they have a room. “It’s twice the cost since it’s our last room.” I don’t care, I book it. This is a phone call with a person at the front desk, I know I’m getting a room.

Postscript: I also spent several days going back and forth with a rep at HotelTonight to get a refund. I guess it’s hard to prove that their system sold me a room that did not exist.

Reply via: Email · Mastodon · Bluesky