Visualizing Large Trees Using the Hyperbolic Browser (2021) [video]

[1]: HyperRogue – a non-Euclidean roguelike https://news.ycombinator.com/item?id=17432974

Just loading all the nodes would take a few minutes on most computers.

Treemaps for space-constrained visualization of hierarchies.

Including the History of Treemap Research at the University of Maryland

Started Dec. 26th, 1998 by Ben Shneiderman

Later updates by Ben Shneiderman and Catherine Plaisant - Last update Sept 2014

A History of Treemap Research at the University of Maryland

During 1990, in response to the common problem of a filled hard disk, I became obsessed with the idea of producing a compact visualization of directory tree structures. Since the 80 Megabyte hard disk in the HCIL was shared by 14 users it was difficult to determine how and where space was used. Finding large files that could be deleted, or even determining which users consumed the largest shares of disk space were difficult tasks.

Tree structured node-link diagrams grew too large to be useful, so I explored ways to show a tree in a space-constrained layout. I rejected strategies that left blank spaces or those that dealt with only fixed levels or fixed branching factors. Showing file size by area coding seemed appealing, but various rectangular, triangular, and circular strategies all had problems. Then while puzzling about this in the faculty lounge, I had the Aha! experience of splitting the screen into rectangles in alternating horizontal and vertical directions as you traverse down the levels. This recursive algorithm seemed attractive, but it took me a few days to convince myself that it would always work and to write a six line algorithm. This algorithm and the initial designs led to the first Technical Report (HCIL TR 91-03) in March 1991 which was published in the ACM Transactions on Graphics in January 1992 (http://www.acm.org/pubs/citations/journals/tog/1992-11-1/p92...). Choosing the right name took probably as long, but the term 'treemap' described the notion of turning a tree into a planar space-filling map.

My initial design simply nested the rectangles, but a more comprehensible design used a border to show the nesting. Finding an effective visualization strategy took only a few months but producing a working piece of software took over a year. Brian Johnson implemented the algorithms and refined the presentation strategies while preserving rapid performance even with 5,000 node hierarchies. The TreeViz application ran on color Macintosh models and led to the widely cited paper (HCIL TR 91-06) jointly authored paper in the October 1991 IEEE Conference on Visualization. This paper was reprinted in Readings in Information Visualization. I think treemaps are a convenient representation that has unmatched utility for certain tasks. The capacity to see tens of thousands of nodes in a fixed space and find large areas or duplicate directories is very powerful. I still use TreeViz for cleaning up my Macintosh. It does take some learning for novices to grasp the tree structure layout in treemaps, but the benefits are great.

PhD student Brian Johnson's implementation added many other interesting features such as zooming, sound (as a redundant or independent code, for example, larger files had a lower pitched sound), hue/saturation control, many border variations, and labeling control. We struggled to deal with the problem of many small files in some directories, but wound up showing only a blackened area that invited closer examination by zooming. We knew that encoding a linear variable such as file size as an area was breaking a graphic design guideline, but the benefits of seeing a large range of file sizes seemed like a compensation. We also knew that visually comparing long narrow rectangles to squarish ones was problematic, but cursoring over the boxes produced the exact file size on the bottom of the display.

[...]

You can import an Elements table and a Relations table and it shows you a graph. Can also attach fields/attributes to each element and the relations to see those when selecting an element in the 'map'.

What you should instead be wondering is why so much stuff today fails to display even this level of interactivity.

I feel like the current state of UX design is an absolute catastrophe, and the examples you just provided makes it clear why; modern UX design, besides being devoid of science and curiosity about how humans actually navigate the world, completely ignores 3d space and any form of graphical representations, instead serving up a minimum amount of data in white space hell with fragmented jump cuts - instead of a natural map based layout that have visible relationships - it seems that even the old school sitemap or the sitepath has been thrown in the dumpster now, instead constantly making the user unsure of "where they are" in cyberspace, where they can go and where they came from.

I'm sure even pretty standard desktop interfaces would be way faster to navigate if you zoomed in and out on folder "territories on a map" or tree navigation with paths that stayed for while after you used them, or knew "where they were" instead of GUI traversal or the command line that takes way too long because you have to go via the correct path, and forget the correct path because everything is "hidden" and dont have any landmarks around you that can point in the right direction ala. oh the "3 tree" that's north of the "4 tree".

And search is still very rarely good enough to work as an alternative, i feel like 95% of users always forget "where" something is in an app because it's hidden multiple layers down - page/ function search combined with a dynamic treeview could work though, but now one seems to implement that.

Eagle Mode (navigation through zooming) https://www.youtube.com/watch?v=G6yPQKt3mBA