I make extensive use of parent notes to give my notes a “contextual hierarchy”. I find this approach makes it easier to find notes, understand notes, rediscover old notes, and make new connections between notes.
The tree panel makes it easy to explore this “contextual hierarchy”, and to open notes to work on. However, if I’ve navigated to a note without using the tree (e.g. via the command prompt, or a link) then I don’t know how to automatically navigate the tree to that card to see its context (i.e. I have to find it myself by clicking around the tree).
An option for the UX/UI of this feature could be a “Show in tree” button in the meta-data panel (which could have a target icon), or just the target icon directly on the card itself (perhaps half-way between the share icons and the tags). I’d also suggest adding a keyboard shortcut for this command.
One challenge with this feature is that a note can have multiple “contextual hierarchies”, due to having multiple parents. I’d suggest making the “Show in tree” button navigate to each tree position in turn, in alphabetical order, upon multiple clicks. The button could show how many times this note appears in the tree with a number in a bubble (like how notes show the number of children they have), or next to the icon (as with likes, comments, and shares).
A closely related question:
I heard that “parent” cards used to be called “context” in an earlier version of Supernotes. Why was that changed to “parent”?
I ask because, for me, the entire value that parent notes give is summed up by the word “context”, so using that word feels like it should make the intent of the feature clearer for users. “Parent” feels so generic, un-opinionated, and lacking in guidance.
This is a pretty good idea, and it’s something we are building into the new-and-improved Tree that we’ve had in development for some time (as I’m sure you’ve seen from other posts around the forum). Unfortunately other things have taken priority (namely the desktop and mobile apps), so that new Tree is still very much under construction.
However this feature is a fairly straightforward part of it, so it might be something we can backport to the existing Tree system. We will take a look and see what we can do.
As for context vs. parent – yep, the original name we had when you opened a card was to say that card was now a “context”. Unfortunately some users were getting confused as to how a context was different from a card, when they’re really just the same thing. While more generic, we have found that the term “parent” has caused less confusion. You start with a card, and when you add cards to it, it is now a “parent” card.
Thanks for your reply. I figured that you and Tobias might have thought of this idea before (it seems like you’re always ahead of the game when it comes to feature ideas! )
On the back porting vs. new Tree decision, obviously you’re in the best position to make that call. My only input would be that, personally, I’d prefer to get a shiny new Tree faster, rather than you spending time adding features to the old Tree. However, if there’s a way to build this “navigate tree to current note” feature where most of the UX/UI design and even most of the code won’t need to be redone, then the back port idea makes sense. Especially if the new Tree is still a long way off.
Your reasoning for switching from “context” to “parent” also makes sense. I can see how “Add Context” isn’t as clear on what’s being added, compared to “Add Parent”, which makes the “type” of thing being added (i.e. a notecard) much clearer. It also gives you the “Child” concept for free, as parent-child is a two-way relationship in a way that context isn’t. Thanks for explaining your thinking.
I’ve been thinking some more about this idea and wondering if “show in tree” should just happen automatically whenever a notecard is opened in the Noteboard (or any of the other upcoming main views).
Perhaps with an option to disable this for those who want to keep the current “static” tree behaviour?
Good point @JamesT! Automatic “show in tree” is probably the most logical solution, although there may be some edge cases where someone might want to navigate up and down the hierarchy and have a static tree (such as for drag and drop organisation). We’ve added this as a todo in one of the upcoming updates
)