March 23, 2004

Objects, Navigation, Long Noses

Long noses because I plan on indulging in my longtime hobby of sticking mine into places it has no qualifications for nor business being, but about which I have an opinion nonetheless. First things first: This post is about a discussion which happened some time ago amongst the worthy folk whose effort brings us the Nautilus file browser on Linux. Late last year, the project maintainer decided to announce that Nautilus would be pursuing a new direction, of sorts - that of presenting an object metaphor for the navigation of files and directories. Here's the thread.

The thread offers some excellent views on why this is a good or bad idea (or both). I happen to work with a couple of the folks on that list, and reading the thread for the first time recently I was inspired to rethink my own user interface preferences and philosophy.

To make one thing perfectly clear, I was a long-time old-style Macintosh OS user. This interface is mentioned in the thread as embodying the 'object' or (as Ars Technica calls it) the 'spatial' model. In it, each discernable screen object (icon, window, etc.) does more than just represent something on the computer - it behaves more as if it was that thing. For example, an icon doesn't just represent a file - it is a file. Double-clicking it opens the file. If it is a folder icon, double-clicking it opens a window which shows us the contents of the folder. Not only that, however, but there can only be one window open on the screen showing us that particular folder's contents at any one time. This strengthens the tie between that picture of a folder on the screen and the notion that manipulating that picture is manipulating that folder.

There are many other characteristics of an object system. My favorite? That position matters (this is why it is also called a spatial system). If you put something in a folder, and close the folder and then open it again, that object is painted at the same place you dropped it, relative to other objects in the folder. When you open an object and get a window, that window will always open on the screen to the same spot it was in when it was last closed. All this and the many more things that make up an object system are there to do a specific thing - they are there to allow (and encourage) us to take advantage of the human mind's ability to organize objects spatially when using the computer. The mind has been conditioned since birth (in sighted individuals, at least) to use spatial recollection and placement to impart meaning. Important stuff? Closer. Center. Less important? Fringe. Far. Ordering? How about top to bottom, or left to right, or bottom left far to top right near. Whatever we've decided on the spur of the second is easiest or most effective for us. This is why it can be such a powerful organizing tool, and is the reason so many otherwise-low-tech Mac users would reach for hatchets whenever anyone talked about taking away their Macs (for more on why Windows never did this right, see the thread).

There are, of course, limitations and disadvantages. It's difficult to perform the magic that the computer, a mechanism for abstraction, lets you, when you're miring yourself in a physical-representation interface. It's very difficult to handle scripting, and complex selection, and searching - for the very reason that there are no physical representation for those tasks. For these tasks, some argue, a navigator metaphor - a viewer representation that shows you what is available, as in the Windows file explorer or the Nautilus navigator window - is better, because since it is more abstract, it is easier to abstract out past its visual limitations. The current maximum abstraction is the command line; maximal learning curve, minimal representative binding, but maximal power to perform actions with minimal user physical effort.

I know, I know. This is all in the thread. What the hell are you saying, J.B.?

I suppose I was intending to weigh in with this notion. The limitations of the physical representative interface are not necessarily inherent limitations of the approach. In many cases, they are in fact limitations of the technology (both software and hardware) and resources (ditto) available to the user. It is easy to say that one simply can't represent a search action on an object interface, but this may not be true - rather, it may just be that there aren't any available standard methods for doing so, and not enough horsepower to do it convincingly.

If this is the case, if in fact the limitations are limitations of the present rather than of the logic, then don't bind us to an interface (the navigator) simply because it can be made more powerful with today's technology. Of course, offer it as an option for the technically astute. However, given technology's curve, it is becoming increasingly difficult to claim that the 'average user' doesn't have the horsepower in CPU or GPU to represent a fully object interface in complete Virtual Reality, even - the limitation is that there is no standard mechanism for handling VR available to the coder.

Always, always make the 'reach for the sky' solution a possibility, even if you have to cover your bets with the currently possible. Open source is one of the few places in the world right now where this approach is possible, much less lauded - but here's a perfect example. When these VR methodologies, and interfaces, and systems, are invented, coded and built - let's not have them shot down because people have convinced themselves that 'the Navigator metaphor is more powerful than they are.' Sure, it might be, initially. It might always be, because it will always be easier to increase capabilities via increasing abstraction than by building the elegant machine to take The Rest Of Us (thank you Apple) there. But someday, that elegant machine will come - and an Object metaphor implemented now will give all of us an easier step and path to it when it arrives.

Oh yeah, there's another reason. Heh heh.

As it stands, our current user interfaces are all attempts to some degree or other to produce a working object model (thank you, Xerox PARC). The Navigator model came about in order to cover technology deficits in implementing an actual object model. However, we still have 'desktops' and 'windows' and files are still icons that look like pieces of paper, or like pictures, or what-have-you. Simply put - don't let these interfaces remain half-assed. So much of the confusion in current computer interfaces is at that point where the object model craps out and the navigator model intrudes; at that meniscus of interpretation where understanding curves, like light going from water to air, and we lose track of what we're doing.

Let's push that point outwards by building on the object. Push it away from us. Work for consistency in the presentation. This isn't to say abolish the navigator - just try to build, for us dunces, a consistent world option. There's no way to make a navigator model 'consistent and complete' really, because the first thing it asks you to do is give up some of your understanding of reality in favor of its own. The object model, in contrast, asks you to retain your understanding of reality and then endeavors to provide as few rude shocks as possible. The second approach is closer to the seamless experience we want, especially as newbies; indeed, once we are of a technical mind to use the navigator, we're mostly to the CLI since so many navigators, these days, rely on typing arbitrary stuff into search boxes and address widgets. Posted by jbz at March 23, 2004 11:59 PM

Comments
Post a comment









Remember personal info?