Jim Nielsen’s Blog

You found my experimental HTML feed (there are also other ways to subscribe).

I HTML

Recent posts

Unresponsive Buttons on My Fastest Hardware Ever

View

This is one of those small things that drives me nuts.

Why? I don’t know. I think it has something to do with the fact that I have a computer that is faster than any computer I’ve ever used in my entire life — and yet, clicking on buttons results in slight but perceptible delays.

Let me explain.

Imagine a button that looks like this:

<Button
  onClick={async () => {
    const data = await getSessionUrlFromStripe(id);
    window.location = data.url;
  }
>Upgrade to Pro</Button>

For SPA apps, when the user clicks that button it takes a split second (even on a fast connection) for anything to happen because:

  • The browser makes a request to the server
  • The server talks to Stripe to get a session
  • The server responds with the session data to the client
  • The client redirects

When clicking on that button, even on a fast connection, my brain glitches for a second, my thought process going something like:

  • I click
  • [nothing happens]
  • I think “Did that work?”
  • Just as I’m about to click again, I see the URL bar change
  • I think, “Oh, ok, it’s doing something.”
  • I stop myself from clicking again while I wait for the UI to redraw

Granted those thoughts occur in my brain in under a second, but I hate that pause of indetermination.

I clicked, I want (perceptibly) instant feedback. If something is happening, tell me!

For SPA apps, you could put some state in there, like:

const [isLoading, setIsLoading] = useState(false);

return (
  <Button
  onClick={async () => {
    setIsLoading(true);
    const data = await getSessionUrlFromStripe(id);
    window.location = data.url;
  }
  >{isLoading ? 'Upgrading...' : 'Upgrade to Pro'}</Button>
)

This would provide more immediate feedback. But it also raises a whole set of other questions:

  • Is that actually the interaction you want, where the text changes? That’s probably gonna shift layout. Maybe you want something different, like a spinner in place of the text. How do you handle that?
  • What if you have multiple places to upgrade? Do you have to implement isLoading state in all those places too? What if the trigger in each place is slightly different? A button here, some text there, and icon over yonder? How do you handle all of those different interactions in a standard, immediate way?
  • Errors. What if it fails? Well, we already weren’t handling that in the first code example were we? But maybe we should…

Oh boy, this is getting complicated isn’t it?

This is why, I assume, lots of apps just don’t deal with it.

They accept there will be a slight delay in the responsiveness of the UI (and that it might error, but the user can just click again) and justify that it’s really not that big of a deal if there’s a slight, almost imperceptible delay between clicking a button and seeing the UI respond.

“We’ve got bigger fish to fry.”

And it makes sense. I mean, a slight delay in UI responsiveness, is that why people will or won’t buy your thing? Seems like a small detail. Who’s got the time to spend on details like this?Who cares?

I care. That’s why I’m writing this post.

To my original point, every piece of hardware I currently own is the fastest version of that device I’ve ever had in my life. And yet, everywhere I go I encounter lag. Lag everywhere.

And I’m grumpy about it, hence this post.


Reply via: Email · Mastodon · Bluesky

A Brief History of App Icons From Apple’s Creator Studio

View

I recently updated my collection of macOS icons to include Apple’s new “Creator Studio” family of icons.

Doing this — in tandem with seeing funny things like this post on Mastodon — got me thinking about the history of these icons.

I built a feature on my icon gallery sites that’s useful for comparing icons over time. For example, here’s Keynote:

(Unfortunately, the newest Keynote isn’t part of that collection because I have them linked in my data by their App Store ID and it’s not the same ID anymore for the Creator Studio app — I’m going to have to look at addressing that somehow so they all show up together in my collection.)

That’s one useful way of looking at these icons. But I wanted to see them side-by-side, so I dug them all up.

Now, my collection of macOS icons isn’t complete. It doesn’t show every variant since the beginning of time, but it’s still interesting to see what’s changed within my own collection.

So, without further ado, I present the variants in my collection. The years labeled in the screenshots represent the year in which I added the to my collection (not necessarily the year that Apple changed them).

For convenience, I’ve included a link to the screenshot of icons as they exist in my collection (how I made that page, if you’re interested).

Keynote:

A horizontal row of Apple Keynote app icons from different years—2014, 2015, 2020, 2021, and 2026—showing the evolution of the blue presentation podium icon from a detailed lectern to a simplified, abstract symbol.

Pages:

A horizontal row of Apple Pages app icons labeled 2014, 2015, 2020, 2021, and 2026, showing the evolution from a detailed pen-on-document icon to a simplified, abstract pen symbol on an orange background.

Numbers:

A horizontal row of Apple Numbers app icons labeled 2015, 2020, 2021, and 2026, showing the evolution from a detailed multicolored bar chart on a grid to a simplified, abstract green bar chart symbol.

Final Cut Pro:

A horizontal row of Apple Final Cut app icons labeled 2012, 2015, 2020, 2025, and 2026, showing the evolution from a detailed clapperboard with a colorful light burst to a simplified purple clapperboard symbol.

Compressor:

A horizontal row of Apple Compressor app icons labeled 2011, 2015, 2020, and 2026, showing the evolution from a detailed metallic clamp over film strips to a simplified, abstract golden compression symbol.

Logic Pro:

A horizontal row of Apple Logic Pro app icons labeled 2013, 2015, 2020, and 2026, showing the evolution from a realistic metallic dial on a dark interface to a simplified, abstract blue control knob symbol.

Motion:

A horizontal row of Apple Motion app icons labeled 2013, 2015, 2020, and 2026, showing the evolution from a detailed, metallic orbital graphic around a color wheel to a simplified, abstract magenta motion symbol.

MainStage:

A horizontal row of Apple MainStage app icons labeled 2012, 2015, 2020, and 2026, showing the evolution from a detailed concert pass with a guitarist silhouette to a simplified, abstract teal stage-control symbol.

Pixelmator Pro:

A horizontal row of Pixelmator app icons labeled 2012, 2015, 2018, 2021, and 2026, showing the evolution from a photo-and-brush motif to a simplified, abstract layered-shapes symbol on a red background.

(Granted, Pixelmator wasn’t one of Apple’s own apps until recently but its changes follow the same pattern showing how Apple sets the tone for itself as well as the ecosystem.)

One last non-visual thing I noticed while looking through these icons in my archive. Apple used to call their own apps in the App Store by their name, e.g. “Keynote”. But now Apple seems to have latched on to what the ecosystem does by attaching a description to the name of the app, e.g. “Keynote: Design Presentations”.

  • Keynote -> Keynote: Design Presentations
  • Pages -> Pages: Create Documents
  • Numbers -> Numbers: Make Spreadsheets
  • Final Cut Pro -> Final Cut Pro: Create Video
  • Compressor -> Compressor: Encode Media
  • Logic Pro -> Logic Pro: Make Music
  • MainStage -> MainStage: Perform Live
  • Pixelmator Pro -> Pixelmator Pro: Edit Images

Reply via: Email · Mastodon · Bluesky

Study Finds Obvious Truth Everybody Knows

View

Researchers at Anthropic published their findings around how AI assistance impacts the formation of coding skills:

We found that using AI assistance led to a statistically significant decrease in mastery […] Using AI sped up the task slightly, but this didn’t reach the threshold of statistical significance.

Wait, what? Let me read that again:

using AI assistance led to a statistically significant decrease in mastery

Ouch.

Honestly, the entire articles reads like those pieces you find on the internet with titles such as “Study Finds Exercise Is Good for Your Health” or “Being Kind to Others Makes People Happier”.

Here’s another headline for you: Study Finds Doing Hard Things Leads to Mastery.

Cognitive effort—and even getting painfully stuck—is likely important for fostering mastery.

We already know this. Do we really need a study for this?

So what are their recommendations? Here’s one:

Managers should think intentionally about how to deploy AI tools at scale

Lol, yeah that’s gonna happen. You know what’s gonna happen instead? What always happens when organizational pressures and incentives are aligned to deskill workers.

Oh wait, they already came to that conclusion in the article:

Given time constraints and organizational pressures, junior developers or other professionals may rely on AI to complete tasks as fast as possible at the cost of skill development

AI is like a creditor: they give you a bunch of money and don’t talk about the trade-offs, just the fact that you’ll be more “rich” after they get involved.

Or maybe a better analogy is Rumpelstilskin: the promise is gold, but beware the hidden cost might be your first-born child.


Reply via: Email · Mastodon · Bluesky

Saying “No” In an Age of Abundance

View

You’ve probably heard this famous quote from Steve Jobs about saying ‘no’:

People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.

But wait, we have AI now. We don’t have to say no to 1,000 things. We can say yes to all the things — generate them all, simultaneously!

Do you really have to “pick carefully” when AI can materialize everything you previously would’ve been too constrained to do?

Generative technology paired with being “data-driven” means it’s easy to build every idea, ship it, measure it, and see what sticks.

Humans, money, time — these all used to be constraints which required budgets, trade-offs, and decision making.

Organizations had an incentive to say “no” when development was constrained — “We can only do so much, so let’s make sure we do the most impactful things.”

But maybe the scarcity of organizational resources was the wrong focus all along?

It’s never been a good idea to ship everything you think of. Every addition accretes complexity and comes with a cognitive cost.

Maybe we need to reframe the concept of scarcity from us, the makers of software, to them, the users of software. Their resources are what matter most:

  • Attention (too many features and they can’t all be used, or even tried)
  • Stability (too much frequent change is an impediment to learning a product)
  • Clarity (too many options creates confusion and paralysis)
  • Coherence (too many plots and subplots cannot tell a unified story)

So maybe the way you argue for saying “no” isn’t because it helps you as a business, but because it helps your customers. It helps them make sense of what you’ve made.

And yet: arguing for customer clarity has always been harder than arguing for internal efficiency or some bottom line.

In an age of abundance, restraint becomes the only scarce thing left, which means saying “no” is more valuable than ever.

I’m as proud of the things I haven’t generated as the things I have.


Reply via: Email · Mastodon · Bluesky

The Browser’s Little White Lies

View

So I’m making a thing and I want it to be styled different if the link’s been visited.

Rather than build something myself in JavaScript, I figure I’ll just hook into the browser’s mechanism for tracking if a link’s been visited (a sensible approach, if I do say so myself).

Why write JavaScript when a little CSS will do? So I craft this:

.entry:has(a:visited) {
  opacity: .5;
  filter: grayscale(1);
}

But it doesn’t work.

:has() is relatively new, and I’ve been known to muff it, so it’s probably just a syntax issue.

I start researching.

Wouldn’t you know it? We can’t have nice things. :visited doesn’t always work like you’d expect because we (not me, mind you) exploited it.

Here’s MDN:

You can style visited links, but there are limits to which styles you can use.

While :has() is not mentioned specifically, other tricks like sibling selectors are:

When using a sibling selector, such as :visited + span, the adjacent element (span in this example) is styled as though the link were unvisited.

Why? You guessed it. Security and privacy reasons.

If it were not so, somebody could come along with a little JavaScript and uncover a user’s browsing history (imagine, for example, setting styles for visited and unvisited links, then using window.getComputedStyle and checking style computations).

MDN says browsers tell little white lies:

To preserve users' privacy, browsers lie to web applications under certain circumstances

So, from what I can tell, when I write .entry:has(a:visited) the browser is telling the engine that handles styling that all .entry items have never been :visited (even if they have been).

So where does that leave me?

Now I will abandon CSS and go use JavaScript for something only JavaScript can do.

That’s a good reason for JS.


Reply via: Email · Mastodon · Bluesky

The Don’t “Contact Us” Page

View

Nic Chan comes out as the whistleblower on how many “Contact Us” pages are made (spoiler: they’re designed to keep us from contacting anyone).

A “fuck off contact page” is what a company throws together when they actually don’t want anyone to contact them at all. They […] are trying to reduce the amount of money they spend on support by carefully hiding the real support channels […] If you solve your own problem by reading the knowledge base, then this is a win for the company. They don’t want to hear from you, they want you to fuck off.

It’s true. This is how the proverbial sausage is made. I’ve been there. I’ve seen these decisions handed down. Which means, like Chan, I know how to read between the lines of most “Contact Us” pages on the internet.

I’m not sure about you, but as a user, when I see [these kinds of pages], knowing that whatever my original query was, [I know] I’m going to have to solve it unassisted.

My process follows this arc:

  • I have a question.
  • Go to the company’s “Contact Us” page.
  • Immediately intuit from the design of the page whether I’m actually going to be able to contact someone and get help, or if I’m on my own.

A direct line to a human is the ultimate luxury in today’s world.

The project finished on time, everyone got paid, and the client was happy with the end result, but I still felt very disappointed in the whole thing.

So it goes.


There’s a scene from The Matrix that kept echoing in my head while reading Chan’s post.

There are contact pages, my friends. Endless “Contact Us” pages.

Where human beings no longer exist.

For a long time I probably wouldn’t have believed it, and then I saw the pages made with my own eyes. Watched them remove the ability for human beings to contact one another.

And standing there, facing the pure, automated precision of it all, I came to realize the obviousness of the truth.

What is the “Contact Us” page?

Cost savings.

The “Contact Us” page is a computer-generated dream world, built to keep us from contacting another human in order to save cost and turn a human being into this: a source of revenue.


Reply via: Email · Mastodon · Bluesky

You Can Just Say No to the Data

View

“The data doesn’t lie.”

I imagine that’s what the cigarette companies said.

“The data doesn’t lie. People want this stuff. They’re buying it in droves. We’re merely giving them what they want.”

Which sounds more like an attempt at exoneration than a reason to exist.

Demand can be engineered. “We’re giving them what they want” ignores how desire is shaped, even engineered (algorithms, dark patterns, growth hacking, etc.).

Appealing to data as the ultimate authority — especially when fueled by engineered desire — isn’t neutrality, it’s an abdication of responsibility.

Satiating human desire is not the highest aspiration.

We can do so much more than merely supply what the data says is in demand.

Stated as a principle:

Values over data.

Data tells you what people consume, not what you should make. Values, ethics, vision, those can help you with the “should”.

“What is happening?” and “What should happen?” are two completely different questions and should be dealt with as such.

The more powerful our ability to understand demand, the more important our responsibility to decide whether to respond to it. We can choose not to build something, even though the data suggests we should. We can say no to the data.

Data can tell you what people clicked on, even help you predict what people will click on, but you get to decide what you will profit from.


Reply via: Email · Mastodon · Bluesky

CTA Hierarchy in the Wild

View

The other day I was browsing YouTube — as one does — and I clicked a link in the video description to a book.

I was then subjected to a man-in-the-middle attack, where YouTube put themselves in the middle of me and the link I had clicked:

Screenshot of a webpage that says “Are you sure you want to leave YouTube?” and there are two buttons. On the left is the secondary, de-emphasized button that says “GO TO SITE” and on the right is the primary, visually emphasized button that says “BACK TO YOUTUBE”.

Hyperlinks are subversive. Big Tech must protect themselves and their interests.

But link hijacking isn’t why I’m writing this post.

What struck me was the ordering and visual emphasis of the “call to action” (CTA) buttons. I almost clicked “Back to YouTube”, which was precisely the action I didn’t want.

I paused and laughed to myself.

Look how the design pattern for primary/secondary user interface controls has inverted over time:

  • Classic software:
    • Primary CTA: what’s best for you
    • Secondary CTA: an alternative for you
  • Modern software:
    • Primary CTA: what’s best for us
    • Secondary CTA: what’s acceptable to us

It seems like everywhere I go, software is increasingly designed against me.


Reply via: Email · Mastodon · Bluesky

New Year, New Website — Same Old Me

View

I redesigned my www website. Why?

  • The end of year / holiday break is a great time to work on such things.
  • I wanted to scratch an itch.
  • Websites are a worry stone [gestures at current state of the world]
  • Do I really need a reason? Nope.

I read something along the lines of “If you ship something that shows everything you’ve made, it’s dead on arrival.”

Oooof. I feel that. It’s so hard to make a personal website that keeps up with your own personal evolution and change.

But the hell if I’m not gonna try — and go through many existential crises in the process.

I was chasing the idea of making my “home” page essentially a list of feeds, like:

You get the idea.

The thought was: if I condense the variety of the things I do online into a collection of feeds (hard-coded or live from other sites I publish), then I’ll never be out of date!

Plus I love links. I love following them. I wanted my home page to be the start of a journey, not the end. A jumping off point, not a terminal one.

At least that was the idea behind this iteration.

Behind the Scenes

I built the (static) site using Web Origami.

I loved it! Origami is great for dealing with feeds because it makes fetching data from the network and templating it incredibly succinct.

<h2>Latest from my notes blog</h2>
<ul>
  ${Tree.map(
    (https://notes.jim-nielsen.com/feed.json).items.slice(0,3),
    (note) => `<li><a href="${note.url}">${note.title}</a></li>`
  )}
</ul>

In just those few lines of code I:

  • Fetch a JSON feed over the network
  • Grabbed the 3 most recent entries
  • Turn the data into markup

For example, here’s the code showing my latest blog posts:

Screenshot of Web Origami code on the top and its output on the bottom (a list of blog post links).

And here’s the code showing the latest icons in my iOS collection:

Screenshot of Web Origami code on top and its output on the bottom (a grid of icons).

Beautiful and succinct, isn’t it?

Origami is a static site builder, so to keep my site “up to date” I just set Netlify to build my site every 24 hours which pulls data from a variety of sources, sticks it in a single HTML file, and publishes it as a website.

The “build my site every 24 hours” isn’t quite as easy as you might think. You can use a scheduled function on Netlify’s platform but that requires writing code (which also means maintaining and debugging said code). That seems to be Netlify’s official answer to the question: “How do I schedule deploys?”

I went with something simpler — at least simpler to me.

  • Setup a build hook on Netlify (which you have to do for the schedule function approach anyway).
  • Use Apple’s Shortcuts app to create a shortcut that issues a POST request to my build hook.
  • Use Shortcuts’ “Automation” feature to run that shortcut every day.

So the “cron server” in my case is my iPhone, which works great because it’s basically always connected to the internet. If I go off grid for a few days and my website doesn’t refresh, I’m ok with that trade-off.

A tiny, pink origami bird with the text “Built with Origami”


Reply via: Email · Mastodon · Bluesky

Easy Measures Doing, Simple Measures Understanding

View

In his talk, I like the way Jake Nations pits easy vs. simple:

Easy means you can add it to your system quickly. Simple means you can understand the work that you’ve done.

I like this framing.

Easy means you can do with little effort.

Simple means you can understand what you do with little effort.

In other words: easy measures the effort in doing, while simple measures the effort in understanding the doing.

For example: npm create framework@latest or “Hey AI, build an instagram clone”. These both get you a website with little effort (easy) but do you understand what you just did (simple)?

It’s easy to get complexity, but it’s not easy to get simplicity.

(I get this is arguing semantics and definitions, but I find it to be a useful framing personally. Thanks Jake!)


Reply via: Email · Mastodon · Bluesky