This is a new thread to allow this aspect to be separated from the current thread on Roam.
Roadmap offers quite a bit of functionality and in the interest of starting things off in this thread, Iād float the idea that the only aspects of that tool that seem essential in the text pane (at least initially?) are:
- the two columns listing incoming and outgoing links of the note currently in focus;
- the ability to click on a link in either column to shift focus to a new note.
In other words, Iād suggest that a new slide-up view at the bottom of the text pane doesnāt need to replace or duplicate the Roadmap in itās totality.
2 Likes
Agreed, though there are also some new features I would appreciate. For example, the ability to specify a subset of link types to view, and a way to order the list of links by type. Some links are more interesting than others, and Iād want the most interesting to be at the top of the list.
This would also allow an implementation of the āunlinked but relatedā notes that Roam has: You could create a (low-priority) agent that creates a ārelatedā link if a noteās $Text contains the name of a note, and then arrange for the Roadmap to show these beneath the untitled links.
Isnāt that more sensibly a third list?
Frankly Iām not sold on its usefulness, but in any case itās representable with an agent that curates links of a specific type. Granted, the agent is O(n^2) so care should be taken in its implementation.
Just chiming in to say Iād love to have the ability to have roadmap present as a slideup under the current text pane, and also that I agree with @eastgate that a similar notes would be a third list. The features are already in tbx, itās just making it more convenient and accessible by adding a different way to work with it in the standard interface (e.g. if the app is full screen).
I also agree with @galen that it would be great to have the ability in the (embedded or popover) roadmap view to have the ability to filter links by type.
It is a third list, I think. And also, it would make sense for it to be accessible in other views (hyperbolic, map) where presumably the list of links is less useful.
Roamās āunlinked but relatedā presumably leverages the fact it is a cloud app and can run larger search/ML processes against any user account, compared to a local native app that has only the host Macās resources to use and has to play nice with all the other running apps/processes.
And what is ārelatedā? Outside tightly bounded contexts where AI/ML only offers speed against other means of finding things, Iāve been generally unimpressed with such enhancements. What about the things I as a human can understand as relevant but the algorithm is to dumb to spot? Is an unlisted item thus irrelevant?
My point being, for the overhead of doing this assessment in the background we get a guessed list that gives false provenance. Unless the precepts upon which the listing is based we canāt be comfortable the list is what it purports to be. Ergo, is the ROI there or is this another bit of tech āme tooā feature addition?
Much more useful, in linkage/hypertextual terms would be means of knowing things like notes that arenāt linked at all, or not linked to the current in-doc network. Note that though likely, it is entirely possible to have more than one discrete link-based network, especially if based on a particular link type (hyperbolic view doesnāt yet offer a link-type based filter, although edges of a given link type can be highlighted). Iām conscious here of ROI for Eastgate, if weāre not generally using links more than trivially (more for drawn linkage than hypertextually) adding deeper hypertextual features is a risk even if some of us would love to see them.
āUnlinked but unrelatedā in Roam is actually rather pedestrian. If a string occurs in the title or text of another not that is not linked to the the current note, then the noteI(s) containing that string in title or text are āunlinked but relatedā.
Thereās no sophisticated search or AI involved. Just vanilla search perhaps aided by a concordance in the background.
Ah - apologies, Iāve not had the spare time to try Roam and Iād assumed (naughty!) extra cleverness. In context, Iām conscious that neither the Tinderbox Get Infoās āsimilarā or āwordsā source scope is clearly documented. Of course, this sort of detail doesnāt matter until just before some deadline and you suddenly need to know. Plus a recent post asked for $Name inclusion in scope as the results looked wrong as they put key data in $Name only; ambiguity derails assumptions. FWIW, I think both those Tinderbox features only use $Text, but Iāll check and clarify in aTbRef.
Edit: the āsimilarā tab looks at $Text, $Name and textual content in (string-based) user attributes. āwordsā is less clear but should be assumed to based on $Text alone.
Tinderboxās āFindā, which I believe supports regular expressions, is far more clever than āunlinked but relatedā.
1 Like
To confirm, the View pane Find does support regex and targets a user-defineable scope of $Name, $Text and a single user-chosen session-scope user attribute (the 3 attributes can be individually toggled in/out of the find action). See more at the link.
By comparison, find and find & replace in $Text do not support regular expressions.
(Ha. Checking this means Iāve just fixed improved those aTbRref pages and several more!)
I agree with Paul. I have been testing Roam as well for temporary/extraneous notes. The āunlinkedā feature is to me a word search containing the exact words that are brought up as unlinked. It also has a problem with the use of synonyms (although there are some āhackā workarounds.)
I currently think Roams ābest use caseā,is not as a replacement or comparison to Tinderbox but rather as a āfront endā to tinderbox especially on mobile. Roam=āinitial temporary processingā Tinderbox = āfinal processingā or as Luhmann calls them zettels.
As a side comment, Tinderboxās find with regex is far more powerful than the Roamās unlinked for me because of Tinderboxās use of RegEx for pattern search. I also use Tinderboxās āsimilarToā and use attributes extensively which gives Tinderbox some very robust and unrivaled powers for finding the information I need.
Lastly, I typically tear off the find window and do searches independently on notes I want to further explore relationships. I then use quicklinks to link the most relevant notes I find. This gives me the flexibility I want over Roam.
Anyway, no right or wrong way to use both tools, but leveraging both is what I find useful.
2 Likes
BTW, testing further (using v8.5.1b437) Iām confident Get Info/words checks $Text and $Name. I think its pre-v6 predecessor (Common Words) used $Text alone. Unlike in Get Info/similar, textual user attributes are not searched for words.
Iāve updated my notes on the āwordsā tab.
In practice, the engineering works in the opposite direction. Youāve got a ton of processing power locally and itās all yours, just waiting for you to need it. Itās harder for a cloud app to use the resources because they have a limited number of servers that do work for everybody.
In fact, Twig had an āunlinked but relatedā pane that was based on a variety of textual features. (DEVONthink also did this early on.).
The question is: how useful are these suggestions likely to be? Can we make them good enough to deserve the screen space the list will occupy?
one of the ways (in my opinion) that DevonThink 2 did a good job with this UI is by putting the list of related notes (the magic hat list) in a drawer that opens to the right. I like this approach because it doesnāt typically steal space from what Iām looking at right then, and itās easy to close when Iām done with it and preserve the ratios of the rest of the window. It seems DT 3 has moved to the inspector model, where the inspector eats into the main window no matter what. My recollection was that the DT 2 drawer would extend out and leave the main window alone if there was enough screen real estate.
Anyway, I guess my thinking here is:
- I think the suggestions are likely to be useful, but really how can anyone know until implemented? The utility in my mind is that even results that I choose not to link may fire some association off that is interesting. In some usages, I can imagine not being interested in this feature and just wanting to link what I know I want to link. In other usages (those that I think match the more associative and gardening-like Roam work people are doing) I think a few keyword hits could lead down interesting paths.
- The screen space thing, for me, is all about showing/hiding. If I can call it up in a location I can anticipate, and which doesnāt cover anything else up, then I tend to appreciate it. One of my experiences of the existing āroadmapā and ābrowse linksā features is that they pop up covering stuff I want to see. If this new ārelated notesā opened in a vertical drawer on the right hand side, keeping text pane the same width, but stealing horizontal space from the view pane on the left side (if necessary based on how much screen real estate is available), that would totally be worth it to me.
3 Likes
Roam takes the simplest path by showing you notes that contain exactly the same string. DEVONthink took a slight more sophisticated path (and called it āAIā, for marketing purposes) of providing concordance-based scoring: documents with concordances highly correlated to the selected noteās concordance rank higher.
Reality is, no manner of automation can accurately determine what ārelatedā means to the user. Inspection, perhaps aided by search, or similarTo() is the most reliable approach.
3 Likes
I accord with the answers above.
Realistically? To the mass audience, less useful than imagined (but usefulness != marketing 
).
This is a thoughtful and more valuable question; the tyre-kickers are outside the circle. It is a fair question to ask, but I think the initial response to the Roadmap changes are illuminating. Itās done something Iāve always wanted but felt churlish to ask for whilst I knew where Roadmap lived, but in truth, did my use of it reflect its propinquity? My gut says āNoā - shame on me, not Eastgate.
Which leads to the chick-and-egg of deliberate link usage. Long-term hypertextualists will know how typed links were a big thin pre-Web (itās just one of the N iterations of AI-will-save-us-all) but it failed on perceived complexityāof the āOMG, too many choices typeā. But I canāt help thinking the issue was a mix of erstwhile AI-solution hubris (plus Ƨa change) and limitations of the then UIs. The early Web just pushed on the same prejudices - too hard.
To counter this, I find the affordance of Hyperbolic really interesting. So, what is/should be in the network? Whatās missing? Why is is missing - is it just link type choice or something more? This seems rich and nuanced. Perhaps at last some of the depth of hypertext, pre-Web, is walking back from the long grass. Hypertext/hypermedia is so much more than dragging lines between things.
3 Likes
further to my last, Iād note that others have stated, more eloquently than I can, that the insight comes from revisiting notes (and metadata) rather than in a mindless dependence on āComputer says answer isā¦ā.
The Term āgardeningā is well used. A gardener knows that nature is not certain. Not everything we plant prospers. Yield varies season to season. This might make gardening seem a pointless task and yet the constant gardener is rarely unrewarded, even if it is with unexpected bounties.
I think Tinderbox most rewards us when we seek rather than demand. That doesnāt mean I canāt use it for seemingly workaday tasks like planning a trip itinerary, making a to-do list or filing expenses. But, my experience is it yields most when I demand least and explore most. Certainly, I struggle to think of another tool with the open-endedness that powered my recent research, and work, so well.
2 Likes
Do note, however, that Roam seems to support fully general datalog queries over the graph, at the block level (thereās no Tinderbox equivalent, but a block is roughly equivalent to a paragraph within a noteās $Text). Documentation is very sketchy at this point, but it seems likely that one of the matching criteria would be regex match. You can embed that query anywhere in the page, and the matching blocks are displayed right in the page, within the surrounding context, and are even editable in place. Itās early stages yet, but this aspect of the software is quite slick.