Creation modal for "New Page"

[mtias]

Let's explore combining the current "zoomed.out" experiment for patterns with the new frame mode when it comes to building new pages and templates based on sections. The idea behind zoomed.out was to allow operating at a higher level than individual blocks, which is now better accomplished in the frame mode.

Iteration 1

Can be triggered from nav menu, buttons, command center, etc.

• Modal with page title, slug, and parent
• Once in the editor, patterns modal shows

Mockups:

See also this comment for some more explorations on the slug editing, there is a simpler option if the above is too complex.

Iteration 2: See #50739

Underway.

[jameskoster]

Edit: The following concept speaks to "Iteration 2" as detailed in the OP.

Here's a potential design for the add page flow. It doesn't capture the working-with-sections element yet, but does install the basics.

add.page.mp4

• The flow originates in the Pages panel (as proposed in Re-Introduce Content Editing in the Site Editor #44461 (comment)), where clicking the + reveals the New Page panel.
  • Worth noting that there could be a command in the Command Center that would send a user to this panel too
• The New Page panel contains a two fields:
  • Input for page title
  • Template selection modal.
• Once the page is created, any patterns associated with the Post Content block are presented in a modal (this is existing functionality).

One technical detail to discuss here (in addition to any design feedback) is the status applied to these new pages on creation. They should probably be drafts, but there's not currently a way to publish draft pages in the Site Editor, so we may need to work out a design for this in a subsequent issue (perhaps as a part of #50386).

Another question is which templates to include in the selection modal. Page plus any $custom templates are a given, as are any patterns associated with the page template. Should we also include any singular template (e.g. single-post)?

[mtias]

@jameskoster for the details view iteration, I'd like to explore a design where the available templates are small thumbnails already shown without needing to click on the big template thumbnail.

[mtias]

Would it be possible to edit the slug or it's just a visualization?

[jasmussen]

I was hoping something like this:

But a simpler starting point might be this, click the slug to replace it with an input field for editability:

Main challenge there is to retain a piece of "locked text" — the site — inside that input.

An simpler way to do it would be to just invoke the existing permalink popover from that helper text — this one:

[jasmussen]

I've updated this issue with mockups for iteration 1, and added "Needs dev" label for that.

I've kept the design labels for now, as we still need mockups/feedback for iteration 2.

[mtias]

That seems like a whole lot of separate interactions for such a tiny modal. I think if the slug is editable it should probably be a large input. If it's just a reference, then it should not be editable.

[jasmussen]

Happy to update. Any preference on editable vs. not?

[mtias]

No strong opinion at the moment

[jasmussen]

Cool, just visualizing the two options side by side for posterity:

I think we should go with option 1, not editable, for now, and revisit as we go.

[jameskoster]

Displaying the slug could increase the likelihood someone would want to edit it. If it's un-editable I wonder if its worth displaying at all?

Does the input need a label?

Does the "Parent" button open a popover? Could be fine, but they can sometimes look a little awkward on top of modals so might be worth mocking up.

"Save" and "Edit" feel a bit unexpected as actions – they're both somewhat ambiguous. How about "Create draft" as the primary action, then show an "Edit" action in the resulting snackbar?

Finally, connecting a dot with #50444, perhaps "Add" instead of "Create"?

[SaxonF]

For iteration one I think we should just show page name and nothing else. We can spend time working on iteration two with more complete controls.

Does the "Parent" button open a popover? Could be fine, but they can sometimes look a little awkward on top of modals so might be worth mocking up.

More generally I'm not a huge fan of including any controls in the footer of the modal if its avoidable as it throws off the hierarchy of what you are saving/acting on. Related information is fine.

"Save" and "Edit" feel a bit unexpected as actions – they're both somewhat ambiguous. How about "Create draft" as the primary action, then show an "Edit" action in the resulting snackbar?

Also agree with this. I would just have "Create" as primary action that takes you directly to editor. If we notice people want to bulk create pages we can handle that use case after, perhaps in a similar way to how Linear handles it.

[richtabor]

An aside (noting so its shared/visible/I don't loose it):

Would be neat if there was an option in the "Add a Page" modal to open zoomed out mode + pattern inserter — essentially a "design my own page with patterns" isolated view. Alternatively to starting blank, or picking one page design.

Related: #45395

[jasmussen]

I've tentatively updated this one as the conversation seems to have solidified.

[simison]

Issue for categories in the new page template modal, neat to see categories in these designs. 👍

[jameskoster]

@jasmussen a tiny detail that seems to have been missed: Instead of "Parent", it might be more intuitive if the default option in the dropdown was "Top level". I think that dropdown may need a label too, but it's hard to say for sure without seeing the contents mocked up. I'd echo Saxon's comments about not placing it in the footer, but feel less strongly about that.

The "Save" – and particularly "Edit" – buttons still feel a bit off to me. Could save just be "Create"? If we need the edit option too, maybe "Create & edit"?

[jasmussen]

I prefer we start with single words for the buttons, and then change if and when we get to test it in a branch where it might feel off. It's always harder to pull back later on. Same, honestly, with the parent. Also not a strong opinion here, but feels solid enough to start a PR for.

[getdave]

Is anyone actively working on the tasks here? The current implementation seem quite tied to the Pages section of the Browse Mode. I envisage that this modal will be needed elsewhere and thus will need to be invoked on a global basis. For example:

• Link UI
• Navigation in Browse Mode

I'm thinking the modal needs lifting to somewhere where it can be invoked from an action dispatched to the edit site store.

[jasmussen]

I think I've seen some work done by @SaxonF.

[jameskoster]

Page creation is now possible via the Pages panel (#50565).

Should we close this issue in favor of new ones for any follow-up tasks?

[SaxonF]

@getdave the initial implementation of the add page modal was actually global via edit site store like you suggest but was changed to use local state based on feedback. You can view the reversal here 5fc86cf . It Might be worth creating a separate issue and could almost copy/paste from earlier commits on that branch, but @youknowriad might have some thoughts on a more elegant global approach .

[getdave]

Thanks @SaxonF. Interesting that it was reverted. Was reasoning was provided for that? I assumed it had simply been conceived as a local component from the get-go.

I can say now that we need to be able to trigger the creation of a new page from both Navigation panel in Browse mode and also the Link Control/Link UI. But in our case we need to be able to control what happens after submission in order that we can act on the resulting data.

[SaxonF]

@getdave we just didn't want to introduce deeper changes at that point in time as it was only being triggered in one place.

I added a redirectAfterSave option to the action which you could turn into a more generic onSave callback, but using actions that way feels a little dirty.

Ideally we'd also want the command center to be able to trigger the add page modal.

[getdave]

@getdave we just didn't want to introduce deeper changes at that point in time as it was only being triggered in one place.

Absolutely. No problem at all. I was just curious if there was another bigger reason I had missed. Thanks for confirming. I commented on the original PR and waiting on Riad to advise if he's happy with this becoming global again.

Thanks for your context and also all the original work here 🙇

[youknowriad]

I'm happy if we take the "Add page" modal global (block-editor) again in its own PR. Here are a few things/requirements in my mind:

• Rely on the existing abstractions (settings) we have in the BlockEditorProvider
• Use the same UI for all the places we already have (avoid adding a new standard without removing the existing ones)

Related to this, at this point, we have a number of block editor settings and we're often unsure what each setting is about, what format it supports and how is it useful for third-party editors. I think we should also make sure to add a documentation page to document all these settings.

[getdave]

I think we should also make sure to add a documentation page to document all these settings.

@ndiego I wonder if this is something you would be able/interested in looking into?

[ndiego]

@ndiego I wonder if this is something you would be able/interested in looking into?

@getdave definitely. I'll get myself caught up on this issue this week.

[mtias]

This looks to be concluded, do we have any follow ups?

[jameskoster]

I think just the zoomed-out stuff which is already documented in #50739.

If anyone disagrees please re-open.

[ndiego]

This would be a separate PR, but does it make sense to add the option to choose a specific template for the page on creation?

[jameskoster]

I think that is probably covered by #50739.

[richtabor]

Related to #55117 (connecting dots).