Just a brain fart while reading The Design of Everyday Things:
Increased complexity leads to an increased likelihood of what Donald Norman describes as “slips”. Thinking about this, I realized that it’s not only due to the obvious math of “more options equals more wrong options”; if we think of actions stemming from a neural model of patterned relationships, increased interface complexity increases the sum of patterns and mental relationships, therefore decreasing pattern comprehension (or pattern matching, a critical component of task completion).
A great example of this is the “Rule of Seven”: humans have a hard time conceptualizing more than seven discreet items in a list (for most people, the max is closer to five). Beyond that, they begin clustering the information, and the items within a cluster lose their individual relevance. There is a pattern cap happening.
If you see a control panel with 100 undistinguished knobs, the chance of mismapping your pattern of desired action to the pattern of necessary action is very high, because your mental model can only include the correct answer, not all of the wrong answers (to be avoided).
There is a concept in programming of a “null” number. It isn’t zero, it doesn’t exist at all. UI actions have a binary completion/error result set, but UI designers should be aware that there is also a “null” result present in complex systems where a user simply cannot comprehend all of the options and action paths.
An easy solution here is to decrease complexity. An alternative solution is to provide surrogate patterns to aid mental modeling – Don Norman talks about positioning light switches within a floor map. Even an “important/unimportant” schema helps users find markers along a path to action completion.
No related posts.
The idea of a ‘null’ result is actually borrowed from mathematics rather than being a programming concept. It’s a part of set theory that states that every set has at least one subset, that being the null set (or the set containing nothing). Only the null set doesn’t have any subsets. The idea of null usually shows up in databases or programmatic return values. Basically a program function could return nothing, or null. This often conflates with a return of false. However, since programming is essentially binary there is no real null, just a one and a zero. Often, for the sake of simplicity though, programming languages that aren’t strictly typed treat zero, false, and null as the same. Null makes much more sense in terms of databases, where results are generally sets, and records can even contain subsets. When a set has no members, it is null (equivalent to the null set), or when a record has a null value for a specific column it contains a set of nothing. The difference between the two (programming vs. database) is that null in programming is zero, since nothing cannot be represented in binary, whereas null in databases is a record with no contents, but since databases are higher than binary this concept can be represented digitally.
And that folks, is a UPenn Master’s degree in the making!