I designed the explorer bar, a set of web navigation helper UI, for Internet
Explorer 4.0 & 5.0. For History and Favorites we provided a treeview much
like the one you describe.

The short summary is that we felt it was worth autocollapsing unused nodes
by default. There are heursitics to help minimize the amount of shuffling,
and we'd felt it was better to keep the user focused on the item they
clicked on instead of forcing them to go back and cleanup unwanted open
nodes in the tree.

We spent a bunch of time in the labs experimenting with this, and found
overall the simple action of autoclosing worked better across all of our
users. When a user clicks on Menu3, they want menu3 - if you don't close
menu2, then they have to scroll anyway to see the items in menu3. It's
useful more often than it's annoying, so we did it.

Most power-users disliked it , since they wanted to see all of the nodes at
the same time, especially when viewing local content - we eventually did
provide an advanced option to turn it off in IE5.

I recommend looking at Microsoft bookshelf and how they manage their
treeview - I spent a ton of time looking at different treeview
implementations over the years (Mac, bookshelf, Superbook, etc.) and the
recent versions of Bookshelf managed to do an excellent job of keeping the
churn in the treeview to a minimum. Working with Javascript makes it hard to
be smooth - it's sad that there isn't a reusable control somewhere so that
websites can reuse the same widget behavior.

-Scott



-----Original Message-----
From: Hal Shubin [mailto:[log in to unmask]]
Sent: Wednesday, March 03, 1999 10:50 AM
To: [log in to unmask]
Subject: Menus in a left-hand nav bar -- show all contents?


I'm working on a couple of Web applications. They all require menus, which
will be vertically on the left side. How should they appear?

I did an application once where there were a number of menus, all with sub
menus. Only one menu was open at a time. Clicking on another one would
close the first one and expose the second one. (This used frames.) I wanted
to focus the user's attention on the task at hand. Example:

[Initial state]
MENU 1
MENU 2
  choice a
  choice b
  choice c
MENU 3
MENU 4

[Then click on Menu 3]
MENU 1
MENU 2
MENU 3
  choice a
  choice b
MENU 4

There are some problems with this. One is that things move. After you click
on MENU 3 above and the page is redisplayed, MENU 3 is no longer under the
mouse pointer. Another problem is that it makes exploring the menu choices
hard -- you can only see one set of submenus at a time.

We didn't do enough testing to get feedback on this, and I'm faced with a
similar situation. In this case, the client wants to use DHTML, so we might
not even need to redisplay the page in order to open and close menus.
That's a plus.

On the other hand, if the menu choices are always displayed you always know
what the choices are, and they don't jump around. Unfortunately, if the
list is long, or the screen is short, they won't all show, and some will be
lost to the user, maybe forever. I'm leaning toward this, and will do some
testing soon, but wonder if anyone's had any experience with these two
methods (or any others).

thanks                                  -- hs

Hal Shubin, Interaction Design, Inc.
http://www.user.com
617 489 6595 voice, 617 489 7395 fax