Map view and hyperbolic view allow you to drag a link onto the background and make a new note. In Map view if you make a text selection and drag from the text pane link park to the map background that makes a new note with a text link from the first note.
This explains another disconnect. Most people tend to only think of the app from a single input perspective. To the ardent typist everything is/should be a key input so the link drag method gets boos. To the ordinary typist, most of the extended syntax of ziplinks doesn’t help as the menu closes or auto-finishes in odd ways if—as may be natural—mouse and key inputs are mixed. Some folk can’t do without RTF, others want only plain text, etc.
I think that unpicks the point about making implied links, i.e. wiki-type
[[ link mark-up for a note/agent not yet made. That makes some sense in a wiki, as it has no index or hierarchy and only the links you give it. The ‘red link’ is a wiki affordance to get around the fact you can’t see what isn’t yet there and in fact you can’t ‘see’ it at all as you only view a single page at a time.
Tinderbox has all sorts views that means if you need a note you can easily link to it or add new linked content. This leads to the next aspect of such branching work: new (side) notes are “too time consuming” “break the flow”, etc. I’ve heard the debate many times over in the forums and whilst I’m all for everyone following their own style, some of these justifications about how a feature ‘must’ work seem a bit post hoc and instead more readily reflect where people previously did their work. The tools we use shape our perceptions, make us productive where we embrace them, yet also blind us as to other possible approaches. We then invest as much/more time justifying our acquired assumptions than we do learning [sic] things that might help. Thus, at times the forum feels like working in a cheese shop where the customer only ever wants to buy fish, and despite the sign over the door saying ‘cheese’ they are sure there is fish but it’s just being hidden from them.
Habits are hard to break!
I think the ‘maturation’ of granularity and abstraction goes like this:
- Titles used as text (i.e. very long titles)
- Discover there is $Text. Now try shorter titles and lots of text. But, everything becomes a text search (regular expression, for granular search work are not easy to master).
- Other apps have ‘tags’ Yay, Tinderbox has $Tags too! Now we start putting various bits of info into $Tags. Now all the tags are in one (per note) un-segmented tag bucket. Again, searching becomes as much about excluding false positives as things finding things we want. Do your tags on Ovid or patient diagnosis need to use the same bucket as your grocery to-do? Probably not. If only…
- Aha! User attributes. Now discrete strands of tags can ‘live’ in discrete buckets, even if we just treat them as tags. Master Yoda nods approvingly.
Cool result. With the last step new achievements are unlocked in your Tinderbox usage development tree:
- Now we have scope for much more targetted search, as we can target just one attribute (or more if we choose) rather than the bigger target of all $Tags or all of $Text.
- With information in these user attributes, they are more easily showing in Displayed Attributes (i.e. attributes displayed in a note’s text pane), or shown in column view (in Outlines and Attribute Browser (AB) view), and can be used to fine tune things like AB view or Crosstabs view.
Yet, no one has to use all these features. If just making notes on a map with no $Text works, then it’s likely good enough! But for those who want or need it, more depth is on offer.