Tinderbox Forum

Revisiting Roadmap

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.


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.


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:

  1. 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.
  2. 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.

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.


I accord with the answers above.

Realistically? To the mass audience, less useful than imagined (but usefulness != marketing :cry: ).

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.


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.

1 Like

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.