The Stripy Strudel's Journal

From all the features of my PDA, I only use two; all the others have turned out to be useless or unusable. Firstly, I read books with Haali Reader; secondly, I use the to-do list, but only to keep the shopping list for the supermarket.

The look of this to-do list is trivial: there is a list with a square to the left of each line; the square can contain a check mark. This simple application also has a menu where I should point out two items:

• Active tasks
• Completed tasks

Obviously, tasks are subdivided into active and complete. Initially, I can see both kinds in the list. If I pick “Active tasks” in the menu, I'll only see the active tasks, and when I open the menu next time, there will be a check mark to the left of the “Active tasks” item. So I can only see active tasks (I've enabled this mode a year ago and have already forgotten what I did to get there), and now I want to see all the tasks. Question: what should I pick in the menu?

Here is how I think: “Right now I can only see active tasks, and the ‘Active tasks’ menu item is checked. I cannot see any completed tasks, and the ‘Completed tasks’ item is unchecked. It seems like the categories of tasks currently shown have check marks in the menu. In addition to the active tasks that I already see, I also want to see the completed tasks, so I need the ‘Completed tasks’ menu item to have a check mark. Usually, when I want a check mark to appear for a menu item, I have to click the item.” Of course, I make a decision like this rather intuitively, but it is actually backed by reasoning like this.

After considering this for a second, I pick “Completed tasks” in the menu, and what I get is… the list of only the completed tasks! After that, the “Completed tasks” menu item has a check mark, but the “Active tasks” item hasn't. At a second attempt, I realize that, in order to see all the tasks, I have to remove the check mark from the menu item that has it, which returns the system to the “normal” state (as opposed to the “special” modes where only active or only completed tasks are shown).

Of course, I'm long used to such behavior of this application, but I've never understood it and have rather memorized the “irregularity”, just like I had to remember that the marks for cold and hot water in my bathroom are switched. Every time I use the tap, I routinely recall, “The wrong way!” and tilt it to the side marked with red to get cold water. Similarly, every time I use the menu in the to-do list application, I recall that it works “the wrong way”.

Earlier, when I encountered such interface solutions working “the wrong way”, I thought them to be bugs or design mistakes. However, mistakes of this kind are quite common and are often similar to each other, fitting in a pattern. Moreover, such solutions are often found in applications and devices that non-technical users usually describe as simple, intuitive, easy and convenient to use. It seems like there are two approaches to interface between a human and a machine, and maybe even two systems of thinking. I might not have chosen the best names for them, and someone might have already described and studied them, but nevertheless I'll try to provide brief descriptions.

Object-oriented approach

This approach is often found in technical experts, especially programmers. The approach is centered around the notion of an object (such as a document or the system as whole). An object can be in one of a multitude of states, and it transitions from one state to another under influence of various factors, including user actions. In order to control the object, it's important to know its current state, that's why this approach great attention is paid to informativeness of the interface, that is, to its ability to inform the user about the current states of objects. The problem the user is facing is perceived as the difference between the current and the desired states of the system, and is solved by applying the inputs necessary to get the system into the desired state. To solve a problem successfully, one has to understand the structure of the system, its possible states and the transitions between them, that's why the object-oriented approach favors documentation that describes concepts, principles and the overall system organization.

Procedure-oriented approach

This approach is prevalent in people who aren't technical experts. The approach is centered around the notion of a task. In order for a problem to be solved, it has to match one of the tasks that the application or device is designed for (ideally), or at least to be possible to break up into a sequence of such tasks. The problem is solved by applying the inputs that get the system to produce the desired result. That's why the procedure-oriented approach favors documentation that provides step-by-step instructions for solving typical problems. Because the critical part is knowing what input is necessary to perform a task, attention is paid to discoverability of these inputs (toolbars, context hints).

It's hard for me to write about the procedure-oriented approach because it's not how I think, and everything that's made that way feels unnatural to me. The conclusions I'm making are based not on my personal experience from using this approach but rather on the analysis of the systems following it.

I'm surprised not by the very existence of two different approaches, but rather by the gap between them that is so wide that people following one of them can't even project the thoughts of those following the other approach onto themselves. The existence of these two approaches answers a lot of questions:

• Why cannot programmers design a good interface for non-programmers?
• Why do televisions and videotape recorders have such “stupid” menus that an experienced programmer often cannot configure them without the manual?
• Why are the “easy to use” image processing applications (that often come along on a CD with a scanner or a digital camera) unusable?
• Why don't you have to press “Enter” on a doorbell after entering a one-, two-, or three-digit apartment number?
• Why do home appliances so often have those (annoying to many programmers) automatic transitions from one state to another after a delay?
• Why cannot many people master programming?

On the other hand, new questions arise:

• Is the bias towards one of the two approaches inborn or is it rather acquired with upbringing?
• Can a person following one of the approaches learn to use the other one?
• Does schooling affect the choice of approach?
• Does the object-oriented approach determine the choice in favor of a technical occupation, or is it the other way round?

The original entry in Russian features a poll: Object-oriented vs. procedure-oriented approach. It is possible to vote in the poll after logging in to LiveJournal; registration of LiveJournal accounts is free.

Which of the approaches better describes your way of thinking?

• Object-oriented approach.
• Procedure-oriented approach.
• A third approach not described here (please comment).
• The subdivision into the two approaches is fundamentally flawed (please comment).

Please don't vote if you haven't read all of the above. Also don't vote and accept my apologies if you regard asking the question inappropriate.

UPDATE: I have to agree with kalinka_malinka. This entry is an example of how to run knowingly non-representative surveys.

UPDATE: Another interesting aspect of the problem (in Russian).

По-русски: Все программисты с Марса, все пользователи с Венеры