Closed andrewserong closed 1 year ago
Love seeing this conversation being started...
I do like the idea of these showing contextually in the Browse view. From a user POV I would expect that these are places I'd expect matching controls.
This makes sense to be shown when the Index of Home template is being shown or on Site Editor first load when the front page is set to show latest posts.
However, I can imagine this makes less sense if the user's Home/Index template has no Query Loop block at all - and they're not showing posts.
If the user has a static page selected - it could be cool to have the specific page be able to be changed from first load in the site editor (when we're showing the 'home' page).
I can imagine this working quite well as an option that is available when the site editor first loads. The context of showing the Front Page is perfect for making a note like your site is currently showing a static page
or your site is currently showing your Index template
and an option to switch - which reveals the static/latest post option.
@jameskoster would love to hear your perspective on this as I know you've done some work on this in the past: https://github.com/WordPress/gutenberg/issues/43418
Wonderful opportunity to clarify some of the divergent thinking that has happened on this issue across many different issues. I'll take a stab at answering your questions in a moment, but want to preface with a note that this is still to a certain extent being figured out and subject to change.
The key aspect is that the site view (dark material background, preview on the right) is meant to be a receded project-wide view of your site, surfacing high level options, whereas the edit view (fullscreen editor) shows the nitty gritty low-level options. Notably tricky to figure out is where to draw the line between high level and low level, and this will likely take a couple of iterations to get right. This is also something both @SaxonF and @jameskoster have thought a lot about, so I'd love their input as well.
Where should high level settings live within the UI, for example:
- Posts per page
- Home page static page
- Quick template switching
I see all of these being primarily interacted with as properties of the pages that make out your site. That is, you drill into Site Editor > Navigation (or "Site Structure" as I've called it in these mockups), you drill into the detail page for each section, and page attributes are surfaced there.
For a page:
For a page set as homepage:
Page type might also be a choice during page creation:
Post settings would similarly be surfaced when you choose to edit the posts page:
Are these to be exposed within the Browse interface, or within the Template sidebar? What is the list of settings to be exposed?
There may be overlap in cases, and this speaks to still figuring out the best heuristic for what we count as high level vs. what we count as low level. In general I would avoid surfacing every page attribute in the dark material sidebar (title, parent, order, template, allow comments, password, private, date, author) — the majority of those feel like nitty gritty. But an argument can be made that things like URL (slug) and visibility (draft, published, pending review, and maybe a new one: "hidden from menu") would be useful high level tools to edit in the receded view.
Do these settings need to be set at the Template level, or at the global/site level? (i.e., is this just exposing the existing controls within /wp-admin/options-reading.php within the site editor / browse mode — or, do we wish to add more granular control at the template level, where some settings or attributes are stored within the template itself?
It's still an open question whether we need an explicit "Site Settings" item in the site view. For what it's worth, I could see one such exist, to have a ergonomic and easily findable place to change site title, site logo, and tagline. This might also be a place to surface the reading settings in a single place, but I would make this be in addition to those options being available as metadata in the drilldown detail pages.
On a separate note, I've come to appreciate the terms "Site View" and "Edit View", which I think @richtabor coined. They are a good way to differentiate the high level receced view, and the fullscreen editor view:
They are also less confusing than "Browse mode". Originally we did indeed intend to absorb the browse mode feature in the site view, letting you actually click links in the preview on the right to navigate to all the various aspects of your site. But this is indefinitely shelved, and actual browse mode is likely to land as a ⌘ Click feature, a la i #49582.
This comment is a bit outdated since the issue was updated.
It might be worth considering the Front Page template too. It would include similar settings to the Blog Templates (index, home).
Here are some designs for this one:
The Index template can potentially have the same contents.
Nice work. I do like in the page details that the whole row is one clickable element that opens the modal, and I appreciate the clear mockup denoting that.
The omission of the site hub confused me for a moment, but I'm assuming that's unintentional.
The "Manage categories" link sits in a bit of an awkward place for me. I think that's one of the things that could conceptually fit in the save hub. I know there was a longer conversation about what goes there, but it still feels like a "Manage" link that should sit at the end, like revisions, or "Manage all templates". What do you think?
We could place the manage link above the save/revisions area. But that would be inconsistent with the latest designs for other panels (pages, templates, template parts) where it is positioned in the header.
Another option could be to keep the placement but use an icon button. That would reduce the footprint, but choosing an icon is tricky.
Mainly my concern is that including it in the title makes it really tricky for translations, and will wrap very quickly. I'd put it in the list somewhere, since there's room to scroll.
I don't mind moving it to the list, if we acknowledge it'll be different to the Pages panel.
I'm not sure there should be a manage link in the pages title either, or any titles, to be honest. But perhaps I'm missing some crucial nuance?
We have manage actions for other list panels (templates, parts, likely patterns & menus in the future) which take you to the table view via toggle:
This design is a response to suggestions about avoiding the drilldown we have on trunk for this. And feedback has been that the header placement feels better than the footer. I do think the icons need some more thought though.
I don't think Pages should be any different in that sense? The nuance is that we don't have a table view for pages in the site editor yet, so linking to the wp-admin table is the next best thing. Alternatively we just don't like to wp-admin at all and have no manage link for things like Pages.
The toggle seems to fare better than the label button.
I'm still not too sure about the label button, for the translation notes I mentioned also on #44461. However I don't think that needs to necessarily be blocking us from moving forward. So if it isn't too weighty to try the outlined approach, knowing that we might want to move that button elsewhere (dev correct me if this is a big lift), I think we can go with this for now. 👍 👍
Here are some updated designs for this one. One holistic change was to left-align values in settings. This based on a 6 columns grid layout with 16px gutters and 32px margins:
select
to begin with (just like in wp-admin) but may require expansion to include a search input in the future.Grid looks great, colors look great. Two things:
Here's a quick mock of what I mean, but one which isn't polished at all:
we intentionally added them left originally and we might as well keep the same component as we use in the post editor
It looks a bit strange in this context to me, but I can live with it.
As we just discussed in a chat, we can use checkboxes there. The toggle implies immediate saving, which isn't the case here.
Yup, checkboxes can work:
I'd appreciate a once-over in terms of which discussion settings to include here. There are a lot, and the above was just a first pass:
This looks good to me. Spacing looks good, colors look good, checkboxes can work. I think this issue is good to update. Nice work Jay!
I'd appreciate a once-over in terms of which discussion settings to include here
I think as a first pass I actually wouldn't include any of them. The main reason is I think we need to think a little more about where post type settings should exist. I'm not 100% sure they should exist in the template as that idea starts to break down a little bit when considering other post types like products, events, projects etc. Another option is to link off to these settings within the most relevant post type sections. e.g. in future if we have a blog/posts section.
With the first version of page detail branch merged we are now free to build out template and template part detail panels.
I've created a PR that prepares us for these changes by giving templates and template parts their own screens.
Started the template detail branch https://github.com/WordPress/gutenberg/pull/51150 if someone wants to run with it
Thanks @SaxonF I can take a look.
From the designs it looks like there'll be template-specific requirements. I'll try to get something generic up first and then folks can pick up individual template PRs
Hi all!
I have a few questions about how the designs might work in practice.
Header / Footer detail is read only. In the future can serve as a shortcut to view their details.
Could someone help me understand the Areas list? Is it meant to show just the theme's Header and Footer (if they exist)?
Does it have any relationship to the individual template? E.g., what if a template doesn't have a footer?
Posts per page setting can be edited via modal.
Is this still the case? Reading it from this comment.
The designs in a subsequent comment appear to imply inline controls?
Thank you!
I'm not 100% sure they should exist in the template as that idea starts to break down a little bit when considering other post types like products, events, projects etc
That's a great point. This placement suggests the settings are blog-specific rather than global. I certainly wouldn't object to omitting these settings for now.
Could someone help me understand the Areas list? Is it meant to show just the theme's Header and Footer (if they exist)?
It lists any template parts within the template that are assigned as header
or footer
. If there are none (unlikely) we can hide that whole section.
Is this still the case? Reading it from this https://github.com/WordPress/gutenberg/issues/49597#issuecomment-1551505336.
Hopefully we can put the input(s) in the panel (https://github.com/WordPress/gutenberg/issues/49597#issuecomment-1562969365) rather than relying on the modal. I suspect this will come down to how well the text input component works on the dark background. Let's start there and see how we go.
I've updated the OP now that a PR has been opened. We can continue to tweak details in the relevant PRs.
This huge PR adds a single property — modified
— to the template/templates parts API response so the UI can display "Last updated" 😄
I consider this finished. We can open up follow ups for specific templates as we identify improvements and gaps.
This issue seeks to break out tasks from the item in the Phase 2: Customization overview (https://github.com/WordPress/gutenberg/issues/33094), with the label "[Browse] Access to high level settings (posts per page on relevant blog templates; home page static page; and quick template switching)."
Blog Templates (index, home)
When the site has a static home page, we can allow the user to update the Posts Page title from the Home / Index template.
Frontpage
Contains the homepage settings (static page or latest posts).
When set to display latest posts the user can specify how many posts to display.
When set to display a static page the user can select the page, and define the Posts Page.
Category
It would be nice to list categories in the panel, and link to detail views for each one:
But in the short term we may need to just have a link to manage categories at the bottom of the panel, similar to the one in the Pages panel:
Ellipsis menu (next to Edit button)
Existing screens for reference
/wp-admin/options-reading.php