Radu Luchian(ov): Portfolio:
Computer-Human Interaction

One may wonder why I'm not using the widely accepted term of HCI (Human-Computer Interaction). I prefer CHI for several reasons:

1. Because we cannot control what the human does with the interface, we have to concentrate on the Computer side of the equation. It's the computer we program in order to be easy to use (though some people want to program the Human through seemlesly identical interfaces and shortcuts -- see below).
2. To distance myself from those psychology-challenged experts of HCI who write long papers full of great ideas, ideas which they fail to apply to their own work... They say things like, "interfaces should be as easy to use as walking or like writing with a pen on paper." And they ignore two very important facts:
   • That people spend several years quite intensively training their walking and writing skills, and after that they get to exercise daily. It's not fair to compare such specialized activities with using some newly-encountered interface.
   • That walking and writing are fairly simple at a functional level, while computers and their software are designed to perform tens of thousands of functions in tens of functional areas of creation and communication (reading, writing, coding, drawing, calculating, simulating, playing, composing music, editing sound, tracking activities, etc)
3. Also the name of Human-Computer Interaction, following the SOV strucure (subject-object-verb; regardless of where the V is, in English the S comes always first), with which the English language primes us, puts the interaction in the lap of the (human) users. Well, I consider that since computers are better at consistency and exact memorisation and at following protocol than users are, the computers should be recording the pattern of interaction, and the users should just set the pattern to something they are comfortable with.
4. And finally, because it's kinda cute to have a greek letter for the name of the discipline :)

I know that the issue of user-adaptible interfaces was thrashed continuously with arguments ranging from "The user should concentrate on doing the job, not fiddling with the interface" to "If you allow the user to change the interface, you'll have to say good-bye to standards and team productivity will go down." To the first sort of argument I would reply that the users should set the interface in the process of learning the software they are using. This will force them to consider how often they'd use a function in relation with and as compared with the others, thus building a better conceptual network about their activity (interaction with the software), thus shortening learning ramps and lenghtening memory decay slopes.

To the standards argument I don't have what to reply, me being sort of an anarchic type. I know that standards are necessary for communication, but I prefer to decide what is the best way for myself to do things, thank you very much... Not everyone thinks (imagines, works, plans, ), the same way, and the shortest path between two points in the n-dimensional conceptual space is not a straight line, but the one you know best.

Taking into account these observations, I set out to allow the users to decide where and what to do, and simply provide the tools for them to arrange, use and modify as they see fit. That includes allowing them to make their own tools within this framework. (See MonDoc)