Aggregate / Summary / TOC Cards

As SuperNotes allows for arbitrary hierarchy of cards, it’s rather common for me to have “empty” cards and store most information in child cards.

When a card body is empty, it would be great if SuperNotes could display a index, summary, or aggregation of the cards below instead.

7 Likes

Oddly enough I quite like parent cards like this to be empty, so I would love to be able to leave them blank like today.

Maybe there could be some Markdown syntax that you could put in the parent card that changes into a ToC? That way you could optionally enable this functionality on a card by card basis.

2 Likes

Cool idea. This probably makes sense as a “Card Type” (once those are introduced). That way it is up to the user whether they want the parent card to be a normal “content card” or a “TOC card”.

6 Likes

I think it would be useful to be able to mark a parent card as a table of contents card so that all child cards appear in the contents of the parent as a dynamically updated list sortable by any current sorting means.

5 Likes

What’s the advantage over current sidebar hierarchy?

1 Like

I think @austinjaney’s idea is a great one. Currently it seems (at least, using Firefox) that if a parent card is in the sidebar/table of contents bar, it’s children will only appear in the fold down menu once you have gone into the child card (by which I mean, opened it as a parent, even if it’s childless.) It would be really useful to be able to see a summary or a snapshot of cards within the top level cards one sees in the table of contents.

Secondly, I’ve just been doing some reorganising: putting lots of cards in others, then making them “visible” rather than “priority” so that they no longer appear in the sidebar.

  1. I found this a little buggy. The visibility status of the cards were frequently sticky, or would show themselves as “visible” even if they were showing in the sidebar (so should have been “priority”).
  2. Child cards remained priority even when I made their parent not-priority. As I’ve said a few times, this generates a big hassle.

Still really enjoying Supernotes and looking forward to new updates :slight_smile:

1 Like

I usually organize my notes systematically, forming a hierarchy.

As you can see in Supernotes’ graph view, notes form a tree structure. There are cases where there is content in the middle of the tree, but there are many cases where it is not.
In this case, I have to look at a completely empty note on my way to a particular note from the Outline, and this experience does not help me find the information I want, but it also puts pressure on me to write something down in the middle note.

If there is a function to take and show the contents of the child note(s) when a note has only title and no body but its child note(s) exists, I think it will significantly help eliminate the pressure or disappointing experience above! :smiley:

I am exploring SuperNotes for Zettelkasten. What if Parent Cards automatically included an linked index to the child cards. Need only be one level deep to be useful but multilevel may be even more useful. They would then form Structure or Index zettels.

1 Like

Hi @ancall,

Thanks for your feature request, I’ve moved your topic “Parent Cards include automatic linked index to child cards” to this existing thread about having a table of contents (TOC) within a parent card.

Previously we’ve marked this thread as “Out of Scope” since we’ve been focusing on making the Outline in the sidebar be this “index” – you can use CMD / CTRL + SHIFT + O when focused on a card to quickly zoom into to the relevant part.

However since there’s been quite a lot of requests for an index of child cards to be directly part of a parent card, so I’ve re-categorised this as “Under Consideration” and we will look into a way to potentially support this in the future.

First thing that comes to mind is an implementation of a TOC as a dedicated noteboard view. This way it would integrate nicely in the current architecture, i. e. it is easily filterable/sortable. Would that make sense?

1 Like

I think you’re definitely right @freisatz about integrating it with the current interface so it feels seamless and helpful – rather than just adding it in.

One thought we’ve previously had was to add a list of all the child cards of a card underneath a card in preview, almost like backlinks, so it would be super easy to get to and always be helpful. We could also repurpose the “backlinks” draw to be related cards that has backlinks at the top and all the children underneath. Some food for thought, if any of these ideas feel right to you for your workflow do let us know :slight_smile:

I think you guys need to decide what the abstraction needs to be.

The typical idea of an outline forms a tree

Supernotes allows >= 1 parent, which IMHO is great, so that forms a DAG, normally. I said “normally” because the normal parent-child relationship does not allow circuits/cycles, but apparently Supernotes does (perhaps unintentionally) and consequently gets a little bit confused when it tries to present the hierarchy in “Outline”. Outside of this anomaly, it is hard to present a DAG in a tree.

Links and backlinks are two different types of arc, and I believe that is what “View as Graph” tries to show, and conceptually, I don’t see any reason why circuits/cycles cannot be formed.

At the moment, I’m afraid that I cannot offer my opinion on what I think the abstraction needs to be as I’m still pondering on it.

Just a precedence as you ponder on the abstraction: Google Drive used to support multiple parents, but it dropped that feature in favor of the more familiar shortcuts in 2020-09.

There are some very subtle ramifications in the Google Drive’s multiple parents approach (e.g., the file name stays the same) that at the end of the day, Google decided that it is not worth it for a “file system”.

In contrast, it is very natural for a VCS commit to have multiple parents, but time only goes one way in a VCS.

I know “Multi-parent Nesting” is a feature in Supernotes, but there are different ways for a card to show up at different places.

I think it is a matter of card structure vs. citation (i.e., link/backlink).