Maybe it is a good idea to use zooming (ctrl + mouse wheel) to transition between various visual representations of the program. Zoom out — and you'll see the whole picture. Zoom in — and you'll see the code. Zoom in even further — and you'll see some details. Etc. I wonder how many different useful layers in between we can think of. Are there programming environments which somehow implement this idea? Do you like this idea?

a long time ago I saw a demo similar to that, I can't find it but I found this one which may be a good starting point to explore related work:

I believe touch designer pro uses this to support nested data flow programs ( at a low zoom level you see a node, and at a higher zoom level the node becomes its own graph). I think it's a good idea for visualizing recursive things.

YES! I really like this idea (in fact, working on it :) ). Node n noodle software usually has the concept of double clicking a node to open it up, revealing its subnodes / implementation. Though zooming is a bit more natural in certain cases. I have a combination of outliner/mindmap on an infinite canvas (translation + zoom), in which a node may be expanded as a list in the outline, or exploded to the side as a mindmap/graph, or fully moved into (becoming the current ctx/workspace). When expanded in the current ctx, its nodes becomes a bit smaller, thus allowing infinite expansion on the same view, resulting in a fractal-like zoom experience. The subnodes may be static logic, or a dynamic result, and in such case, they may define their rendering to a certain degree themself, so making an actual fractal out of this wouldn't be too far off :)

<- this one is close to the one I remember

I really think ZUIs are underexplored. If I ever get round to designing a UI it will be a ZUI combined with "search anywhere". I think these two together can combine the best of CLI and GUI.

For programs, semantic zoom (of various sorts) is what you want. And yes, ZUIs are underexplored.

I really think ZUIs are underexplored.

Absolutely! For me this falls into the category of interesting opportunities in the space between 2D and 3D interfaces. It’s easy to be distracted by the possibilities of AR and VR in “true” 3D, although there is still so much more to explore in 2D (2.5D?) space. Zooming is one of those interactions deeply rooted in the way we think. It has an embodied physicality to it, which provides a powerful metaphor that most people understand intuitively. This is why the touch gestures for it (pinch to zoom) are so easily remembered. I’m sure there are many more ways for us to build upon the patterns (kinesthetic image schemas) that provide the underpinnings for most of our linguistic reasoning and build interfaces with them that can truly be “intuitive”.

@Mariano Guerra Oh my God, this Eagle Mode is so amazing. In this way you can keep so much more information in your working memory — when transitions are continuous, than in the usual way when you discretely jump between contexts (windows, files, webpages, ...). I feel like I keep everything which was shown — because nothing disappeared abruptly, just smoothly diminished so I remember where to find it. Thank you so much for showing it. Why doesn't everybody here use something like this every day? Another half of my amazement is by the experience of this question-answer interface: I imagined what I wanted to see, posted a question to the right place, and in minutes I get something wonderful and relevant. How much better experience it is than googling. Can it be scaled so that thousands or millions of people can have such super high quality prompt answers to their questions?

I’m also a huge fun of ZUIs. And I do think the question

Why doesn’t everybody here use something like this every day?

is a good one. My guess as to why ZUIs are not more mainstream is that, though they can be quite effective for readers by leveraging spatial perception, they are rather difficult for makers of ZUIs. Essentially, making a ZUI is akin to cartography, but the digital world is ultimately unbounded (infinite canvas). Parent-child relationships can be mapped to containers and relative size, so something like “Eagle Mode” (which is awesome!!!) works really well since filesystems are a tree. But even then, there are many display and layout questions like the how many columns and rows per container. On the application side, something like uses a ZUI for relating documents and text to one another, but once you get to a certain number of documents, I think this seems pretty intractable as well. Spatial perception is a lot harder when the X-Y-Z dimensions are unbounded. This is just my guess though! What does everyone think?

@jeff tang It seems to me that an object tree with circular references is a pretty nice (and scalable) structure. One giant tree can hold all your data. Any object (node) can have links to all other objects (nodes) related to it in the form of key-value pairs (object properties). You can know and use the "real/absolute address" (e.g. shortest path from the root) of a node if you want, but you as well can start from any node and go "only down" — following the links which relate a node to all other things meaningfully related to it. And so on recursively.

Is a tree with circular references the same thing as a graph with a root?

I mean object tree, like this:

@Jared Windover yes, an object graph! Though @Grigory Hatsevich is driving at a canonical spanning tree and the idea of zooming parts of it more than others.

One giant tree can hold all your data

@Grigory Hatsevich yes, this! I call it a multidimensional tree, but this is what my project is all about, one single tree that is connected back and forth to all - tho having it directly circular like the example means you’ll have a hard time serializing it and updating it. the real structure in the backing should not be circular by reference like that but its more or less it. Great to see people thinking similarly!

Yeah we need more non-binary input besides mouse position (e.g. keypresd is binary)

Adding a depth sensor to trackpad would be fun, getting an extra dimension in work.

I think some already have a pressure sensor, or you mean more project soli?

Yup, meant more like project soli

Reading Building the Memex Sixty Years Later: Trends and Directions in Personal Knowledge Bases and they mention tree + graph as a data structure to consider 🙂

@jeff tang "Although graphs are a strict superset of trees...", object trees with circular references are actually no less general than "general graphs" because 1) each node can relate to any other node or to a group of nodes ("children:[child1,child2,child3]"), 2) there can be multiple kinds of relations ("son: value", "daughter: value", etc.). So I cannot imagine any relation which could not be expressed with object tree structure. Object tree is a graph which just has a default convenient structure, but is not limited by it. Please correct me if I am wrong in substence or in terminology.

Object tree is a graph which just has a default convenient structure

I’m not an expert on this, but yes I would say that an object tree is a kind of graph since you can have cycles and bi-directionality

Wait, soli wasn't an april fools joke??! AWESOME!

@Leonard Pauli no, it’s running in prod 😄

@Ian Rumac "if you have more than 1 parent" Thanks, I forgot to consider this case. Though I think it still can be handled with an object tree. There are two options: 1. You can simply know that "child"/"son"/"daughter" relation is by its nature a multy-parent relation, so each time you see "child"/"son"/"daughter" property you should look at the referenced object and get information about reciprocal relation from there: in this case you look at "parents" property of the referenced object and get all other parents from there. Thus you got info about this multy-parent relation. 2. If you require that it should be semantically indicated that a relation is multi-parent each time you look at this relation, you can implement this with object tree through the following convention: a relation value can contain not only the referenced object, but also some meta-information about this relation besides its name: John={name:'John', son{multy parenttrue, referenceObject:James}} Not sure if I am correct with terminology.

Your all seem to include muddling with the tree as an abstraction to support an array as parents afai can tell. There are more ways to implement this, one would involve what I guess is a wrapper parent, but that dilutes the data, one would be to make a full circle with copies, but that expands the depth recursively, one would be to cross dimensions, but that is not for a normal tree. I assume you could do it in a parser by checking fi a child of a this node exists in depths above it, but that would/could get quite expensive and screwing with bloom filters for basic operations. Graphs are the different perspecive to a tree only because of the indication of whats a parent whats a child.