Another hyperbolic geometry game and previous discussion here [1]. The different areas in the game help with a grasp of different interesting properties of the non-euclidean geometry.
Computing speed and rendering power were the barriers for a long time, and those have long fallen. But a larger headache is that navigation gets really unwieldy as the trees grow. I do a lot of stuff with graph visualization (conversational structures, community structures) and you have to do a lot of pruning, filtering, and bundling.
The audience for any given graph is inversely proportional to the number of nodes visible. Once you go past 100-ish nodes layouts start to seem arbitrary and once you go past a few hundred most people's eyes just glaze over. You can make the graph more readable with smart choices about color and node size but it's a constant signal:noise battle.
I looked into using a hyperbolic browser for a semantic graph UI over a decade ago. I aborted because the hyperbolic view seemed very patent encumbered. I agree that hyperbolic views are amazing, but has the patent situation changed?
It displays ALL of the nodes, given the millions of files and thousands of folders on a typical computer these days, some form of pruning would be required.
Just loading all the nodes would take a few minutes on most computers.
There is no reason that processing a few million files could not be done at interactive speeds. Searching for certain filenames on Windows is awfully slow with Explorer, but there are tools like UltraSearch [1] which directly scans the Master File Table of NTFS volumes and will find all matching files orders of magnitudes faster.
Also the UI is not a problem, I experimented myself with something vaguely similar and it was relatively easy to have millions of nodes - I think I just used plain buttons controls for nodes - in WPF at interactive speed. I think it somehow involved quadtrees to make it fast, just naively instantiating millions of buttons did not work, but it was doable. This was however ages ago and my memories are quite fuzzy.
Because Explorer certainly relies on APIs that abstract away the file system details and the smallest common denominator is probably recursively walking the tree structure of the file system which is orders of magnitude slower than scanning through a few megabyte of a central database.
Also it tries to search within files. I have a huge document library and it's often faster to look up a partial filename from the command line than to use Explorer's search, is slow and buries the file I want amid hundreds of irrelevant results.
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'.
Layered ignorance and incompetence from years of exponential growth, and linear education. I would also hazard a guess that the general disdain for understanding context and proven tech is another major factor.
I'm looking forward to the next decades, there's a demographic collapse on the horizon, global supply chain are weakening. The incentives to bring back manufacturing onshore will increase and that will require full understanding and will likely put constraints on supply anyway, just less so than a total collapse. Software will have to adapt and get all the compute results to a much better power efficiency.
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.
UI from the past tried to solve false UX problem. How to present to user a big amount of information they can look (literally) through. At the end filters and search were the answer.
> They're useless when you want to know about the dynamics of a system.
Generic UI experiments don't try to solve "dynamics of a system". Current best answer: interactive notebooks with first hand facilities to query, transform and visualize data.
I build such notebooks and an important part of that is figuring out what's interesting about the data in the first place, because it's not always obvious what you want to measure.
If you look into social media analysis, for example, there are a great many different approaches being developed and documented in academic papers and codebases, but little consensus on exactly what to measure and how. Lots of work was done on follower/friend relationships only for those to be subsequently discounted in favor of behavioral patterns. Of course, the fact that the mechanics of social media platforms are opaque boxes and are competitively manipulated for a variety of purposes complicates things further.
For me best value is a "walkthrough" feature with detailed description what's going on. It seems that static diagram with appropriate description text can have the same explanatory power.
The PSIBER Space Deck is an interactive visual user interface to a graphical programming environment, the NeWS window system. It lets you display, manipulate, and navigate the data structures, programs, and processes living in the virtual memory space of NeWS. It is useful as a debugging tool, and as a hands on way to learn about programming in PostScript and NeWS.
Cyberspace. A consensual hallucination experienced daily by billions of legitimate operators, in every nation, by children being taught mathematical concepts … A graphic representation of data abstracted from the banks of every computer in the human system. Unthinkable complexity. Lines of light ranged in the nonspace of the mind, clusters and constellations of data. Like city lights, receding ….
>PSIBER Space Deck Demo: Demo of the NeWS PSIBER Space Deck. Research performed under the direction of Mark Weiser and Ben Shneiderman. Developed and documented thanks to the support of John Gilmore and Julia Menapace. Developed and demonstrated by Don Hopkins.
Described in "The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines".
>PSIBER Space Deck and Pseudo Scientific Visualizer Demo:
Demo of the PseudoScientific Visualizer and NeWS PSIBER Space Deck. Research performed under the direction of Mark Weiser and Ben Shneiderman. Developed and documented thanks to the support of John Gilmore and Julia Menapace. Developed and demonstrated by Don Hopkins.
[...]
The Pseudo Scientific Visualizer
Darkness fell in from every side, a sphere of singing black, pressure on the extended crystal nerves of the universe of data he had nearly become… And when he was nothing, compressed at the heart of all that dark, there came a point where the dark could be no more, and something tore. The Kuang program spurted from tarnished cloud, Case’s consciousness divided like beads of mercury, arcing above an endless beach the color of the dark silver clouds. His vision was spherical, as though a single retina lined the inner surface of a globe that contained all things, if all things could be counted.
[Gibson, Neuromancer]
The Pseudo Scientific Visualizer is the object browser for the other half of your brain, a fish-eye lens for the macroscopic examination of data. It can display arbitrarily large, arbitrarily deep structures, in a fixed amount of space. It shows form, texture, density, depth, fan out, and complexity.
It draws a compound object as a circle, then recursively draws its elements, scaled smaller, in an evenly spaced ring, rotated around the circle. The deeper an object, the smaller it is. It will only draw to a certain depth, which you can change while the drawing is in progress.
It has simple graphical icons for different data types. An array is a circle, and a dictionary is a circle with a dot. The icon for a string is a line, whose length depends on the length of the string. A name is a triangle. A boolean is a peace sign or an international no sign. An event is an envelope. A process is a Porsche.
It randomly forks off several light weight processes, to draw different parts of the display, so there is lots of drawing going on in different places at once, and the overlapping is less regular.
After the drawing is complete, the circular compound objects become mouse sensitive, selectable targets. The targets are implemented as round transparent NeWS canvases. When you move the cursor over one, it highlights, and you can click on it to zoom in, pop up a description of it, open up another view of it, or select it, and then push it onto the stack of the PSIBER Space Deck.
Figure 9 shows a Pseudo Scientific Visualization of the NeWS rootmenu instance dictionary, also shown in figure 3 and figure 8.
Figure 10 shows two views of a map of Adventure.
Figure 11 shows two views of a map of the ARPAnet.
This is the network of IMPs (Interface Message Processors) that comprised the ARPANET in 1986. The ARPANET is history now, but thanks to the magic of Pseudo-Scientific Visualization and the ScriptX language and class library from Kaleida Labs, you can now experience what it was like to be free ranging packet hopping around the ARPANET in 1986!
This Pseudo-Scientific Visualization of the ARPANET was woven by the ScriptX language and class library from Kaleida Labs.
Select an IMP to jump into ARPANET Psiber Space. You can also view Text or Small Images.
Does anyone know if the Java hyperbolic tree visualization they were showing (or a similar implementation for the JVM) is still available, either open source or as a library on Maven Central?
If someone wants to 'grasp' what hyperbolic space is about, this game is one of the fun and inspiring ways to do that.