The NINCH state/behavior and its motivation are things with which you should be familiar if you are designing UX. This blog post will explain it in detail.
To get started, NINCH stands for “no input, no change”. Of course, once you see it in action, only then does this mean anything.
PREFER TO WATCH INSTEAD OF READ?
EXPLORING THE NINCH
Let’s begin. Take a look at the File Property dialog in Windows 7 – this is shown below for a single text file.
Here’s a simple question. What happens when select two (or more) files and try to see the properties?
Clearly something different:
Let’s compare …
|ONE FILE||MULTIPLE FILES|
And then we shall consider this for a a few moments:
- Notice that the the UI’s look a little different
- Some fields appear on both versions, some are unique to their case
- In the case of multiple files, notice that the dialog in general tries to do something meaningful with what it shows:
- The name in the title of the window on the right is given as “B.txt, …” indicating that multiple files are involved
- The filename are not given, not editable, but instead it says there are two of them
- the sizes are added together
- And now notice the Read-only checkbox. It is unchecked.
The Read-only check box is where we will begin our exploration into NINCH.
It isn’t checked. The implication is that both files have this value set to unchecked. If we check it and press OK, then both files will have the read-only bit set. Makes sense so far. The key point to remember is that once we modify the dialog and press OK, any changes in the dialog will be committed to the files.
But what if when I had opened the dialog, file A was set to read-only, but file B was not? What would the dialog show?
This is interesting. The Read-only checkbox is NOT set to checked it is not set to unchecked, it is set to some third value. To make this more obvious, I’ll show the three states below.
Neither checked not unchecked
The first thing this enables the UI to do is to represent the fact that the files have different values. Note that it doesn’t indicate which file has which value only that “there’s a mix”.
What should you expect if you hit OK without changing the read-only field? Well, you didn’t make a change so none of the files will be altered. And this is in essence the what the NINCH state is about “no input, no change”.
Now at this point you may be wondering why we need a NINCH state. After all, I could have hit Cancel and no change would have taken place. First, not all UI is cancellable. Second, sometimes you need to make a change in something else and are forced to hit OK.
Let’s demonstrate this latter case. Suppose I have multiple files and I want to set them all to hidden but I don’t want to alter their read-only settings.
Per the screenshot below, I would open the properties dialog, ignore the read-only checkbox, and check hidden and then click OK. Then all the files will be hidden but their read-only values will be left alone.
The NINCH state is one of this tiny little UI behaviors that people tend to forget about, but is quite useful when you understand the scenario in which it applies.
The NINCH behavior clearly comes from a UI design background, but the same conceptual thinking can be applied to code. One may, for example, thing of using Nullable types in C# as a way of expressing a not a specific value but in addition – the meaningful lack of one.