Heterogeneous Trees, Part II

Uli Kusterer has a response to my Heterogeneous Trees post.

His approach on modifying TADS Workbench for Macintosh – which is his app, after all, so he has some authority in the matter – is a compromise, and I can see his point.

There are some usability benefits to using trees. Trees nodes are easier for the user to minimize, and might be less cumbersome than, say, three separate list widgets stacked vertically in a window. If you make it so the list widgets get bigger as the window gets bigger, then even the spatial arguments I made before hold less water, since the coordinates of the beginning of the lower lists are not fixed, but depend on window size. If you don’t make the lists grow in that fashion, then you’re condemning the user to endless scrolling to navigate lengthy lists, no matter how big you make the window.

Split views are one solution, but I find them a bit cumbersome. You have to click just so on a split control to resize it, unlike the larger disclosure triangles of an outline view.

Well, so how about the Finder’s Info window? It uses disclosure triangles, but I’m dissatisfied here as well. Letting the user have so much control over minimizing pieces of a window’s UI feels sloppy: window-as-accordian.

My ideal solution to this is not to have multiple lists in a single window at the same time at all. Separate the lists onto different panels of a tab view, and make those single lists grow as the window grows. Will that cover all cases comfortably? Probably not, and I wouldn’t be rigid about it, but it’s where I’d start.