Gutenberg: Navigation: Add option to create a new page

[obenland]

When pressing the + button, it would be great if the first thing a user saw was an option to ‘Create a page’, which then would link linked to the right place and allowed them to create a new page in the block.

This would have to be done carefully — clicking on the + should insert a menu item and open the link menu.

Creating a new page should probably be part of that link menu and should also be added to the block navigator.

A lose list of considerations as they come up:

• [ ] Show Add new Page only if users has the publish_pages capability.

[karmatosed]

@obenland I just wanted to check a little more into motives here, because we don't know that someone wants to add a new page all the time, in fact most of the time. Similarly, what about adding a new post?

[apeatling]

This comes from user testing, and seeing users taken out of the Gutenberg experience in order to add a page, and then be brought back again. Everyone we tested with expected to be able to create a page right within Gutenberg and it didn't even cross their mind that they'd need to leave the editor.

This would be an option, and certainly not a requirement to create a new page every time you add a new item to the navigation.

[karmatosed]

This would be an option, and certainly not a requirement to create a new page every time you add a new item to the navigation.

Ah ok, that makes sense and means it doesn't have to be the first thing they see. Would having an option to create any type post/page be even better?

[shaunandrews]

Here's my first pass at adding a way to create a new document from the Navigation block:

If you check the checkbox, it would create the new page/post and load it in the editor. Otherwise, it would create a blank page/post and just add the link in the Navigation block.

[apeatling]

My initial reaction to this is that it looks straightforward, but do we use the "Document" terminology anywhere else? I'm not aware of it. I think we should try and avoid introducing new terminology here.

[apeatling]

What about "(+) Add New"?

[mtias]

Document is used in the sidebar tabbed panel, but it's a bit confusing.

[karmatosed]

What about saying 'content'? I also think document is a little confusing when used here despite it being in the sidebar. Just saying 'add new' to me would be potentially confusing as could be too similar to '+' for a block.

[karmatosed]

Regarding the design, over having an overlay, could the bottom portion slide out and then the panel appear @shaunandrews?

[marekhrabe]

I can start playing with the implementation while the design settles. In the end, we will definitely need the title input and an API request to create the page/post, regardless their location in the UI, so I'll start with those

[marekhrabe]

I'm currently writing the Ajax request for creating the post entity. From the tiny form we obviously only have the post title and post type, however, we should also set the status. I think publish might be the best choice, otherwise we might be breaking expectations that the post you have created (and already added to the menu) won't be accessible by public. I can also see how publish might be unexpected choice for more WP-savvy users. Any opinions on this?

The second question I hit was the handling of saving the post where the navigation is placed.

If you check the checkbox, it would create the new page/post and load it in the editor. Otherwise, it would create a blank page/post and just add the link in the Navigation block.

If user checks the checkbox, we need to:
1) Call an API to create a new post and get its id and URL
1) Insert Navigation Link for the new post with its data
1) Open the new post in editor

The tricky part is that before we navigate away to the new post, we should probably save the current post where you just added the Nav Link. Saving draft is relatively easy but what about saving already published page? User usually needs to do that explicitly using the "Update" button.

We should probably design an error state for the form. It's a possibility that the user might not have enough capabilities to perform the action. A nice improvement might be to only show the "add" form after checking the capability. I'll take a look if we already have the data for that ready and if not, I'll file it as an improvement issue.

Another improvement I have in mind is to check for existence of page/post with the exact same name before creating it and offer to use it or create a new one regardless.

tldr questions:
1) What post status to use?
1) How to handle saving of the post with navigation?
1) Do my future improvements make sense? Any more ideas?

[mtias]

Before this gets too far, has the option of just opening a new editor for the new page been considered rather than handling it inline?

[marekhrabe]

My only context is from this thread and there doesn’t seem to be a mention of that. Would that work in a way that it completely ignores the nav and is literally just a link to open a blank editor?

[mtias]

Yes, it'd be a fork in the flow, but it might be more reasonable than trying to account for all that's needed when creating a new page within a dialog.

[marekhrabe]

What do you think about the simplified way, @karmatosed and @shaunandrews?

[shaunandrews]

has the option of just opening a new editor for the new page been considered

I'm not sure I entirely understand your suggestion here. We could add a single button to the Link UI, and assume it will _only_ create a new page:

If we "just" opened a new editor, I feel like it leads to a very confusing situation. You'd end up on a blank, un-published page. Also, the link you added from the previous document would disappear from the Navigation block.

[getdave]

I'd like to think about this again from a user perspective.

As a user, let's say I'm working on creating the outline of my new website. I may think of this as a-kin to creating a sitemap.

Many people I've worked with in the past, when thinking about a plan for their website, default to outlining the primary nav as their first port of call. They imagine this as creating the _structure_ of their website. Therefore it's important we avoid breaking their flow during this task.

With this in mind then, I can well imagine a use case akin to the following User Story:

As a user, I want to create my primary navigation in order that I can create the structure for my website.

...and:

As a user, I should see a means to add new pages from within the Navigation Block in order that I can create my site outline without breaking flow by having to return to the Pages area of the WP Dashboard.

Thinking about the user experience here, the key element is not having to break flow. Working with clients in the past, I've often found they find it very confusing to have to create pages separately from Menu items (in current WP) from within Pages in the WP Dashboard.

Generally, they want to be able to add Pages to their Nav and _then_ come back and add the content to these at a later date.

Therefore, I'm in favour of a slimline UI which enables users to quickly create a Page and add this to their Navigation without breaking into a new UI context.

This means not leaving the Nav Block.

We don't need to overdo this. Users just need the ability to add a title and hit "Create". Once done we could display an unobtrusive flash notice to the user with a link to their created Page just in case they want to edit it right away (secondary use case). However, I expect most users to simply want to add all the Pages to the Nav and then switch to Pages within the WP Dashboard to edit these and create their content.

I notice @shaunandrews' designs appear do this quite well already.

I appreciate all the above is _highly_ opinionated but I'm trying hard to base it on my experience working with people who work to create websites and how they think and approach such tasks. I acknowledge that not every user exhibits the same behaviours but if we can hit the 80% mark then we'll be on a good path.

As always, happy to be told I'm wrong! For example, I'd be interested to see how breaking into a new editor could address the issues of flow I referenced above.

Thanks for the productive discussion here.

[davipontesblog]

Generally, they want to be able to add Pages to their Nav and then come back and add the content to these at a later date.

Therefore, I'm in favour of a slimline UI which enables users to quickly create a Page and add this to their Navigation without breaking into a new UI context.

This means not leaving the Nav Block.

I can attest that this is what a lot of people ask for when I am helping them create sites in DotCom Concierge. Having to leave the editor, go to the Customizer, add an item to the menu for a new page, then go back and edit that page in Site > Pages is... less than ideal.

[shaunandrews]

A quick iteration on how the "new page" UI could work within the context of the Link UI alone:

This gives the new option a visual treatment similar to adding an existing document or a link. This might be confusing since adding a new page reacts differently than the other items in the list; It opens a modal or the editor, rather than adding an item to the Nav block immediately. But, I find the visual consistency to be nicer, and it maps to the keyboard interactions that already exist.

[apeatling]

@shaunandrews Taking on board @getdave's thoughts, and your visuals. What if selecting the "New Page" option did function in the same way as adding a link, but created the page in the background at the same time?

I think doing that as well as adding an "edit page" option in the flow could satisfy the majority of use cases. If I want to flesh out a skeleton I can keep going. If I want to stop and edit the page I just added, I can use that edit option to deliberately take me out of the navigation flow.

[karmatosed]

What if selecting the "New Page" option did function in the same way as adding a link, but created the page in the background at the same time?

If this was sort of 'magically done' in the sense you wouldn't know, I think this would feel great.

[getdave]

I'd like to start taking another look into this. I appreciate @marekhrabe has started a PR, but it looks inactive and was going down a previous (rejected) route so I trust he won't mind me pivoting to my own PR? I'd appreciate his help on this if he has any time.

What if selecting the "New Page" option did function in the same way as adding a link, but created the page in the background at the same time?

My understanding of this that it is akin to a descoped approach whereby we don't show any kind of "Modal" or overlay. Instead, we to allow you to create a page based on what you've typed into the search input. I like the idea of approaching with an MVP mindset because I feel this could easily become a complex interaction and so aiming for simplicity is a good option.

There are a few implications in the comments above that I'd feel more comfortable seeing resolved in Design/UX before I commit a lot of effort to coding them:

• Can we confirm that the "Create New Page" option would _only_ display if the result is _not_ one of the URL protocols (eg: http, mailto, tel or internal anchor #).
• I assume that the Page would always be an exact match on the text you typed - About Us would create a Page with title About Us and slug of /about-us/.
• Once selected would a user see a notification to confirm the page has been created? I note that @karmatosed said she'd like it to be "magically done", but as a user, I think I'd appreciate a note (however unobtrusive) to confirm something occurred, possibly with a link to edit that page.
• To be ultra-clear, can the label wording be "Create New Page?". I feel the Create is critically important and should be part of the main label.
• As things stand you can enter any text into the text input and create a link from it, even if it's not a Post or a valid URL. I think we may have now found a use case which suggests that we need to determine what is/isn't a valid input. Without this it's going to be difficult to realise all the states shown in the mockups above (eg: "No posts/pages found"). Test the existing Nav Block against the UX in the mockups and it will become clearer.

I assume you're handling the Design/UX on this one @shaunandrews? Happy to sync when you have time.

Also pinging @aduth because this will impact LinkControl which he is busy refactoring. This could impact on his work and any work undertaken against this Issue.

Thanks again to everyone for moving this forward.

[marekhrabe]

I like this direction with the "new page" action integrated with other results 👍

The ability to create a post has disappeared with the change. While I think it was valuable, pages seem much more important in this context and I'm ok with this change. I just wanted to explicitly point this out as nobody mentioned it.

[karmatosed]

@getdave let me answer some and then @shaunandrews can also reply, so we keep you moving on this.

Can we confirm that the "Create New Page" option would only display if the result is not one of the URL protocols (eg: http, mailto, tel or internal anchor #).

For me that makes sense.

I assume that the Page would always be an exact match on the text you typed - About Us would create a Page with title About Us and slug of /about-us/.

Again, yes that makes sense.

To be ultra-clear, can the label wording be "Create New Page?". I feel the Create is critically important and should be part of the main label.

I think 'yes' if we are limiting to pages for a start. I would like us to consider increasing this to other things but that likely needs deeper UI exploring.

As things stand you can enter any text into the text input and create a link from it, even if it's not a Post or a valid URL. I think we may have now found a use case which suggests that we need to determine what is/isn't a valid input. Without this it's going to be difficult to realise all the states shown in the mockups above (eg: "No posts/pages found"). Test the existing Nav Block against the UX in the mockups and it will become clearer.

I think we do need this.

[marekhrabe]

There is a possibility that creating page fails for some reason like a network timeout. How should we show the error state? The latest UI collapses the search input once you click the "create page" option and it shows "Creating page" text, as seen in the gif at the bottom of https://github.com/WordPress/gutenberg/pull/19775#issue-365223910

Imagine the flow breaks somewhere between "Creating page…" and showing the link preview for newly created page.

It's worth noting that we'll try to prevent the most common errors like user capability to create pages but network issues and other random errors could still happen unpredictably.

[getdave]

There is a possibility that creating page fails for some reason like a network timeout. How should we show the error state?

Good question @marekhrabe!

If the page isn't able to be created then we could consider re-showing the UI in the state it was prior to the click on Create but with an error message within the Link UI explaining that the Page wasn't able to be created and they should try again (unless of course there is a specific error such as permissions which we could display, but I would suggest that the option to Create a Page shouldn't show _at all_ in this scenario).

However, I think some Design eyes would be good on this @shaunandrews @karmatosed.

[karmatosed]

I think if an error then reshowing with error works. I think in some cases snack bars are being used but we might just want to be inline for this.

[shaunandrews]

Spent a little more time thinking this through today and came up with these two GIFs. The first shows how it could work when creating a new page without a title:

The second shows how we could use the search input as a way to create a page with a title:

--

Haven't worked up any error handling, but will get that on the next pass.

[getdave]

@shaunandrews Thanks for the extra detail here, especially around blank page always being shown (I had not considered a use case but I guess it is!).

I notice the 2nd gif shows no "Selected Link" state. The Link UI always shows a preview of the link you have selected even if you create a new Page. Just so you know for your next steps.

Also you're showing G2 UI styles. We're still working against current styles so are we better off to use the existing styles? What do you think?

We're also missing a loading state which needs to appear whilst the New Page is being created. Note we cannot simply just display the link and do the creation in the background because a) we won't have the data b) we can't rely that the page creation won't fail. Therefore we need a formal loading state. Also an error state as discussed with @karmatosed.

[apeatling]

@shaunandrews I have one concern with creating a new page with no title. I think it's likely that users will see this new page button before they start typing anything in the box, meaning this will be the most common usage:

Based on your gif, it looks like it creates the new page with the "New Page" title, and also the slug of new-page. In the scenario that @getdave talked about earlier in the thread -- where the user fleshes out their navigation -- the user is going to end up with a lot of pages that have new-page slugs and "New Page" titles when they go to edit the page. These would not match up with the link titles shown in the navigation block (assuming they edit the "New Page" link title for each).

I think that could be quite confusing for users, and we should encourage them at minimum to add a title first before adding a new page. I think having a default "New Page" option is going to cause the opposite to happen.

[karmatosed]

I would agree a title should be added as that otherwise could be a little confusing.

[shaunandrews]

I notice the 2nd gif shows no "Selected Link" state. The Link UI always shows a preview of the link you have selected even if you create a new Page. Just so you know for your next steps.

There's actually a PR #19686 that might change this — defaulting to closing the Link UI when adding an existing page. When looking at that change in this context, it occurs that we'd also be hiding the "open in editor" button when creating new pages. Perhaps we _do_ need to show the Link UI when creating a new page, but hide it _only_ when adding an existing page.

Also you're showing G2 UI styles. We're still working against current styles so are we better off to use the existing styles? What do you think?

Yes, when implementing continue to use the current styles and components. The idea/hope is that #19344 (and future related PRs) will update the styles. Designing with those styles will help us push that work forward and ensure our designs are ready for the future of the block UI.

We're also missing a loading state which needs to appear whilst the New Page is being created.

On my list for the next design iteration.

I think it's likely that users will see this new page button before they start typing anything in the box, meaning this will be the most common usage.

Ah, good point. I'll look at keeping the focus on typing in the input and choosing a recent page.

[shaunandrews]

Here's an update that removes the default "Create new" option and adds a loading state:

I also mocked up a quick error state, adding a standard (or what I _think_ is standard?) error notice in the popover:

Do we have any idea what sort of errors we expect?

[marekhrabe]

Do we have any idea what sort of errors we expect?

@shaunandrews Probably network errors or other unidentified glitches. The user capability to create pages will be checked before showing the "create page" option so that shouldn't be a possible error.