![Checkbox vs switch](/notes/checkbox-vs-switch-1.png)

You can see checkboxes everywhere in the screen user interfaces. But here and there they are represented as switches. Both are boolean fields, both switch binary state. What's the difference?

A switch put in a long form, say, order form, would feel unnatural. Checkbox in a form would feel more organic. That's because of the level of interactivity that comes with both elements. Checkbox is less interactive, it gets applied not immediately, but after some other actions performed. For example, after you click the submit button.

This intuitive distinction comes from the real checkboxes from real paper forms:
![Checkbox in a paper form](/notes/checkbox-vs-switch-2.png)

You cannot expect anything happening after ticking it on the piece of paper. Things will happen only after you hand in the form.

This is the real switch:
![Physical switch](/notes/checkbox-vs-switch-3.jpg)

Opposed to checkbox, you expect immediate feedback from physical switch after turning it on or off.

Rule of thumb for computer interfaces – use checkboxes for choices/options executed later and switches for immediately applied state change.


Checkbox vs switch

There are times when you face a problem and you dead sure that it is impossible to resolve it due to circumstances out of your control. It is always worth questioning this impossibility.

It is not about motivation or popular 'everything is possible' motto, but more about actualization of your knowledge. Say, you 100% sure there is no native method to flatten an array in your favorite programming language. And if you have to flatten a specific array in your code right now, you instantly start thinking about how you would implement a recursive function to do just that or maybe how to change the initial shape of data. But what if you were wrong and there *is* a native method out there? What if it has been added to the language just recently?

So here is the principle – every time you think something is impossible, confirm it. Maybe circumstances have changed and what was impossible before is absolutely possible now.


Principle – check impossibility

Essentially every programming code does two things – it is an input interface for computer and a self-documenting program manual for humans who will read the code later.

Each and every programming language designed for humans, not for computers. Computers are fine with just ones and zeros. Let's not forget about it when writing code as we are doing it for another human being rather than for machine. This other human being could possibly be yourself in the future.


Code is an interface

If we think about the most efficient user interface possible, with [signal-to-noise ratio](/notes/signal-to-noise-ratio) close to 1, it literally has no interface. Everything you are about to imagine is already done or in the process.

How close can we get to it realistically? Thing that comes to my mind first is standartization. Currently, each and every website or app has its own user interface and we have to learn how to use it. After several decades of evolution of internet, some UI control elements are more or less standardized. Take button, for example. It is simple, everybody knows what it does in theory, but still sometimes buttons on certain websites have strange and unconventional behavior.

Typical experience today looks approximately like this:
![User interacts with UI of an app](/notes/remove-interfaces-1.png)

How can we avoid having to learn interface of each and every website/app? Standardize it, of course! Each button should be with the same design, have the same functionality, same states and behavior.

Yes, this is utopia of course, nobody will do that.

What if apps and websites had some kind of universal API that would allow us to control them programmaticaly via certain protocol. We could use it to operate them from outside. And we could create some kind of adapter that would connect our own custom interface to the app. That way we could remove inefficient 'alien' user interface and use our own, familiar user interface, customized just for us.

Let's call it *Adapter interface*. The whole idea could be illustrated with something like this:
![User interacts with app via adapter interface](/notes/remove-interfaces-2.png)

Adapter Interface could be as personalized as needed for each individual, question is only in creating such adapter that works with various APIs and does its job.

For example, let's take MacOS's Finder app. Imagine you need to move a file from one folder to another folder. You have to do absurd amount of small actions to achieve that. You need to move your cursor around, click Finder app in the Dock, wait until window appears, go to the folder where the file is located currently, drag it to some other folder in a weird way, make mistakes, start over again, etc.

But this operation itself is basic and have been essential to computers for the last several decades. Why it takes such an amount of effort to just move the file between folders?

Now imagine how much easier it could be done with a Terminal app. Mouse or trackpad are not needed at all. You don't have to fight with user interface, all you have to do is just fire simple commands. Thing is, the simpler the action, the lesser interface is needed. So every OS is a compromise between really complicated concepts and really simple commands. It's nice to have a user interface to better understand and have a better control over complex stuff, but for simple actions an additional user interface is often just an overkill.

We can use Adapter Interface to address basic and the most repetitive tasks just like moving the file. Just a few more examples: google something, open certain web page, open certain app, check email, turn certain setting on or off, paste certain text snippet. The list goes on.

All these actions could be done without any interface with a single button click.


Remove interfaces

Any data transmitting system has certain limited bandwidth, i.e. amount of useful information that it can pass through over certain period of time.

In real world, efficiency of any data transmitting system is always less than 100%. Say, certain system can transmit *X* amount of actual meaningful data per unit of time of total *Y* amount of data sent per same unit of time. Then signal-to-noise ratio would be X/Y. For example if 73% of data sent is actual meaningful data, that means that the rest 27% is either noise or just signal loss. Or, more realistically, vice versa. Anyway, amount of meaningful data transmitted is always less than 100% and ratio is always less than 1.

We can apply this to user interface as well. Since 'user interface' has a word 'interface' in it, that means that some kind of data transmission is happening. So, any user interface allows user input to pass through and provides some response back to the user. That is a *signal*. Along with signal always comes *noise*.

Designer's task is either to increase a fraction of signal or decrease a fraction of noise. In a nutshell, that's what any user interface is all about and that's the only reason why one would want to improve it. Any interface can be viewed through the prism of signal-to-noise ratio.

Potentially almost any change in user interface would affect this ratio. However, the designer should first take advantage of the improvements that provide the most value.


Notes