Scrivener already does a lot of this! It’s worth noting that it does things differently than a tool that has no actual formatting in the editor, and is doing everything dynamically based upon the construction of markup syntax around text. Delete a bracket accidentally and your hyperlink vanishes, as does the back-link. Not a fatal problem of course, but it could be disruptive if you fail to notice. While I suppose some of the concepts you are referring to are not mutually exclusive with a formatting-based writing environment, there are some things about it that make it different enough to expect a different sort of toolset.
For example, you absolutely can type in “[[something]]” and get a section called “something” created elsewhere, and with that “something” item linking back to the item that referred to it. What’s different is that the brackets are stripped out and the word “something” is hyperlinked persistently, in a way where you could go on to change the text of it, without the link pointing to something else, or having to go in and add additional syntax (often much more cluttered) so that doesn’t happen. I would argue that for a writing tool, having link text that is naturally unbound to the target is a more natural and seamless approach.
The other main difference is that Scrivener’s back-linking system is much more permanent—perhaps even to a fault, some might say, in that historically referring to something is a recorded event that stays recorded even if the link is removed, until you delete the back-link directly. But this philosophy of providing automatically generated back-links as a permanent and mutable structure is something not often found in other tools. This provides the following characteristics:
- The back-link list is fully editable. You can organise them in the list in a way that suits their purpose. I’ll push topical connectivity to the top of the list, and workflow related links (such as editing notes) to the bottom, for example.
- Unlike a typical dynamic back-link list, the list itself can be added to freely, and in doing so, this of course generates back-links to the targets. Scrivener thus has an area within each section of the outline where general connectivity can be established, rather than textual.
- Bookmarks are “objects” in the sense that they have more to them than being simply a list of links. They can be individually selected as objects, and things can then be done with them. I can for example select all of the back-links for something, drop them into a Collection, and then compile that collection as a focussed list of pertinent information about a thing. It would take quite a lot of clicking around and temporarily tagging—maybe you can’t even do it at all, in some tools. In this same way, bookmarks operate as saved selections. They respond to the Reveal in Binder command, which once invoked means you can now do stuff with that selection—such as run a search constrained to them, or tag (keywords) them all with a single action. As proxies for the item itself, they have a plethora of functional drag-and-drop interaction worth exploring.
- Noted briefly, above, but you can delete them. Not every back-link is meaningful, and in fact that’s one of the things I find myself working against in tools like Logseq, where the reference lists build up chaff that require manual adjustment to fine tune, or filtering to get around.
- While it has less to do with the list’s characteristics themselves, I feel it is worth mentioning: I have yet to see any tool that combines a back-link list with a sidebar editor. The power of that cannot be underestimated in that quite often you don’t even have to activate a back-link in order to view or edit what it refers to.
I don’t mean to suggest Scrivener’s approach is superior in every way. Far from it! There is much we could learn from Logseq and similar, though I also agree with you that a lot of it would be overkill. We have to remember that a back-link in Logseq is equivalent to the concept of compiling in Scrivener. It’s a core, fundamental component of its whole design. We would expect there to be a lot of embellishment around its usage of the back-link, because without that it would be like removing the compiler’s breadth in Scrivener. But there are still some good ideas, like contextual awareness around the link’s point of origination, and maybe even a better active detection (though I would hate to see the mutable idea go away, and these two concepts compete rather strongly with one another).
Here is a list of additional topics on the forum that might help:
-
Using Scrivener like a wiki: not all directly applicable to what you’re speaking of, but it does touch upon some of where Scrivener addresses areas not easily accomplished in other tools. Also note that further on up that thread is another post with a list of links that might be useful to you.
Also note post #4 in that thread, which describes where to turn on bracket linking, if that’s not something you have encountered before.
-
Building a ticketing system for tracking edits: the use case is entirely different from what you are talking about, but the mechanics of what are being done to achieve this are heavily based upon the sorts of things you’re looking to do.
-
Linking to specific text: while you didn’t bring it up specifically, one of the things that makes Logseq so great at what it does is that every outline item is a link target. Scrivener of course works that way as well, but as a tool more oriented toward writing long works rather than gathering notes, thoughts and things to do, it does bias more toward longer notes per outline item. So having a good way of jumping between “blocks” can be essential if you are accustomed to such a fine-grained approach. Scrivener’s concept of a block is more akin to Obsidian’s in that it doesn’t really exist as a formal feature, but rather a capability built into other features that work with a textual marking on the line itself that is to be considered a block. This post goes into what those features are, and how to make them efficient.