This is basically the only feature Iâm looking for in a notetaking / task management tool.
I take notes in meetings and brainstorming, and in-line write down things to followup with people on using @ and priority levels using #. I need to be able to aggregate all the items for @Dave or all the #urgent tasks into a single view that I can check off when theyâre completed without following them back to the original note every time.
I recommend against deleting all clones when one is deleted.
I think it would be better if the delete action works the same way for every node, clone or not: remove the selected node from its parent without affecting the rest of the tree. If the deleted node happens to have clones, the clones would remain where they are and would not be affected (but they remain clones of each other). If the user really wishes to delete every clone of a specific node, then in my opinion that should be a separate command. This preserves the current functionality of the delete command and prevents surprises for the user.
What Iâve described above is the way many similar apps treat clones, e.g. Freemind, Leo, NoteLynx, and others. They treat cloned nodes much like symbolic links in file systems, or pointers in a programming language.
Hereâs an example use case where deleting clones would be counterintuitive:
For story writing, itâs useful to have a master list containing oneâs major characters, each containing details about their description, storylines, and so forth. For each scene, itâs helpful to list each character that appears in that scene. It would be great if those were clones of the main list of characters so that one can have all those details at hand while writing the scene.
Now letâs say I decide that I donât want John in Scene One after all. The most natural action is to delete John from the âScene Oneâ node, expecting that the references to John in âMajor Charactersâ and âScene Twoâ would stay safely right where they are. It would be surprising and frustrating if the tool also removed John from Major Characters and Scene Two!
I hope this is helpful. Thanks for taking the time to listen to your users.
Thanks for the input, Mark! Is it possible to create a bookmarked search for e.g. â@Daveâ and then use that later?
Thanks Craig, very helpful!
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?
P.S. Internal links would work pretty well for this case in my opinion.
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.
Thanks for the explanation!
I think this fits your description more than the clone feature though: Trello
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.
Yes, thatâs exactly what I was thinking.
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:
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.
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:
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. 
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)?)
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.
Yeah, I agree in the backup it should just copy the text form. Maybe with a special marker that this is a cloned item.
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.
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âŚ
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:
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:
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:
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.
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.
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.
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:
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. 
I think clone is an unfitting name. Transclusion seems to be the right technical term. Other suggestions:
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.
Let me give you some examples. I set up a shared dynalist document:
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:
>.
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.