I’m coming from RoamResearch/Obsidian background. I’ve bene using Devonthink for over 3+ years and heard multiple complements how TB plays very nicely with DT & hence my interest in evaluating TB seriously.
I want to make a daily journal maintaining my daily activity of meetings. Daily activities of meetings invariably reference projects I’m working towards. I would like to backlink? (is this the right word) the relevant project and keep capturing any todos which arrive on these projects.
DO I have 1 TB file per month ? year ? How do I link tasks to a project ?
I’m generally very tech savvy but very very overwhelmed by TB and hence these n00bs question. if there’s any literature I should read which one will be relevant for me?
You may find the ‘ziplinks’ method of making links may seem most familiar from a Roam/Obsidian experience point of view. Importantly, ‘ziplinks’ are not a special type of link - the term relates to the [[ form of link invocation whilst typing. Tinderbox link types are described here; most likely ‘text’ links will seem most familiar.
For literal backlinks, there’s a ziplink syntax that you’ll probably find familiar:
Today, we discussed the [[<Perkins-Larsson]] project.
This adds a link to the note “Perkins-Larsson” and appends a link to this note from Perkins-Larsson.
However, Tinderbox also offers many alternatives to backlinks, and sometimes the alternatives are clearly superior. For example, you might make a user attribute named $Project. A note concerning a project puts the project name in $Project. That makes it easy to ask "what notes discuss Perkins-Larsson?
It is difficult to make simple mapping between Roam, Obsidian and Tinderbox as whilst all use notes, they so differently. Experience of one may be unhelpful as a start point for the others.
Roam and Obsidian are both powerful but are so by finessing only some features found in Tinderbox. Roam’s block level linking is sort-of there in Tinderbox (see my previous) post. Obsidian majors on simple Markdown-based text and its link graph. Tinderbox supports use of Markdown but it is not a default (the app long pre-date’s Markdown’s invention). The Tinderbox hyperbolic view offers a link-based diagram of the document.
By comparison, Tinderbox offers a wider set of tools but without the narrow feature optimisations—which is why better/worse comparisons don’t aid understanding. Some key things to explore are the multiple (concurrent) viewsof the same underlying data and strong support for incremental formalisation. Tinderbox’s inheritance and prototypes are both powerful affordances.
Probably the biggest difference coming, as you say from Roam/Obsidian, is that whilst you can just as easily type in your notes and connect them in Tinderbox, it offers a larger toolset to allow you to explore your understanding of your data, rather than your data having to fit into a app design optimised (with good intent) for a particular focus on how the data should fit together. Thus, inevitably there is ‘some assembly required’ to get the best out of the app, compared to process-optimised apps. But, if you don’t start from the premise of looking for the ‘correct’ (i.e. app dev’s view) method of how to use the app you should find it easy to get into. also, experiment with features in small text docs; this lessens confusions due to false negative/positive outcomes and keeps your real docs freer of cruft. It is not difficult to split documents if needed. Indeed, Tinderbox is very forgiving of false starts.
One doc or many? My suggestion would be to start with one and see how scale works. There’s no one-size-notion-fits-all here. You might have multiple docs split by topic but not time. You might have all topics in one time-frame. The sweet spot will come from seeing how your own natural way of thinking is best reflected (note: your thinking as opposed to “computers says”).
Apropos of this, I’ve had difficulty splitting files because it isn’t clear (at least to me) what information comes along if an existing group of notes is dragged to a new file.
Suppose I’ve created a cluster of notes relevant to a topic, and want to split that cluster off to a new file. What’s the best way to preserve information that might be associated with the Prototype? (Primarily $DisplayedAttributes, but also things like color, assigned due dates, etc.) What about links and Agents?
Thank you such a detailed reply. It makes me way confident to put myself inside Tinderbox knowing there’s help to guide a newbie like me. My plan is to use the next 7 days to learn TB for my simple case of journaling and task capturing & hopefully grab the winterfest discount
Hyperbolic view is indeed graph view of Obsidian. Thank You
I can’t figure currently how to create a user attribute and search (which seems to be precisely what I need in my question below) . Going through the help files to understand that. Ziplinks currently seem natural way to start.
Question
I used zip links to create a link something like below. TB auto creates the notes [[Zara]] & [[Basecamp]] for me. Is there a way to “see” the content of my daily notes on [[Zara]] pages OR see content connected to Zara in outline view?
24th December
Had a meeting with [[Zara]] designers , they suggested change in the designs
IT team says there are problems with the app [[Basecamp]] .
25th December
[[Zara]] has now rolled back the changes suggested, they want to roll back to previous submitted designs
[[Basecamp]] is working properly now , internet issue is now gone.
Task - Check on [[Jan 10th]] regarding [[Basecamp]] and see if everything is sorted.
If I only work in outline view (for beginning) do I have to manually link notes together or zip links will be sufficient ?
[sorry - @PaulWalters posted while I was checking info for my reply. My opening points echoes his and I provide some more detail to build on that.]
The easiest way to split a mature document, i.e with customisations such as user attributes, is to duplicate the document and delete the now-unwanted material in each.
To retain the prototype association with the notes, copy the prototype as part of the selection of copied notes.
Inter-note links are retained if the source and destination are both in the same selection of copied/pasted notes. Moving notes to a new doc will not create inter-doc links back to the source docs, if that is an implied question.
Agents should retain their query and actions, though for them to function as before any user attributes needed must exist in the new document.
Since v6.0, it has not been possible to to drag/drop or copy paste attributes (i.e. in their customised form) between documents. The best approach is therefore to:
In the source document, before copying any data, make a new note and give it all the user attributes you wish to use in the target document (do this in the note itself and not by using a prototype). If too many, make several such notes.
Copy/paste the latter note(s) to the target document. For each of these note(s), open the Displayed Attributes configuration panel (button top right of text pane) and then click outside the panel.
This will open a dialog asking you to configure or discard any attributes in the Displayed Attributes not existing in the current doc. Tick each item and set its data-type before clicking outside the pop-up. This causes the new-ticked attributes to be added to the current document. Repeat for each of the notes from the first step.
At this point you have now added all the needed attributes to the target document but only their name and data-type Any further customisation of the attributes (e.g. non-standard defaults, description) should be made in the Inspector for the target document.
You can now delete the notes used to help configure the new user attributes.
You can now start copying across your notes, agents, etc.
This is a good example of my earlier point about feature optimisation: link traversal/content display is one of Roam’s main features )or at least appears so from my albeit limited experience of the app).
Note that Tinderbox does not require links to have any notes to other notes. Consider a map view and doing some initial investigation. We might cluster notes about topic A separately from those on topic B. The spatial hypertext of map view now shows two discrete clusters of no notes without any links being used. Separately, Tinderbox’s hyperbolic view shows only the notes that are linked to the currently selected note. So, a map in the example would show no network. this shows a simple example of how different views allow different ways to look at notes in the document.
. Here I’ve 3 notes which link to Note : Miraaya birthday Party
Below I’ve created an agent which allows me to see all notes containing the same link from different places. I also see all text notes on the right side.
Agents aren’t a big deal. You can create them, and if they don’t turn out to be useful, or if you’re finished with them, just delete them. (Years ago, agents could create performance issues and so old-timers like me are sometimes worried about them. Nowadays, don’t worry until the document tells you to worry!)
As this is a discrete task, I’ve chopped to to a new thread (no censure implied!) as that helps later readers find potentially useful content. You can always add hyperlinks to your posts to cross-refer to other threads (or answers within threads).
I’ve added the build-in 'Person" prototype† and made a ‘People’ container that sets that prototype. In there I’ve made notes for our specimen callers so we can fill in things like phone numbers. I’ve then linked the call to each person in the $Callers list using a custom link type ‘call’. This is we know why there is a link; I could have as easily used ‘caller ID’ or such. Use what makes sense to you as Tinderbox doesn’t force a single answer upon you.
Now we can also look at the call in terms of who was involved using the Hyperbolic view:
†. Note that built-in prototypes don’t use atypical naming styles. So, with them I tend to either use the app’s name or duplicate the prototype and give the latter my own distinctive name. I can see ‘Person’ as a being a name of a note a user might create (‘pPerson’ or ‘*Person’, etc., less so). Here, I’d kept the system name for easier process copying by those using the TBX)
