A "tree view" is a way of exploring tree-structured data; at any given time, a subset of the tree is displayed, and clicking on any node to display its children or hides all its descendants. An editable tree view, where you can easily change the contents of any node or copy or move it elsewhere in the tree, is often called an "outliner".
Some people are big fans of outliners as universal user interfaces, notably Douglas Engelbart and Dave Winer. They have the advantage that the display at any given time can include data from many different sources, but still remains essentially linear. I wrote recently about the art of summarization or rubrication as an aid to navigation and retrieval. These days, when I want to find a web page on some topic, I might perform a Google query; this yields ten web page titles, which I generally read in sequence, and when I find one that sounds promising, I read the extract. If it sounds sufficiently interesting, I might follow through to the page itself, which may have its own table of contents summarizing different sections of the document. This sounds a lot like outlining, and you could imagine a web browser that would display the whole process as an outline, dynamically transcluding text beneath each link you click on. This may or may not be an improvement on the standard web browser UI; probably for some tasks it would be, especially if the web pages in question were designed for it. Today I was watching Dick Hardt's Identity 2.0 presentation from OSCON <http://www.identity20.com/media/OSCON2005/>. In Larry Lessig style, his slides changed more than once per second, and typically had only a word or two, or a simple diagram, in each slide. I used mplayer's "]" key to speed the presentation up to 6x real time, and in consequence I zipped through the presentation summary pretty quick; when something looked interesting, I would use the "[" key to slow back down to to normal speed, and the "<-" key to zip back to what I'd just skipped over. It seems to me that this kind of interaction technique was closely analogous to the operation of an outliner, and could likewise be applied to navigating hypertext. If "linked-to" text is temporally compressed (by some standard ratio) after the "link text", you could skip over it by speeding up. My analysis of typical summarization suggests that if the standard ratio were a factor of 60 (six octaves), the compressed text would usually take about the same amount of time as its summary; six octaves is enough that it could perhaps run concurrent with the "link text" without interfering with its comprehensibility. Even an infinitely-deep link structure could fit in some finite time by this method, even without concurrency, because the total time is the sum of an exponential series. More refinements: Adjusting the speed should pop you back some fixed amount of subjective time, since presumably there's some time lag. Without concurrency, there should probably be a relatively nearby floor on the speed of any particular text, perhaps an octave or two below 'normal speed'; otherwise you might find yourself in a very long silence. Without any extra help, speech sounds fine at 1.75x or so (about 3/4 octave up); apparently by squeezing out pauses and using a little signal-processing magic, people can quickly learn to understand speech at 2x. This could be very helpful. Obviously this all applies to video as well as audio. To actually play this, at some point you have to cheat and limit yourself to some finite sample rate.
