Transclusion/clone (display item in multiple places)

[Mark_Thomas]

I do bookmark that; the problem is the things I want to talk to Dave about (to run with that example) are across ~10 different documents (different meeting notes, to-do lists categorized by different projects).

When I meet with Dave, I want to be able to pull up the @Dave bookmark and edit the items there - add a note answering a question, mark an item as completed, etc. It’s a big pain point to have to click on the item, add a note in the document itself, and then go back to the bookmark for each item that I’m chatting with Dave about.

[Erica]

When I meet with Dave, I want to be able to pull up the @Dave bookmark and edit the items there - add a note answering a question, mark an item as completed, etc. It’s a big pain point to have to click on the item, add a note in the document itself, and then go back to the bookmark for each item that I’m chatting with Dave about.

Thanks for the explanation!

I think this fits your description more than the clone feature though: https://trello.com/c/qxDj1eHs/132-make-results-in-search-everywhere-editable

[George]

I wonder if what would work for many (but never all I am sure) people is for links to other Dynalist items to be expandable and editable in place. Deleting the item outright would then just delete the link. This would be great when compiling a list of topics for say a meeting which are links to items scattered around other lists, and would permit expanding/collapsing the items easily whilst discussing them.

[Erica]

I wonder if what would work for many (but never all I am sure) people is for links to other Dynalist items to be expandable and editable in place. Deleting the item outright would then just delete the link. This would be great when compiling a list of topics for say a meeting which are links to items scattered around other lists, and would permit expanding/collapsing the items easily whilst discussing them.

One possibility I see is to allow “expanding” the details for internal links.

[George]

Yes, that’s exactly what I was thinking.

[Craig_Oliver]

I guess in your storywriting case, there’s still the concept of the “original” copy. If the original copy under “Major characters” were deleted, should the clones be deleted too?

Thanks for your note. I can see why it looks there’s an “original” vs. “cloned” distinction in the story characters example, because there’s a sort-of “official” list of major characters and then the “other” lists in the scenes. However, my thought is that there would be no “original” node vs. “cloned” nodes from the user’s point of view, but rather they are all simply references to the same node.

To illustrate nodes that don’t have an original vs. cloned relationship, imagine the following shopping list:

• Auto Store
  • Oil
  • Batteries
  • Wipers
• Grocery Store
  • Milk
  • Bread
  • Batteries
• Home Store
  • Batteries
  • Hammer
  • Nails

Let’s say I’m planning to run errands. I thought of buying batteries while writing up the auto store list, and added them there. Later I decided to make “clones” of the battery item in the Grocery and Home store lists, since I might find batteries at any of those places.

If I find batteries at any of the stores, and check off any one of the Batteries nodes, I would expect that all three Batteries nodes would become checked off, since they’re clones. Or if I realized I needed AA Batteries I could change the name of one of them and they would all change. That’s the power of cloning.

However, let’s say I get to the Auto store and they don’t have any batteries. I would naturally want to delete the Batteries item from the Auto store list since they aren’t there. My expectation would be that Batteries would be removed from the Auto store but they would remain on the Grocery and Home store lists.

Essentially, I don’t think the user should have to try to remember which list they added Batteries to first, fearing that if they delete the “original” it will disappear everywhere but if they delete a “clone” it only disappears in that spot. In my opinion the best user experience is if deletion works exactly the same way on every node, irrespective of whether it’s a regular node, a clone of some other node, or the “original” node from which clones were made.

P.S. Internal links would work pretty well for this case in my opinion.

Agreed, links are great! I do sometimes use links in this way.

The reason I wish I had clones in addition to links is that the two serve somewhat different purposes:

Links are separate nodes from the one they link to, so I can check them off independently, use whatever link text I want, make changes to the links without affecting the target node, and generally use them as “jump-off points” to other areas in the outline. This is great when I want to refer to another node in-line, or provide a table of contents to other nodes, or otherwise refer to information elsewhere in the outline.

Clones are essentially the same node in different places, so if I check off one, they all get checked off; if I change the node text in one, they all change; if I change its children, the children of the clones also change. This is great when I want to keep details of a node handy while working in a different context, or work on two nodes next to each other that would otherwise be far apart in the outline, or otherwise embed information from elsewhere in the outline and work with it locally.

The difference is most noticeable when the nodes are far apart in the outline. To illustrate this difference, let’s go back to the storyline example for a moment:

• Major Characters
  • John
  • Mary
  • Pat
• …imagine lots of other nodes here…
• Scenes
  • …lots of other scenes…
  • Scene 22
    • Characters
      • Mary
      • John
    • Plot…

Let’s say I’m zoomed into the Scene 22 node so that I can focus on just that scene. I’m working along, in the zone, and then I realize that I can’t remember the name of John’s sister, one of the child nodes of John under Major Characters.

If John is a link to the node under Major Characters, then I must: click on the link; jump out of Scene 22; expand John’s node; look up his sister’s name; click Back to return to Scene 22; find the node I was working on; and then get back to work – hopefully still remembering the name. It requires a context switch, a bunch of clicking, and enough friction that it makes me reluctant to click on the link unless I really need to.

On the other hand, if John is a clone of the node in Major Characters, then I simply: expand his node right here in this scene to show his family, and get back to work. No context switch, no friction. Even better, John’s family info stays on the screen visible to me, in my current zoomed-in context, as I work. Best of all, if I learn something new about John I can edit his info right here in this context, knowing that the clone up in Major Characters will get updated too.

I hope this makes sense, and isn’t too long-winded. I really appreciate your dedication to understanding our suggestions, no matter how complicated they get.

[Viktor_Papara]

What @Craig_Oliver describes is exactly the behavior that I strongly support.

It boils down to having the same node in different places where
a) I can expand the item instead of having to follow a link, and
b) being able to edit every occurrence (obviously).

About a): the collapse/expansion of bullets is maybe the strongest feature of Dynalist that helps me keeping my notes in a neat and clear organisation. This is why I strongly prefer expanding a bullet (clone) instead of following its link and having to adjust to a new “context”. (Especially if I want to copy text.)

I prefer treating all clones equally without any “original” node. This feels more elegant and you don’t have to worry about deleting all clones by deleting the “original”. Still, it would be useful to have the option to delete all occurrences (clones) of the bullet. (Although, you could do it manually with a text search; see next paragraph.)

It would be nice to get a list of all places where the bullet is cloned to, but a simple text search already makes that possible (if the search would treat each clone individually).

One other detail: the “Make Backup” function. I do feel more relaxed, knowing I have a text backup of my stuff. So the question is how does a clone look like in “text form”. In the spirit of treating all occurrences equally, I suggest plainly copying them (with content).
But I have no idea what to do with infinite loops from clones within a clone. (Maybe limit the recursion depth while exporting (making backup)?)

[Erica]

But I have no idea what to do with infinite loops from clones within a clone. (Maybe limit the recursion depth while exporting (making backup)?)

No clone inside clone should suffice.

That is, you can’t insert a clone inside a cloned item. And you can’t clone an item that only contains a clone. Hmm, I think we’ll still miss a few cases on the first try which will freeze Dynalist with an infinite loop… thanks for bringing up this.

One other detail: the “Make Backup” function. I do feel more relaxed, knowing I have a text backup of my stuff. So the question is how does a clone look like in “text form”

Yeah, I agree in the backup it should just copy the text form. Maybe with a special marker that this is a cloned item.

[Craig_Oliver]

But I have no idea what to do with infinite loops from clones within a clone. (Maybe limit the recursion depth while exporting (making backup)?)

No clone inside clone should suffice.

I think we only need one rule to prevent loops:

Do not allow the user to clone a node into itself or any of its children.

I think that should ensure the outline is always a directed acyclic graph and will never have a loop.

[Erica]

Do not allow the user to clone a node into itself or any of its children.

I think that should ensure the outline is always a directed acyclic graph and will never have a loop.

What if you clone some unrelated node B under A, and later clone A under B? That doesn’t seem to break the rule but it sounds like it’d cause an infinite loop.

P.S. Totally didn’t expect a graph theory discussion in the community forum…

[Craig_Oliver]

What if you clone some unrelated node B under A, and later clone A under B? That doesn’t seem to break the rule but it sounds like it’d cause an infinite loop.

Yeah, that’s a great point! I think you’re right – we need to word the rule a little more carefully:

Do not allow the user to clone a node into itself or any of its own descendants.

In your example we have nodes A and B:

• A
• B

Then we try to clone B under A. This is fine, because A is not one of B’s descendants. Now the outline looks like this:

• A
  • B
• B

Then we try to clone A under B. This should fail, because B is already one of A’s descendants.

This rule also prevents us from cloning A under A.

This also covers another, less obvious scenario:

• A
  • B
    • C
• C

If we try to clone A into C, it should fail, because C is already one of A’s descendants.

So essentially I think we’re saying that any time we try to paste a node as a clone, we need to check the child node’s entire subtree to make sure there are no references to the parent node. If we find no references, it’s safe to paste.

Thanks for taking the time to think through this with us.

[Erica]

Do not allow the user to clone a node into itself or any of its own descendants.

Yeah, that’s the idea. In reality we might check it differently, as checking it this way might be expensive (it can have tens of thousands of descendants). But in effect, yes, what you said.

[Asher_S]

From a UX perspective, would it be easier to present it as search results inside of a list instead of multiple views of the same instance?

Right now we have the ability to search and display content at the application level; it’s a common usage pattern that most users will be familiar with. By using that same language for displaying clones/filtered lists and views inside other lists, it might help users understand the difference between copying an item into a new list and displaying an item from a different list.

Familiar framing would also help users navigate the system with markdown/the UI. They’d have a query to search for (a tag, a string, etc), sources to filter in/out (documents) and display limits (number of results, depth, etc) to work with. All of that can be handled in a relatively concise markdown-like string, and the UI approach could easily emphasize that they’re creating a view of things from elsewhere instead of copying content into another document.

Pair that with some color blocking for visual delineation and a “view in original context” button of some kind, and the system would be reasonably accessible. The issues with visible depth and understanding object deletion would be handled and additional features (copy view to current document, etc) could be displayed through the context menu.

On the recursion front, terminating the loop with an item that looks like an internal link with a context-relevant icon (looping arrows in crossed circle, etc) and microcopy would be a forgiving answer. It wouldn’t kill the entire query, but it’d prevent it from displaying a loop and it’d give the user feedback on why what they’re trying to display is problematic.

In any case, I think it’s a great idea. Views inside lists are great tools, as they allow users to monitor and aggregate information dynamically without diverging from the keyboard-driven core usage cycle. Basing it on search features would allow multiple implementations of the same idea (tags vs strings, granular search scoping, granular display context) while leveraging familiar language and clear visual indicators.

[Ron]

I voted for this feature on Trello.

Recently I discovered this feature while researching an outlining code editor called Leo. http://leoeditor.com/

Leo’s actually difficult for me to use, so I don’t actually recommend anyone here try it, haha. Dynalist in comparison is awesome!

However, one idea that Leo had is the ability to clone a node of an outline. That means that that node can appear in 2 or more places in your documents.

The file system analog is the hard link on UNIX/Linux/MacOS.

Item clones would allow me to do this:

• Separate my TODO items by project. Now each TODO item has 1 instance.
• Create a new document (a “view”) that organizes my work by Week. I can look over my various projects and pick and choose which items to clone into my Week view. These are the items I wish to accomplish this week.
• Create a new document (“view”) that organizes my work by Day. Every morning, I look in my Week document and choose ~5 items that I want to clone into the Day view. Now each of these TODO items has 3 instances (in Day, Week, Project A/B/C/D).

It’s just like a file system hard link.

If I modify one instance in any way, it reflects on all instances. So if I edit the text, or add a note, I can see the changes in Day, Week, or Project A.

If I complete / check the item, it will be checked in all three views.

If I delete the item from Day, it will remain in Week and Project A. It’s just like a file system hard link. Only when the last instance is deleted will it be truly deleted.

For convenience, we might want to add a right click menu that says “Delete all clones (3).” Selecting that option will delete all 3 instances of the item, and all its children.

Having this feature would help me a ton! (BTW, if you need any help designing or implementing, I’m happy to help out in any way possible. I have a decent amount of coding and UX experience and am 100% behind this feature request.)

Thanks for considering.

[Viktor_Papara]

I think clone is an unfitting name. Transclusion seems to be the right technical term. Other suggestions:

• citation, cite

• mounting (as in linux drive mounting in file tree)
• (hard)link
• mirroring, mirror image
• wormhole
• reference (as in computer languages: pass by reference)
• pointer

The name is not important. What is important: we talk about multiple parents for a node. This would effectively change the graph structure of Dynalist from a tree to a directed graph (aka a concept map).

This is exactly the difference between mind-mapping (tree) and concept mapping (directed graph aka “network”).

In my opinion, Dynalist would greatly benefit from such a feature.

A directed graph is especially useful for a knowledge base. The larger the existing knowledge, the harder it is to find one single place for a new node. And with multiple parents we can put the node under all places it can fit. You could use hyperlinks but transclusion is more elegant and streamlined.

With transclusion we could use dynalist as a full concept map. TheBrain was mentioned here and I agree that they do it perfectly. If I had a magic wish, I would incorporate the relations from theBrain into Dynalist.

[Viktor_Papara]

Let me give you some examples. I set up a shared dynalist document:
https://dynalist.io/d/_D0uU00va_PT0nY5JVzcVkXX
where I just copy-pasted the “clones”. (You have to use “collapse all” from the node menu, since the document is fully expanded by default.)

(This is actually a qualitative example of my own dynalist.)
You see that the notes of books are under “books” but they also should appear under the respective author. An even stronger argument is for notes from reading a book and which need to be incorporated into “Knowledge”. Both places are perfect for those notes.

This example in TheBrain would look something like this:

TheBrain does display children nodes under the “zoomed in” central node. This is similar to current Dynalist. But not less important is that the parent nodes are also visible! They are very important to navigate this network graph.

My suggestion is to display a list of all parents of a node under the breadcrumbs like this:

Of course with other separators as >.

That said, I change my mind about loops. If possible, we should definitely allow clones inside clones and even clones of themselves! That would make formally “infinite” documents but I suggest that all second occurences of clones inside clones will be displayed fully collapsed and would need to be expanded by hand.

[Viktor_Papara]

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.

[pimgeek]

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

[Erica]

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?)

[Viktor_Papara]

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”.