Linkposition in mapview

[ShawnMichaels]

Hello!

Is it possible in the Mapview to determine the location of the endpoint of a link yourself?

The issue is this:

When you connect one note to another with links, the link might be hard to see or positioned in a visually awkward way, making the connection between the two notes not obvious enough. Up until now, I’ve manually adjusted the endpoints of the notes. But when you have a lot of notes, that gets really annoying because you end up focusing more on fixing the links than on the actual work.

Pictures say more than thousands words:

This is what happens, if you link note “1” with note “1.2”

But this is what it should look like:

To get this you have to repair the links start- and endpoints.

Is there a way to determine those start- and endpoints when making the link instead of repairing the start- and endpoints afterwards?

Shawn

[mwra (Mark Anderson)]

No, or not to my understanding. The location of a link’s out/in location on notes is stored in the TBX’s XML (see the sourcepad and destpad stored data here). On completing drag/drop of the link, it is generated using the default out/in [positions. These can then be repositioned manually by the user, if so desired. If a non-app-default location is set, the document remembers his, the custom edge location being stored in the document’s XML(as per the previous link).

The map’s design is not a box-and-line drawing tool such as with OmniGraffle or Visio. As such the default will suffice for most people in most cases, but the manual repositioning is offered for cases where this doesn’t suffices. In addiction the arc of the bezier curve used for the link can be varied if necessary.

So, not quite what you were hoping for.

[eastgate]

How would you express your intent to route the link from 1 ➛ 1.2 via specific edges? I suppose we could have a link widget for each edge, but that feels awfully busy….

[mwra (Mark Anderson)]

To add some underlying detail…

The default example goes from right edge (stored position #4) to top (8) but what is desired is from 4 to 6. Short of having ‘smart’ attachment points for dropped links—as used in box-and-line tools^†—it is hard to see how this can work. That still leaves the problem of the departure point of link. IIRC, in b&l tools, one drags from the centre of an edge and this is assumed to be the link (line) start. doing that seems a lot of re-engineering.

Separately…

There is a wider point to embrace here too, as has been discussed in the community a number of time over the decades. Is the point of a map to be pretty? At first sight that might seem dismissive, but isn’t meant in that vein. There is a false assumption that faux graphic design (a ‘neat’ layout) imparts more meaning to the person making the map: that transpires to not automatically be the case. Sure, if the aim is to inform others, then significant design polish might be needed, but it is fair to argue that might better be done is tool designed for that. After all Tinderbox has excellent export. Make the broad strokes of the map—the hard part, then export to a deliberate design tool like Illustrator (other similar apps are available) to do standard 2D graphic design polish. But the hard part is the first step, to inform oneself of what then needs prettifying for others. At that stage, a challenge is not prettifying (visually) before the informational intent is actually clear. I write this as someone who used to think the point was to make a pretty map: I’ve leaned otherwise

[eastgate]

I have worked hard to make the initial guesses at link anchors consistent. The underlying problem is this:

• We try to have links depart from the left or right edges, and arrive at the top or bottom edges.

• This doesn’t work when the source and destination are close together, as is the case for 1.1.

• If the layout algorithm takes distance into account, there will be some radius r such that two notes, one inside and one outside r, have different layouts.

• This is further complicated because the width and height of both notes can vary.

There might be a better way to choose anchor points, but it’s not obvious.

[ShawnMichaels]

Thank you very much for your detailed responses!

Essentially, my question has been answered: it just isn’t possible. Now I know I didn’t do anything wrong and don’t need to keep searching. Thank you so much for that!

@mwra

This helps me understand how it works. I get that Tinderbox isn’t a drawing tool, or at least it’s limited in that regard.
On the other hand, Tinderbox is a tool for representing and analyzing information, and the mapview offers a visual representation and analysis. Where Tinderbox’s scope ends and a better-suited software begins is a fluid transition and varies from project to project.

As for the “beauty” of a map, I’m basically with you on that, though there are also fluid transitions and nuances here. Because a certain level of tidiness is usually sensible in most cases to make it easy to capture information. Tidiness doesn’t mean beauty, though. A map can be very beautiful but not very helpful for capturing information. Personally, I think Tinderbox’s focus is as a personal data tool, so presentation (and thus beauty) plays a subordinate role for others. First and foremost, Tinderbox should help me as the user understand a topic. In a second step, another software can come into play.

Back to the links:

The moment the links are hidden or drawn inconsistently, it makes the visual capture/analysis of the information more difficult. So for me, this area has less to do with beauty and more to do with the core function of the Map view.

@eastgate

You asked:

How would you express your intent to route the link from 1 ➛ 1.2 via specific edges? I suppose we could have a link widget for each edge, but that feels awfully busy….

I understand that automatically connecting links is complicated. And no, a link widget sounds interesting, but I suspect it’s too fiddly for most users. Conceivable might be a toggleable link widget that’s off by default. But that wasn’t really what I was getting at.

Something else that might be conceivable:
When you draw a link, the “Create Link” window appears anyway. Here, if you want, you could additionally enter where the link’s endpoint should be. If you don’t specify the start/end point, it stays with the (current) default setting. Maybe it could be solved more discreetly, by offering this function only via a keyboard shortcut to keep the interface lean. Just an idea.

Actually, it’s not about the presumed placement of a link, because if I want to connect two existing notes, I already drag the link’s endpoint to the desired spot on the target note – which might be an answer to your question how I would express my intent to route the link from 1 ➛ 1.2 via specific edges?. This means, the information about where the link should end is already there and is communicated to Tinderbox. However, the information isn’t captured and processed.

To narrow down the problem further:
Even though one already drag the link’s endpoint to the desired location, Tinderbox ignores that desired location and determines a new – presumed – point for the link.

Whether there’s a simple, complicated, or no solution for that, I as a user can’t judge. So I can only stick to describing the problem.

I have worked hard to make the initial guesses at link anchors consistent.

I´m pretty sure about that!

Thanks!

[PaulWalters]

@eastgate

awfully busy…

… and very very edge case