Some UserInterface ideas that I've been thinking about for a while and found rewarding. I'm talking about programming environments here, but these ideas are applicable to lots of different kinds of user interfaces.

You can look at a computer program in a bunch of different ways, right? It's a multi-dimensional thing; you have different focuses at different times, and you want to be able to look at your program from lots of different angles.

The Smalltalk solution (which has been adopted in lots of other places) is to provide "tools." System browsers, class hierarchy browsers, inspectors, workspaces, debuggers, senders/implementors lists. Each tool lets me manipulate the program from a different angle. Sometimes I want to see the classes of the system divided up into their system categories. Sometimes I want to see the classes as an inheritance tree. Sometimes I want to see just one object and poke it and prod it to see how it works. Sometimes I want to see a running computation. Sometimes I want to see all the methods named "fred" in the entire system. The Smalltalk tools let me view and manipulate the program from any of those points of view.

An approach that I like even better is what I call the ChessBoardUserInterface approach. This is one of the ideals that the Self environment strives for, though DavidUngar would be the first to admit that it isn't even close to the ideal yet. The idea is that instead of providing a tool for each point of view, put all of the points of view on the screen at once, in a way that lets the user's brain switch between points of view as easily as it can switch between seeing the vase and the two faces:

http://pictures.funnyjunk.com/pages/vaseorfaces.gif

For example, look at the difference between the way Smalltalk and Self handle object inspectors and code editors.

In the SmalltalkLanguage, an object contains data, and its class contains its methods. When I want to look at an object, I ask for an Inspector (which is a box on the screen that shows me all the data in the object); when I want to change the object's behaviour, I ask for a ClassBrowser.

In the SelfLanguage, an object can contain both data slots and method slots. When I want to look at an object ''or'' change its behaviour, I ask for an Outliner (which is a box on the screen that shows me all the slots of the object and lets me change them).

The point here is that the Outliner acts as both an object inspector and a coding tool. In Self, switching between those two particular points of view ("looking at this object" and "writing code for this object") really ''is'' as simple as switching your focus between the rook's moves and the bishop's moves, or between the vase and the faces. In Smalltalk isn't not quite as easy to make that switch, because you also have to switch tools. (And in TextFileOriented languages like Java or C or even Ruby it's pathetically difficult, because of the silly artificial split between compile-time and runtime.)

Anyway, I found it useful to train myself to notice when I use the word "tool" and consciously look for ways of chessboarding my UIs instead. We programmers are proud of our tools, but it's fun to see if you can make the tools invisible and strive for an AlternateRealityUserInterface instead.

-- AdamSpitz

So in Self your tool is non-modal, while in Smalltalk the tools are so modal that you have to switch tools.