I’m a user who likes to be able to use keyboard shortcuts rather than have to do everything with the mouse. Specifically, I would like to be able to navigate the connections between notes using the arrow keys or similar. While I recognise that notes are not always arranged “hierarchically”, i.e. with one central note linked to sub-notes and these in turn connected to sub-sub-notes; often, a significant portion of the notes on a Scapple canvas are organised in this way. Within these sections, I would find it very helpful to be able to navigate “up” (to the higher-level note) with the “up” arrow key, to siblings using the “left” and “right” arrow keys, and to a daughter using the “down” arrow key (doesn’t matter so much which daughter, since I can then use “left” and “right” to move to the right one).
At present the behaviour does not correspond to this, and using the arrow keys leads to the active note jumping about the canvas wildly.
Would it be possible to introduce this form of shortcut-based navigation, at least as an option?
Best regards,
James Denman
The current behaviour is directional, or the best that it can do with what may at times have a chaotic answer to what is “next to the right”. Stacks are the only thing that have a special programmed behaviour, because those are quite logical.
Connections though? Granted, I understand you have chosen to use connections draw a picture of something that a human mind might interpret as hierarchical, but there is nothing like that in the software at a code level, and for there to be, we’d have to throw out a lot of what Scapple is. I think it would just take too much narrowing down of the software to say that “up” means “higher level” instead of “up”, and thus sometimes select down or even right, depending on which side of the cluster you are on. For example, we’d have to remove from you the ability to connect one note to two different notes in the “higher level” direction, and connections between siblings would no longer make sense. Indeed, freely connecting anything at all would not be possible, otherwise there would cease to be one logical arrow key response to what is “higher”, what is “previous sibling”, etc. For those concepts to have answers in a machine logic sense, you need extremely strict rules that the software forces you to follow.
I do this with the help of Keyboard Maestro. For instance, the palette you see here. It’s for mouse-clicks, but any menu item can also be reached by a keyboard shortcut with KM or just using System Preferences▸Keyboard▸Shortcuts on the Mac.
Thanks for your answer. If I’m understanding you correctly, you’re describing the possibility of additional keyboard shortcuts to access existing but exclusively mouse-driven Scapple menu items. Thanks for the tip, but that isn’t actually what I’m aiming for: the navigation I would like to be able to do is not available as a menu item in Scapple either by mouse or by keyboard; so it requires additional Scapple functionality, rather than just expanded access to existing functionality. Or have I misunderstood you?
Thank you for your very swift and comprehensive answer!
I get your point, though I think that the objections you raise are resolvable and that it is worth doing something in this respect.
How might the objections you raise be resolved?
Version 1 would be to handle the “narrow” case of a “tree” of nodes with only unique routes between the nodes, i.e. no “cross-links” between branches. I accept that many Scapple users do not adhere to this restriction, but a perhaps significant subset does, and for them this could prove useful. On the basis of this assumption:
it would be computationally easy to:
iterate out from the current note via the existing connections, assigning a number to each note denoting the “distance” from the current note (i.e. a neighbouring note would have distance 1, a note connected to a neighbouring note would have distance 2, etc.). This would obviously only cover those notes connected by connections to the current note; the Scapple canvas might contain other notes unconnected (directly or indirectly) to the current note, and that’s OK that they wouldn’t be involved in this process.
(if a note already has a number because it can be reached by a different route, then this would be a signal that the assumption of “only unique routes” does not apply and that the function can be declared as “not available” - that’s OK too)
the user would need a possibility of defining which the “central” note is, either via a UI option to define a flag “this is a ‘central’ note”, or perhaps via a defined starting text in the note (e.g. “+”, or something user-defined)
then the “distance numbers” attached to the notes could be modified: “modified distance of note” = ABS(“distance of note” - “distance of central note”)
…and then there would be a navigable hierarchy
Version 2 would be to take the “broader” case of collections of connected Scapple notes which do not respect the constraint that there may only be one route between two given notes. Then the arrow-key navigation functionality could for example offer:
movement only along connections
“up” arrow key moves to leftmost of connected notes which are higher than the current note; subsequent “left” or “right” arrow keys cycle within the set of notes which were higher than and connected to the note which was selected at the time the “up” arrow key was pressed
“left” arrow key moves to uppermost of connected notes which are to the left of the current note; subsequent “up” or “down” arrow keys cycle within the set of notes which were to the left of and connected to the note which was selected at the time the “left” arrow key was pressed
some fine-tuning is probably worthwhile, e.g. restraining the definition of “up” to an arc of less than 180 degrees (but probably more than 90 degrees) above the current note, to prevent a connected note e.g. to the left of but 1 pixel higher being counted as “above”; and allowing the user to switch between “cycling between set of notes above/to the left of previously selected note” and “continuing to navigate”
Why do I think that it is worth doing something in this respect? Because in the “usefulness” hierarchy of keyboard shortcuts, the arrow keys are high-value shortcuts: they are familiar to users and users have an intuitive understanding of what “up”, “down”, “left” and “right” should do. And yet: currently in Scapple they produce an almost-random result: any Scapple canvas filled in two dimensions with notes will cause the use of the arrow keys to produce wild jumping around between entirely different regions of the canvas, which in most cases is a more disturbing than useful behaviour. And because the ability to navigate a network of nodes sure would be handy for those users (and they’re always a relevant contingent) who prefer the ability to use keyboard shortcuts rather than having to revert to the mouse.
…just one more idea, @AmberV : to “cycle through” alternatives after using the arrow keys to navigate, the spacebar could be a valid key (and if the current note hadn’t been reached via arrow key navigation, then the spacebar would remain functionless as at present)
