Bicycles and Text Editors
Although I am sure they are commendable fields of study, I remain wary of User Interface (UI) and User Experience (UX) experts. The kinds of advice that they give seems to favour interfaces that are quick to learn and easy to grasp by new users. That is not evil. Often I am in situations where I have to learn just enough about a program to use it once or twice. In those situations having a consistent, easy-to-grasp user interface is quite helpful, because I can learn just enough to get my work done, get my work done, and then get on with my life. There have certainly been programs that I have avoided because I found the interface too complex, but which might have been valuable had I had the patience to learn them.
So why be wary? I believe that there are certain kinds of interfaces that are highly effective, but which are systematically disregarded (or outright criticized) by UI designers. My favourite example (maybe my only example) is the text editor Vim. It is my suspicion that if UI designers had their way Vim would never have been invented. The reason Vim exists is because its predecessor vi exists, and vi was invented in a time before UI designers got to impose their UI fashion choices on software expectations.
From a UI perspective Vim is crazy. First of all, it's modal -- you use one mode for saving a file and a different mode for entering text. Secondly, there are few UI hints to indicate what and how you are supposed to use the editor. There are hundreds and hundreds of features, most of which most users never use. Newcomers to Vim find it incredibly intimidating; climbing the learning curve to basic proficiency can take weeks or days. That alone means that it is an abomination in the eyes of UI designers.
But Vim is also incredibly popular, and it is not just because its adherents are masochists. Once you become familiar with Vim's interface you can edit text efficiently. Its modal nature means that it is really quick to navigate your document using few keypresses or mouse gestures. Its plain interface means you can concentrate on words, not formatting or misspellings or other visual distractions. It is easily customized so that people who have different preferences can configure the text editor the way they want it. From the perspective of efficiency, Vim has a great interface, but it is not optimized for UI consistency or a gentle learning curve. It is not the kind of tool suitable for those who need to touch it once or twice and then get on with their lives. Instead, it is a tool that pays off for those who use it regularly. I am no Vim expert; whenever I use it in public the real Vim experts mock me. However, I rely upon Vim nearly every time I sit in front of a computer, and I miss it dearly when it is not available. It has gotten to the point where I cringe when I have to compose text in an editor that lacks Vim's basic features (Hello, nano. Hello, Microsoft Word.)
Scripting capabilities also tend to be overlooked when considering UI design. In my arrogant opinion, any systems administration tool that lacks a scripting interface (or at the very least textfile-based configuration) is a broken systems administration tool. A script is a form of living documentation; often I will write a script so that I do not have to remember piddly details about how to get a job done. Then if I ever need to repeat the job I can look at the script, and either rerun or modify it as appropriate. Interfaces that require me to document long lists of menus and buttons to click are broken interfaces, because I either have to take the time to write out those instructions (which is tedious) or I have to relearn the interface every time I want to repeat a task. But I do not see a lot of UI designers insisting that scriptability should be a core component of software tools.
I am not arguing that interactive tools are useless, or that we should neglect interactive tool design. But there are many correct tool designs, because there are many different contexts and tradeoffs we might choose. I have seen very little acknowledgement of this in UI discourses that I have come across.
One problem is that it is very difficult for me to express the value of unorthodox interfaces to other people, especially nontechnical people who are already intimidated by computers. However, today I listened to an Audio Dharma talk on Equanimity that served up the perfect example: riding a bicycle. Bicycles have learning curves. Newbies cannot take a bicycle and expect to be riding immediately; it can take days or weeks to climb that learning curve and ride without crashing. But bicycles are effective, elegant machines, and overall their user interfaces are pretty good. Some people try to make the process of learning bicycles easier with training wheels, but this might be misguided: it does not take kids that much longer to learn how to ride a bike without training wheels than with, and training wheels can teach some bad habits that must be unlearned later on.
The analogy is not perfect, of course: the version of Vim I am using as I write this has a graphical menu which I can use to load and save files on Windows, and I use these "training wheels" instead of figuring out how to specify paths on Windows properly. However, we expect that that new cyclists take the time to learn the tool before using it effectively, and I think that this is expectation is reasonable. But we do not apply the same reasoning to computer interfaces.
There is a near enemy of this argument that states we should intentionally make Vim's interface difficult for new users so only true believers will use it, thus making the user population smarter or something. I completely disagree with this approach. When we can change UIs to help new users in ways that do not diminish their effectiveness for experienced users, then we should do so. Indeed, Vim has done so: old versions of vi did not allow navigation via arrow keys, and did not allow navigation while in insert mode (you had to use the hjkl keys in command mode). Vim fixed this: one can both edit text and move around with the arrow key in insert mode. Perhaps this is ideologically impure, but it makes the interface easier for both newbies and experienced users.
I reiterate that I do not consider UI or UX to be evil disciplines. I think consistent, understandable user interfaces are important, and I have seen plenty of tools where the UI is inconsistent and frustrating (Hello, GNU tar). But insisting that there is one kind of UI that should apply to everybody, that should not be configurable ("convention over configuration" is such a crock -- what's wrong with sensible defaults that can be changed?) and that is biased towards new users is deeply mistaken, and leads to some really frustrating UI experiences (Hello, GNOME). Different people have different inclinations. Different tools should be optimized for different tasks. Diversity can be a virtue.