I have mixed feelings about Raycast announcing their move from the native interface to one powered by web tech (this is the same thing that made Photoshop’s dialogs so bad), but their blog post announcing the change has at least a useful list of some details that separate good native apps from bad web ones.

I think it’s worth checking out that list and internalizing it even if you’re nowhere near that kind of a decision, because some of these are universal requirements for a better-feeling interface:

• No cursor: pointer on interactive controls. Desktop apps don’t do this. It’s small, but it immediately signals “this is a website.”
• No hover highlights on most controls. On macOS, buttons and list items don’t highlight on hover the way they do on the web.
• Settings open in a separate native window, not a modal or a side panel.
• Popovers and tooltips render as native windows, not as DOM elements inside the WebView. They can extend beyond the window bounds, just like native popovers do.
• On macOS Tahoe, we adopted Apple’s new Liquid Glass material so Raycast blends with the system’s updated visual language from day one.
• No flickering when views appear or transition. This is a common tell in web apps, and we did a lot of work to eliminate it.

There is more in the blog post, and a lot more still left unsaid. Let me add one that I see all the time: accidental text selection. Web makes all text selectable by default, regardless of whether it makes sense for that text to be selected. On top of that, text selection heuristics on complex layouts are not that great. That means that surprisingly often you will see half a text on the page being selected in response to an accidental click or drag.

Here’s an example from YouTube I just spotted, where dragging a sidebar selects everything inside it:

It’s all solvable via the use of event cancellation and user-select, but requires someone to think about it happening.

Yes, there are moments where GUIs allow you to select text for a reason…

…but it’s always been a tricky proposition given the scarcity of affordances. It might be better to employ a pretty common “copy to clipboard” pattern instead.

Chrome’s find option, like every search coming from a good home, does something clever with accented characters – it normalizes them:

No matter whether you search with a proper accented character, or with its basic Latin equivalent, all the same stuff matches: The “ø” letter is treated the same as “o” both in the input field, and then in the search itself.

Yet, Chrome’s tab search inexplicably doesn’t do that, which confused me when working on a post about diacritics earlier this week. Here, it should match all four open tabs:

Tab search was introduced years ago; the Occam’s Razor says this isn’t a recent bug, but that the feature has always behaved like this. I filed the bug, but even if it gets fixed quickly, I think this doesn’t reflect well on Chrome’s team. If the right code already exists for ⌘F, why not reuse it? If it cannot be reused, why not repurpose at least its unit tests or the QA process to make sure this doesn’t fall through the cracks? Normalization should be treated as a core property of any search, rather than an optional “nice to have.”

But, Marcin, didn’t you just invalidate your assertion that diacritics actually matter? After all, wouldn’t you input “nestlé” instead of “nestle” if they did?

To this, I have a few answers:

• Input is not output. This is no different than autocorrect, autocomplete, or other IME helpers.
• The very fact that on many keyboards accented characters are hard to input is itself a sign of anglo-centrism of companies that made early typewriters (Remington, which established a lot of European layouts like QWERTZ and AZERTY, employed a person who bragged he didn’t actually speak any languages in a “how hard could it be” way) and then most microcomputers.
• There is this really interesting rule, also known as Postel’s Law: “be conservative in what you output, but liberal in what you accept as input.” It’s not universally applicable – sometimes it’s better to teach the user to be more explicit if it benefits them in the longer run – but it feels appropriate to me here.

Why does it matter specifically for the ⌘F and the tab search experience? I have this personal theory: the simplest the search, the more the users will blame themselves if it doesn’t work, and assume the tab or the string just isn’t there, rather than rewrite their query. That’s what happened to me. I assumed that the tab wasn’t open and tried to get to it again, wasting time and effort.

The rule might be universally true for any UI surface – the tighter it gets, the less likely we assume it can break. After all, there is a manual for a typewriter, but there isn’t one for the pencil! And these UIs do feel positively basic; they are small windows with basically one input field and an immediate as-you-type reaction.

I witnessed this Siemens locomotive depart yesterday and for a second I thought I was losing my mind. Then, I smiled so hard:

Turns out, the startup melody was intentional in this particular model. The power converters have to adapt the current from the overhead line to convert it to the three-phase motors of the locomotive, and that generates a rising tone. The engineers decided to change the logic to increment the tone in precise few steps resembling a musical scale, rather than allowing it to rise continuously.

I debated whether to include this on Unsung. I guess it is software, even if it’s attached to the hardest of hardware. And sure, it’s “just” delightful, but it is still kind of nice to see someone go extra, adding a human touch atop a technical process that had to happen anyway.

But then, it reminded me of something. No, not the poor CSIRAC trying (and similarly struggling) to become a musician. Rather, a “musical road” built in Lancaster, California, where the engineers messed up the execution, creating a truly unpleasant, atonal melody. David Simmons-Duffin wrote a fun essay in 2008 analyzing the “bug” thoroughly, including useful visuals, and even replicating the problem. Subsequently, Tom Scott visited the road and made a video about it ten years later.

It won’t surprise you that the cause of the bug was bad hand-off between designers and engineers, but there can be no software patch for grooves you cut in asphalt – and so at least as of last year, the embarrassingly sounding road was still there.

I think I prefer my out-of-tune musical scale performed by a train. Given it’s easy to find compilation videos of Siemens locomotives booting up, it seems I’m not alone.

Turns out that the breathing light survives, sort of, not really, in an Apple product today:

The AirPods Pro case does this when charging – right at the start, or when you tap it later. But it disappears after a while, the pace is now 28 breaths a minute (over twice as fast as the original iteration), and the light is orange.

Is it still the same thing, reflecting on how smaller organisms breathe faster? Or is it mostly an unrelated idea, with the light fading in and out indicating activity rather than lack of it? My money is on the latter – the light turns white when pairing, too, and it cycles even faster then – but it was nice to imagine the return of the old feature for a second or two… or 2.1, to be precise.

This DOS demo called Wake Up! is astonishingly small – only 16 bytes:

The demo doesn’t just make QUOD feel gargantuan. Output this one solitary emoji, “Woman Technologist with Light Skin Tone” – 👩🏻‍💻 – and you spent all your 16 bytes, too. (Proof!)

The creator’s write-up is a bit hard to follow, but there are some interesting aspects to it: “stealing” the beauty from math itself, the reliance on the environment being set up properly (to avoid wasting precious bytes on initialization), and the tight connection between the hardware, the visuals, and the sound.

Oh yeah, in case you haven’t noticed, this has sound! Two out of 16 bytes are devoted to its production, using an existing BIOS function that slots nicely into the existing graphics routine.

This is another recent demo that caught my attention: NINE, from about a year ago:

The platform here is a computer of a similar vintage as the early DOS machines, Commodore 64. C64, like many other home microcomputers, supported special graphical entities called “sprites,” which were used for gaming since the rest of the graphics couldn’t move very fast. (Today, your mouse pointer is conceptually similar to a sprite, being imbued with special powers unavailable to anything else.)

C64 could output up to 8 such sprites. The demo inexplicably has… nine.

The NINE demo didn’t focus on absolute minimalism, but instead employed a barrage of ghostly (and ghastly!) trickery to achieve something that was thought impossible. This time around, the explainer from the author – a 22-minute YouTube video – is filled with great storytelling, and absolutely worth a watch:

I think both of these showcase two things that I appreciate and that translate to great UX design as well.

The first demo shows tight integration between design and the capabilities of software and hardware. Let’s pick the sound routine that needed just 2 bytes. If there wasn’t a way to output sound within this extremely tight budget, the author likely wouldn’t fight to their death to get sound… they would instead focus on what else was possible within two bytes. This is getting as close to full understanding of the medium you’re working in as possible.

The second demo highlights how sometimes you can use absolutely horrid sleights of hand to achieve something beautiful – and how you can perhaps find beauty in those sleights of hand, too. It reminds me of the quote attributed to Teller (of Penn & Teller):

Sometimes magic is just someone spending more time on something than anyone else might reasonably expect.

Penn & Teller talk a lot about how there are only two keys to their success: going further than others would think, and not worrying about employing inelegant tricks in service of something that would appear to be of utmost elegance.

Today’s computing limitations are different than the ones from the 1980s. But a lot of this attitude can still be helpful, even four decades in, and even if your work seems as far away from the demoscene as you can imagine.

The iOS 26 update introduced a bug in the Czech keyboard. Instead of the customary háček (ǍǎĚěǦǧǏǐǑǒǓǔY̌y̌) in the bottom row, another key was duplicated, removing access to the accent character (or, a diacritic) very popular in that language.

Here is the before and after of this situation:

Ordinarily, this can be frustrating but not insurmountable; you can always copy/​paste, rely on autocorrect to help out, or even add some topical text replacements for common phrases. The problem is that this bug only appeared on the keyboard used for logging on, and at least a few people used that character in their password. There, none of these workarounds were available – and so those people were now completely locked out of their iPhones.

The Register reported on this on April 12, and a few days later suggested that Apple was working on a fix. I won’t keep you in suspense; I just verified that the fix landed with the recent May 11 update.

This is, in an of itself, not a fascinating story, but with interesting things to talk about at its periphery.

First of all, The Register never showed a single screenshot. This led to a lot of confusion and speculation in the comments. Turns out, screenshots are valuable not just with bug reporting, but also with bug reporting.

Second, check out this Czech keyboard. Even within the limitations of the ancient QWERTY, there’s a lot of cool stuff happening here. Two new accented keys just appear on the top layer when you switch to Czech. Both have magical properties, too. They’re the modern “dead keys” that either stand alone, or get combined with the previous letter if that makes sense.

This is the stuff typewriters, and even desktop keyboards, could only dream of. But, as always, more software means more bugs, including some with unforeseen consequences; a typewriter could never break this way.

Thirdly, there is this interesting tension between us being led to believe “more interesting passwords are safer,” but then sometimes being penalized for actually making them interesting. A decade ago someone used emoji in their password without realizing they won’t be able to input it, and I’m sure there were other examples.

But the most interesting, to me, part? It’s the diacritic itself. Under one of the posts, a commenter wrote:

Stick with the 7-bit ASCII subset. You will never go wrong.

7-bit ASCII basically means “26 Western letters and nothing else.”

I hate this. I know it’s objectively true – in the late 1980s I felt a sense of relief my name didn’t have any of Polish language’s nine diacritics, which would complicate my life. Even just yesterday in Germany, I spotted this:

Software still struggles beyond ASCII. But this is why we need to keep pushing. Diacritical characters are to be found everywhere in the world. They’re detailed, and varied, and filled with histories. Umlaut is not diaeresis. Kreska is not the acute. A háček is not a breve. They’re rarely optional decoration, and often not even decoration at all; learning about Turkish dotless i might completely upend your understanding of what’s an accent and what is not.

If you don’t have a favourite diacritic, you are missing out. Even the names – grave! ogonek! horn! – are beautiful. (Háček is also known as caron and a wedge depending on context, and in other regions referred to with beautiful words kvačica and strešica.)

If you’re interested, here is David J. Ross’s 22-minute talk about getting to love diacritics from the perspective of a type designer. It’s filled with craft and playfulness:

My favourite accent is, obviously, ogonek. Just looking at Adam Twardoch’s guide on how it should be drawn fills my heart with joy:

A simple rule for overflow logic that will prevent your app looking a bit stupid…

…is to avoid “more” expanding to just one item. If the expansion takes up as much room as the UI to show the expansion, why not show it in the first place?

A reader asked me this, and I thought I will answer here:

One bit of challenge with [where I work] is that my audience isn’t already almost-guaranteed to be into design! They’re hopefully interested in making good software in general, though, and probably curious about the app [I’m building] they could be using. I’m also afraid that developers sometimes confuse “easy to use” with “beginner-only, limiting”, which makes it harder to write about streamlining UIs; there’s only so many times you can invoke “reducing mental load.”

I love this question because it gets to the core of why I started this blog. I’m perennially unhappy with the conflation of “craft” with “delight,” and the subsequent narrowing of “delight” into “cute strings and slow animations.” In the famous words of Steve Jobs, “Design is not how it looks. Design is how it works. What’s tricky is that they’re sometimes related, and even if you learn how to tell the difference, your exec team probably never will.”

I am quoting from memory.

Anyway, I hope spending time on Unsung – please like and subscribe – helps with examples of what to talk about and how to talk about them. But, just to list some alternatives to “reduces mental load” for well-made software that come to my mind:

• is more efficient
• gets you home earlier
• will allow you to spend more time on things you enjoy
• will allow you to choose which parts of the problem to spend time on
• reduces tedium
• understands and practices progressive disclosure
• understands you
• speaks your language
• learns your preferences
• meets you where you are
• is made by people like you
• respects you
• will make you better at what you do
• rewards mastery
• doesn’t dumb things down
• will teach you concepts helpful in other software
• never takes control away from you
• is easy to customize
• adapts to you
• doesn’t disobey you
• will make you look good in front of others
• respects history and legacy of the space
• is built well
• is conceptually/​systemically beautiful
• is well-considered or thoughtful

There’s more, and I am curious what comes to your mind and how you all connect with developers! But maybe just going through a list like this will provoke some ideas.

(Of course, if you cannot honestly claim some of these about software you’re working on, and you think they’re important – I guess you have some work to do.)

I like the Fits on a Floppy manifesto by Matt Sephton:

Software should be as small as it can be. Not as a gimmick, but as a discipline. The floppy disk is the measuring stick: 1.44 MB. If the software that ran entire businesses could fit in that space, then a modern, focused, single-purpose tool certainly can.

In my own work, I have mostly focused on the web side of this equation, as this is where the situation feels the most dire: tens of megabytes dedicated to heavy frameworks, unnecessary tracking scripts, and video ads have a real negative effect on experiencing websites. Progressive loading challenges also make it harder to offer a great experience.

But space considerations are starting to feel more pertinent to local software too, in an era where SSD and hard drive prices are going up, and where local LLM models start taking up more room.

Also, this passage feels very Unsung, and is exactly why the tag #history exists on this blog:

I don’t miss floppy disks. I miss the mindset they demanded—that every byte matters, that constraints breed creativity, and that software should be light on its footprint.

If you reduce tech history to just nostalgia, it won’t be that useful. But if you look at it as inspiration, you might find some truly wonderful and meaningful stuff in there.

On that note: Bonus for a nice classic domain, and a nod toward Mac’s most famous screensaver.

To me, “tap anywhere at the top to scroll to the beginning” is an amazing and underappreciated mobile gesture:

It not only provides an alternative to desktop‘s Home and ⌘↑ keys, but the student laps the teacher here; it’s actually better than every way to scroll to the top on desktop (do you like pressing ⌘↑? do you even have a Home key?), and it’s an icing on a cake of a regular flick to throw the page to the top already being pretty nice.

Tap to return to top is also distinctively mobile in that it allows you to tap just anywhere near the top edge that’s not already a tap target; as far as I can observe, traditional GUIs detest being imprecise in this way, always asking you to click on something specific (although window moving on macOS in the post-title-bar era is also starting to feel similar).

The iPhone gesture seemed to work so well that, over the years, more patterns started borrowing from it. In Bluesky and tons of other apps, you can tap on any tab with scrollable content a second time to scroll all the way to the top. (Again, something that’s hard to imagine on desktop, where you pretty much almost never think of clicking on an already-selected item.)

It’s not just the top, either. In Podcasts, tapping Home goes back to the left:

And in Photos, to the bottom:

To me, the whole “tap to return to the beginning” gesture universe feels ascended to be the core property of the interface. In that way, it is similar to scrolling, undo, copy/​paste, arrow keys moving the text cursor, and so on, all inducted to the National Register Of Historic Gestures.

Why? Because these gestures can only blossom if they work consistently, everywhere. You need to start trusting them so much they slide into your subconsciousness. Breaking the gesture in one place will make it less trustworthy in other places, too, ejecting it from motor memory back to the level of deliberate effort, and therefore making it a lot less usable. “Does this thing work here or not?” is a death knell of flow.

The fact that tapping on tabs is idempotent means there’s also no penalty; if you’re already at the beginning but are not sure, tapping it mindlessly won’t hurt or send you back somewhere else.

This is all great. And this is why I’m unhappy Safari started mucking with it.

Safari has tabs at the bottom – starting with two (regular set and “private” set), although you can add more. Above is a long list of site cards, with newest at the bottom. It’s exactly the same situation as in Photos, and yet tapping on either tab doesn’t restore the scroll position. Instead, it opens the settings dialog:

And, tapping around the buttons does nothing.

I would imagine Safari is a pretty important app used by many people, and so this feels like a bad place to introduce an inconsistency that could have a more serious consequences of un-teaching people about tap to scroll to top in the long run.

The funny thing is that the solution is already there: you can tap ··· in the upper left corner to get to the same functionality. The long press on the tab also opens the same menu.

Messing with a “tap to go back to the beginning” system gesture like this means to me the design team doesn’t fully share the understanding of the value of their own creation, or maybe that stewards of the gesture system are not vigilant… or perhaps the awareness is there, but the caretakers aren’t recognized, rewarded, or empowered enough.

It’s similar to the “no, thanks” example I shared before, a possible worrisome tragedy of the UX commons in the making if the respective teams do not change course. Because, wedging that sort of an exception in – even if you have a great set of reasons in the moment – creates a precedent. Inevitably, from my experience, the next team that will want to override scroll to top, or misuse “No, thanks,” will now require less of a justification.

More unexpected Mario content: a 7-minute video speedrunning composite by FlibidyDibidy:

This video combines my first 5,162 attempts to speedrun Super Mario Bros. I recorded 193 hours of attempts (and practice) on an original 1985 Nintendo Entertainment System, then I wrote a custom computer program to process those videos and combine them via machine learning and conventional image processing techniques.

This is not just fun to look at, and – presumably – study as you’re speedrunning yourself. A sign of a good visualization is that it makes you see stuff that you haven’t before and here, at some point (after 1:42), you start noticing strange comb-like patterns in Mario running.

Turns out this is actually a thing called a “frame rule,” a quirk of game’s timing code where it only checks for a completion of the level every 21 frames, or one third of a second. That means that for every level after the first one, your start will be rounded up to the nearest 21st frame:

The analogy often given is to think of a bus that leaves every 21 frames, and levels can only end by getting on that bus, and so other than in the last level (which has no new level to load at the end of it), improvements in Super Mario Bros. can only happen in 21 frame increments. If you save a frame or two in a level, but it’s not enough to make the previous frame rule, it’s not enough to take the previous bus, you’ll just end up waiting for it to happen anyway.

Stay tuned to the end of the video for some fun stats, and click through in the description below to see the same tech applied live during an in-person speedrunning event.

I like sharing, thinking about, and revisiting basic rules and principles because they really do ladder up to help you with more complex things down the road.

I wrote before how a simple rule to give some breathing room to your length-limited edit fields can be upleveled to a more general “let me color outside the lines when I’m editing” principle. This is another example of a similar situation.

I am in Buttondown, which is a mailing list software. I created a quick test draft just to check something out in the editor, I didn’t do anything else, and then I proceeded to delete it. Then, I was greeted with this:

This is nothing more than a larger version of the “You have 1 email(s)” problem. There might be a situation when I’m deleting something that has been published and linked to. In that case, it’d be good to know about how any links to that thing will cease working.

But this is not that kind of a situation, and the software has all the info to know that. In this moment, it could show me a simpler, much less alarming message more appropriate to my situation. This is not the end of a radio pharma ad where you have to rattle out all the legal disclaimers just in case something could happen.

One tiny counterexample from my neck of the woods: in Figma, when you start writing a comment and then exit without posting it, you get a little warning. But you don’t get that warning when you type something that’s <= 8 characters. In this case, the assumption is that retyping a few characters elsewhere (assuming you haven’t just changed your mind altogether) is much easier and faster than cognitively processing and dismissing the warning.

The challenge with Buttondown’s dialog is that this is more than just extra cognitive processing and “cheapness.“ Here, the stakes are higher, as we’re talking about something adjacent to data loss; the dialog really does feel a bit scary and makes me think I can do some real damage in a situation no real damage is possible.