Tinderbox Forum

Roam, Zettels, and Zips: a different approach

Currently, Tinderbox ziplinks let you make links [[like this]]. This inserts a link anchor like this that links to a note named “like this”, and creates a note if necessary. Various extensions are implemented too,. That’s great for some styles of rapid note-making.

It’s also a bit arcane. Here’s another idea.

  1. After you type “[[”, Tinderbox deletes the brackets and an overlay window appears:

  2. The focus initially falls in the Link field. Type the name of the anchor you want. Pressing Return or ]] dismisses the overlay and creates the link. Pressing Esc cancels the overlay and returns to the text pane.

  3. The Destination field is red if the destination does not yet exist, and black if it does exist.

  4. If the text in the Destination field is identical to the text in the Link field, changing the link field also changes the Destination. If the fields differ, each can be edited separately.

  5. If Append Backlink is checked, a link to this note is appended to the destination note.

  6. A menu the left of the text pane continues to present a list of potential destinations whose names contain a substring of the current link text. This, if you had typed [[book the menu might contains “Books and Journals” and “Booker T. Washington”. Choosing from this menu autofills the Link field; if the text of the Destination field is identical to the Link field, it is replaced as well.


  • No need to remember arcane syntax like [[<anchor|destination>]]
  • Slightly fewer keystrokes than at present
  • No mouse clicks are required


  • The text pane is partly obscured
  • More development work in support of a feature whose utility remains uncertain; the current implementation is good enough
  • Cleaner code in TbxTextView
  • Arguably more idiomatic for Macs

By the way, this is the sort of discussion we normally have backstage: https://www.eastgate.com/Tinderbox/Backstage.html

I’ve brought it here in the wake of the monster Roam thread, but if you’re interested, you might consider joining the backstage program.

I would be disappointed if it were necessary to step through this dialog in order to use ziplinks. 90% of my ziplink use is with the “arcane” syntax of [[text::content of the new note]]. Close to 10% is of the form [[text|name::content of note]].

Your proposed design seems good for someone other than me, so it would be pleasing if some arcane variant were preserved that avoided the dialog.


I think the basic zip links syntax is drawn from familiar established wiki norms that aren’t far removed from things like markdown. They become complicated if you want to append text without shifting focus to a new note, but that isn’t a basic use-case. As I imagine it, replacing that syntax with an overlay seems obtrusive and I think I prefer the current implementation.

That said, what seems new in this proposal is the easy toggle to create a back link. Perhaps that addition could instead be an attribute accessible in document settings? Something like $CreateZipBacklinks or something? I’m assuming (without knowing) that that people who want backlinks probably want them everywhere.

1 Like

I agree with @entropydave – making zip links is really fast with the keyboard, and I would experience a lot of friction with a dialog box. Dialogs are generally not a great UX, in my opinion. Although for newer users, and probably many others even experienced with Tinderbox, dialogs are helpful. I cannot measure that.

Maybe if the dialog were an option – as @bcrane suggested?

1 Like

This proposal makes sense to me in outline. If the tabbing between fields is correctly wired up that a competent typist can whizz through the fields pretty fast. If we just optimise for typing speed that is not good for the general users. Tinderbox is a deeper, richer tool that some of the tools/method being compared to it. Making Tinderbox harder to use (increasingly overloaded typed sequences) just for one niche group would, IMO, be loss for the Tinderbox community as a whole. In writing that, I reflect on the range of users with very different ways of using Tinderbox that I’ve helped here and in past fora.

Separately, I think ‘speed’ and ‘ease’ are the wrong starting lens here as they are highly subjective and give a skewed perspective as to the delicate task of optimising the act of linking.

Missing in this revision is a method to set link types. There is a chick-and-egg problem here for link types. People don’t use them (as link metadata as opposed to drawing labels) because they are a bit hidden away. As a result people don’t see them in use, … and so don’t think to use them (yet want link metadata) …etc.

I’m beginning to see a dichotomy of approach to linking that is implicit in some of the discussion leading to this thread: the ‘hares’ and the ‘tortoises’—for ease of simple terminology and without implied judgment. The ‘hares’ seem to see linking as an impediment to their thinking, something that takes them out of the flow. The ‘tortoises’ approach is more considered; the link is made after some deliberation.

Also to be unpacked is the note creation via linking, or more pertinently typing a link. This approach has already had someone then opine that changing the new, linked, note doesn’t change the original source anchor. There is a very precise, but narrow, approach there that wants some consideration before implementation. Here, the ‘tortoise’ would likely have considered the name of the new note before linking thus not needed the app to fix a predictable error. Again, I’m not making a value judgment here, just flagging the problems inherent in silo-ed thinking that tends to come to the fore when discussing polarising features.

Obliquely, I can see these developments adding to a desire to manipulate source/destination text anchors remotely, i.e. via action code. As my own projects end up as having a lot of notes, I’m conscious of scale and for things that attractive with 10 notes, aren’t so with a thousand.

My opening 2¢, anyway.

1 Like

I’d like some arcane syntax for link-types too, as it happens. Combined with link actions, they are a powerful tool.

1 Like

So if we prefer to avoid working with a mouse as much as possible (not an easy feat in any event with Tinderbox), then we’re “just a niche group”?

I don’t read the ask in the thread as playing groups off against one another. It’s how to accommodate the whole tent. Isn’t that the best approach?

My point exactly.

I’ve been using Keyboard Maestro to create a dialog box for some zip link data entry and thought you might find the example useful.

It’s not what you’re asking, but it may be interesting to see that a user has set this up for herself, and (2) values the ability to make a choice about when to use it (CMD+Shift+/ vs CMD+Shift+.)

Here are my shortcuts for those interested in that sort of thing:


My thoughts are that the arcane system is actually not that arcane when you get used to it. When you’re in a creative burst inside a text field, “coding” links the way ziplinks work now is my preferred method, and I’d welcome even more keywords/modifiers like the link type @mwra spoke about. The idea above is also great, but if possible I’d like both of them, not either/or.

In summary – agree with what @entropydave, @bcrane and @PaulWalters have said up the thread.

1 Like

I’m not sure if I’m understanding things correctly, but I thought I would just observe that a lot of software seems to try to cater for very different levels of expertise (not to mention disability) by having an interface that has menu items, with the addition of hot keys or shortcuts for frequently-used items. For those who have a failing memory (like me), or are new to the program, or who don’t work that way, you can hunt around for the menu item and select it. But as you get used to the program you may be able to remember the hot keys for items (incremental formalisation?!) and work in a different way. This approach seems to me to be both humane and egalitarian. A quick option for those who need it, but a different way of getting the same result for those who, perhaps, cannot work that way.

For a long time I have used my computer and applications in a kind of semi-configured state because I have never had the time to sort them out properly. I am now trying to do that, and I have found that the load of things to remember is so great that I am having to create a kind of wiki in Tinderbox that I can refer to, with items like hot keys to remember. I recently emailed Mark Bernstein about something that wasn’t working in Tinderbox, only to discover that it was a hot key conflict with 1Password. I’m reaching the point when I have to use Keyboard Maestro (thank you @Beck!) because of cognitive overload. I’m grateful that option exists.

Sorry, I think I have wandered off topic. Put it down to overload!

1 Like

By using the term arcane, I don’t believe @eastgate was using as a slur, but in the real sense of ’ mysterious and known only by a few people’…which it is. The process and syntax is only covered in part in Tinderbox Help, and—I believe—the only public full description is an article in aTbRef (albeit based on data in the Backstage’s release notes file, ‘Notes.tbx’).

So the feature is arcane (no parenthetical quotes needed) but that does not mean it is not useful to the small number of people who have found, mastered and liked it. In the same vein, my reference to that sub-group as a niche (i.e. ‘an an area or position that is exactly suitable for a small group of the same type’) simply reflects this.

The opening post didn’t state the new method as a binary replacement for the current experiment but is generously considering making the same outcome accessible to a wider group of users via less arcane methods. That does not seem a bad thing, as reflected in @MartinBoycott-Brown’s post above: not everyone uses each feature enough to internalise the less common.

We all, myself included, can tend to view our use of Tinderbox as the norm, when in fact we use it different ways. Interesting, in context, is the linking method shown by @beck’s video where the user is adding links after typing the text (recall, there is no one right way). ISTM, the proposed new method offers the opportunity to improve the link creation process (when no using drag-drop) if the dialog can be invoked either inline or from a selection. That doesn’t preclude the existing non-dialog method being retained for those that use it (I’ve not seen ay reports of it causing major problems other than its arcane nature for some users). Thus the suggestion of doc setting to disable a dialog in response to [[ invocation would seem sensible. Default I would suggest as ‘off’ (i.e. dialog used) as that benefits the learner who can turned the setting off if/when they decide it suits. For those who can’t live with setting this in new docs I’m sure it would be possible to add config.xml support for setting; I use that method for an app default it so happens I don’t like—darker outline colours—and it works just fine).

This is also a good opportunity to reflect on how/why we link and how that plays into the manner of our effecting of that task. Fresh from ACM Hypertext 2020, that’s certainly in mind for me.

So, I think there is space for all in the tent, even if some gather in niches within: we’re all using the same broad toolbox, just in differing ways that don’t always overlap.

. Definitions for ‘arcane’ and ‘niche’. Source: Cambridge Dictionary.
. I’m sure the Help article will expand as the ziplinks method matures; I believe it is still broadly experimental and thus the lag for the newest changes. But, as I write, there does exist additional un-described syntax (for which aTbRef can update because it exists outside the app package); this is not a criticism of the Help file.

Since this is an “off the wall” topic, I’m going to go off the wall as a response.

Ziplinks and the new link pane that was developed alongside them are great new features for making links. They also both manage to seem mature in a way that I find a bit unbelievable given just now new they are.

Given that, I honestly wish they could be left as-is for a bit so we all have time to acclimate and explore them in their current state.

Now my off the wall thought: if TBX needs to compete in terms of “ease” or “flow” or whatever, then fiddling with zip links feels like a distraction to me. The one place where alternative software carries the day without question is in their ability to open their data and read their files without hackish workarounds on iOS/iPadOS.

Now obviously, making an overlay and making a new app aren’t comparable expenditures of time and energy. But for my part, I’d much rather see any energy that would be spent on something like this new overlay be dropped in the bank of resources that might one day go toward developing an outline-view style reader that could allow key aspects of TBX files (Outline hierarchy, $Name, $Text, …) to be viewed (not even necessarily edited) on iOS/iPadOS.


I like the idea of “Append Backlink”

Came back to find this msg from a hypertext colleague reminding me of this from Andrew Dillon’s ACM Hypertext 2010 keynote:

Pushing design in the direction of navigation ease might have stifled significant effort at enhancing the making and sharing of meaning.

This resonates for me in the context of this thread.

1 Like

It’s a horses-for-courses thing, imo. For instance, I love being helped out with guides in maps. It makes lining things up very easy, not unlike snaps and inferencing in CAD software. But sometimes it’s good having rawer techniques that give you a lot of fine control with text input. A bit like how, for me at least, it’s easier using a command line to move around a lot of files than with a GUI.

I think the most useful question a software author can ask when it comes to design is “what is the user most likely to be doing at this point, and what are the best methods to give them to accomplish this that allows the software flow with that task as much as possible?”.

To clarify, as I think my last (re last above and some DM) have been misread as applying to the narrow scope of UI design, I was referring to the overall hypertextual process that Tinderbox encapsulates…

I’m not in any way versed in the theoretical side of things, and tbh most of my exposure to it comes through using this app, with a distant second being a short, unsuccessful attempt at trying to introduce a wiki at a workplace a long time ago now.

From my end-user perspective, Tinderbox very ably allows me to capture info, classify it, link it together, retrieve it and present it. Is it fair to say that I am engaging in a hypertext process by using it to do all of the above, whether or not I consciously know it? It seems like it is, because when I try to explain the app to people they think I’m talking about a database, but it certainly doesn’t feel like a database. Is the click-through navigation (when and if you want it) the key thing?

Mark and Mark — I, for one, would be very interested to read the papers you presented at Hypertext 2020… Can you supply links? Thx

1 Like