Transclusion/clone (display item in multiple places)

🌟Features
#41

Now a few technicalities.

a) As said above I think allowing loops makes it so much more powerful. And since there is only one instance of the node, the server should have not much problems. I see the bottleneck in the browser. Even my example from above does not load in chrome at all and firefox has problems. But with enough collapsed nodes, this is no problem. If people want to expand many levels or see how far their browser can go, this is their own problem!

b) With a) we also allow clone chaining. Basically allowing the node graph to become a full network instead of a tree (currently).

c) Deleting occurrences:
We need two mechanisms: 1) delete the link, delete only one occurrence while keeping the others and 2) deleting all occurrences (clones).

d) Display. All occurrences (clones) should look the same.

e) It is very important to be able to quickly navigate to the parents of a node.

To sum it up: we are trying to add features of a concept map (like theBrain) into Dynalist which is an outliner.

I think it’s worth it. There are a ton of concept mapping tools and mindmap tools but none of them are as elegant and easy to use as Dynalist.

#42

Agree, “Mirroring Node” or “Reference Node” is better than “Clone Node”, semantically.

#43

Clone is the code name for now, just so we have a common name to refer to this feature.

In my opinion something like “reference node” is a bit technical though, ideally we want something that everyone can understand immediately. (Does such a name even exist?)

#44

How about “node syncing”, “synced node”. Item menu: “Create a synced copy”.

If we want to keep it less technical, then my next idea is bad: “quantum entangled nodes”: Change one, change them all!

Next bad idea: “dynamic copy” or “Dynacopy”. :sweat_smile:

1 Like
#45

Out of curiosity, rhetorical questions

  1. How would one store or export the data in ascii? With a strict tree right now it’s n-dimensional array, or n levels deep hierarchical list. The parental lineage is inferred by the structure. Once you go non-tree, would you have to store every item with a list of all it’s parent IDs? Would an item have to check every single item to find it’s children? I don’t know how databases work but is it a 1x to 2x difference or O(n) to O(n^2) difference or what? The snappy responsiveness of Dynalist is probably it’s #1 feature in my book and if everything takes 2 CPU cycles instead of 1 it might feel icky who knows.

  2. Since you no longer guarantee an item has one and only one parent, does the list go into infinite loops of infinite expansion just like http://orteil.dashnet.org/nested ? If you hit the expand all hotkey does it stop before it runs out of RAM?

Admittedly I don’t know that much about such things – maybe someone knows all the benefits and pitfalls and terminology of non-tree structuring of data. I’m just curious about it all.

also the theme song for this thread https://www.youtube.com/watch?v=eYlJH81dSiw

#46

One way to do this is just allow (+) on any linked node. (maybe restrict to within the document?). Then you don’t have a separate Clone operation and you don’t have new operations and no new data storage method.

Then I just type

  • [[Other Node]]

and I can expand in-place or click to jump to the target.

2 Likes
#47

I have read this thread with some skepticism because I don’t see how this is an improvement over the [[internal links]] and create massive duplication of data.

But @Alan has great idea and one I would find useful. Just expand the internal link in place if needed. No big changes in the data structure and no data duplication.

#48

Of all the points, I think this is the main point:

A directed graph is especially useful for a knowledge 
Preformatted text`base. The larger the existing knowledge, 
the harder it is to find one single place for a new node

This is the challenge I see. As the number of documents and nodes increase in a knowledgebase, you really begin to wish you could clone content (link, translinkity, dynaloopity or whatever you want to call it). I am working on a reference database that has a lot of shared and overlapping information, and yes I just simply have to do a lot of duplication (leading to duplicity) and linking.

Cloning and recurring nodes will really change Dynalist to an outliner on a new level (and if it only had multiple columns like OmniOutliner – ok don’t push it).

By the way, I agree with @erica cloning is a simple term and self descriptive to most users.

Chris

2 Likes
#49

I completely agree with this and everything you said!

1 Like
#50

If you do implement Clone, it would probably be a good idea to have a visual that the item exists in multiple locations.

[3] + • This item is found in more than one place.

And then make the [3] clickable to go to any of the other parents.

5 Likes
#51

Alan makes a good point. a good visual indicator will be very helpful.

1 Like
#52

If you Check done a cloned item, should that only apply to the current spot, or should it apply to the original?

#53

Following the spirit of transclusion, all states should be synced along all “clones” because it is just one node. So checking should apply to the “original” and all “clones”.

On the other hand you may have a project that appears in different contexts and when it is finished in one context, you may want to check it off and work on the other contexts where it is not checked off yet. But I think there are enough possibilities to manage that with real transclusion as above.

#54

This is a good idea that takes care of half of the feature. We still want to have classical hyperlinks to dynalist nodes, but it should work with your rule: nodes that have nothing but an internal link would look like “clones”: I can expand them and edit them and all other clones are “updated”.

If it behaves like transclusion, I’m happy.

But it does not take care of the other half: linking back to parents. This is where I like your other idea. To indicate that a node has more “clones” together with a button to navigate to the other parents.

I think there should also be a way to quickly navigate to the parents when you are zoomed in to the node.

You are right: internal links are already very powerful and I would not want to miss them.
But they don’t allow you to put a node in several contexts (branches of the tree). You can make a link but to view the node you have to use the link and change the context. But if you had cloned it, you could simply expand it and use it as any other node.

I do have lots of linking in my documents but often I encounter a link and wonder what’s behind it. Usually I would expand the node, have a glance and quickly collapse it when I don’t need it. But with the link I have to follow it, view the node, navigate back to the previous context and scroll to the place where I left.

#55

I would like to suggest using the middle mouse button to open the link. In Google Chrome, it allows you to open a new link tab, instead of “following” it, it’s not as fast as the cloning function you expect, but it will not lose its place where you left off.

#56

Tech note:

  • x
    • y
    • (clone of x)
      • y
      • (clone of x)
        • y
        • (clone of x)

Clearly, expanding a clone needs to be handled at each appearance, because otherwise you expand (clone of x) once and you have an infinite sized view.

Unless you disallow recursive references.

1 Like
#57

Hey. New to Dynalist, but I can already see a feature like this would be very helpful (that is, an ability to “duplicate”, as opposed to “copy”, an item, so that if I check off the item or the duplicate, it becomes checked off in all locations where it exists). I imaging using it as follows. I create headers with children items, of course. But above all these, I have a header called “My Day” or something like that, where I would duplicate or clone all the items I want to do on that particular day. I can check them off right from the My Day list, and they will be checked off in whatever list they actually came from too. This would be great.

My opinions on your questions: 1) Yes, the clones get deleted if you delete the originals. This is logical since otherwise they would be mere copies. Here, a clone and its original would be the same item, just in multiple locations, and would “sync” if you want to think of it in those terms. 2) Yes, I suppose. 3) Single result, since the link would have to be to a particular clone location, not to the the clones of a single item considered as a group.

1 Like
#58

Mirroring. That’s a clearer way of thinking about it.

1 Like
#59

This would exactly be my main use case for this too, or more generally, tasks in multiple places (tagging allows this of course but requires one’s ‘day’ to be a search, which is quite clunky to work with)

#60

@Stephen_Dewitt 's use case is just like mine. I have tasks in lists related to their project, but I also have a “Today” list which is my dashboard for the day. I would love to be able to clone/mirror/symlink the tasks for today into my “Today” list, and when I check them off there, they get checked off in the other list too.

Like Stephen, I realize I could mark all the tasks with #today and use a view – and I have done that in the past. But it’s not as easy to work with: I can neither sort the items in the order I would like to work on them, nor can I easily add new tasks as they pop up.

EDIT: It occurs to me that the current “move” interface would be great for adding new parents too. You select the node you want, press the keyboard shortcut, and a UI pops up asking for the new parent of the node.

6 Likes