I also like the new icon and new item type of Heading. And I agree with andrew that I would also like an item type of Project. I see them as two different things.

The Heading is, in my opinion, a tool for hierarchical organization. It helps visually and intellectually separate (or join) ideas/thoughts/nodes from one another. Similar to the paper outline method of marking things with a Roman numeral, then a capital letter then an Arabic number then a small letter, etc. I don’t think Headings need any “superpowers” and I don’t think I would even use Group By Headings pane type.

The Project can be used for task and activity management. In GTD terms, anything that has more than one step is a project (not that I strictly adhere to that, but it makes a good working definition). I would use the Project item type to contain tasks, meeting notes, emails, ideas, thoughts, etc. about a specific goal I am trying to achieve, i.e. a project. This is the item type I would like to see have it’s current “superpowers”. Earlier in this conversation, Jerud outlined all the various item type superpowers and I think these should remain (to be able to search for, group by, filter by, zoom into, etc.). There might be other powers they should have, such as being able to let their children inherit tags and dates or maybe having the children auto-complete when the Project is marked as complete. Finally, I liked the icon for the old “Projects” and I would suggest bringing that back for a new Project item type if it is added back to Legend.

Hrm, you can see it already in the comments above - the difference between the usage of a “project” and the usage of a “heading” have a high probability of causing issues.

If I had both, I would use both for sure.

Example:
HEADING - Active Projects
…..^ Project 1
…..^ Project 2
……..TASK
……..Notes.
………^ Sub Project A
…………….Notes
…………….Task
HEADING - Someday/Maybe
…..Area (Yard)
………….Notes
………….Project 1

Etc.

This is the way my document is set up as it is, I just use “normal” bold and underlined text for the headings, and the Project designation for the projects so that I can view just my “actionable” things in their own view.

It seems that calling them “Headings” is going to drive a push for better “heading” functionality - which I agree with! But possible at the expense of project functionality - which I don’t want to lose!

andrew My gut feel is still that I would want a Project item type with that icon as the prefix and that I can filter and group by (just like old Projects), and a Heading item type without a prefix and that I don’t need to group by or filter but that just auto applies a default style (bold and a level-specific font size). This would allow me to group related stuff together (either within a project or outside) with a automatically styled header item, but still exclude that when I just want to see or group by project.

I agree with Andrew here.

Ok, done! I added a Project prefix ^ (which was an alternate Heading prefix) which works exactly the same as Headings, but it’s a different thing. A new Project view and is:project filter lets you view just Projects without Headings included. So Heading can be used mainly for size/formatting while Project could be used for specific projects you want more control over.

We could add additional features to Projects in the future but I think just having them be separate things is pretty useful.

This will be a bit confusing as an update though, renaming Project to Heading but also adding a new feature called Project 😅.

What do you think of this?

    Jay Oh, I LIKE THIS! (At least after all 5 mins I’ve just spent messing with it…)

    I really like being able to use both! I can see lots of ways for this to be really useful.

    RE the Update - HA! 🙂. It makes much more sense to explain that you added “Headings” as a new item type.

    One bug I see right away: If I filter for “project”, the filter box shows the heading icon

    BUG: “headings anywhere in the hierarchy” is not working the same way as “projects anywhere in the hierarchy”.

    with “headings anywhere” NOT enabled - it is still showing headings from anywhere.
    When “headings anywhere…” is enabled it is showing both headings AND projects.

    • Jay replied to this.

      LauraH Fixed both of those! Thanks!

      Now that we have the separate feature does it feel like “Projects anywhere in the hierarchy” should be default? We can tweak it later as we get used to the new systems the separate Projects type enables, but something to think about…

        First impression of this is positive. But one thing I don’t fully understand is how the displayed heading level is determined and why I would want to or should be able to manually set the heading level. I’ve never used a multiple # prefix before so I’m just experimenting with this for the first time, now that there are buttons in the context menu for Heading 2 and 3.

        It seems that the displayed heading level is the manually set level plus the number of levels down from the zoomed level? So an item might be Heading 2 in one view and then I zoom in on it’s parent and the item is now Heading 1.

        If I manually set an item that is a child of a Heading 1 item (or non-heading item) as Heading 2, then it shows it as Heading 3 icon and font size. So in effect I am setting the relative level not the absolute level and it is showing the displayed level by taking into account the level I manually set plus the number of outline levels down? This is hard to understand.

        What would make sense to me is either (1) there is only 1 heading type and the displayed heading level is auto set to the heading level of the nearest ancestor header plus one, or plus the number of outline levels below the ancestor header, OR (2) there are multiple heading level types and it applies whatever level I select without regard for outline level or ancestor headers OR (3) there is a heading type button in the context menu and heading increment/decrement buttons (instead of multiple absolute levels) which increases or decreases the heading level relative to the level that would be displayed purely on outline level (would also cumulatively apply this offset to all descendant header items).

        I think I would be happy with #1, and personally I can more or less accomplish this just by only using Heading 1, but still trying to understand how I might use the manual multiple heading level capabilities.

        • Jeff replied to this.

          Jay No, the bug I was describing with “anywhere in the hierarchy” is not fixed.

          I assume it should behave the same way as with projects.

          Expected behavior:
          When viewing by “heading” or “project” - The view will show only items at the same level as you are zoomed to. Sub headings or sub projects would NOT BE SHOWN.
          With PROJECTS - this is behaving as it always has.
          With HEADINGS - a default “view by heading” view is showing headings everywhere in the hierarchy, even when that toggle is not enabled.

          I like the concept here - but PLEASE MAKE SURE TO FULLY DEBUG this before releasing!
          I messed with it for awhile last night and quickly got frustrated. The search and filter behaviors are inconsistent and frustrating. I’m very happy to mess with software until I find the right settings for what I want; but that doesn’t work when the results of switching various toggles and filters doesn’t make any sense.

          @Jerud posted in another thread about how, despite the power of views like “by project” and now “by heading” - he mostly uses straight Outlines, occasionally lists or tag views - but uses those because they are the most consistent in behavior. I 100% agree. In theory I love the power of the various pane types, but I often end up finding them unusable because their results often do not make sense.

          • Jay replied to this.

            Probably just still on the “to do” list, but @Jay - with “headings” and “projects” as separate entities, could we get the code in the “Display Settings” to control them separately?

            For example: I want my “H1” headings to have different format than my “top level projects”.
            Being able to format headings as just a visual differentiate has a lot of possibility!

            • Jay replied to this.

              Hrm - so in setting things to “headings”, taking away “projects” and the adding back “projects” -
              Right now it looks like everything in my documents that WAS a project is now a “heading”… and I’m having to manually change them all back to projects. UGG.

              It would be MUCH BETTER from a user perspective to leave my projects as projects… and introduce “heading” as a new item type that I can then apply as I choose (or not.). Is it possible to make this the way the change rolls out?

              Ideally it would be the way it shows up in Beta too… but at the very least, before releasing as “live” - that is the way the update should go!

                andrew I had mentioned similar questions back in November. I found the cumulative interaction with the automatic setting, and changing zoom levels, to be confusing and unpredictable, as you describe. I think for most people, in most cases, just using single # with automatic levels works best. Even if you want to export as Markdown, Legend will automatically add the appropriate number of #s based on the indentation.

                I’d be interested to hear if people find other uses for them though. One place where it would be helpful is if you’re writing something in List view, without indentations, and still want to control the headings. In this case, if you want to export via Markdown, Legend ignores the manually added ##s, which it probably shouldn’t. A work-around is to select the text on the screen, copy, and paste it. You’ll get the heading levels you specify, though some other things like code blocks don’t work right.

                LauraH You’re right, there will be many people who prefer to have their existing # projects remain projects - now with ^ - rather than headings. On the other hand, many people would not - myself included, since I’ve always used them as headings. I wonder if Jay can provide some way for people to mass convert them?

                The convention of using ### for headings, with more of them meaning lower levels, is a standard part of Markdown. It makes sense to use them for that purpose in Legend, and use ^ for projects, which don’t have any corresponding feature in Markdown (other than the top level of a task list, which is - []). It’s especially true if you want to export from Legend to somewhere else that supports Markdown - nothing else will recognize ^ as being a heading.

                  Jeff I originally had Laura’s reaction. i.e., keep old projects as new projects, otherwise it would be very confusing. But then thought this was done because I mistakenly believed new projects could only be a single level so couldn’t support multi level old projects, BUT it looks like new projects CAN still be multi level depending on how many ^ prefixes are used. So I guess you could convert old projects to new projects. It’s just that the multi level functionality is less obvious than it is for headings now.

                  I also used old projects more frequently (but not always) like headings so didn’t mind the old projects becoming headings, but wouldn’t be put out too much if I needed to manually change some projects to headings to use the new heading functionality. You can just create a list view, filter by project, select all, and change all to headings with the context menu. Even relative levels seem to be maintained.

                  Holy cow y’all, I’m away for just a few days and WOW look what happens. I skimmed all the above, then spent a few minutes playing. I need to spend more time (both playing and thinking), but some initial thoughts:

                  This all feels like a strong start in a positive direction that just needs some final tweaks. I think a lot of folks are going to like this, especially the prefix-hiding (though I do like to see them, so thanks for the option). I will might hide the Heading prefixes while keeping the others via 0% opacity styling…but the 3-lines icon is nice, so maybe not. And the hotkeys are good!

                  The first thing that jumps out at me is how the different ‘sizes’ of both Heading and Project behave very unpredictably as Panes change. An H2 heading will render as H1 if the “from anywhere” option is picked. Zooming ‘resets’ the baseline indent, so a P3 item is drawn in P1 style when you zoom into it. It’s also completely possible to apply “inverted” styling (H2 above H1) … maybe there’s an edge case for that, but it makes my soul hurt to see it. I haven’t even tried mirroring a Project or Header yet, but that was already janky… Tiered styling has a lot of value to me – but if I can’t rely on it to be consistent I won’t use it at all.

                  I really appreciate that the H or P “size” auto-decrements as the item is indented. That is very “right”. I think it should cascade, though – If I have H1, H2, H3, H4 and then drop the indent on the H1 down to H2, I expect all the child-headings to also decrement by one level, with the H4 getting un-heading-ed if necessary.

                  I do see now (I didn’t support it earlier) that there is value in having both Headings and Projects.
                  HOWEVER, having both of them really calls for differentiating them more. Intuitively, Headings seem structural while Projects could be anywhere…The G-B Heading & G-B Project PaneTypes just underline this blurring of purpose – what’s the difference? How is GBHeading better than an Outline view that’s just filtered to “show headings”?

                  My immediate inclination for using them is to apply Headings according to Outline indent, to emphasize structure and improve visual orientation (especially when zoomed or heavily filtered). Then I’d use Projects – at any indent – to designate “container” items, as you would expect. I currently do this with unadorned Parents and it works fine – but they are hard to ‘extract’ with a filter or to differentiate from other parents. Using Project-prefixes for them, combined with the Headings (if they didn’t change sizes constantly) would be a wonderful improvement for me in look & feel, plus utility.

                  Based on the above (and admitting that I haven’t thought it all the way through), I’d like to discuss the following ideas. I don’t know myself, which of these I like best. Some are a LOT more restrictive – know that I don’t wish to reduce Legend’s wonderful flexibility at all, but the option to choose structure also has a LOT of value to those of us with squirrels in the attic:

                  • The problems with displaying in multiple sizes depending on zoom would be helped if there were simply fewer variables to deal with. I’m thinking of ways to have multiple “sizes” but less direct user control over them.

                  • One way is to peg Headings to absolute Outline indent (regardless of zoom or filter), while keeping Projects independent of position. So, the Heading prefix would not “cycle” through the sizes as it does now – whatever indent level the first Heading-item appears at, that becomes “H1”. Each tier below that goes down a step – across the whole Outline.

                  • This could be an optional behavior, with a user setting for “Heading style by indent” or such.

                  • The above would probably require supporting all the way down to <h6>.

                  • With the above Heading-based structure, There would be no question what size to display a Heading-item at when zoomed or mirrored!

                  • Projects could behave as now, so user can manually cycle through the sizes. This would allow for both the usage style we had before, and a more rigorously structured style (which I’d like). And some in-between stuff, too.

                    OR

                  • Leave Headings manually-sized as they are now but down-sizing or up-sizing a Heading ripples through all of its children.

                  • Then limit Projects to a single style/size. I don’t see how a “big project” or a “small project” has meaning now that we have Headings.

                  Also, a few tag-on thoughts:
                  The current GB Heading Pane seems to be wildly missing an opportunity: This should not be a “group by” Pane but rather should allow user to specify a range of indent-levels to display. So I could ask to only see indents from 0 (root)–>3, and then cut it off below that. Or show me items from 2–>∞. Or indents 4–>4 for a very thin slice. You could also get rid of the Heading Filter entirely if you did this, as the function would be duplicated – and ‘filtering’ on headings seems…weird. This would be especially powerful in more strictly-formatted Outlines (such as indent-dependent Headings would create). Otherwise this Pane just adds noise without having any real function. I’d rather see it left out entirely than included as a G-B.

                  Also, let’s talk about the Move-to dialog box, which currently pre-filters for Projects. What should it do now? Headings only? Projects only? Both?

                  • Jay replied to this.

                    LauraH I believe I’ve fixed the bug now 😆 . Please let me know if there’s still bugs there? I’ve tested a lot and it seems accurate now.

                    LauraH And I added separate theme selectors of Project, with the same defaults as Heading.

                    LauraH The issue with releasing Headings as a new feature is that the default prefix for Projects was # but we’re now using that for Heading. So for most people, their old Projects will become Headings with no issue. A few people were using the ^ prefix so theirs will be Projects. To release this update keeping them as Projects, we’d have to do a large scale automated find and replace to convert # to ^ and that seems more likely to cause issues. I can’t figure out a way to do that cleanly, so I think we’ll have to do as the beta has done, and treat old Projects as Headings. Then you can convert them if you like. But all the old Project behavior is exactly the same in Headings except for the name and icons, so I think most people would not need to change anything? And as @andrew said it’s fairly easy to change them in bulk with a List view filtered by Project, and I’ll describe that in the blog post for the update.

                    Re the automatic sizing: The way they currently work is they display at their specified size minus indent level. So an H1 indented in becomes an H2, and an H2 indented in becomes an H3. The idea behind this was that you may want to have some multiple sizes of headings/projects at a given zoom level, but then they deeply nested headings shouldn’t appear as important as root headings everything if you zoom out. But when zoomed to that item it appears as you set it, and at higher level zooms they appear still sized correctly relative to each other.

                    I think for a lot of you, you may want to just always use an H1 and let the indent level take care of decreasing the size. That’s what I’ve done a lot myself. Maybe we should remove the extra H2 and H3 buttons we just added (but leave it in the / menu) to reduce the complexity? Or how could it be more intuitive?

                    Jerud Re: range of indent levels: I like this idea! But I think it might be better as a collapse feature? A “collapse level 2+” kind of thing? I worry that cutting items off at some level could be very confusing if items just disappear? And then it wouldn’t be clear that items are parents with children, and it would be hard to make them reappear (it would require changing the filter)?

                      Jay It’s been discussed before as a “collapse” feature and that’s cool – I didn’t mean to dig up a whole separate feature request, was just looking for a helpful alternative to the current GB-Heading Pane, which is hard to think of a use for.

                      The “heading minus indent” scheme is a slick approach but ‘indent’ is apparently determined relative to the zoom. So when you zoom into an H3 with H4 children, they draw as H1. I’m sure many see that as a preferred behavior and I get why, but it is disorienting for me to have an item change properties depending on zoom. Would you consider a global display setting that sets heading style from “absolute” document position rather than relative (zoom)? That would make both headings and projects substantially easier on my brain.

                        Jay I’d suggest having a single “Heading” button and removing the H2 and H3 buttons. Then have a separate command/control on the context menu which appears when a heading is selected that allows you to increment or decrement the heading level with +/- buttons or </> buttons. If supporting multi-select, that could also allow you to change multiple headings at once, each changing relative to their own current value.

                        Displaying heading level based on zoom level is kind of cool in some situations, the first time I saw it, I thought it was confusing when a third level heading suddenly became very large. It just seemed disproportionate to its place. It also could make some unsuspecting people try to “fix” the level manually only to find it “broken” again when zooming out. Maybe “auto adjust heading level on zoom” should be an option that defaults off?

                        I think these both fall under the category how to keep it simpler and less confusing for novice users, while still allowing advanced users to access more complex functionality.

                        • Jeff replied to this.

                          Jerud I have long used old projects like headings and had a list view that was grouped by project and filtered on tasks to show all tasks buried within multiple levels of hierarchy within a project/heading in a simple flat list view. So I would still find it useful to do the same with headings now. I could use new projects instead of headings but I can imagine some other cases where it was not “projects” with a task filter, but something else where you would want to show a list of items without their hierarchy but grouped by their heading.

                          Filtering by heading also seemed weird to me at first and I thought maybe it should be eliminated, but then I thought you would need to keep it to not break existing old project filters, and then maybe someone would have some other use for it that we can’t think of now.

                            andrew a List, GB-Heading Pane doesn’t seem valuable to me since it’s functionally identical to a List, GB-None Pane that’s filtered on Headings. It just seems like a “so what” kind of function, unless you’re burying Headings in your Outline without regard for structure/indent. I can see using Projects like that but Headings don’t seem like they should work or be used that way.

                            Now, I do not want to pigeonhole any feature into a “right” or “wrong” way of using it…but I do think Headings and Projects are just too similar right now. There should be something that functionally differentiates them, or else why have both, aside from aesthetics? As you pointed out, Projects have already been doing the Heading job, and nobody was complaining about that…Given the huge gap in “superpowers” between Projects and all other prefixes, seems like Headings would be a perfect way to bridge that gap. Jay went ahead and made them both, so I’m compelled to get the most out of that – yes, for my sake, but also because I feel it will make Legend a better tool.

                            A simple example is the resizing-according-to-zoom behavior. Why not make headings do the current dynamic resizing, but projects don’t (they always stay the size they were manually set to)? I would LOVE it if my projects weren’t a ragged mess of unpredictable sizes. I mirror Projects out of my Task List into my Work Queue, which is awesome for me, but they aren’t all at the same indent level in the Task List so my Queue looks like a Ransom Note with all the off-size Projects. Drives me bonkers and does zero good. I wish a project was just a project was just a project. I don’t want “big” projects and “small” projects – and even if I did, I would want them to stay the same no matter where I’m viewing them – or else what does it even mean?

                            Another example might be the Move-To dialog box contents. Right now headings and projects are mixed together in there since they both act like Projects always have, maybe all Projects could be grouped together at the top, then all Headings below that? User could quickly jump to the right section by typing ‘#’ or ‘^’ (a mechanism that’d be real nice if it worked with all prefixes).

                            I am admittedly testy about Panetypes and am probably out of line for making too big a deal about it here. Adding a new Panetype with (apparent) limited usefulness just rankles me when the existing ones have so much more promise but suffer from functional issues. I don’t want to run this thread aground though, so I invite you to set me straight when I (eventually) post a dedicated thread outlining my Panetype grievances 😉

                              Powered by: FreeFlarum.
                              (remove this footer)