Do you know those “Are you still here” screens? In some cases – like banking – they are ostensibly there to improve security. In public transit ticket or similar machines, on the other hand, they exist just so the machine can easily reset itself ahead of a future customer.

Resetting to default state happens on your phone, too. I’ve been thinking about it this past week and found a few examples.

The Google Search app comes back how you left it, except if you abandon it for longer than 45 minutes. If that‘s the case, it returns to a pristine, deterministic homepage. (You can always come back to the previous session, though.)

When you pause a podcast or music, at least in my setup, it will be on the home screen for 5 subsequent minutes – you can then resume it by simply tapping on your AirPods. But leave it dormant for longer than that, and the home screen forgets about it and resuming is impossible:

My favourite: if you swipe through the apps back and forth on the iPhone in a touch UI equivalent of command-tabbing, there needs to be a specific moment where the app you switch to becomes the “current” app. On desktop, it’s easy – you can reset the state at the next invocation of ⌘⇥. But there is no such obvious moment on mobile.

When there is no obvious moment, timeout can be a great answer. And so it is here, and it seems to be set at about 5–6 seconds:

I understand the Google Search and the app switching examples. But I am not sure I know why a podcast resets so soon. A challenge when talking about this without seeing the code – as it is with many things on Unsung – is that I don’t know if this is carelessness, a technical limitation, a design consideration I’m unaware of, or just something that’s intentional, but I happen to disagree with. Even testing this has been hard if the delays are longer than seconds.

The extra challenge for Google Search, as it is for many other apps, is that they also reset when iOS itself purges it to make room for other apps. This isn’t great, and can be avoided if you care; we talked before about Bear and how it remembers its precise state even after the system evicts it from its memory.

Whether you want your app to remember you forever, or whether you want some deliberate forgetfulness, it could be important to take ownership of that. My go-to example of a miss in this category is Google Maps, which completely throws away its current trip-in-progress status whenever the iOS kicks it to the metaphorical curb – and returning to that status later again as a user is a really complicated sequence of steps including rewinding back the time, on top of travel already being stressful.

By the way, I can think of fewer examples on the desktop, but that makes sense given desktop apps are less tactical, and given that ⌘Q exists.

But Spotlight does freshen itself up after about 7 or 8 minutes…

…and Raycast actually offers an option to set its short-term memory from between 0 seconds and three minutes, with the default being 90 seconds:

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.

Among many genuinely useful deeplinks you can use to control Raycast from afar in a simple way, I just spotted an interesting one:

raycast://confetti

This is what it does:

Despite it being a confetti cannon and nothing more, I think it goes deeper than stuff like e.g. Asana’s “celebration creatures”, and it deserves recognition for three actually kinda serious reasons:

• You can use it to quickly test whether you’re wiring deeplinks correctly. It’s clever the Raycast team put it at the beginning of the doc page; I think every API or a complex connection method should have a simple and delightful “success scenario” for two reasons: to celebrate you establishing that connection, and to have something so simple it cannot itself be misbehaving (this way you know that if you can’t get confetti to work, you for sure messed up something elsewhere).
• Once you know how to invoke it from far away, it’s also great for testing other things. Sounds can be muted. In JavaScript, console.log() can be too buried if you don’t have a console open or visible, and alert(“Test”) is kind of depressingly old-school and steals focus. This HUD-like thing feels like a modern way of approaching this: You know you’ll notice it when it fires away, and it will leave no lasting damage. (Okay, fair, it does steal focus too, so that’d be one thing to improve.)
• It has great production value. I hate perhaps all of Google’s search easter eggs because they’re built so extremely cheaply – try searching for “do a barrel roll” or “askew” (and no, I’m not going to dignify them with links because links are my love language). It’s rare and worth celebrating when something that could very well be an internal joke or a test feature for nerds is actually something you want to use because it’s so well-made. (See also: Linear’s internal testing UI.)

Appreciate little moments showing utmost keyboard orientation in Raycast.

The millisecond you hover over the back button, the app says “you should be using the keyboard for this”:

I am not sure you often see tooltips on buttons, with keyboard shortcuts only:

Every select menu – even those with literally two options – has an inline search:

Party like it’s 1983! Or 1982! Or 1967!

Also, unrelated, love the clarity of this panel. This is what’s synced. This is what’s not.