I have just started to play around with Ziplinks, but their utility is clearly amazing for all of us using Tinderbox for scientific knowledge management (read: zettlekästen on an entirely new level, with TBs amazing abilities). I love the functionality of “|” to be able to name the new linked note at the same time as assigning a link in the original note that is short and fits in the text description there. I also love the ease with which Tinderbox allow me to select existing notes to link to as I write the ziplink, but have not figured out how to use the “|”-functionality when linking to existing notes too. This would be very useful. Can anyone help me with this?
I’m still trying to document the nuances of the simple-yet-complex feature. Essentially, if you type [[, and optionally some characters for matching, then select a note title from the pop-up list, the link auto-completes for you.
To use the larger syntax with optional anchor text and/or target $Text, it seems the safe way—i.e. not invoking premature auto-complete of the link— is to manually type the name(or path) of the matched note without using the pop-up list, then the extra anchor/$Text and then close the input with ]]. the latter tells Tinderbox you are done and it then makes the link.
Exact process, given all the options in this very new feature, is still being figured out. Ziplinks have effectively subsumed the older quicklinks. Two different outcomes (just a link vs. a link with extra configuration elements) are running off the same trigger.
2 Likes
Thanks Mark! That makes sense, but is not optimal for the version of knowledge management I use TB for, where the names of notes are descriptive and relatively long to summarise their main contents. TB is definitely the best tool for this anyway, and the new ziplinks really helpful, but if there was a way to select note titles from the popup list and still “rename” the link visible in the original note with ease (as when using “|” when creating a new linked note) it would be a dream.
I am still a bit of a newbie, and only using a fraction of the functionalities of TB, but it is already a way more powerful tool for scientific knowledge management (and any version of zettlekästen) than anything that I have found (and I have looked very hard for rather long). Sincere thanks to Eastgate and to you and the other gurus helping us less experienced to harness the powers of this amazing software!
OK, this is a user forum; I’m a fellow user. We can’t change the app here.
If you feel ziplinks should work a different way that as at present, please email tech support (support info@eastgate.com) explaining why the feature fails you and how you suggest it might work better.
Separately,
You can do this but I think when you get further into use you’ll see this is a rod for your own back. I can see long names as an initial capture mechanism. But, long names:
- don’t fit in the available display space in most views.
- often include characters (semi-colon, parentheses, straight (double) quote, etc.) that ‘break’ query parsing (find() uses queries the same way as agents do).
- make for difficult searching
If the only way you can initially capture information is to write a long title ($Name), I suggest developing a workflow where you review those names and parse the metadata out into $Tags or other attributes. Your future self will thank you for embracing metadata. 
2 Likes
Yes, of course. Thanks for the suggestion to contact Eastgate about my “issue”, although I feel a bit like a spoiled brat to ask for more from an already amazing tool.
Thanks also for the other note/warning! It might be better to rethink my “system” now, so I don’t get stuck in an unsustainable workflow later… I have much to learn…
An alternative — not completely seamless, but not that bad, is to make the zip link using the suggestions menu
. [[1 ➛ [[1,8 dimethyl-cyclooctatetraene]]
and then select the newly link text and type the link anchor:
DMT
But I agree with Mark Anderson; it helps to keep note names concise if you can.
3 Likes
Starting to use Ziplinks. Love it. And, ran into the same bump as @Per .
Following on @eastgate suggestion, another possibility is to modify auto-complete behavior when a modifier key is held down (e.g., Option) while selecting a menu suggestion (with Return or mouse).
Case 1. If Option is pressed, then $Name is inserted as text without the closing ]], allowing the user to continue by typing |explanation::see this]]. User can, of course, change their mind and just close with ]]. This approach also allows keyboard-only entry.
Case 2 (default). If Option is not pressed, the auto-complete performs in its default current manner.
In my usage, I almost always have a different, context-relevant explanation than the $Name to which I am linking. I’d prefer Case 1 as default behavior and have Case 2 require the modifier key, but that is merely personal preference (n=1).
1 Like
How clever! I have so far allowed the auto-complete and then altered the link by “option-clicking” it or placing the cursor just outside the link and moved it into the link with the arrow keys (which are both okay workarounds), but your suggested Case 1 is faster and more sophisticated. Thanks!
In my work, I have notes that can often have similar names. For example, an organization and a product can have the same time, so this makes it very difficult to know which note I’m pulling from when I’m Ziplinking. Also, I have a lot of notes, and filtering through them can be hard.
As noted above, I like to keep my titles short and put the details of a note in $Text.
So, when I create a note I’ll give it a prefix, e.g. Org - LastPass or Prod - Prod-LastPass, see Image 1. This also enables me to filter the Ziplink popup as I start typing a prefix, see Image 2. I’ve also created a user-generated attribute convention for myself, $ShortTitle, which I’ll use when I’m running exports and I don’t want the prefix to be displayed (see Image 3). Now, this has raised some interesting enhancement options from usability and new functionality perspectives that I’ll not share here, as I don’t want to confuse or misdirect anyone; but, I have shared them with the TBX team.
Image 1:
Image 2:
Image 3:
Now, here is something you may not know about. Open the links manager with ⌘7. If you mouse over one of the links the linked note’s title and text will be displayed.
If you draft on this popup right where the hand is in this image below it will “tear-away” a new window.
You can now edit the linked note in this new window and once you’re done you can go back to your other note. This might address your desire to edit the title of your linked notes.
For those that are interested, here is the TBX files for the above examples: Ex. Ziplinknotes 26DEC20.tbx (94.0 KB)
As context and not counter-argument, I think the prevailing view is that if $Name isn’t unique use $Path. But some projects don’t lend themselves to this - structured documentation being an example (though don’t overlook alias & transclusion (and ^include^).
Though I’ve used different methods over time, I’ve long used the notion of screen title ($Name or $DisplayName) to work around such issues. Whether it is because the original ‘name’ uses non-code-safe characters or is simply too long for useful work, for read-world work—as opposed to conceptualised notions. For instance, in my field† authors regularly use all sorts of non-ASCII characters, oblivious to how search-unfriendly they are.
†. The exact field. The point is many people write with no idea‡ as to how the on-screen characters they use are encoded or—as importantly—do, or don’t play well with regular expression-based search.
‡. …and that’s not a bad thing!
1 Like