Tinderbox Forum

Roam, Zettels, and Zips: a different approach

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

What if [[ invoked the current ziplink process, and [[[ invoked Mark B 's ziplink+dialogue box proposal?


@beck, just wanted to thank you for this very helpful idea, I really appreciate it.


Echoing some of the other comments, I’d appreciate the option of a dialog or some other UI support. I’m not very good at learning/remembering multiple variations of syntax, and my work styles don’t include sufficient persistent repetition for them to stick firmly.

1 Like

@Ejspark in answer to your question:

  • “Bad Character: Who do We Want our Hypertexts to Be?” by Mark Bernstein. Paper, slides.
  • “Docuverse Despatch: Information Farming for the Collective” by Mark Anderson. Paper, slides.

FWIW, both papers were in the ‘Blue Sky’ track so observation pieces rather than primary research. The 31 years of the ACM Hypertext conference (in the ACM Digital Library) do have a wealth of papers on/about hypertext from the purely technical through to the creative/literary side.

Unless directly related to this and to avoid thread drift, if there are questions relating to the above papers I’d suggest raising them in a new thread. :slight_smile: I may yet split out your post and my reply into a new thread.

Thanks so much. I look forward to digging into these. We’ll see if a new thread is born… :wink:

1 Like

Second, thank you Beck. Extremely useful.

1 Like

Agreed. I my opinion, the beauty of wikilinks is the speed of creation and no dialog box/form to break the flow.

I like this. Offer us the the option to have Append Backlink by default checked or unchecked. Then we have choice.

For what its worth, it seems that Workflowy has jumped on the bidirectional bandwagon. Although it is not available yet, I have read in several places they are working on it. It might be interesting to see how it gets implemented.

I hope it is more than that a done for a reason other than trends. The years beards for men are popular in the West. nest year? Who knows.

The real point seems affordances for traversal of a link rather than whether it is—or has the appearance of—directionality. Were weto bother to look at the TBX data structure we would see Tinderbox actually uses a linkbase, at risk of using pre-Web terminology. Each link is essentially defines as being between two $IDs.

So I think the real question is can two-way traversal affordances be increased without either breaking significant current use or engineering at scale with poor ROI? As a long term user who has used this app for serious work since the mid-2000s I’d hate to see functionality broken on the altar of fashion. Actually, I don’t see both end points as antipathetical but I would urge caution in rushing to follow fashion. Beards may be ‘out’ by next year.

I’ll get my coat…

No worries.

I believe I have read every published research paper in the literature that impinges on link directionality, as well as a good number that were never published. I have also read deeply in (and contributed a bit to) the literature on link structure and hypertext rhetoric, which is (after all) the study of how to use links to make meaning.

This isn’t a question of fashion.