Link title, not link type?

(Tianrui Niu) #1

Hi there,

I’m a college student and I use Tinderbox to manage my note of thesis and my workspace, which means tracking the Git repo of my codes, write down some notes and ideas for each experiment I’ve performed. My experience if TB is fantastic.
I always use Link to connect each version of my code(note) and sometimes I want those links to carry more informations, like how the bug is fixed. And I want that information to be rendered directly on the Map view so I can tell how the update flow goes when I’m staring at them. Like this:

This was done by setting the text “Bugfix: reshape the Tensor at input of CNN” as the link type, which creates a new link type for the entire document. But instead, I don’t want that new type be created, because I always think that too many link types causes slow loading time for links. Besides, it’s also hard for agents to trace them. I only want a link type of Bugfix of which the title or content is “reshape the Tensor at input of CNN”.
Any ideas about this? Many thanks for your attention.


(Mark Anderson) #2

There is no such functionality as you describe. The labels on links are the link type. To have a different label you need a different type.

The link types allows different types of linkage to be illustrated and analysed. They weren’t intended as a a per-link annotation, thus the status quo. An alternate method might be to put that label, i.e. “bugfix…”, as the (beginning of) the $Text of the later note and to display that text on the note icon. Notes can show body text.

(Tianrui Niu) #3

Thanks for your reply.

Well in that case, I’d vote for this feature :smile: Because it’s always natural in many other Apps, like Scapple, to create titles for links. Link titles can provide more informations to display, it’s really useful for me.

Yeah I agree that this is a working bypass and I’ve used that method for a long time. However, the experience is no good, for I have to create another note, write down the informations and scale that note to show the entire content. That’s quite inconvenient.

Managing link attributes to document strength of relationship between notes
(Mark Anderson) #4

If so, don’t forget to mail it in as this is just the user to user forum. Make sure to add your use case.

Do bear in mind this isn’t an illustration app. Having attributes on links, whilst visually useful does affect the overall app design. Are they objects, as are notes, or—as at present—a separate table of associations between objects (albeit with some visually prettification in Maps).

Scapple isn’t a comparison. It looks a bit like Tinderbox, precisely because it drew on them as a design model but the comparison then fails. Scapple has no nesting or links. Scapple’s links are visual lines drawn between objects and don’t AFAICT have any hypertextual significance. Omnigraffle would be a closer comparator for Scapple in the context you describe.

(eastgate) #5

Another approach might be to represent the fix description as a note:

This has some real advantages.

  1. You can describe the fix in as much detail as you need.
  2. You can link to and from the fix. For example, the last time I actually used a tensor myself was in undergraduate General Relativity, and I don’t recall just what reshaping a tensor would be.
  3. Agents can search for bug fixes than mention tensors.
  4. Bugfixes could then have attributes,

That said, Tianrui Niu raises a discussion I’ve been having with Rosemary Simpson (designer of Lisp Machine’s pioneering hypertext system Gateway) for decades. Simpson believes that links should be first class objects — in essence, a kind of note. That was actually the key behind Halasz and Marshall’s Aquanet, a system to which Tinderbox today acknowledges many debts.

Tinderbox’s immediate inspiration, VIKI, was designed in reaction against Aquanet and its formalisms, and Tinderbox was originally conceived as a tiny VIKI that could escape the laboratory. So, negotiating these two irreconcilable visions is a tricky negotiation.

At the extreme pragmatic end of the spectrum, too, things aren’t easy. Once maps become moderately complex, it becomes tricky to find ways to place the labels so they’re legible. Tinderbox today is quite naive in its efforts at label placement; we’ve actually invested quite a bit of work in that area, and it’s always been a pain in the neck. (The underlying layout problem is NP-hard for most plausible measures of label placement. That means it’s one of the large class of problems that are computationally intractable if you really want the right answer.)

So, that’s the story of the current status quo. Stay tuned! Always happy to learn of new references (I know the literature fairly well but there’s always new stuff and there’s always a dusty corner to revisit) and new approaches.

(Tianrui Niu) #6

Thanks for your in-depth discussion. That brings me some early research of knowledge management. I’ve only thought about this problem as wether to add an attribute to the link object, and cared nothing about the design model behind the software. Your answer has lifted the problem into a higher point of view, quite illuminating.
So, with also the answer of @mwra, we can conclude here that it’s in fact not easy to place link titles, on that the first reason is TB inherits the model of VIKI, an early spatial hypertext system, of whose the design principle does not treat links as 1st class object, thus it’s not trivial to add an attribute like “title” to it. The second reason is that finding the correct place to render the title (or, label) is NP-hard, it’s difficult to compute the best place to render.
Thanks for all of your discussions here. I’d like to see TB to grow faster and more robust. If this feature is too hard to implement and may lag your development process, I’d rather use the walk-around method :sunglasses:.