Auto Presentation

In AutomaticVsManualPlacement, it's shown how blatantly stupid, wasteful and inefficient it is to require users to place objects manually. For the same reasons, it is stupid, wasteful and inefficient to require users to choose what objects will be presented to them.

Antedeluvian CLI fanatics notwithstanding, it's quite clear that auto-presentation of nodes (the most general aspect of an object) is a decisive win. It's better to have a continuous listing of files in a directory which the user can ask to obscure than to force the user to repeatedly ask for such a listing. The listing is almost always necessary and requiring the user to request it is exceedingly irritating. The reason why is simple, getting a listing of files in a directory is not part of the problem domain but is simply overhead, hence a BadThing. These facts are acknowledged even by the CLI crowd in the very existence of MidnightCommander.

Contrary to popular presupposition, auto-presentation hasn't reached its apotheosis in GUIs. Far from it, while GUIs present nodes, they certainly don't present objects. They stop presentation at a stupid and worthless "icon", and require a deliberate act by the user in order to present the object (ie, to "open" it, in technical jargon) in a "window". Recently, this has been slightly ameliorated by the widespread use of thumbnails to replace icons for some object types.

(We will not discuss the auto-presentation of suspect code. The solution is blatantly obvious.)

But thumbnails are insufficient, being little more than vastly superior icons. Thumbnails do not in any way eliminate the icon / window separation. Nothing ever will short of the eradication of the dichotomy itself.

But first we have to show that this separation is bad. Which isn't too difficult since one of the reasons is that they create presentation overhead for the user. For example, the simple operation of closing a window alone generates an enormous amount of overhead. First you have to find the "close window" button of the window, then you drag the mouse to a teeny tiny target, and only then do you click on it. Oh yeah, and all of that overhead only occurs after you've decided whether you want to close a window or "minimize" it.

But presentation overhead of maintaining a window / icon dichotomy isn't restricted to using buttons. There is mental overhead for the user associated with the mere existence of a discontinuous transition. There's additional overhead from having to process and interpret such radically different presentations of a single aspect of a single object. And then there's the navigation overhead imposed by having to go back and forth between the aggregate node and the individual objects.

When objects are presented automatically, the user merely slides on to the next object in the aggregate node. When objects are not presented automatically, the user is forced to go back to the aggregate node (by dismissing the current object) before they can get the next object presented using a precision targeting operation (mouse click on an icon). This constant back and forth movement alone represents enormous overhead, which is only greatly amplified when the user loses their place in the aggregate node (a frequent occurrence).

(Picture viewers allow the user to slide to the next picture. However, movie and music viewers do not. Nor is there any mechanism that allows the user to slide from one object type to a completely different object type! And in fact, picture viewers' ability to slide to the next picture only results in users always losing their place in the aggregate node.)

As already stated, the only solution to all these problems is the total eradication of the dichotomy between icons and windows. This is done simply by replacing icons with object miniatures, as is done in ZoomableUserInterfaces. The result is that users can view objects at any magnification they wish by moving closer to an object or pulling back, they can slide back and forth, staying at the same magnification, without encountering any discontinuous transitions, without incurring any overhead.

(

"opening" an object is not a concept with any meaning to users
"saving" is at least understandable as publishing

A system should have

flexible handling of objects
switchable handling rather than manual handling
designatable, dynamictyping

)

In fact, comparing the two interfaces on a worst case / best case basis, we see that pulling back from an object in a 3D interface (worst case) only has a fraction of the cost of even the best version of closing a window using ALT-F4 (best case). This is because even if the user is summarily dumped into the directory that enclosed the object they were viewing (and this need not be the case since the directory window could have been closed, or simple not been on top of the stack), the user doesn't automatically know where the object they were viewing can be found in that directory. When pulling back, they do know this, and nothing prevents the existence of CTRL-X (or some other key in the navigation menu) being bound to a computer-mediated "pull back" operation.

-- RichardKulisz

Under CoordinateVersusNestedGui I argue that the machine cannot be smart (or human) enough to fine-tune the esthetics to fit haman preferences. Machine-decided placement is fine for drafts, but people like control over placement. Whether this is logical or not is perhaps debatable, but if you want to kiss up to the humans, especially those who pay you, then control is helpful. Remember, we are dealing with Homo Sapiens, not Vulcans. Perhaps you could argue that tools for techies should be more logical, meta, and automatic, but that is another realm. --top

If we had a good theory of aesthetics, the kind of stuff ChristopherAlexander noticeably tried and failed to do, it would be possible to build an aesthetic machine, but that's besides the point. The point is that AutomaticVsManualPlacement already provides a strong counter-example to your assertion that users want control over placement. And it especially counters the claim which lies implicit that users are willing to pay, and pay dearly, in order to achieve control; they are not. Users are not at all willing to pay anything in order to get control of placement because it has extremely little value.

The myth of the customer's "insatiable appetite for control" is about as justifiable as that of netizen's "insatiable appetite for bandwidth". Witness the dark fiber laying unused, witness the telecomm crash. It is nothing but a self-serving myth used to justify the technocrat's own sensibilities, priorities, wishes and desires. The real question isn't "do users want control" but "are users willing to pay for control",. Users are willing to have control only so long as they have no responsibility (as is the case in your example).

The economics of the situation may favour off-loading onto a programmer the creation of the visual layout of an application that will then be used literally a billion times verbatim, that makes sense. But we're not talking about such a situation, we're talking about the placement of a single object or window at a single point in time by the end user. The end user certainly does not want to be saddled with this and the economics of offloading this onto a technical expert are completely ludicrous. What you call a "first draft" is perfectly adequate to every end user almost all of the time. Far from being merely "good enough" it's tyically superior to what the user can achieve after investing substantial amounts of time and effort, time and effort they can never afford to invest anyways because end users (as opposed to mere clients) are always too busy. -- RK