Nonmonotony

Jef Raskin describes an interface where there is only one way to accomplish a task as “monotonous.” He mentions that he does so “tongue partially in cheek.” But he gives it a name in order to contrast it with “nonmonotonous” interfaces — where of course there is more than one way to accomplish a task. He goes on to say, “[t]he more monotony an interface has for a given task space, the easier it is for the user to develop automaticity, which, after all is fostered by not having to make decisions about what method to use.” I mention this because for a while I’ve been thinking about various spaces that allow for end-user customization. On the surface it seems to give the end-user a lot of power over their task space and usually a way to change the look to whatever is more aesthetically pleasing to them. However, at the same time, I believe that some projects incorporating customization tend to shove too much responsibility onto the end-user — not making those hard decisions about what will serve them best. So when re-reading parts of the Human Interface, this part was particularly resonate with me:

Another cause of nonmonotonous design is managerial indecision. Given two or more choices of interface methods and no rational method of choosing one above the others, I have seen the problem “solved” by expediently putting in all of the proposed methods. This is rationalized as giving the user a choice, as if the user were an interface expert and will make the most productive choice.

I’m not saying all customization is bad. However it seems easy to use it as a way to evade doing the proper amount of user research up front and devising a rationale to select the one method for end users that will serve them best.