Include discussion settings / detail for pages in site editor

[jameskoster]

In the post editor Inspector it's possible to enable/disable discussion (comments) on a per-page basis:

This feature is altogether missing in the site editor.

Details panel

The list of details here can easily accommodate a row about discussion. The label / value are initial suggestions.

Inspector

Initially we can mimic the same panel from the post editor Inspector.

[jasmussen]

The eternal question here is: what is worth seeing in the high level site view, vs. what's requiring you to go into edit view? My personal take here is that this particular type of data is worth going into edit view for, because it's per-page. There is separately a global "allow comments" default setting, which while it should likely live in a separate Settings page, would still live in what we could refer to as the site view, or at least "admin view". Not a strong opinion and happy to hear other arguments.

[jameskoster]

My personal take here is that this particular type of data is worth going into edit view for, because it's per-page

The detail panel is also per-page. If it's reasonable to include meta there like the slug, template, word-count, etc. then I don't know why we'd exclude things like comment permissions. To be clear, this is the per-page setting, not the global one.

If comments are disabled globally then either; this detail does not appear, or it has some treatment to explain it's applied globally.

[jasmussen]

If it's reasonable to include meta there like the slug, template, word-count, etc. then I don't know why we'd exclude things like comment permissions.

I agree the heuristic of where we draw the line is tricky, but in order to maintain a conceptual split between high level and low level, we need to set it somewhere, and perhaps it helps to list out all the metadata available for a page:

• Title
• Slug
• Date
• Author
• Password
• Private
• Parent
• Order
• Allow Comments
• Status

The goal is to create an experience where you browse items in the pages and intuitively useful metadata is surfaced. Things like title and slug seem useful as in the site view you are literally building out the structure of your site. Template is useful for the same reason. Parent is currently not surfaced, but I wonder if those can be implied by showing up in the drilldown, or should they be implied by a tree-view?

Status can include private if set, but actually setting "Private" and even "Password" need edit view, no? I would lump in Comments in that same category, honestly, so that if comments are set to disabled, the field appears showing that, but otherwise it's implied to be enabled.

This is definitely tricky, but it seems worth looking at all the metadata cohesively so as to summarize and simplify for the site view. Otherwise we just end up duplicating it.

[jameskoster]

conceptual split

I'm beginning to see that split being a read-first vs. write-first experience, similar to file browsers in operating systems. For instance you can view information about a file in MacOS Finder, and indirectly edit some data via mechanics like right-click. For direct / granular editing you open the file.

Continuing that metaphor – the details panel would show you information about the document. To edit them you either: engage edit view, or utilise a less prominent affordance (ellipsis button, right click).

To be honest I would expect to see all the items in your list represented in one way or another, except perhaps order since it has virtually no meaning for block themes.

so that if comments are set to disabled, the field appears showing that, but otherwise it's implied to be enabled

I suppose we could do that. The inverse would need to apply too though, IE if comments are disabled globally but enabled for a given page, the details panel would communicate that.

[jasmussen]

To be honest I would expect to see all the items in your list represented in one way or another, except perhaps order since it has virtually no meaning for block themes.

That's the thing, there's definitely a line, including for items added by plugins. But I agree it would be nice to have a clearer heuristic for what goes where and when, so the discussions don't have to be fuzzy like this. Read first can be a good starting point; I wonder if we can add to that a rule that for options that they only show up if they have a non-default value? I.e. only ever show a "Password protected" note if there's a password entered 🤔

I suppose we could do that. The inverse would need to apply too though, IE if comments are disabled globally but enabled for a given page, the details panel would communicate that.

I don't know — since the global option only changes the default, I don't know that the local behavior would have to change.

[jameskoster]

I wonder if we can add to that a rule that for options that they only show up if they have a non-default value?

I don't mind that.