Rooms And Doors

OperatingSystemsDesigners should learn a thing or two from ComputerGame developers when it comes to UserInterfaces.

RoomsAndDoors is a SystemMetaphor in extensive use among games. It has the advantage that people can port their knowledge of reality to this UserInterface, making it very 'intuitive'.

RoomsAndDoors is an excellent SystemMetaphor for user navigation of a general purpose OS. Rooms are souped up versions of directories (with no arbitrary single-parent directory limitations) and Doors are souped up versions of hard links between directories. Files are made consistent with this metaphor either by restricting them to a single directory, or merging the class File with the class Directory so that each Room contains a stream of bytes as well as a dictionary of doors. The latter option is preferable from a programming viewpoint, the former preferable from an intuitive user viewpoint.

A graphical shell would represent each room as a navigable 3-space containing doors. Doors would be arranged in a circular configuration since humans recall angles better than distance. So doors to rooms at the same level of the hierarchy would all be in a circle, doors to rooms higher up would be in a second circle above the previous one, and doors to rooms going down would be in a third circle below the first one.

Navigating this space requires 5 or 6 degrees of freedom which can be achieved using a 3D positioning device in each hand (eg, the RingMouse? from Infogrip). Then there's the question of giving out commands (select a door, rename a door, move a door, et cetera). If one recognizes that commands are idiomatic then one can abandon any pretense of making them 'intuitive' and use glyphs or iconographs drawn by the pointing device. Circling a door might select it while making a cross over it might remove it. More complicated glyphs make the command system look like a manual spellcasting system. It shouldn't come as a surprise that computer game designers have already come up with this idea (eg, Black & White). This second wizardry metaphor fits in well with the base RoomsAndDoors metaphor and suggests interesting extensions such as summoning a familiar for help and having a spellbook of glyphs. Even the idea of avatars fits well in this metaphor.

Subtleties of the model include chatting between users done using speech balloons attached to avatars and using concentric circles of doors at each level in order to prevent overcrowding (and maybe a command to make rows translucent in order to see what's behind it).

Of course, the primary problem with it as suggested is that it requires the user to spend all his time in MouseMode. The secondary problem is that navigation in it would be SLOW. -- DanielKnapp

If you define 'slow' to include faster than any other graphical user interface ... And do you know of any games that don't have keyboard shortcuts for any and all mouse commands? Another point to consider is that it should be easier to switch between keyboard and mouse modes with a RingMouse? than with the traditional type of mouse since all you have to do is lift your hand above the keyboard.

If you want to see all the doors at once without having to look around you then just limit them to an arc, easy. Or get a 360 degree projection system. :) If you don't want to look up and down then just move the different level circles closer together. And if you want to navigate quickly, two or more links at once, then use a glyph that makes you very big (a la AlicesAdventuresInWonderland) so you can see the rooms which the doors around you go to as well as just the room you're in. Or even better, use binoculars a la SelfLanguage's AlternateRealityUserInterface. -- RichardKulisz

I still sense the return of MicrosoftBob?...

Care to elaborate? By the way, http://ThreeDsia.sourceforge.net is attempting to do something like the above for Unix. Doing it over Unix is a horrible nightmare, this kind of stuff can only be done over a decent uniform OS.

This metaphor and some of its implications were first presented in a readable and thoroughly refreshing 1986 paper by D. Austin Henderson and Stuart Card, based on research they did in the early 80's at XeroxParc. The paper, titled "Rooms: The Use of Multiple Virtual Workspaces to Reduce Space Contention in a Window-Based Graphical User Interface" should be a must-read for anyone interested in this topic. This paper was published in "ACM Transactions on Graphics", July 1986. ACM members can read it here: http://www.acm.org/pubs/citations/journals/tog/1986-5-3/p211-henderson/ . The general public can read it on the WaybackMachine: http://web.archive.org/web/20011116090943/http://www.parc.xerox.com/istl/projects/uir/pubs/pdf/UIR-R-1986-01-Henderson-TOG-Rooms.pdf [works as of 2005-09-26]

Henderson and Card, because they've thought about this for more than twenty minutes, bring a level of rigor to the exploration of the metaphor that might advance this discussion. -- TomStambaugh

If they had to think more than twenty minutes about something so self-evident ....

My initial impression of that paper is that it's irrelevant to the topic at hand. I'm talking about actual DomainObjects being represented in a certain way. That paper is talking about interface artifacts (windows and icons and other crud) being represented in a certain way. Their primary consideration (lack of monitor real estate) is completely irrelevant to me. It's completely irrelevant period since future technologies (eg, 360 degree projection systems) will make the issue obsolete.

Including one room into another room isn't a 'design solution' to me. It's a hard constraint deriving from the fact that directories in Unix are included in other directories. Even a pathetic OS must do at least as well as Unix. And geez, persistence; that must've taken a long time to figure out! There are a couple novel ideas like having the door you came from be backlit for reverse navigation. And fish-eye distortion is important though seldom though about explicitly. And then there are the plain dumb ideas like allowing multiple instances of the same window to exist.

Creating interface objects (like the collections of windows) is a dumb idea because you end up having to jump through hoops in order to share these interface objects in situations where the domain objects are already shared. The creators of PlanNineFromBellLabs found that out. The only solution is to create new domain objects. If you need a collection of files then that should be some different kind of file, something which users can manipulate and share just as easily and naturally as files themselves. SelfLanguage also has collections of windows, but they are domain objects. Self's UI is based on the insight that interface artifacts must be isolated and eliminated as much as possible.

The structure intrinsic to RoomsAndDoors is an acyclic graph where edges are either undirected or come in link-backlink pairs. Any time you have to structure a large amount of data for users to navigate, that's what you do. You want to design a filesystem for human navigation? Then use this structure. You want to design a network for human navigation? Implementing this design in some new domain isn't the job of researchers, it's the job of any half-decent architect.

I'd call RoomsAndDoors a pattern except that I haven't seen it used by anyone else. What am I talking about, reality uses this. And computer games use this also. Actually, RoomsAndDoors is an entire pattern language. 'A pattern language for human navigation' maybe?

All in all, I prefer the AlternateRealityUserInterface paper, even if it's less 'rigorous'. -- RichardKulisz

But: Hasn't using software often already enough similarity to an adventure game? -- HelmutLeitner

Too much games? Heresy!

The problem is that using software resembles all the tedious parts of a horrible adventure and none of the fun parts of a good adventure game. If it has to be a game, it should be a fun game.

See http://www.cs.unm.edu/~dlchao/flake/doom/

CategoryInteractionDesign