Idea: Zoom levels/embedding

[jimmcnulty41]

Problem

If we are exploring the world of Reggae, we might start with something like this:

If we want to look at the instrumentation of a specific subgenre, I have to either start a new session, or pollute my graph with instrument information.

Different guy:

Pollution:

[jimmcnulty41]

Potential Ideas:

We could allow a node to be connected to another tree.
We could then "zoom in" on the node to open up that other tree.
We could then also "zoom out" to return to the node we started with.
The node could be connected to multiple trees. In these cases, our "zoom" would be parameterized by a "context" or "type" of "zoom"
Circular graphs could be allowed.

[alexburner]

This is interesting, so each node could contain a fractal "session"? Universes within universes?

It sounds powerful. How does the UX work? How would you open the Dub Music instrumentation articles in a new nested universe, instead of the current one?

[jimmcnulty41]

This is interesting, so each node could contain a fractal "session"? Universes within universes?

Yes! woot!

It sounds powerful. How does the UX work? How would you open the Dub Music instrumentation articles in a new nested universe, instead of the current one?

Definitions

Here, I will use tree to refer to what is currently referred to as a "session" in wikitree.
I will use session in the traditional sense -- as in a contiguous period of time connected with a user's use of the software
I will use trigger to refer to a discrete action taken on a node, such as a double click, right click, modified click like shift-click, ctrl+shift+click, keyboard shortcut, etc.
I will use jump to refer to the transition from one tree to another

Initially imagined workflow

• Trigger a jump to a new tree via an existing node in your tree
• If the node is not already connected to a tree, create a new one, named after the triggered node and pre-populated with said node
• Open the tree connected to the triggered node
• Any links followed from this point will be added to the new tree as opposed to the original one
• The jump could be recorded via breadcrumbs linked to a user's session

So in this case, you might double click on "Dub Music". This would create a new tree, named "Dub Music", which has the single node "Dub Music". Then you would click around through different instruments, adding them to the "Dub Music" tree.

Juice Opportunities

Instead of triggering a jump via a discrete action, like a click or keyboard shortcut, we could literally zoom into a node

Then, instead of (or in addition to) zooming out of the current tree back to the original tree via breadcrumbs, the user could just zoom out to the point where the nodes become to small to see, at which point we would jump to the 'parent' *tree

Link-based zooms

Alternatively (or possibly, in addition) we could provide a way to execute a jump from a link within a wikipedia page. I haven't thought through this one as much, but it seems like this could cause some issues.

For example, if we were reading the "Dub Music" article, while our initial tree is open, and we did a link-based jump into one of the "typical instruments" articles, do we have the Dub Music node in the new tree? In the initial tree, do we link the new tree to the Dub Music node or do we add a new node to represent the instrument?

Opportunities for confusion seems high, but there may be something down this route.

Creating a new tree from existing nodes

The above workflow assumes that you have the foresight to create a new tree before getting distracted. Often, this is not the case.

We may want to explicitly address the issue of creating a new tree from a subset of nodes in your original tree

Take, for example, the tree labelled "Pollution" in the original comment of this thread. It could be nice to select the instrument nodes (shift+clicking, lasso-selection, or something else could work well), and then drag them into the node that should have the link to the new tree