I’m a user of Xmind and received a link to a 36 min video on how it’s used for knowledge. I thought I’d share it here as it has some interesting ideas.
Xmind’s shortcoming is in linking to other documents which TB can do via Hookmark.
Does anyone use a TB file to link to something like an assets folder and grow a map linking to different content, but doing all their thinking in TB? This sounds like a good use case to me. Perhaps you are all already doing this and I’m late to the party!
I would really be interested if anyone is using a main TB file as a dashboard for all their other knowledge and linking to other files outside TB (including other TB files) and growing their map over time. I know the recent video on TheBrain has a similar theme, but I’m specifically looking to have files outside of TB in general rather than everything embedded. This allows me to use other applications that can do other things better, but allow me to think in TB.
This is quite a common use case for me.
Note that you can create as many such links as you like in addition to the intrinsic/system ones, simply create an User Attribute and give it type URL.
File type Attributes work similarly and find files/folders on your Mac.
So in short, you can reach out from Tinderbox to external files, folders, URLs, and even specific url anchors.
And simplest of all, you could drop a URL into your Note Text, the rich text editor saves it as a hyperlink.
Note that there are a total of six URL-type attributes being used as Displayed Attributes; you can spot them via the globe icon, which you click to open the URL in a web browser. Here I’m supplementing the system attribute URL with 5 user-defined URL-type user attributes.
A point of the grab is to show that such user attributes are best seen/used when part of a note’s Displayed Attributes.However, in some projects, I make many URL attributes but don’t necessarily show all of them all the time. Don’t forget that the list of attributes in Displayed Attributes is set via $DisplayedAttributes. So, by saving different lists of attribute names and swapping the lists into $DisplayedAttributes, you can have context/use dependent Displayed Attributes in your notes.
Whereas in my apps it is a case of bending your task to the app’s way of doing things. Though Tinderbox does have some limitations, most often your task is figuring out which features to use in what combination to best suit your work.
I am no fan of Hookmark – its links are fragile and ordinary changes to Tinderbox documents can trash the linkage.
I use the methods mentioned by @mwra and @archurhh. Not only files, and web pages have links, but many assets on the modern Mac generate custom URLs: DEVONthink, Curio, MarginNote , etc. My own twist on their approach is that in some Tinderbox documents I will create stand-alone notes whose sole purpose is to contain the $URL of the linked asset and $Text with a note or two explaining the purpose of that asset in the model I am building.
I then link to those asset notes in other notes that depend on the information in one or more asset notes. I do this because I find it useful to manage the network of asset notes separately from my writing.
Yes, this is all I do, I include images and videos in the concept of “assets,” not just PDFs or other docs.
I NEVER embed anything TX. My application suite, generally is:
Tinderbox
Zotero
Pandoc
Grammarly
Text Expander
DEVONThink
Finder
Hookmark
Readwise
Diigo
As little as possible MS Office apps
I’ve developed one “master” The Brain-like TBX file where I manage 90% of my projects:
writing books
writing articles
blog posts
managing events and webinars
managing projects
managing sales pipelines
managing referrals
managing contract status
curating atomic assets: people, terms, themes, entities, regulations, etc.
I use the action code I’ve refined over the years to link and cross-link it all by link types.
I use export code to frame, present and publish this material in any which way I want whenever I need to.
Thanks for the information, Michael.
Can you share how big that file is? How many notes, words and links does it have? Any stability problems you experience - or data losses from crashes (if there are any)? Really interested!
It is about 14K notes, 700K words, 37 agents, nearly 900 attributes, 86 templates, 71 prototypes, 6,000 links (and growing now that I have it optimized), 17,000 rules and edicts (each with 5~30 lines of action code). I was having quite a few issues, but in the last week have fixed them with just a few optimization tricks that I’ve implemented in the last week. Coincidentally, we reviewed several of these optimizations in today’s meeting.
You can highlight some anchor text in the $Text of your note and “Make web link…”, or you can just paste a very ugly URL in $Text, or in a URL user attribute. In any case, clicking on it takes you to the document in Finder (iCloud).
Hi Andreas…
Just adding my .02, not sure if easier is the advantage, from my perspective, the DISADVANTAGE of using HookMark in Tinderbox documents is that the links are very fragile. IF the name of the document changes or if you copy and paste that note into another document…Hookmark links break. That has been my experience anyway.
To Hookmark (and to almost all file systems), the identity of a file is the location in which it is stored. The Web works this way, too: if you have a URL
then it’s a link to whatever file is stored in /tutorials/example3.html . If you move that file someplace else and replace it with a new file, the link points to the new file. That’s what the link means.
macOS file:// links are hard to get; they break when you move the file; and you can’t share them. Hookmark file links are much better. Select a file in Finder (or open it), invoke Hookmark (⌃H) and Copy Link (⌘C). You’ll get a hook://file/ link. You can move or rename the file without breaking the link. It’s like a Finder alias; but it’s (a) a link; (b) more versatile; and (c) shareable
Seems that Hookmark is not using the path but the name of a file first of all. I’m having no problems so far
I just verified…If the hookmark-tinderbox note gets copied and pasted into a new updated document (for me … is a big deal because I will periodically update my entire tinderbox document especially if it is an older tinderbox file) OR if the the title of the tinderbox document gets renamed or moved… boom. the hookmark link breaks in tinderbox.
That is my experience
I have reverted back to more standard $URL and $File attribute storage as well.
That’s the AppleScript in Hookmark to deal with a TBX link:
use framework "Foundation"
tell application "Tinderbox 9"
if (count of documents) is equal to 0 then
return "No document is available"
end if
set openFile to file of first document
if openFile is missing value then
return "Hook can't link unsaved files"
end if
set filePath to my encodedPath(POSIX path of (openFile as alias)) as string
set openNote to selected note of first document
if openNote is missing value then
-- link to file if no note is selected
return "file://" & filePath
end if
set tinderboxURL to value of attribute "NoteURL" of openNote
set tinderboxURL to (text (1 + (length of "tinderbox://")) thru -1 of tinderboxURL)
set tinderboxURL to "tbx://" & tinderboxURL
return tinderboxURL & "?filepath=" & filePath
end tell
-- encodedPath :: FilePath -> Percent Encoded String
on encodedPath(fp)
tell current application
(its ((NSString's stringWithString:fp)'s ¬
stringByAddingPercentEncodingWithAllowedCharacters:(its NSCharacterSet's ¬
URLPathAllowedCharacterSet))) as string
end tell
end encodedPath
and this is a link Hookmark extracts from TBX: [dummy](hook://tbx/ExternalCode?view=outline+select=1688838559;?filepath=/Users/detlefbeyer/Documents/Tinderbox/Projekte/ExternalCode.tbx)
So the TBX file will be referenced by name and the note by $ID. The ID is specific for a single TBX file. So Hookmark has no chance to find this note again after you copied it to a new TBX file.
Hookmark’s reference to a note $ID (which is TBX document-specific) seems fair. Whatever our personal wishes, Tinderbox was never originally designed as a multi-platform app or a multi-user app. It’s thus an exercise in hubris to assume features that stems from the latter design context. It doesn’t stop anyone requesting new features, but it is silly to assume they exist when patently they can’t. But, that does imply reading the docs, which we tend not to.
IOW, Hookmark is not fragile, but rather our untested assumptions about it.
