Блоги: заметки с тегом interface

When you type to search in Finder, files and folders are mixed together

Ilya Birman — Wed, 06 Aug 2025 19:44:33 +0500

In Norton Commander, as well as in Windows Explorer it’s always been the norm that folders go first, then files. On Mac, it used to be different: files and folders were always mixed together based on the selected sort order.

A few years ago, Apple finally gave in and added a proper sorting option to Finder: folders now appear first, files below.

In Norton Commander, as well as in Windows Explorer, and even in Finder, you’ve always been able to select a file in a list just by typing its name. I’m always surprised when people scroll through giant file lists looking with their eyes, instead of just typing a couple of letters.

So imagine you open a folder in Finder, and in it you have:
images/
index.php

You press the “i” key. Obviously, the highlight should jump to the images/ folder. But in reality, it jumps to index.php. Because even though Finder visually sorts folders to the top, deep down it still believes that index.php comes before images.

Vibe coding had not been invented then, but the implementation quality of Apple software was already at that same level.

Recognizability between mobile and desktop

Ilya Birman — Mon, 04 Aug 2025 00:58:13 +0500

Ilya Birman:

How much can a design change when adapting it for mobile?

I go by this rule: the mobile and desktop versions should be mutually recognizable. If I’ve used a website on my computer and then open it on my phone, everything should be where I expect it to be — and vice versa.

If, say, there’s a row of six images on desktop and on mobile it becomes two rows of three — that’s fine. But if the images are replaced by a “View Photos” button that opens a popup — that’s not fine anymore. If there’s a large block of text on desktop and on mobile part of it becomes hidden with “Show more” — that’s fine. But if the text is edited down just for mobile — that’s not fine anymore.

I disagree with the idea of separating scenarios where people say things like: “On mobile, users are usually in a hurry, for them section X is more important than section Y, so let’s move it up”. That breaks the mutual recognizability.

You can put the mobile and desktop designs side by side and ask yourself: do they feel like two views of the same thing, just rearranged for screen size? Will someone who knows one version find their way around the other? If not — I’d ask for a redesign.

Superpedestrian fleet management interface

Ilya Birman — Fri, 18 Jul 2025 20:39:08 +0500

Ilya Birman:

Check out the Superpedestrian fleet management interface:

I like designing interfaces of this kind where you need to figure out an obscure process.

The problem with automatic email sorting

Ilya Birman — Fri, 23 May 2025 20:14:18 +0500

Ilya Birman:

New email apps keep coming out, trying to organize your inbox. Folders in email were invented nearly fifty years ago, and since then we’ve had filters, rules, and now AI — all aiming to automate sorting.

Some apps don’t even call them “folders” anymore, but “categories” or something else that only adds to the confusion. Every new app tries to outsmart the others at sorting: “inbox”, “important”, “newsletters”, “social”, “purchases”.

Even Apple Mail recently jumped in with its own version: “primary”, “promotions”, and so on. Surely, I have no idea how it decides where things go. To avoid missing an email, I have to check all the categories, so the workload goes up, not down. “Didn’t get our message? Check your spam, secondary, non-urgent, and low-priority folders!” I turned that off immediately, of course.

For some reason, email designers don’t get that folders only work when you create them yourself and sort things manually. If the system exists in your head and you stick to it, you can trust it. But someone else’s system makes you second-guess everything.

Instead of sorting emails into folders, computers should be mining the actual information from them.

Yes, finding booking references and boarding pass QR codes in your inbox is a pain. But even finding them inside an email you’ve already opened is a pain! I don’t want just a folder with those emails — ideally, I’d see the info without even opening a message. If I do need more context, let there be a shortcut to the original message. And I don’t care what folder it’s in.

If an email invites me to a conference and asks me to respond by the 25th, I want that deadline clearly flagged next to the message. And show me, in my inbox, the three emails I should respond to today — based on what they say. Leave folders for people who actually like manual sorting.

Reversibility of an interface element

Ilya Birman — Wed, 10 Jan 2024 17:59:01 +0500

Ilya Birman:

Reversibility is a property of an interface input control, where the user can return the control to its initial state at any time. Or, more generally, where the user can freely switch between all available states. Irreversibility, consequently, is when the element has states to which it cannot be returned after some actions. Well-designed controls are reversible.

An example of an irreversible control is a group of radio buttons of which none are initially selected. Once one option is selected, there is no way to return the group to the initial blank state. This creates discomfort and frustration. In a proper radio group exactly one element is always selected, including in the initial state, so the group is reversible.

But what if picking an option is required to proceed to the next step? There is no point in unselecting all options! Why would the user want that? Well, the reversibility requirement stands even if the initial state is not “valid”. This has to do only with the mechanics of the interface control, not with its role in the interface external to it. It affects the sense of control. Consider this: a text input field does not resist having all characters erased from it, even if it is required. Any other element, if it has a blank state at all, should let you return to it. In the case of a radio group, remove the blank state altogether by providing a default option.

Here’s another example of irreversibility. Suppose you have a required text field, initially blank. The user clicks the field, then clicks another element, leaving the field blank (or fills it in, but then erases everything). The system now draws a red border around the field, hinting that the field cannot be left blank. Now it is impossible to return the field to its initial “clean” blank state. A solution would be to fade out the red border so that the field returns to the initial state after a second.

How I stopped using Duolingo

Ilya Birman — Sat, 09 Sep 2023 13:07:29 +0500

Ilya Birman:

Duolingo used to be a great app. I opened in to practice almost every day. But then they changed the design:

The redesign rolled out gradually — apparently they were testing it. There was a period when the iPhone was already broken, but it was still possible to use it with an iPad or on the web. I chased the old design for a while, but soon after the final switch to the new one I lost interest in studying.

There was a lot of outrage online about the change, including in the comments under this video. But the design has not been rolled back, which means Duolingo’s numbers are good.

Before and after:

From a Duolingo blog

In the old design, as you went through the lessons, the next ones opened in bundles. In the example on the left, you could choose from: basics, phrases, animals, food, family. Sometimes I was in the mood to learn something new, so I tapped an untouched topic. Sometimes, on the contrary, I wanted additional practice in something I already had an idea of, so I went there. When I made a choice to learn something, as the owner of my choice, I was motivated to learn it. The interface was informative and engaging with a variety of topics. Sometimes it was fun to scroll up and be pleased with how much I already learned. Sometimes it was interesting to scroll down, to the lessons locked so far, to be inspired by what awaits next. Maybe the remaining required lesson isn’t very appealing, but look at what’s there to learn afterwards!

The new design has none of that. The endless wave of identical coins means nothing, you just have to tap the green one: you have already completed the previous ones, while the next ones are not available yet. If you scroll up or down, the endless wave of already completed or not yet available unsigned coins continues, and there will even be a button to scroll back to the green coin. The informativeness of this screen is literally zero, it gives you no choice, it exists only for you to tap the one single button! Even the iPad cat games are more interesting.

In the video, they tell us that was the intent:

We’ve redesigned the home screen to better guide you through lessons.

Translated from marketing speak, “now we decide what you learn”.

Follow a path crafted by our learning experts to help you better reach your goals.

It’s different for everyone, but for me, “reach your goals” is the weakest motivator in life. I want to effortlessly enjoy the process and then suddenly be thrilled to discover my own accomplishments. Duolingo doesn’t give me that anymore.

And don’t worry, we’ve kept all the progress you’ve made so far

What are you talking about? I no longer see the huge list of topics I’ve completed. From my point of view, all the progress I had, I’ve lost.

Anyway, it was a great app.

Onboarding

Ilya Birman — Mon, 28 Aug 2023 13:20:19 +0500

Ilya Birman:

Often when we open an application, we see a screen that tells us about it or about some recently added features. The screen may consist of several pages that you have to flip through one by one. There may be a button to skip it all and go to the main interface of the application. This is commonly referred to as an onboarding screen.

It is bad practice to do so.

The statement may seem ridiculous to you as so many products have onboarding screens. Unfortunately, most of their creators don’t even ask themselves the question “what if we are wrong?” In some occasions I asked them why they do it, and I heard: “well, it’s onboarding”. People don’t even realize that this doesn’t answer my question — the belief that this is the right thing to do is so strong.

Let’s examine what’s wrong with this kind of onboarding, what task it’s designed to accomplish, and how to accomplish that task well.

Summary: The onboarding screen appears at the wrong time, prevents you from using the application, and when you really need the information from it, you can’t find it anymore. This causes frustration and reinforces the habit of skipping messages without reading them. It is better to make tutorial elements an integral part of the interface and allocate a permanent place for information about new features and changes.

Why not introduce the application at first launch

First, consider an onboarding screen that introduces you to the application as a whole.

In the dumbest case, it’s advertising: onboarding pages praise the app and its features. However it is nonsense to advertise an app that the user has just installed and opened: we have already received the desired attention; it is now time to stop seeking it and start converting it into value. The user also has their expectations of the application and wants to start using it. They now have to overcome our annoying obstacle. So advertising should just be removed.

In a slightly less dumb case, onboarding tries to teach you how to use the application: this is how you order a pizza, this is how you make a money transfer. If the user already knows this, it’s again just an annoying obstacle to their goal. If the user doesn’t know this, however, we present them with an uncomfortable choice. They need to read our onboarding screen carefully and memorize it so that they can later apply what they’ve learned to the real interface, which they haven’t even seen yet. But as a user, it’s impossible to estimate how mindful I have to be and how thoroughly I have to memorize. Maybe I will be able to figure it out on my own in the real interface?

Just think how crazy this is. You buy a new washing machine, and they forcibly hand you the owner’s manual and say: “You can throw it away, but if you can’t understand something later, no one will help you”. Uh.. Can one not figure it out without the manual? We don’t know. Well, can’t I just leave the manual in the box and take it later if I need it? No, you can’t: you either have to read it now or throw it away.

It is worth analyzing the main interface carefully. How to make it clear without the initial tutorial? If you can’t do without hints, how can you provide them so that they don’t interfere with the usage of the application? Maybe you need to add explanatory text somewhere. Maybe in the tricky places you need “?” buttons that open the detailed explanation. Or maybe you need your own educational YouTube channel that is easily accessible from the interface.

Why not talk about new features after an update

Now consider an onboarding screen that highlights new features and changes.

The same problems are even more acute here. When somebody opens your application for the very first time, they probably have little expectations. However, when the user is familiar with the application, when they’ve been using for some time already, they launch it with a specific purpose, for example, to check delivery tracking or to pay the household bills. Most likely, they have a “plan”: they remember what corner they are going to tap first, what will appear next, where they are going after that. But suddenly, instead of an interface they expected, they get a presentation of new features they don’t need right now!

In this situation, the urge to skip the onboarding screen is even stronger, and so many users simply won’t learn about your innovations. Again, not because they don’t need them at all, but because they don’t need them at that moment. If your application is being actively developed and updated, the constant talk about changes will be annoying, and the habit of skipping them will become more entrenched each time.

To keep users aware of what’s new, it’s a good idea to provide a permanent place in the application for this purpose. My favorite example is the messenger Telegram:

The designers took advantage of the nature of the application: the information about new features comes as chat messages from a special “Telegram” account. When you open the application, you see these messages on an equal footing with others. You can chat with your friends or respond to important work messages first, then learn about Telegram itself. Each feature is revealed in a separate message with a nice video. The message can be forwarded to someone who, you believe, will benefit from the feature — the advertising effect is amplified for free. And, of course, no one prevents you from returning to these messages at any time later. That’s exactly what I did to take the screenshots.

Even if your product is not a messenger, you can find some permanent place to talk about new stuff. And for people to remember to go there, you can put a red badge when unread items appear. What’s important is that the rest of the application’s features are available even before the user has read everything.

Good user interface and good business

I start my course User Interface Fundamentals with the subject of humaneness: the interface should be for the human, not the other way around. When an interface stands in the way and pisses you off, it’s a bad interface. In the lecture on habit, I talk about the problems with confirmation windows and blocking messages, and onboarding screens are examples of that. They reinforce the habit of reading nothing and agreeing with everything.

Onboarding screens have problems similar to those of confirmation windows, yet both things are very common. The reason is that in product development, the goal is rarely “to make the user happy”. Typically, those in charge of a product look at other metrics. Let’s say the onboarding screen is watched by 10% of users and as a result sales grow by 1%. Who cares then if it disturbs the rest of us? The gain is greater than the loss, so fine.

Reader Egor, who works as an analyst in a large product, once wrote to me:

Do you believe an a/b test would help to settle this debate? Say, we’ll show the onboarding screen to half of new users and skip it for the other half, then look at two metrics: the conversion rate from first session to a completed order and the time from application launch to completed order. If the conversion rate with the onboarding screen is higher while the time to order does not increase (i.e. the time a user spends in onboarding is won back later), would you agree that onboarding screens are justified? And how do you generally feel about validating product hypotheses with a/b tests?

I would agree even without the test. But what this test would prove, at best, is that it is better to tell about the application by onboarding than not at all. And what I’m saying is that there’s a better way than onboarding.

As for validating product hypotheses, it has little to do with a good user interface. Sometimes you can boost the metrics by degrading the interface: by reducing the clarity of options, by nudging the user towards a disadvantageous purchase; by making it harder to unsubscribe. A good interface is only sometimes important to product success, but sometimes it is not. Just look at Facebook or Booking.com. I wouldn’t want to have anything to do with making these very successful products.

In a large product with pragmatic management, adding an onboarding screen may indeed be the most feasible solution. It doesn’t interact with the rest of the application in any way, it doesn’t add any new logical connections, a separate team can even be responsible for it. It is much easier, faster, and cheaper than thinking about how to improve the educational properties of the product itself.

But not all businesses operate on squeezing metrics at all costs. Some have a different set of values, where product quality and user delight matter. Sometimes there’s an opportunity to think carefully about these things, rather than just do what everyone else does.

I find that onboarding is often done because the creators genuinely think it’s a good idea, rather than for the pragmatic reasons mentioned above. They don’t even look at the metrics, don’t compare user annoyance with the gains in conversion rate. They just put up a splash screen because they absolutely want to talk about the new features! In such cases, when I talk about the disadvantages, people are happy to engage in a discussion of alternatives.

Yes, doing things well is usually harder than doing them poorly, but the effect can also be greater.

One more question please

“Ilya, it all makes sense, but there’s a really amazing feature that we’ve been working on for two years. We even made a video about it! We want to put it in the onboarding screen, because it’s important for us that everyone sees it!”

It’s great that you’ve made a feature that you are proud of. I sympathize with your desire to tell everyone. If you put it in the onboarding, you’ll blow the opportunity. How could you communicate about the feature in a way that everyone will love it? Give this question at least a fraction of the care you gave the feature itself.

Marco Arment on UI stability

Ilya Birman — Wed, 09 Aug 2023 00:33:53 +0500

Ilya Birman:

In ATP Episode 439 Marco Arment had a good speech on UI stability, I even took time to write it down. It starts at 35:07:

UIs so often lack stability. It is such a critical quality. You want the UI to be stable.

Not every surface should be “live”... If you try to select some text on a website with a mouse on a desktop, you don’t want every single thing that you can click on or accidentally brush against with your finger on a phone to be something that is live, that does something. You want stability, you want things to feel solid, and predictable, and forgiving. And not being so susceptible to things like accidental input or imprecision in input... People are doing things unintentionally.

You also don’t want the UI to be moving around when people are trying to use it. And I feel like a lot of the current Mac design language these days, where everything is being hidden behind hover states and then things animate somewhere out of the way and change where they are... this is all violations of UI stability. It makes everything a hot zone or a live zone. And things are jumping around, and it’s disorienting, and it’s inefficient, and it’s unintuitive as well, and undiscoverable and all sorts of other problems.

Anything you can do to make a UI more stable in a sense that things don’t move around too much, there aren’t too many different modes where things come in and out or slide around, or pop in, or pop out, that makes it easier and better and more calm to use for more people. And it’s a better design.

Typing your password over a button

Ilya Birman — Sat, 15 Apr 2023 15:26:26 +0500

Ilya Birman:

Apple came up with this interface behavior that would seem strange before.

When biometric authentication is available, the password input field is hidden. But if something goes wrong, you can still enter your password. However, you can start typing the password even before pressing the “Use Password...” button — any input will take the window to the next state.

Apparently, the password interface is hidden initially for the sake of beauty, and also not to give people the false impression that the password must be entered.

The only annoying thing is that the two states of the window are of different heights, that is, when you start typing the password, the window gets bigger.

Is iOS scrolling modal?

Ilya Birman — Sat, 23 Sep 2017 12:33:39 +0500

Ilya Birman:

Someone has tweeted this and got several retweets:

https://twitter.com/jordwalke/status/884553142813081601

What they mean is this: when the content is still, tapping the screen is interpreted as a tap, but when the content is in motion, tapping the screen just stops the motion. So is the behaviour modal? No, here’s why.

Most people think that an interface is modal when it has modes, i.e. when same user input produces different output depending on the state of the interface. However, that’s not the definition.

Let’s read Jef Raskin carefully:

An human-machine interface is modal with respect to a given gesture when (1) the current state of the interface is not the user’s locus of attention and (2) the interface will execute one among several different responses to the gesture, depending on the system’s current state.

Most people’s understanding includes only the (2), but not the (1). But they both equally matter. Perhaps, Raskin didn’t name the thing well, but we have what we have.

You unlock your iPhone and tap Messages:

But just as you are tapping it, you notice that it’s actually Shazam:

Oops, you are on a wrong page of your home screen.

In this case, launching of Shazam instead of Messages is a mode error: your gesture (tap in the top left corner) produced the wrong output depending on the current state (the page number), which was not your locus of attention. So, the iPhone’s home screen is modal.

Now let’s say you are in Contacts and tap the bottom left corner for Favourites:

Is there any chance you actually meant to go to a previously visited web page?

The gesture is the same (tap in the bottom left corner), and it produces different outputs depending on the current state (the active app). But here, the app is your locus of attention: you are fully aware whether you are looking for a contact or browsing the web. That’s why a modal error is not possible here, and this interface is not modal.

If we get back to iOS scrolling, it now becomes clear that it is not modal. When the scrolling animation is playing, it is the user’s locus of attention. The user is fully aware of the interface’s state: they are looking at the moving content. So the fact that the tap is interpreted differently during this animation is not a surprise and doesn’t produce a mode error.

Timed modes

Ilya Birman — Thu, 09 May 2013 03:02:25 +0500

Ilya Birman:

As you may know, modes are bad. Even worse are timed modes often used in the human interface of consumer electronics.

A mode is a state of user interface in which the same user action leads to the same result; in different modes, results of the same actions are different. Photoshop is famous for its exuberant use of modes: a click within an open image may do anything depending on what tool and options you have selected. The problem with modes is that you are not constantly aware of the current mode, which leads to errors: you want to draw a line, but accidentally create a gradient fill.

Now imagine a TV remote. Left-right buttons change volume and up-down buttons switch channels. These four buttons are also used for menu navigation. Now, when you are in the menu and you want to make the TV louder, you press the right button through habit. Unfortunatelly, now the button means “make screen aspect ratio wider”. The menu is not just a mode, it is a timed mode: if you don’t press anything for 10 seconds, the menu will be closed. If you are trying to set up this TV with a help of a user manual, you will be very frustrated: every time you look up the manual, the menu disappears and you have to start over.

Timed modes in a car UI are not just frustrating, but can also be dangerous. To change the audio bass level, you have to go to the menu, find the EQ settings, select “bass” and then adjust it with a knob. By the time you get to the necessary menu item, the traffic light turns green, so you have to postpone the adjustments until the next traffic light. Chances are, you will then need to navigate the menu again. If you know that the interface will not wait for you until the next traffic light, you will be forced to adjust bass while driving.

If you cannot avoid modes in your user interface altogether, at least don’t use timed modes. If I have changed my mind and don’t want to set up the TV or adjust the bass, I will just press cancel myself.

Button text in Mountain Lion

Ilya Birman — Thu, 26 Jul 2012 01:09:30 +0500

Ilya Birman:

John Siracusa in the review:

Creating a new document and then immediately closing without saving now shows a dialog box whose far-left button is labeled “Delete” rather than the milder “Don’t Save”. The same button in the dialog that appears after selecting the “Duplicate…” command and then immediately closing the duplicate window is now labeled “Delete Copy” instead of “Don’t Save”.

Nice touch.