Revisiting Roadmap

Off the Wall
21

I’ve found this discussion really interesting as well, both the Roadmap and the Roam discussion together. The thing that it has me thinking about is the power of reducing workflow friction. Roam isn’t really doing anything that hasn’t been around for a long time, and it doesn’t do all that much but for a certain use it does the right things very easily (backlinks make it very easy to see where something has been mentioned, which aids discoverability; new pages can be created and linked to very quickly and reliably; embedded and backlinked blocks are directly editable in place — i.e., in more than one context).

Tinderbox is far more powerful than Roam in terms of action code, attributes, visualizations, exporting, etc etc etc., but in my experience its open-ended nature gives it a lot of friction that has to be reduced with agents, keyboard maestro macros or what have you. And even then sometimes you hit a wall (my desire to be able to add links with action code is based on hitting one such wall). The UI is often part of the friction — I can’t tell you how many hours I’ve programmed action code in the tiny boxes of the action inspector, or how many times I’ve written a bunch of action code only to find that I forgot to hit enter and save it so all that work has to be recreated. Even just getting to the attributes of a note can feel slow sometimes (opt+cmd+I, then click on attributes, then search, etc.). I’m not a person who needs to cut every extra keystroke out of the UI experience or anything. But friction does matter to a workflow.

It’s in this context that I think this Roadmap discussion is super interesting, because it could reduce friction for some very common actions and perhaps shift how people tend to use links in Tinderbox.

3 Likes
22

I’m going to comment on this from one specific perspective, rather than generally. That is, how Tinderbox could be the essential visual component of a Zettelkasten workflow involving Devonthink. I’m starting to investigate Zettelkasten so these may be naive thoughts (I’m still trying to work them out), but I hope they’ll add something to the Roadmap discussion. Do critique away…

TLDR:

  1. I’d like to see the Roadmap as a collapsible pane which reduces the height of the text pane but doesn’t replace it (in the same way the Key Attributes panel works).

  2. I’d like to see a button on the Roadmap which transfers its contents into a list of [[Name of the Linked Note]] wiki links, which is either added to the end of the note, or placed in the clipboard for copying back to the original note in DT3 / The Archive etc.

Reasoning:

The main assumption is that Tinderbox can’t be the single one-app-fits-all repository for an all-encompassing Zettelkasten. You also need at least a reference manager/big document store and for me that’s Devonthink. As DT3 offers many of the same features as Tinderbox, the main question is where you carry out those ‘shared’ actions. For me, DT3’s abilities to search the text of the sources (pdfs etc), and its greater capacity are decisive, so if it were a question of choosing only one, it would have to be DT3. So for me any use of TBX for Zettelkasten has to be as a supplement, rather than a substitute.

But I do see TBX as offering something unique to the process and that’s in the field of visualising the network of ideas and ‘happy accidents’ that a Zettelkasten is supposed to foster through ‘clusters of ideas’ and ‘note sequences’. All the Zettel apps, including DT3, I’ve tried seem to struggle with this: at best they seem to expect you to identify the clusters through a combination of tagging, searches and explicit links and there is no easy way of identify a note-sequence in its entirety, apart from following the links individually.

Tinderbox offers a way round that: you can Dance a map until the clusters of related notes become obvious and then you follow the note sequence through the Hyperbolic View and the Road Map. This seems to me to be a really valuable and as far as I know rare ability and the reason why Tinderbox has to be part of the overall Zettelkasten workflow.

So, what could an enhanced road map add? The obvious first answer is that it takes away the need to worry about backlinks – a real problem in DT3 and The Archive and so on, where you have to jump through hoops or Script Editor to get them. A toggled Roadmap panel which follows the selected note and keeps the Main View (Map, Outline etc), the Text panel AND the Roadmap in view at the same time would allow you to see the whole structure ‘unclustered’ and still be able to follow links easily to further parts of the map, where there may be spatial rather than explicit links.

So the first suggestion from me would be that the roadmap works like the Key Attributes list does now: it’s a collapsible panel which reduced the size of the text panel, but doesn’t replace it.

The second request is to facilitate the use of the backlinks in Devonthink and other systems. Spending a lot of time creating links between notes in Tinderbox is less useful and less likely to be done if you have then to recreate them manually in DT3.

I do appreciate that two-way syncing isn’t available, would be a huge challenge, and it’s not realistic to request it! So I’m not…

But I wonder if it would be useful to be able to have a button to add the contents of the Road Map to the end of a note’s text in Wiki Link format? I see the process as:

  • the TBX Zettelkasten is populated by watching the external Zettelkasten folder (in the finder or in DT3)
  • you use Dancing, Hyperbolic view and Roadmap and all of Tinderbox’s tools to analyse the networks and create new links
  • when you’ve finished, you click the button and the contents or the Road Map are added to the end of that note’s text in [[Name of the Note]] format (which most ZK editors recognise). Or perhaps the button simply adds the formatted contents to the clipboard?
  • you copy and paste the new content into the note in DT3 (navigating by the DT URL field…) for storage/editing etc where it will later be ‘watched’ back into Tinderbox for the next bout of visual analysis.

Export won’t work for this (AFAICT) because it creates a new note in DT3, when we want to change an existing one. (There is a question of how links created in DT3 are added to the TBX map, but that’s a lesser issue, because those links are visible in the text in TBX, while the reverse isn’t true.)

I imagine that it would be possible to write a stamp to add the links to the end of the note oneself: but I think it would be useful to build this into the Roadmap itself.

I hope this helps add to the discussion – just writing it down has helped me think about what I actually want from all the software I (very happily) spend so much time and money on…

Thanks.

3 Likes
23

This is very interesting. For my own use, I see one major caveat. Transferring link info back to DEVONthink begins to lead to what I think is a “danger” (probably too strong a word) in having more than one source for notes: keeping one’s notes in more than one place. Doing that, in my experience, leads to the frustration of keeping one’s notebooks aligned and 'synced’

Of course, this is my use case and not @brookter’s, so no criticism intended. My preferred use of Tinderbox is if I’m going to take notes within a given domain, this is where I keep all of those notes. If I need to reference something in DEVONthink, or anywhere, then fine – I link from there to Tinderbox. IOW, DEVONthink (or some other container) is a gross repository of source info. Tinderbox is a refinery and stays closed.

1 Like
24

I agree that there’s a danger of this, and also that where one splits the line between the overlapping features will vary between users. Neither Tinderbox nor DT3 can do everything.

I think that if you want the Zettelkasten to be all-encompassing (and therefore capable of growing to thousands of notes), and if you want to be able to work on it away from the Mac (I use the iPad and a Linux laptop), then DT3 is a better fit for being the canonical repository. But of course others will have different views and requirements and if there are ways to get my two requirements completely within Tinderbox, I’d be happy to think again.

So for me, the ‘danger’ is the price to be paid for using Tinderbox in the process at all. I think you can probably reduce it a bit by always writing in DT3 (which is better equipped for it in the round anyway, in my experience), but it remains a problem.

But I’m feeling my here and don’t really know the right answer…

Thanks.

25

Horses for courses, of course :slight_smile:

I never write more than brief notes in DEVONthink – it’s just too limited. It’s really designed to work with with external editors, anyway. For me, DEVONthink to Go is not where I want to be writing. Others think differently, for sure.

There’s something focused about note taking in Tinderbox that makes me content with its Mac-only footprint. I associate the phone and iPad with frenetics and noise and hyper-distraction. That’s just my experience.

1 Like
26

Being able to use external editors easily is one of the attractions of DT3 for me! I tend to use Emacs everywhere except iOS, where it’s IA Writer.

In truth, it’s all far too complicated and there’s no one true solution… I suspect I’d have been more productive over the years sticking to text edit rather than searching for the Holy Grail…

27

:+1::+1:

(same is true of my life-long avoidance of commercial TV, sports, and social media – immeasurable benefits :slight_smile: )

1 Like
28

Surely this process should then delete those links as basic links, otherwise a note’s basic links + plus existing text links now gains all the existing basic links. IOW, if a note had 20 basic links and 10 text links and we do this process without de-duping the note now has 50 outbound links (20 basic, 30 text) of which 20 are duplicates. That alone doesn’t break anything, though it probably makes some listings over-long. However, I’m not sure the existing ecosystem of link-related action codes has evolved with such gratuitous levels of duplication in mind: ergo, ‘just’ doing this without deeper consideration might just create new problems elsewhere.

This is, and always has been, a challenge in a non-single-purpose app. I’m minded to note this here as many of my early feature suggestions gained a polite reply asking me to consider the wider set of use cases (i.e. not just the one upon which I was currently focussed). It’s annoying, when one ‘just’ wants to solve this issue at hand, but I taught me to take a wider toolbox perspective.

Please don’t read that as negative to the Zettelkasten concept. I’m simply holding the ring for non-zero-sum outcomes where one workflow breaks another. As such a paste-to-clipboard that concatenates basic link info to the text makes much more sense that actually duplicating the basic links as text links just for easier copy/paste from $Text to [other app]. Or, now there is AppleScript support, wouldn’t that be a simpler and more configurable/maintainable bridge (apps change over time).

I do wonder if WikiLinks—as in CamelCased words used as article names and link anchor text— aren’t over venerated. Large wikis, e.g. Wikipedia, don’t use them using instead normal names with spaces and other punctuation of required. The other limitation which became very apparent when I helped curate an early version of this forum in wiki form (in the mid 2000s); the names needed to invoke the auto-linking are often not unique and lead to all sorts of silliness to create names, until everyone gave up and used normal links instead. Also node titles change; q.v. in 2016 only 41% of the 12+ million articles in English Wikipedia were actually articles. The remaining 59%†, i.e. over half the supposed articles, are actually just redirect pages‡. OK, here we work at smaller scale, but the ‘automation’ of wikilinks where we offload the cognitive effort of creating links onto a supposedly cleverer computer strikes me as hubristic.

† A surprising and unexpected finding whilst researching large scale hypertexts like Wikipedia.

‡ This is fast-rising technical debt caused by failing to address node name changes as they arise; scale (“…too difficult…”) is always an excuse for inaction.

Of the large long-lived Tinderbox documents I use, link triage—most normally arising from node refactoring—is the most complex and time-consuming task. Yet, done with care, it’s one of the most rewarding as it preserves the health and longevity of the hypertext therein. I’m very happy to have link creation tools to allow be to create links at scale for defined circumstances, i.e. links of my choising: indeed, I use such tools.

However, having the app generate more of the links at its own cognisance isn’t an appealing. I think the emerging improvements to Tinderbox quicklinks are a far more positive approach. The latter still offer speedy linked note-taking without the format constraints of wikilinks.

29

Interesting points Mark, thanks.

Taking them one by one — I did wonder about the issue of basic v text links, which is one of the reasons for the alternative suggestion: that there could be an easy way (the ‘button’) of transferring the content of the Roadmap to the clipboard. Wouldn’t that deal with the issue? Yes, those links would come back into note on the next watch, but they won’t be active (at least I assume they won’t be — Tinderbox doesn’t automatically convert anything in doubled square brackets to text links, does it?). So, I’m happy with the idea it would be to the clipboard alone.

The other point is that it I wouldn’t see this as an automatic process: the decision whether to use ’the button’ would be at the choice of the user, rather than imposing anything on anybody’s workflow. At heart it’s the simplification of something that an expert user (not me…) could probably do with a stamp, or with Applescript, as you say: but we’re talking about a reworking of the Roadmap. Dealing with links programmatically is a fairly advanced topic (I’ve been using Tinderbox since 2010 and I’m not sure how I’d go about stripping the links out to the clipboard), so a simple built-in way of doing it may be useful addition to the toolkit?

As for wikilinks — the ones that seem to be used in The Archive, Emacs, DT3 and so on aren’t camel case. They are in the form [[This is the name of the note]]. Yes there are problems of curation, but there are with the other apps… And as these are being added programmatically to the clipboard, presumably the official Tinderbox url could be added at the same time (but that’s a refinement for discussion, of course!)

On your last points:

the ‘automation’ of wikilinks where we offload the cognitive effort of creating links onto a supposedly cleverer computer strikes me as hubristic

and

However, having the app generate more of the links at its own cognisance isn’t appealing.

Well, I agree, but that’s not what we’re discussing here, is it? The computer isn’t creating the links — the user is doing that in exactly the same way we do every time to choose to link one TBX note to another. All this suggestion is, is to turn that user choice into a particular format so the choices we have made can be useful externally. Isn’t the the sort of automations which computers are good at?

But I’m trying to think of ways in which how the Roadmap can help the interaction between DT and Tinderbox to be smoother in the context of Zettels. As I said at the beginning, this is from one perspective amongst many.

Thanks!

30

Re using the clipboard - I’d say yes. It enriches inter-app use without imposing on the Tinderbox data in an unexpected way.

The term ‘Wikilink’ has probably seen some semantic drip and in many context has perhaps acquired the meaning of using [[ ]] to define a link anchor.

As to creation of links, what I was getting a—perhaps too obliquely—was the difference between links made with distinct purpose (in the extreme guess, one an algo likely won’t guess) and those that are simply proxy structure. In a chart or map, sibling status and order are explicit in the view; in a map less so. So, link lines showing order/sequence may be useful to 'reading ’ the map whilst having less real significance that the deliberately made links.

Also, a link may just be a visual affordance to traverse context from here to there (wherever it may be). The link has no import per se, other than as a means of conveyance. That doesn’t make the link unimportant to the task at hand, but it if still functionally different. I tease out the point as these distinctions may prove pertinent for those trying to implement the functionality and do not harm for being surfaced.

If I sound like Eeyore here, it’s not my intent or general demeanour! I’m genuinely enjoying the uptick in discussion here, and so many more new voices. The more the merrier!

1 Like
31

Me too…

I do think the clipboard idea (whether it’s built in or not…) has some legs, so I’ll be pouring through the atbref to learn how to do it anyway :grinning:

In a chart or map, sibling status and order are explicit in the view; in a map less so. So, link lines showing order/sequence may be useful to 'reading ’ the map whilst having less real significance that the deliberately made links.

Bearing in mind that I’m explicitly coming to this in the context of trying to understand how to construct a Zettelkasten workflow as a neophyte. As I understand it, a Zettelkasten is based on certain assumptions, which of course don’t all apply to many other TBX uses.

The main one for the purpose of links is that a Zettelkasten is a flat structure – it does its best to avoid top down organisation (e.g. containers). In that sense, it fits well into one of the ways of starting a tinderbox map – open a map and start throwing notes at it till a structure emerges.

But rather than going on to put related ideas into containers, any structure the ZK has[1] emerges from the connections made between notes - its the combination of the connections and the notes which is the Zettelkasten, in that sense and it never moves to an outline structure.

I do appreciate that many people use Tinderbox in this map-only view by default, so of course it’s not unique to Zettelkasten, but it does throw light onto the use of links, I think.

As there isn’t the concept of links simply reflecting order/sequence/hierarchy – if a link is there, it’s a deliberate choice by the user. (Yes, there’s a chain because one note connects to another, but there isn’t the concept that any note in the chain is necessarily privileged over any other in the chain.)

The advantage of Tinderbox for this over DT3 and The Archive, I think, is that Tinderbox map view reflects this all in one view very well – you get an overview of the entire Zettelkasten slip-box, and Dancing and Hyperbole and Roadmap help you make sense of it.

In DT3 etc you get the equivalent of (a single level) Outline View only.

Hope that makes sense and that I’m not traducing the idea of Zettelkasten too much to any experts reading…

[1] There are ‘structure notes’ which are essentially an ordinary note which acts as a table of contents of links a topic, but they are still just one note at the same level as the others.

1 Like
32

If you are using explicit (actual) links, then hyperbolic view is useful as only linked items are in view and it works across the document. Tinderbox doesn’t limit the number of items in a container, but with 00s general navigation gets harder. So, if your Zettelkasten is going to hold 000s of notes you probably won’t be storing them in one container (map), for practical purposes, so the hyperbolic view again has attractions. If I recall the view is essentially a force-directed layout built out from the selected note and drawn across the surface o a virtual sphere (so things further way are drawn smaller). Changing the latter creates a new layout. The view can be zoomed/panned, etc.

33

With respect to the main topic of the thread, namely an improved Roadmap, I’d like to add my vote to keeping any new pane with the $Text pane. I prefer having key attributes, name and text in one place. And I’d add new things there.

1 Like
35

My response is strictly off-topic to the roadmap. I agree that links are used for different purposes and your characterisation of the matter. Some are additional structure with some bonus UI/visualisation affordances, some are trying to express some content. Of this latter sort, a feature I would value is individual links having a $Text attribute into which I could put notes that expanded on the purpose of the link. These could be arbitrarily detailed and so not expressed by a link type. I have no idea of the feasibility of this feature.

One way to do it is to make a type of link that was also a note. The conceptual difficulty with this is that the link would possibly be at two places in the container hierarchy at once.

Right now, I can simulate what I want by linking from the source note to an intermediate note which contains details on the purpose of the link and then from that note to the destination note. It works, though not ideal.

36

AIUI he had two forms of notes: the reading notes kept separately with the bibliographical data, and the permanent notes derived from his thinking about that reading kept on their own in the slip-box (the Zettelkasten itself). The first naturally lends itself to containers (or in a separate program) and it’s kept separate from the second, which is a flat structure of permanent notes made after contemplate the literature notes (a bit simplistic, but that’s the basic idea, I think).

(I’m taking this mainly from Sonke Ahren’s How to take Smart Notes BTW. )

He didn’t rearrange the permanent notes after they were created, but he took care to file them in an appropriate place initially – they were not simply added to the end of the box sequentially, but a note was filed behind one which was relevant and numbered accordingly. A note numbered 35/5k5 is linked ultimately from the idea first sparked in note 35 (without assuming that the first note is the ‘primary’ note in the sequence). And he took care to link any new notes to ones that had been created outside that sequence, I think.

He also kept lists of keywords, and index cards and as you say, they’re easily replicated with tags and they are important (thought there are issues with using tags of course). But according to Ahrens, they were an entry point into the web of connections, not the list of connections themselves. And the information encoded in the note-naming isn’t so easily replicated is it?

I appreciate there are plenty of variations and that people will build their own workflows – and that Luhmann wasn’t the first to use notecards anyway… The issue of whether the note-sequences actually add anything or is just an artefact of Luhmann using pen and paper and no longer relevant when explicit linking is available through software seems to be quite contentious amongst the ZK community. I’ve no desire to wade into such religious wars! (I have to concentrate on fighting the Emacs v Vim fight…)

Given the state of the other software, I thought the ability to harvest the links made in TBX would be useful, irrespective of whether it’s completely Luhmann-conformant :slight_smile: .

1 Like
37

I’m not sure if I’ve misunderstood, but Eastgate—as ever responding to interesting user requests—has added the ability to annotate an individual link. See Browse Links and Roadmap. This feature is new and still evolving. for instance—lest you wonder—these link annotations are manual for now(no action code access). Yet, I’d be surprised if more means of access to this info didn’t come in due course.

I think—going back to your post—that making these attributes of $Text might be difficult, but I think the above meet that need and without the architectural restriction. Rather, these annotations as attributes (not in the $attribute sense) of a link, which makes sense to me; the next step will be to figure an appropriate way to have other ways to access them other via the above dialogs.

38

There are too many ideas here to respond to individually. I think we are all collectively feeling our way towards “what we want” (which is probably not entirely congruent with “what would be useful”, but that’s another topic).

A few things I don’t think I’ve seen mentionned:

  • the ability to “programatically” generate links from text would allow us to choose what is relevant or not (the “but is it useful” objection) in our gardening.

  • i’ve discovered much power in using Hook to link my TB notes to “other stuff” on my machine. It’s truly filing a gap in my usage (a niche probably occupied by DT/TB integration, which never worked for me) of TB as a notebook, repository of my ideas and hub of navigation. The remaining frustration is that I’d love to populate either $Text or some other attribute with my list of Hook links.

The theme being: allowing the user to generate links programmatically from various sources …

39

This is interesting. As the list is indeterminate in size, the approach of making a few user URL-type attributes isn’t ideal; it doesn’t scale neatly and setting the attributes would be fiddly.

At present there is no method to generate a link in $Text - either a text link or a web link (external links would need to be the latter.

That said, if you don’t mind links that are RTF only (i.e. functional links in the RTF not recognised as Tinderbox links) then paste your local URLs into text and the Apple RTF frameworks should recognise them and create links (using ‘smart links’ functionality).

The ability to adopt smart links as true Tinderbox links is on hold. As I recall, initial attempts (around the time smart links were added) to merge RTF-generated smart links with native Tinderbox links caused issues not satisfactorily resolvable at the time. So for now text smart links work to open web or local URLs but can’t be ‘seen’ by Tinderbox, i.e. they aren’t included in things like $WebLinkCount.

40

But this is not the Hook use case is it? To see Hook links, i.e, the list of things one has “Hooked” to a Tinderbox note, one must invoke the Hook app or open from the Mac menubar.

I would say the shortcoming to obtaining from Hook a list of related notes plus links is not Tinderbox’s shortcoming. Tinderbox cannot work with something that doesn’t exist. The Hook app does not afford such a “list of Hook links” – it’s an issue for that app’s owner to solve.

1 Like
41

Well Hook is very versatile. When you hook two objects together, invoking hook on one shows you the other, which you can navigate to in two keystrokes.
I have a type of TB note to which I link 6 or 7 objects (a couple of web page, a few of folders and files, an Omnifocus project …)
I’m not denigrating TB - and in fact I believe @mwra solution almost works - the issue (and yes, it’s hooks, really) is that I’m not sure how to get ALL the hooks out of Hook in one go.
Also, both Hook and TB are scriptable - so there may be some hope here.
Hook is very rapidly evolving - and frankly, the fact that nobody refers to it as the Hook cult is refreshing (yes, #roamcult is a thing in Twitter …)