Start a new post from Query Loop

[mtias]

The query loop block should have an easy way to write new posts. I've noticed some users try to write posts directly in the content of the editor, either above or beneath what "latest posts" or the "query" shows. This seems like a great place to tie the loops, teach users, and guide them around creating content in the relevant places.

It's similar to how the navigation block should have a way to add a new page. Of course, once Query supports different custom post types, it should be routed accordingly.

Examples:

• We could add a "write new post" in the toolbar of the Query Loop block.
• In the sidebar within the description area of the block, including a description "The loop displays a list of your posts. (Link)Write New Post."

[ntsekouras]

--cc @mapk @ItsJonQ

[mapk]

Research

Here's a look at how other blocks allow the addition of new content inside them.

Gallery block
On focus, an option at the bottom appears allowing an upload or selection from the Media Library.

Columns block
An option in the sidebar exists to increase/decrease the number of columns.

Buttons block & Navigation block
These work similarly in that they provide a + icon to add additional content.

All of these are quick ways to add content and keep the user relatively focused on the block at hand. The Gallery block does open the Media Library, but returns the user back to the block when a selection is made.

Option 1: Create new post from within the Query block

Creating a new post could do something similar. A new post in the Query block would show block placeholders that conform to the layout pattern (ie. Post Title, Post Author, Post Excerpt, etc). When the placeholders are filled out, and the post is published, it would create a new post which includes any/all settings applied to the Query block such as the category or tags for filtering to ensure it shows up in the feed.

Option 2: Create new post outside the Query block

Now because the Query block sorts the posts, this new content would have to follow that order. This makes it impossible to know where to position this new post before it gets published. This leads me to believe that the interface for creating new content should exist outside the block so that when it is published, it gets added in the correct order.

Option 3: Create new post in new instance of Editor

None of the above solutions feel very strong when a user needs to publish a robust post and has a user subscription base that receives emails of new posts. Publishing a post that lacks any real content seems awkward. This makes me think that if a user is creating a new post from the Query block, they should be pushed to a new instance of the post editor. This flow breaks out of the Query block, and should alert the user of non-saved actions, and about this jump, before switching them to a new editor. Once switched to a new editor, the settings should automatically reflect the Query block's parameters from the other page to ensure that this new post shows up in that feed.

Feedback

Option 3 feels like the strongest solution for this particular interaction. Creating a post within the confines of the Query block is too limiting. Pushing the user to a new instance of the post editor allows proper creation of a post that, when published, would not only notify all subscriptions, but also populate the Query block feed on the other page.
Keep in mind these are first iterations of various solutions. I'll be iterating on Option 3 more this week.

• Which option appeals more to you, and why?
• Is there anything I'm missing that this interaction should include?
• Option 3 switches the user to a new instance of the post editor, so there's no real way back to the initial page with the Query block without forcing the user to find that page and get to it manually. Any ideas on how this could be improved?

[ntsekouras]

Hey @mapk - thanks for looking at this!

It's not clear to me yet where we should add this, but your exploration with what currently exists for other blocks was really helpful!

My first thoughts though were that option 3 (leaving the page) wouldn't be the best one. I feel like the direction is to be able to do it more intuitively and within the same page.

[mariohamann]

Want to add that the people from Sensei (@yscik) implemented this kind of interaction to create and show lessons of a course. Maybe this is interesting to share some code.

[mapk]

My first thoughts though were that option 3 (leaving the page) wouldn't be the best one. I feel like the direction is to be able to do it more intuitively and within the same page.

Hey @ntsekouras, that was my thought as well. But the more I dug into this, and the fact that a post needs to be published before seeing it in the feed led me to Option 3. Publishing a post is often a big deal sending out emails to subscribers, etc. And writing a post is a more involved process.

In Option 1 & 2, I explored a possibility to create a post from within the block. But these were pretty limiting. Bringing all the features of the block editor into the Query block is too much, and limiting it gets tricky. If this is desired, for cases in which people want to just create some quick content, we can make it happen. I'm uncertain if this is the desired outcome. Still iterating though!

[mtias]

I'm fine with just a link to a new post for the current post type at first, it doesn't have to be more involved than that. Worth noting I've seen some feedback that users can end up clicking on the [+] shown at the bottom as a way to add a new post. That's why it's important to remedy that flow gap. It's less important where the creation happens (the regular editor for a new post is the best and quickest start, there).

[mapk]

The Good
Ultimately, the link in the sidebar settings proves more effective. When preparing to create a new post, the user is already shifting mental models from the block to think about content for a new post, so pulling them away from the block to perform this action makes sense to me.

The Bad
And any sort of "Add" button in the block itself would conflict with the "Add block" + buttons. At this point the user would be adding content rather than adding a block to this particular block.

The Ugly
I'd like to avoid any "Write new post" or "Add a new post" options in the block's toolbar especially if we're exploring an "Add block" option there as this issue outlines.

Go ahead, make my day
I suggest we work toward a sidebar link with notification that alerts the user about unsaved content and transitioning between screens. Is this a custom modal that notifies the user? Or is it a browser notification like we use elsewhere?

Example of our current notifications

[mapk]

I'm fine with just a link to a new post for the current post type at first, it doesn't have to be more involved than that.

Just to clarify for devs, this is what that would look like:

[mapk]

Because we can't yet ensure that the Query settings are ported over to the new post, we need to reword the phrasing to something like this: