A nice blog post by Nathan Manceaux-Panot on Pending Design about the subtle design of the tabs underneath the search results in the programming editor Nova:

Through buttons right below its text field, the bar also lets you filter results: only show files, only show symbols, or only show symbols in current tabs. Here’s the thing, though: each one of these buttons has four distinct purposes. They’re not just for clicking.

The tabs are clickable as they normally are, but they’re also a treasure map (to tell you something is possible), a cheat sheet (to remind you how to do it again), and an onramp for faster keyboard navigation.

I’d add two more things to the celebration:

• I myself often forget onboarding is not just about the first run, but also about reinforcement. Here, this UI does a lot of reinforcing over time, helping you build the habit. Pressing the key highlights the tab. Clicking on the tab adds a key as if you pressed it, and so does using an advanced shortcut (e.g. ⌃⌘O instead of ⇧⌘O). Even slash as a symbol comes from path names, so you might naturally associate it with files.

• The search pop-up always has a nice contrasty appearance: dark when the background is light, or vice versa. Many modern interfaces go for white background for every UI element and surface. This seems like solely an aesthetic choice, but has more consequences when it comes to visibility of things, and even hierarchy. I am personally always excited when I see a duochrome app these days, because it feels like the team knows what they’re doing and isn’t just chasing visual trends. (Below is an example from Bear.)

A nice moment in the iOS emoji keyboard – after selecting an emoji from the grid, its name shows up for a second:

I have small reservations here, as reusing a placeholder like this trips up my “this is cheap” alarm. But otherwise I like that this – just like keyboard shortcuts in menus or tooltips – ambiently teaches you the alternative representation of the emoji that you can use later to get to it faster.

(Another way of looking at it: This is a tooltip in a place where tooltips cannot exist.)

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.

This is a thoughtful post from Florian Schulz about designing a typeahead experience.

I liked the details both within the implementation – for example, making sure the kerning is preserved! – but also in the presentation. I particularly enjoyed Schulz making the component demo itself, rather than using prerecorded videos. (I was delighted to discover that even the first large “picture” of the component is actually interactive!)

A small comment to this bit:

Unfortunately, not all browsers expose the selection or accent color of an operating system. For example, if a user would set the accent color in macOS to pink, the special CSS keyword color “Highlight” will still result in a light blue color in Safari. In other browsers like Chrome, the color will match the user preference. But since this is an attack vector for user tracking / fingerprinting, Apple made the right choice to hide the user preference from developers.

From my understanding, this is not necessarily correct. For example, in theory, the purple visited link color can be used for fingerprinting, by building a profile of whether or not I visited one of the hundreds of popular websites, quietly in the background.

The way browsers solve this is to never expose the color programmatically back to JavaScript – if your code asks for a link color, it will be blue regardless of whether the link was visited or not. It seems to me that the Highlight color could be used the same way here. Given that CSS now supports things like color-mix(in srgb, Highlight 20%, white), it would even allow a designer to riff on the color without ever knowing what it is.

I feel like social media and recently the slate of AI-powered “tell me what’s here” features continue to show us the power and longevity of screenshots. After all, nothing beats a more or less approachable shortcut and a file format that works literally everywhere.

But screenshots have issues, and I liked how Bear (a note-taking app) brilliantly integrated OCR inside images into its flows. This just worked for regular ⌘F finding without me having to do anything:

The recognized text also appears when you search through notes, and so on. It’s just a great peace of mind that you’re not going to miss on text just because you happened to screenshot it.

Apple operating systems have had detection of text inside images for a while – I know on iOS in particular it sometimes gets in a way of normal gestures – so I thought it was just that, but curiously this doesn’t work as nicely in Apple’s own Notes.