The above post lead to me searching for âroam vs dynalistâ, which brought me here. I think the most appealing feature Roam has is that you can freely create pages without thinking about where they belong in the hierarchy. It would be great if Dynalist could support something like this where pages can live in a mesh outside of the normal hierarchy. There could also be some kind of graph view that displays this mesh, but thatâs could come later (or never).
I want to pile onto the observations that others have about the value of the bidirectional links feature. To me, this is all about the creation / encouragement of serendipitous links between bits of knowledge. This is my #1 value-add in my job, and I would love to have a tool that would help me amplify this.
I would seriously consider switching to gain this feature - to me, itâs way more useful to me than most (all?) of the recent features that have been added to Dynalist put together. This would be a hard feature to add into Dynalist without seriously disrupting what makes Dynalist unique and powerful in its space. Hello, innovatorâs dilemma
What do others think? How valuable are bi-directional links to you?
I agree it would be a boon to Dynalist. I used it a lot with NoteStudio before that app was closed down. It would make Dynalist a perfect research tool.
I struggle to understand whatâs going on in that video. I think itâs a very poor example because the effect of clicking on that link is the same as clicking on the bullet in DynaList.
I think the notion is that [[Thing]] is more like in DynaList #Tag, and clicking on [[Thing]] is just the same as clicking on the tag in DynaList. But the interaction is different. Clicking on a link in Roam switches you to the other link. Clicking on a tag when you already have a tag selected in DynaList adds the tag to the filter. You would need to edit and remove the previous tag to get the same effect of navigating. One other detail: Because itâs bracketed, Roam lets you have full text inside the brackets, but tags are not allowed spaces.
If itâs something else than this, please explain.
Even if my explanation is indeed different, it might still be a great way DynaList could do similar, without âseriously disruptingâ the nature of DynaList.
Whilst weâre on the topic of bi-directional linking, hereâs the Dynalist feature request thread.
Please go there and add your votes!
Yes, we definitely see the innovatorâs dilemma here.
Dynalist had [[
links before Roam Research started (we introduced it in April 2016), and we had always wanted to go deeper in that direction. But like you pointed out, if we want to introduce it now, it has to be non-disruptive to current Dynalist users. Weâre well aware not all Dynalist users need it.
Right now our consideration is to make the bottom âreferencesâ area only show when you turn on an option, plus providing a convenience utility to find out how many places linked to this node.
Still, this only applies to links to full nodes, not [[text segment]]
. But since [[text segment]]
doesnât do anything at all right now, we can hook it up to global search, which will search for all occurrences of exactly [[text segment]]
(linked occurrences) and in another section results for text segment
(unlinked occurrences).
I think the notion is that [[Thing]] is more like in DynaList #Tag, and clicking on [[Thing]] is just the same as clicking on the tag in DynaList.
What happens when you write a [[pagename]] or #pagename in Roam is that it creates a new page. It doesnât have tags in the ordinary sense. Every act of tagging creates a full page you can write to, and all pages gather intentional [[pagename]] links to themselves and mentions of pagename themselves throughout the userâs Roam database.
The pages themselves are shown to the user as a hierarchically flat, and structure comes from the connections between pages. Writing links to index pages is basically the systemâs filing action since the indexes will end up creating a typical tree-like structure:
Dynalist isnât inherently like that, but linking notes was a key part of why eg. Niklas Luhmannâs Zettelkasten - a hierarchical tree-like structure a lot like what Dynalist can do, and consisting of something like 90 000 individual notes - worked and wasnât a yawning abyss of notes organized nicely but that youâll never see again because Luhmann had a separate, file cabinet organized reference box, and a separate box for his ideas, and his paperslips linked to each other. My notes are certainly underlinked at the moment.
Luhmannâs actual paperslip collection, scanned:
https://niklas-luhmann-archiv.de/bestand/zettelkasten/inhaltsuebersicht#ZK_1_editor_I_17-1b12
I understand now. Yes that is beyond DynaList capability and different from the tag system. Yet similar could be done by DynaList enhancements without going to the length of generating an actual page for each link. Fact is, DynaList has zillions of editable pages, accessible by tapping on any bullet, and dynamic pages generated by tapping any tag. Put those together with some creativity on both the side of development and of user, and we can have cake too.
Itâs not there yet. And as DynaList documents grow it becomes more necessary as things get lost in vastness.
I love this idea! It would be great to see links to the current node.
One âeasyâ step forward to make [[square bracket]] use a bit more comfortable already is to, once a link has been selected, move the focus to the end of the inserted link.
Currently if you type [[ & select your link, your cursor is stuck in the highlighting of that text. You have to manually go to the end of the inserted link; this gets you out of the flow of writing.
I had hidden backlinks in powerpack (it can be enabled if PP still works and someone wants to play with code that I published in PP thread) more than year ago when I tried to use one of my docs in Dynalist for zettelkasten Itâs cool to have backlinks, but itâs far from Roamish experience. At least these features would be needed â automatically created daily notes + backlinks + easy way to create zillion of docs + global search that works like doc search + sidebar that allows to open multiple different docs and drag&drop nodes between everything + embeddable docs. And possibly more. That gives true flexibility and allows for total ZK experience. Dynalist has superior datetime features + calendar integration; and generally I think itâs doable to recreate Roam in Dynalist, even as browser extension - one can use doc as database as I did in Powerpack, so itâs possible to do crazy stuff, but I doubt it will happen as it is a ton of work.
#roamcult
For many itâs an edge case, yes.
The creation of new pages when using empty square brackets is a problem as the link would change once the entry is moved to another document; simply using the inbox wouldnât help.
It took me using Roam to realize again that [[page creation]] is something Iâve really enjoyed when using wikiâs; in my case especially Zim Wiki
I donât know if trying to duplicate Roam with this kind of data structure is a good idea in the first place - but backlinking is insanely useful for ordinary filing systems as well, as Zettelkasten proves.
Iâve been trying out Roam myself with mixed feelings. Lot of power there but some issues as well.
This discussion is interesting but seems to bouncing between a few different Roam features that might be valuable in Dynalist (all of which I agree with). For me the priority of these is worth mentioning -
- Backlinks - automatic backlinks (possibly as a pro option ?) is by far the most powerful. This one gives me 50% of the value I see in Roam. Yes it would be very nice if those links updated automatically but not absolutely crucial to get the value.
- Automatic reference aggregation - visible when you focus on that particular item. Also powerful and gives me another 20% of the value.
- Automatic page creation based on links - nice but is mostly a matter of smoother workflow. I would like to have it but the impact on my knowledge management is not nearly as powerful as the two above.
This all can be approximated very simply by making Dynalist interpret [[any stuff]] Markdown as a Saved Search. You click the link and DL opens and runs search for all instances of [[any stuff]].
You get a search this way, not editable, but you can of course edit any of the things you find, including expand any of them with children and put details related to [[any stuff]], which details are available on a click.
This provides 2., and half of 1.
Whatâs cool is you get a very clickable UI. Click ((my project)) and see things under the project and references to ((my project)). Then See and click ((@Robert)) and see everything that mentions him. Then you see ((picnic june 1) to find all the details on that and click a node which has advance Setup Plans.
(Aside: Currently [[ hot-runs an immediate find and generates the UID link to the item you chose. The keenest aspect of this feature is to have plain text be used as link, not the UID.)
How is âautomatic reference aggregationâ different from backlinks? Sorry I didnât fully understand. Could you elaborate how they work differently?
We were wondering in an internal discussion earlier, how is this different from tags that allow spaces? Say if Dynalist allows for #any stuff#
, is that better than, worse than, or the same as [[any stuff]]
?
(P.S. We did realize #tag
currently triggers a document search, not a global search. Assume this can be solved somehow.)
Quoting me from earlier:
Then itâs much closer to the global search, which leads to a new page.
Clicking a tag does update the URL as well, but the back/forward navigation doesnât work as well.
Anyone else got opinions on how similar #any stuff#
is to [[any stuff]]
? Our motivation to not use [[ ]]
is that in Dynalist, [[ ]]
links will lead you to a Dynalist item, not a search result. If [[any stuff]]
simply leads to a search result page, it works much more similar to a tag than a [[ ]]
link. For the sake of consistency, we want to maintain the tag syntax is thatâs not too different.
From my perspective, I donât see any advantage of creating a [[ ]]
syntax for this purpose.
- If I want to link to a particular page/item, I can use a regular Markdown link or raw link* to the Dynalist URL of the item.
- If I want to link to a tag search, I can just place the tag itself in the node.
- If I want to link to a general Dynalist search, I can likewise link to the URL of the Dynalist search page.
I admit Iâm probably missing the point of the request â maybe someone could help me understand?
On the other hand, I do see value in a related request for showing backlinks to a node, or more generally showing search results in-line. I would love to see a transclusion syntax** which would display as an interactive node or list of nodes that match the search. This would allow us to create handy lists of references to a particular topic or term, or show all our tasks in one place, or a variety of other applications. I think this would be a very powerful tool in Dynalistâs toolbox.
Craig
* I recently discovered that putting a raw link to a Dynalist item will display the up-to-date title of that item â even if the item title later changes! Super cool.
** Examples of powerful transclusions:
-
{{backlinks:abc123}}
: renders as a list of backlinks to the given node. -
{{is:checklist -is:completed}}
: Renders as a list of all unfinished tasks in this document. -
{{\#tag1 \#tag2}}
: Renders as a list of all nodes with both tags.