Wich One Comes First, Object or Action?

By Gerd Waloszek

Recently, I tried to recall what "object-action approach" means to UI designers. In short, using this approach, users select an object first and then perform an action on it. For example, the user selects a document icon on the computer desktop and then chooses an action from the pulldown or context menu, such as Open (see figure 1). This procedure has been so widely adopted and therefore so deeply engrained into our behaviors that we don't even think about it. But a few "old hats" like me may faintly remember that there had been something different way back in the past: the action-object approach. When issuing a command in an command-line interface, such as DOS or CP/M, we had to name the action first and then the object(s) – plus maybe quite a number of tricky parameters, options, switches, and the like.

With the upcoming of graphical user interfaces, there were heated debates about the better approach. Both have their advantages and disadvantages, though, and I do not want to reiterate this discussion here. In the end, the object-action paradigm, together with direct manipulation, won and took over. However, if you take a closer look at today's user interfaces, you will see that a pure object-action approach cannot be persevered. Typically, there is a blend of both approaches in order to achieve efficiency.

Classical desktop

Figure 1: "Classical" desktop with object-action approach – a selected folder with associated actions in the context menu

There are some notable exceptions to the dominant trend, which – at least in certain aspects – still follow an action-object approach. Among these are graphic applications, in the line of and including MacPaint, and photo editing software. You might argue, that these programs also follow an object-action approach because you have to select a document first, that is, a picture or photo. But for me, their handling is quite different from clicking icons on the desktop and then selecting commands. And what about an empty canvas? OK, it's like an empty sheet of paper, and as such an object, too... But do we really think of an empty sheet as an object? I would rather say that we think of the entities, which we draw on the empty sheet, as objects. We create and modify them using the application's tools – brushes, pens, the eraser, etc.: I select a brush and paint a dot, another one, and so on, and finally a circle (see figure 2 – in German: Punkt, Punkt, Komma, Strich, fertig ist das Mondgesicht!)

Asimple face drawing

Figure 2: The moon face in a paint application – five objects or one?

Let me tell you one more story from the past: When I programmed GLUE, a graphical programming environment (for LISP using LISP...), I suddenly realized that I had created an application following an action-object approach: Users had to click a tool first and then applied it to the objects on the screen – boxes standing for LISP lists and functions. This user interface was very efficient, but I must admit that I changed the handling paradigm into an object-action approach later (see figure 3) – I did not dare to swim against the (main)stream.

Figure 3: GLUE – object-action version

Nevertheless, I was never completely convinced of the object-action approach. Somehow, I regarded it as an "side-effect" of the object-oriented programming paradigm, which was particularly well suited to graphical screen objects (I realized that, too, when programming GLUE – and switched from a functional programming style to an object-oriented one...). Somehow, I rather find it "artificial" or even cumbersome. On the other hand, proponents of GUIs and direct manipulation often highlight the "naturalness" of the interactions in the object-action approach. But is it really "natural" how we deal with objects on the screen? When I pondered this question, I asked myself how I deal with objects in real life. The answer is quite surprising: In natural environments, we are surrounded by objects and tools, which are also objects, in arbitrary order – one might even call it a chaos (think, for example, of the daily chaos on our "real" desktops...). Often, the distinction between tools and objects is blurred because we may have to care for our tools, too.

For illustration, please follow me into my garden. Let's assume that I have to repair my garden shed, and there are quite a few tools lying around in front of me and the shed: a power drill, a cordless screwdriver, a hammer, and some more tools. There is also a couple of boxes with bolts of different sizes (see figure 4). First, I take the power drill and drill hundreds of holes into the shed's shelves. Then I take my screwdriver and screw hundreds of bolts into the holes. Usually, I hate to put a tool aside. Instead, I try to use it as long as possible on different objects. The alternative would be to switch tools for every hole – that's the object-actions approach. Even worse would be – and that actually happened to me – to have only one tool at your disposal and to switch between drill and screwdriver mode for every hole...

Figure 4: A "prototypical illustration" of the situation

Of course, there are also stories, which go the other way round, for example, if you treat a special work piece or a work of art. To sum up, both styles have their places in real life, and neither seems to be more natural than the other. Why should it be different at computers?

So, returning to the computer, my ideal desktop would look more like this screen:

Figure 5 : A "quick-and-dirty" collage from Kai Krause's Soap – a lot of tools and objects lying around on the desktop; the remote control looks somewhat "outdated" in this context...

Actually, this is a quickly made collage (see figure 5) from two screens from Kai Krause's infamous Soap application. In the appendix, you find three original screens – two of them were used for the collage.

Appendix

For demonstration purposes, I show three original screens from Kai Krause's Soap, which seems to go a little into the direction I wanted to point to. Regrettably, I could only find so-called "heaps" of objects or collections of tools but no mixtures of both. These are demo screens – the application does no longer run on my computer.

Figure 6 : Kai Krause's Soap – a lot of tools lying around but only one photo to work with

Figure 7 : Kai Krause's Soap – again, a lot of tools lying around but only one photo to work with

Figure 8 : Kai Krause's Soap – now, a lot of objects lying around but no tools

Originally Published: 03/01/2007 - Last Revision: 01/31/2009