Jay I often like to use Headings as an outer layer of formatting and grouping
Yes that’s the immediate appeal to me, as well. While H and P can be used interchangeably, this is a perfect example of how users will inherently want to use them for distinct purposes and thus they should behave – at least a little – differently to facilitate that.
Jay I’ve also been thinking of having some quick options to choose from in the themes which would set them a certain way, so for example a “Same size projects” option could quickly tweak the theme that way
This is a neat idea that probably has broader applications, too – but I don’t think it should be used to address the discussion about relative re-sizing of P and H. Just because one wants Projects to display in a consistent size shouldn’t preclude the ability to use multiple sizes. However if Projects continue to resize themselves with zoom this style change will indeed be my workaround. Just because it can be fudged with style changes though, doesn’t mean we shouldn’t consider changing the behavior so casual users get a better experience. The way this impacts mirrored items in particular makes Legend look sloppy and confusing. I’m thinking here about new users and adoption.
Jeff you can use heading levels as a kind of non-indented hierarchy
This is a really clever idea, a kind of “narrow” outline format. Someone can probably make good use of that. This does make me think headings should run all the way to <h6> though.
And yeah, the documentation is getting increasingly more-needed.
Jeff PS, where do I find the “anywhere in hierarchy” setting?
It’s with the Filters, not the Pane Options. Only appears for GB panes. It makes sense there but does seem out of place in the context of this specific conversation.
Given that this ‘option’ actually defaults to ON, I wonder if it should be inverted s/t the button defaults OFF, but the option is instead “Groups for top-level only” because now we have 3 ‘levels’ of Project/Heading, whereas before there was just ‘top level’ and ‘not top level’ and size was set automatically.
BTW this gets weird if you have mixed-size siblings. For example:
(P1) project A
(P2) project B
In a GB-Project pane that is only showing top-level Projects (i.e. “anywhere in hierarchy” is OFF), you will see a group for A and a group for B, and BOTH are drawn as P1 style, presumably because “top level” is defined by indent regardless of user-specified size. Different-size siblings get even weirder in Agenda Panes that are zoomed…
Jeff To me it seems natural that the headings get larger when you zoom in. I’d find it confusing if they didn’t. But maybe I spent too much time looking at fractals in the 90s.
I totally appreciate the logic behind this – but it’s exactly the opposite for me. Comically, fractals perfectly illustrate why I feel that way. I don’t want to get lost in Inception layers while perusing my Outlines…that’s exactly why I need Legend in the first place!
Jeff I’d like the auto-sizing, if any, to be according to the destination indentation rather than the source.
I want this too but don’t think it can work on the “destination” end, which is why I proposed non-dynamic-sizing instead. Legend can’t “know” what size the mirror is “supposed” to be at the destination. If you drop a mirror between two P2 items then it’s obvious, but what if you put it between a P1 and a P2? Or at the top of a series of P2, with non-P items above it? Or blank items? The app can’t determine user intent from context.
My proposal to not dynamically resize P-styles solves that by always showing the size the user specified…which…I mean…isn’t that what apps are supposed to do – respect user input?
I’m all ranty because this change looks to me like adding a second ‘project prefix’ while duplicating a behavior that made old-projects hard for me to use and resulted in a confusing and ugly side-effect in mirrors. It is cruising past a perfect opportunity to fix this behavior – without causing any negative impact to users who are un-bothered by the current behavior (since they will just keep using the headings that their #Projects got converted into).
Why not at least try this one tweak, which would provide – but not force – a solution to both? It makes a lot of intuitive sense for Projects to display consistently, since some “projects” are “bigger” than others – and that doesn’t change with zoom. A “big project” is a “big project”. Similarly, having Headings dynamically resize also makes intuitive sense (even if I personally have trouble with it) because the presumed natural application for Headings is connected to indent/position/outline structure.
All of the above notwithstanding, I think it’s clearly hard to figure out the true “size” of a Heading or Project in many circumstances. It’d be nice to have some tool (mouseover or RMB maybe) that explicitly tells the user what “size” these items are. Maybe even both numbers (actual & display)? doesn’t have to be obvious or easy, but it would be real helpful in troubleshooting and style-editing.
andrew This is not equivalent for me… just gives me a flat list of headings.
Oop, yes you’re right. Should have tested before posting. I stand corrected.
Also, GB Headings could get very interesting if paired with the improvement @LauraH and I were discussing here, which would allow user to show only a specific subset of Headings based on a text filter.
What’s powerful about GB Panes is that they extract and rearrange items into property-based groups from anywhere in a Document. This lets you effectively build “3 dimensional outlines” (actually more than that!), which is the fundamental thing that no other Outliner can do. This gives you tools to work with information that is interrelated in multiple independent ways, and is exactly why I’m here right now. The downside is that you lose track of the basic “2 dimensional” (outline) context for those items. Sometimes, that’s exactly the point – but other times it’s a liability. Breadcrumbs (when available) help, but something that definitely hurts is having Projects draw at a size/style different than they would normally appear in Outline (2 dimensional) view. Maybe that’s part of why my perspective is at odds with others on this thread – I love to use Legend to extract items but I need them to look the same regardless of “where I’m looking from” or they’re harder to work with.
Jeff I’m still pretty mystified by group-by and the different views. I don’t know why I’d want to do either of those things.
I think this just illustrates that other PaneTypes have functional shortcomings or bugs making it too hard to understand what they do, why they do it, or how you can use them. I have a LOT of ways I want to use GBs but just can’t right now. That’s a topic for another thread, though.
