I think I’m doing something wrong. When I add connected notes, sometimes the connecting line attaches in the correct place (roughly, the center of the end to which the line connects). At other times, the line attaches close to the button or even slightly toward the middle bottom. I’ve attached an example. I’m sure I’m doing something wrong, but can’t figure out what it is. Any help is appreciated. Thanks!
Science at the Frontiers copy.scap (7.02 KB)
Everything looks okay to me when I open up this file. The attachment point for notes is in the middle of the note, vertically and horizontally speaking, not along any of the edges.
This placement of the connector ends has been a long standing concern of mine. When you have a long set of destination nodes, the connectors actually cross over the nodes that are closer to the source node. Connecting to the adjacent ends of the source and destination nodes would make the diagrams more readable.
We played with a model that used the edges, but it didn’t work out perfectly and was just adding clutter, so it was removed for 1.0 and the idea deferred for a later release. We have it on the list to look at again when there is more time to give it the proper treatment it deserves.
Does “due time” mean weeks, months or years? I would like my documents to look better soon.
I can’t even say if there will be changes made to how this works, let alone when. I just wanted to let you know it is something we haven’t outright rejected.
Can’t see any change over the last months in how connectors can be drawn from one node to another. Still looks like the only option is middle to middle with no edge to edge options so the connectors do not cross over or under other nodes in a list of nodes
If there is a software update it will be published on the website and you may get an alert within the software or through the Mac App Store, with an accompanying change log showing what has been added or fixed.
How much development effort is going into Scapple?
I really like the free form features in Scapple. I just would like a little more personal control over how the connectors are drawn. A previous reply indicated the developers had implemented something like I would like to try but it was removed from the production version. It seems like it could be an option.
Once we get Scrivener through another release cycle the plan is to look at Scapple again, but I can’t say when that will be as there are two pretty large variables in that equations—I’d also stress as before that I can’t say this feature will ever make the cut. It’s the sort of “fiddly” thing the software was designed to avoid, so really it depends upon whether an implementation that stays out of the way can be found that makes sense.
It might be “fiddly” from a developer’s viewpoint, but I feel it is important from my user’s viewpoint as it would make my diagrams much more obvious and easier to read when connection lines go directly to their destinations and do not disappear behind other nodes.
Do you have a means for users to make comments on the changes that could be included in the next version?
As for the rest, I haven’t made myself clear: it was the user interface that was inelegant and fiddly, that is why it was removed. I’m not speaking from a standpoint of the source code, but how you would have had to have used the feature if we had left it in. It wasn’t adding enough to the overall design, and not achieving the goals you desire, to merit the added complexity to the interface.
You’re already speaking with the right person for that. 
I have this stuff all in my notes, as well a few design ideas that would not only address what you are speaking of, but several others usages as well. We may be slow (we aren’t a huge software company and we want to get things right rather than spray and pray), but we do listen.
Thanks for the more complete description of why the feature is not available now. I can hope one of your options make it into Scapple.
Ooops. I see I should have posted in this thread — just left a rambly post in the Beta forum Features Wish List thread.
Great to have an explanation Amber: thank you, and glad to know you guys are at least thinking about this issue! I’ve just been trying out Scapple for the first time and struggling with the same problem as Tom: viz. connectors popping out of the top/bottom of notes when any thinking human could see they need to emerge from the sides to be at all visible! Not criticising the ‘AI’ here : ) Just urging the thought that letting users control this particular aspect is really important — for me, it comes close to making this otherwise fabulous program useless!
Example: I want to do something simple — line up a bunch of notes in a neat stack/column and then draw a bunch of criss-crossing connections to a second column of notes on their right. I need the notes to stay stacked (their original order is an important part of my brainstorming), but I want to show their interconnections. You or I would just draw lines from edge to edge across the gap. Presto! Simple and visible. Scapple insists on connecting the notes through their tops/bottoms with the result that you can’t see what’s connected to what — intervening notes totally obscure the lines!
Couldn’t you just assign notes an additional parameter which users could select: ‘connect via top/bottom’ v ‘connect via sides’? The default setting could remain the centre node, but there would be this possible override where needed. Nothing fancy involving specifying exact anchor points (I can see how that might complicate the UI) — the connections are automatically drawn from the centre point of the edge — but at least you would avoid absurdities like the one I’ve described above…
BTW, I do understand why Scapple hasn’t got much attention lately — you guys have been doing an amazing job with all the epic updates to Scrivener! But thought I’d log this thought with you folks while I think of it, for when you do return to it. You’ve got a terrific application in Scapple; just needs a bit of fine-tuning…
Yeah I guess the idea there is that if the notes are in a stack then they are already implicitly connected to one another by virtue of sharing that common grouping mechanism.
That aside, I would think that even if the connection line went from the side it will still be messy, because they would all then be overlapping each other on the same “rail” alongside the stack, if that makes sense. Sure you might connect two on the left and another two on the right, but it’s still pretty limited in that there are only two sides to work with. I guess another way of putting it would be that this wouldn’t solve a visual issue of drawing connection lines between stacked notes, it would merely move that issue from one side to another. Right now all of the lines overlap in the middle—putting them on the sides would just overlap them on the sides.
[size=80]On the left: is the top connected to 2 and 3 or just 3? On the right, we can barely even see that 1 and 2 are connected.[/size]
I guess overall I don’t know if choosing where the connection line attaches to the note is ever going to make much sense of connecting notes so very close to each other all stacked in a column like that. Again, that they are in a stack is meant to imply they are connected already.
Thanks for the words of encouragement. We’ve got some huge updates to Scrivener in the pipeline, lots of exciting things to share there in time, but we’ll get to Scapple again too.
Aha. I think I’ve been unclear here: sorry! It’s very hard to talk about these things w/out pictures! Thank you for putting your graphic in — I should have put one into my own post, but alas have forgotten how to upload images into phpBB…
Let me try to clarify: I’m not trying to draw connectors between items in the SAME stack. As you observe, it’s redundant: they’re already ‘connected’ by virtue of being lined up into a sort of list. And it is indeed hard to see how you could draw lines between stacked items which are visually illuminating — even with the full freedom of pen and paper!
What I want to do (and seems to me Scapple could usefully support) is something else: to draw connections between two different stacked lists. That is, to visually mark the correlation between (say) item 1 in column A and item 6 in column B.
(column A)[list][list][list][list][list][list](column B)[/list:u][/list:u][/list:u][/list:u][/list:u][/list:u]
Item 1 text text text text text[list][list][list][list][list]Item 1 more text more more more[/list:u][/list:u][/list:u][/list:u][/list:u]
Item 2 text text text text text[list][list][list][list][list]Item 2 more text more more more[/list:u][/list:u][/list:u][/list:u][/list:u]
Item 3 text text text text text[list][list][list][list][list]Item 3 more text more more more[/list:u][/list:u][/list:u][/list:u][/list:u]
Item 4 text text text text text[list][list][list][list][list]Item 4 more text more more more [/list:u][/list:u][/list:u][/list:u][/list:u]
Item 5 text text text text text[list][list][list][list][list]Item 5 more text more more more[/list:u][/list:u][/list:u][/list:u][/list:u]
Item 6 text text text text text[list][list][list][list][list]Item 6 more text more more more[/list:u][/list:u][/list:u][/list:u][/list:u]
The problem here is one of angles: if you are connecting two items that are more or less level with one another, the connector will emerge from the sides of the appropriate items. That is, the line will actually LOOK like it is connecting them! But if the connection runs at a sharp angle, from the top of one stack to the bottom of the other, the geometry will make the line appear to connect two other items, located closer to the middle of the stacks.
My thought was that the simplest way of getting round this was just to give users the option of forcing the lines to be drawn from side/bottom/top where desired, rather than the middle of the text box. To keep things simple, the precise anchor point could still be mandated by the program (presumably the centre point of the side). But this modification would make it possible to construct much denser sketches than is currently possible, and to take real advantage of the stacking feature.
To put it another way, at the moment Scapple is chiefly aimed at the very first, wild, totally freeform brainstorming of ideas across a wide canvas, where there’s plenty of room for connectors to stretch out. But with a few modifications, seems like it could also cater to the next stage of mental organization, where you try to marshal your first doodled thoughts into some kind of logical order — in which the sorting of things into stacks and lists, while maintaining the connections between them becomes important. Think of it as a sort of intermediate phase between the napkin doodle and an actual outline (when one moves to Scrivener!). Not sure if this is an aspect you’re interested in pursuing, but I hope so — it would vastly expand Scapple’s usefulness as a brainstorming tool!
In case you are…I hope you don’t mind my taking the liberty of suggesting a few key improvements to that end:
a) allowing users to specify which edge connections are anchored to.
b) allowing users to specify whether connection lines are drawn OVER or UNDER any intervening boxes. (Sometimes the connector is more important to see than every last letter of the text it crosses!).
c) providing a simple Group/Ungroup function, so users can manually group together text boxes they want to move around together. I know you can do this via magnetic background shapes or connectors, but honestly sometimes that feels like a very long way round just to be able to manipulate boxes in a simple intuitive way like any drawing program would do…
Just some ideas to file away for when Scapple floats to the top of the pile again! And thank you again for your patience with all my queries. Scrivener does have a way of producing enthusiasts, doesn’t it? 
I would like to advocate for the resuscitation of the “nearest-corner” connection preference.
There really does need to be a “nearest corner” option for how connections are made. The current mode which always targets the middle of the node makes maps of even just moderate complexity visually unresolvable – one must move nodes around to discern which node is actually connected to which. I find this true in every serious use I have made of Scapple. A nearest-corner preference would resolve such visual ambiguity in the main.
An app or document preference for nearest-corner would be great. Even if you had to neutralize certain frills (rounded, cloud, blat corners) for this option, it would be entirely worth it, imho.
So, I hope the nearest-corner project gets back on the Scapple development list.
-gr
p.s. Perhaps one would need to hold that there are five possible points of contact - four corners and the middle (this last being desirable for columnar arrangements, for example). Couldn’t help but puzzle about what an algorithm for resolving the corner choice would be – sort of a two body problem. Does a two-pass system unfailingly get the right pairing? My intuition suggested this procedure: Start at middle of node #1, calculate which of the five hotspots of #2 is closest to that. Choose that hotspot on #2. Then in a second pass calculate which of the five hotspots on #1 is closest to the chosen spot on #2. Seems sort of sensible, but I couldn’t figure what a crucial test case might be. Okay, I am getting out my compass and straight-edge… Don’t make me come over there!
I disagree. That would make the connection point jump around when you move an item. With more complexity comes more problems, not less.
Which is why this would be an “app or document preference” so that users who understand the implications can use it and those who don’t are not forced to.
Lunk, thanks for this. I appreciate your pitching in to help think about this. I would like to distinguish between 1) the goal of making more discernible what is connected to what and 2) how this might be achieved. I am not hearing any disagreement about point (1), so maybe we agree on the goodness of that (if not also its importance).
Your point seems to be a concern about implementation. Undue or disconcerting jumpiness seems like a valid thing to worry about. I don’t pretend to know how to implement anything, but you may have seen better into the implications of the little extracurricular sketch I made of an algorithm. For my own part, it is not intuitively obvious to me that the sort of procedure I sketched would make unhappy jumpiness, just as I was uncertain if it would pick the intuitively correct corner to cleave to. But maybe it would.
Just as a thought experiment, let’s try to imagine an implementation that would mute any concern you have. Devinganger is right, if it is a Preference you personally need not be “concerned”. But at the same time, we should also be interested in someone with your same concern who also really wants to be able to better visually resolve what is connected to what. (For all I know, I might be such a one!) So, how could we achieve the benefit of corner cleaving without undo jumpiness?
Consider: First, let’s note that the visual connection point (point of incidence) on a node moves around when you move things already, because the incidence point of the connection line slides along the frame when you move either node. Now, imagine the target of connection remains dead center, but we “magnetize” the corners, so when the incident point gets close enough to a corner it snaps to it. Magnetization of zero gives you the equivalent of how Scapple works now. Magnetization of 100% gives you the equivalent of the suggestion as I first posed it (always snap). Now just imagine we set the magnetization level to the highest strength that you would still be comfortable with. Assuming that level is not zero,* you (or the doppelganger of you we are imagining) now get (some of) the benefit of corner attachment but can mitigate any level of jumpiness you might find disconcerting. And maybe it would even turn out there is a mag level which could be set that would be pleasing to all!
Again, it is not intuitively obvious to me that there would be disconcerting jumpiness in connections on the earlier initial picture. But it just may be useful to demonstrate to our favorite developers that there would be (even if so) reasonable ways to achieve better visual discernment via some kind of corner-cleaving algorithm.
I will be happy just to get the corner-connection Wish back on the table.
Best,
gr
- Surely there is a sweet spot there even for your most obstreperous evil twin!