Inferred hierarchy from Heading size

Jay

This gives you all the benefits of indenting without having to indent. So you can just create a Heading and put some items below it, and then filtering will treat it as if they’re children, and the Heading will be collapsible. But if the item below a Heading is indented, it will cancel that behavior and just work as an indented outline. Of course the existing outline behavior won’t change at all, and with normal outline indenting you shouldn’t see this change anything. The idea is that it would be more approachable for non-outliner people, and I personally find it more comfortable in some situations to write content like a document instead of an outline.

It’s currently an option in the General section of settings if you have “Test beta features” enabled. I would love to know what you think!

# Heading 1
Child
## Heading 2
Sub child

Works the same as:

# Heading
	Child
	## Heading 2
		Sub child

WillLE

Jay, currently, I see (on web app) that

# Heading 1
Text under  Heading 1
## Heading 2
Text under  Heading 2

is not equivalent to

# Heading 1
    Text under  Heading 1
    ## Heading 2
        Text under  Heading 2

because the breadcrumb/path of ## Heading 2 is Root > ## Heading 2 instead of Root > # Heading 1 > ## Heading 2. And when I move some item to a heading, e.g. move Moved item to # Heading 1, it doesn’t go below Text under Heading 2 nor below Text under Heading 1, but goes directly to right below # Heading 1 with indentation, like this:

# Heading 1
    Moved item
Text under  Heading 1
## Heading 2
Text under  Heading 2

Inspecting the exported JSON, I see clearly that # Heading 1 has only one child, Moved item, while all other items, like Text under Heading 1 and ## Heading 2, are still children of the Root item.
==> So, the “inferred hierarchy” is just a “fake” hierarchy! Currently, it seems just “cheat” in folding algorithm 🫣!

I think headings should have real hierarchy, and the unindented display of headings’ children are just a matter of (default) style, like studgeek suggested. In that way, their behavior will be consistent, unlike the current status of inconsistency (when copy, cut, move, in breadcrumb, in display style, etc.).

To be consistent, all headings should have highest order in the hierarchy, i.e. headings cannot be children of non-heading items.

Let’s define order with a natural number N, with #1 is the highest (visible) order, actually Root = #0 is the highest, but invisible. Heading 1 = #1,… heading 6 = #6, non-heading items = #7+.
When editing, adding a heading #N (order N) will puts it under the heading #M for M closest to N such that N > M.
When moving a heading #N under an item iM of order M, don’t simply set #N a child of iM, but must check if N > M. If N <= M, then #N must be reduced order (increased value) to #{M+1}, i.e. it can be reduced to non-heading (#7+) when moved under a non-heading item.
When Tab/Shift Tab, the heading level can be easily adjusted, even no indentation change appears (in default style). With Shift Tab, we can promote a non-heading to H6 right from the left margin (no indent in default style).
Then, Ctrl Shift H is used for quickly set heading at a right level, i.e. #{M+1} under the last heading #M above, instead of H1.

Currently, a heading when moved under a bullet item still keeps its heading level. This is very inconsistent, not only about logic, but also about visual appearance!
Before Alt-M to move Heading under plain text:

After Alt-M to move Heading under plain text:

Moreover, I think that there should be some indicator for the level of heading, which only shown at mouse/caret focus, to make it clear. Currently, even with the option “Show markdown formatting”, there’s no way to know exactly which level a heading is. Some thing like this:

Jay

FYI I’m seeing some bugs with items appearing to be reordered when an H4 is between two H3s in inferred hierarchy. I’m working on it and it will be fixed in the next update.

Jay

That bug is now fixed and the feature seems to be working well for me now. Has anyone had a chance to try it? I’m very curious to hear what people think!

Jay

I’ve been working on rearranging the help page using inferred hierarchy to experiment with it and see if it can look nicer. And I’m experimenting with adding more heading levels with increased H1 size, and reducing the height of horizontal line items. What do you think? The inferred hierarchy version is on the left. I think it looks easier to read when I add lines under the H1s?

Also FYI I noticed that zooming and the overview were not handling inferred children correctly, and will release an update to fix that tomorrow.

studgeek

I wonder if this might create more confusion than it reduces. When reporting filters issues for example the user will need to indicate if they have headers anywhere above the item.

I wonder if instead you could introduce auto-indenting (like Word and Google Docs) do after a header. Plus an stile switcher between indenting sub-items or keeping them inline. So doc structure would still use true sub-items, but user could switch between styles to see the above.

It’s worth noting that Word has this (Outline view vs Print view) and I really like having the option to move between them.

Jay

studgeek Sorry for the long delay in replying!

We had auto indenting for a while but unexpected automatic behavior was annoying people so we removed it. And I’m not too worried about filter issues at this point - we have a large suite of tests for filters now, so I’m pretty confident that they’re solid. And just sharing a screenshot is usually enough to track down problems.

I had thought about making separate views like Outline vs. Print. I think the idea would be that Outline would have all children indented while Print would remove the indentation. But I got stuck at:

What happens if you try to indent in Print view? If it still allows indent, would that have to be different than indentation in Outline? Or would it need to be disabled?
Print view would have to size the headings based on their position in the hierarchy. So changing their size would have to be disabled or it would quietly cause massive changes in document structure.

So I think it’s better to just allow the flexibility. You can indent if you want, or you can use Heading/Project sizes to group them. And either way, you get all the benefits of filtering/zooming/collapsing/dragging as if they have a parent/child relationship.

But I am certainly open to being wrong about that! Do you have any ideas as to how to do separate views without the problems?

Jay

The latest update should move this feature from experimental to ready to use! It would be fantastic if you could help me out and give it some testing to make sure I didn’t miss anything. @Rackleberry and I have been testing it a lot and it seems solid, but there may be some edge cases we didn’t think of.

The goal of this feature is to:

Look more aesthetically appealing as normal documents
Reduce some problems of deeply nested hierarchy where indentation reduces usable space for text, especially in small panes
Appeal to a wider user-base who are more familiar with regular documents than outliners

I think it looks best when using the new Align Prefixes to Headings display setting.

I personally am using it in some documents where I don’t have deep hierarchy, just multiple projects with their own todo lists. Or in other cases I use hierarchy for a few top levels that I always zoom into, then infer hierarchy from there.

I would love your feedback on how you use it and how it can be improved. Also I think “Infer hierarchy” might be a bit in the weeds 😆 - any ideas for a better way to describe it?