home  >  notes  >  interfaces

The sameness of interfaces

v1.0 28jun2001: First version

By Matt Webb.


Thoughts about the sameness of interfaces, some of which were had in The Approach tavern last Monday night with flat James and Simon, and some of which weren't:

A few interfaces to traversing a space are the standard Windows GUI, a Nokia mobile telephone menu system, a text adventure, DOS.

Put aside what the entire map looks like and how it's presented on the screen -- whether it's a network or a hierarchy. Put aside how the memory of navigation is presented, other windows open in the background, or a numerical crumbtrail in the corner. What remains?

What remains is for each node there are a number of exits and a number of items attached to it. A node is a location in a menu hierarchy, or a directory, or a place on the game map. Exits are double-clicking on folders, or pressing Select when an option is highlighted, or typing north.

At this level, all interfaces are the same.

I'll use the term "map" as a generic to describe the network of menus (a tree just being a special type of network), or the filesystem, or the folder tree. The point at which information is extracted from the map to the user is on entering a node, the information being about the items there and the exits to other nodes. All other presentation on screen is constructed by the interface (program) with no reference to the map at all. If other windows are kept open, it's just that the interface has remembered about the nodes. If there's a crumbtrail, it's because the interface has remembered the path. If the node looks different, or has context around the exits, it's metainformation attached to the node (think about a web page).

So: the sameness of all interfaces is in looking at a single node on the map at a time. This leads to three interesting ideas.

Firstly: Interfaces are now ultimately skinnable. You could use Windows as if it were a mobile phone. You could traverse your mobile phone menus as if it were a text adventure. The behind-the-scenes interaction between the map and the interface is the same in all cases; it's the interface that has the smarts.

Secondly: It gives us clues on how to build more unusual, exotic interfaces. When there are bots sitting at the other end of an instant message client offering information, or a voice recognition system giving access to an address book, how should we build interfaces to them? This gives us clues: Use the standard map first, build the interface second.

Thirdly: It's a level of abstraction which makes it possible for solid open source methods for catch up with the established GUIs. A defining feature of the free software world is that it's composed of very small black-box (swappable) programs, all interlinked. But the GUI has always been monolithic -- even the window manager doesn't allow for much flexibility. But by abstracting in this way, new interfaces can be built brick-by-brick, as the community needs. Imagine defining an XML dialect and messaging protocol to navigate the map, returning information and meta-information as required. Now imagine building a window manager, or folder hierarchy, or even terminal shell on top of that; and then it's trivial to write alternative interfaces for the web or for voice.


home  >  notes  >  interfaces