Query block: Toolbar control revisions

[mapk]

There have been some recent additions to the toolbar controls for the Query block. Before we go too far, let's evaluate what we have currently.

Posts per page
This is an important setting, however, will the Query block every produce results that include anything other than posts? My suggestion is to change this to say, "Items per page" and make sure it is in Sentence case, not Title case.

Number of Pages
I think this one can change to a toggle that says, "Show more than one page". The reason being is that the current "number of pages" doesn't allow a default that just shows however many pages are required to display all the posts. And it seems likely that users will want to only show ONE page with a few results, or show ALL pages with a set list of results per page. Of course toggling this "on" would add the Query Pagination block automatically if needed.

Offset
This is good to keep, but needs some explanation (helper text). At first I wasn't sure what this did. Can we add some text below that offers a tip? "Offsetting a list to 3 will begin the results at the 3rd item instead of the 1st."

Categories & Tags
I like that these are added for the basic Query block, but I imagine they will be hidden depending on the template for which they're being used. Like if this block is used on a category-$slug.php page, I would assume the Tag settings would not be available. Nor would the Category settings be available because the template would pass the parameters directly to the block. Am I thinking about this correctly?

Add "Order by" sorting
Let's add the "Order by" sorting option to this list as well.

New mockup

With these design changes, the toolbar popover should look something like this:

cc @ntsekouras

[mapk]

Order by

I realize the "Order by" was added here: #24691 to the Inspector, but I thought it might work well in this popover. Now, I'm second guessing this one because it doesn't feel like an important setting required for the use of this block. Chances are, this particular setting won't get a lot of use as most people will prefer the default of "Newest to oldest".

Filter by Author

The ability to filter by "Author" was added here: #25149. Regarding my comment above about Categories and Tags, should the Author option also hide depending on the template being used? For example, if I'm adding this block to a author-$id.php template, I probably don't need this setting, right?

[ntsekouras]

Hey @mapk! I don't have many answers myself yet, but here are some of my thoughts :)

In the first design iteration I think we should probably change the items per page and offset to number controls and not range. I can't think of any reason for them to be range. If anyone does, please comment.

Number of Pages

Of course toggling this "on" would add the Query Pagination block automatically if needed.

That seems right, probably with different wording, like show pagination.

Offset
An explaining text seems a good idea to me.

Categories & Tags

Am I thinking about this correctly?

I would like to hear some thoughts from people more involved in FSE as well.

Order by
This seems to be a secondary option for inspector controls.

Filter by Author
Even if this is conditionally shown, we should decide where to show it. It seems to me a bit more of inspector controls item.

[ntsekouras]

Also keep in mind that another control will be added for sure that is the search control which require a text input. This will be probably needed for any context.

[mapk]

In the first design iteration I think we should probably change the items per page and offset to number controls and not range. I can't think of any reason for them to be range. If anyone does, please comment.

That's right! I remember you mentioning this before. I'm on board with this.

That seems right, probably with different wording, like show pagination.

Maybe. I think whatever we use for copy will need to be flexible enough that if the results only fill one page, it still makes sense. I'll add the "Needs copy" label to get some thoughts.

Also cc-ing @mtias to get your input on this. We're iterating on the settings for the Query block and can use some feedback regarding this particular issue.

[mapk]

Here's a mockup including some of these changes.

• I noticed labels, if possible, have been moved inline with their inputs, so I did this with the Number inputs.
• Updated the label text for each one.
• The last label, I feel, communicates the toggle really well now.
• Removed the Order by option to keep in the sidebar because it's just as important.

[mapk]

I received some recent feedback that has encouraged me to explore a basic Query block with all the settings, whether in the toolbar or sidebar, first. From there we can explore the variations that may hide certain settings, or show settings preconfigured (and possibly uneditable if inherited from template).

There was also some thoughts on whether or not Offset is important enough to be in the toolbar dropdown.

will have another iteration up today

[carolynannewells]

Hello! Popping in here from editorial. I like what you are doing here, you are making things much clearer, especially with the explaining text. I would perhaps change the "Show more than one page" toggle to "Show multiple pages."

[mapk]

Thanks, @carolynannewells! I actually iterated a bit more earlier today and landed on, "Allow pagination of results" What do you think about that one? I'm totally willing to trust your expertise here!

I've also made some adjustments as another iteration. This is isn't quite final. Just wanted to share my progress from today.

Option 1 - Two setting buttons in toolbar

Notes

• I split the "Filters" out into its own icon button in the toolbar.
• Added the major filters there (ie. Categories, Tags, Taxonomies, Author)
• Removed the "Offset" setting from the display popover.
• Edited some of the toggle text as mentioned above.

Option 2 - Inline filter input fields

Riffing off of the work in the new Link UI, I also wanted to share some explorations I did around the filters. Hat tip to @MichaelArestad for suggesting this. I pulled the filters out into their own icon buttons in the toolbar. When clicked, they open up just like the link UI does. I'm not confident about this direction, but thought it could spur more feedback.

Prototype

Annotated

Mockups

Mockups with a "Is" or "Is not" selection box.

[carolynannewells]

I think that "Allow pagination of results" works! :)

[scruffian]

Could "categories" and "tags" be dropdowns rather than inputs?

[mapk]

Could "categories" and "tags" be dropdowns rather than inputs?

Yes! 😄 I think something like what is in place currently would be great. I'm going to refine those controls further.

[mapk]

I've been working through more iterations today.

• Display (number of items) is an input like the Link UI.
• Pagination is a togglable icon button in the toolbar.
• Categories and tags remain within a Filter icon button.
  • Categories inherits the design from what is currently in the sidebar.
• Filtering by author or taxonomies remain in the sidebar. I'm not sure these should be broken out from Categories and Tags.

Prototype

[scruffian]

Filtering by author or taxonomies remain in the sidebar. I'm not sure these should be broken out from Categories and Tags.

Does it make sense to have the category and tag filters in the sidebar as well as in the toolbar?

[bph]

Seems the idea "Bring important settings" into the toolbar, and add the rest of the settings in sidebar, is pushed quite far. The downside is an increase in cognitive load. On top of explaining the various settings, you also have to explain the icons, (display filters, authors, numbers, tags) too.

They are not as clean as they appear in the mock-ups.

The sidebar is very well established on providing settings for more complex blocks (cover, image, gallery, latest posts).

Screenshot in Guteneberg 9.0 RC
I felt the overlapping drop-down from the toolbar quite disconcerting and very distracting from the task at hand.

[bph]

There are a few assumptions you could make instead of trying to squeeze things into the toolbar:

• Newest to oldest
• use the WPAdmin > Settings > Reading > Blog pages show at most number as default for how many posts in the list
• set pagination to "yes" or true

[mapk]

Seems the idea "Bring important settings" into the toolbar, and add the rest of the settings in sidebar, is pushed quite far.

I think these explorations were important to visually work through all of this. You bring up a good point about cognitive load. The toolbar settings work well as dropdown select items, but when we add more form-like inputs whose input value isn't reflected in the toolbar, it gets a bit awkward.

I'm going to push in the other direction (back to the sidebar) for some of this to share.

set pagination to "yes" or true

I was thinking this same thing too! Most likely, the Query block will be used with pagination, so making that the default sounds reasonable.

[ntsekouras]

I felt the overlapping drop-down from the toolbar quite disconcerting and very distracting from the task at hand.

For now it is, but this is the time and the issue where we will change this :). There have been some ongoing development efforts to enhance the functionality of the Query block, but there is always in mind that the design is in progress and that lots of things might and probably change place (toolbar, inspector controls etc..).

Having said that, I think it's great that there is not only design mock ups and iterations (that are definitely needed), but also feedback and suggestions! 💯

One thing we probably could do is to get some decisions about some of the current options and implement them. For example if there seems to be a consensus on where the search input should live, we should do it and then iterate more.

[mapk]

Riffing off of @bph's comment above, here's a couple iterations of the Pagination icon toggle.

Option 1 - Pagination

We can load the block with that setting "on" and highlighted. It would look like this:

Option 2 - Pagination

Rather than a toggle, make use of the dropdown ability to switch the toolbar setting.

[bph]

Could you have it just one line and use a toggle switch?

I know this is just an example.

There is a Query Pagination block as well. Shouldn't there be a little note somewhere that it needs to be added to the space? Otherwise, the dependency is not obvious.

[mapk]

Could you have it just one line and use a toggle switch?

Yes, that's how I had it in some of the early iterations.

There is a Query Pagination block as well. Shouldn't there be a little note somewhere that it needs to be added to the space? Otherwise, the dependency is not obvious.

That block would automatically be added if the Pagination is turned "on".

[mapk]

I'm thinking about the amount of input fields involved with the Query block settings. I've been working around creative ways (see above iterations) to show these form fields without breaking from existing UI patterns, or incorporating future patterns that are in development (Link UI). For the most part, block toolbars include simple toggle switches (ie. Bold, Italic) and dropdown selections (ie. alignment) whose states are reflected in the toolbar itself. There are a few that include more advanced controls like the Link and Color settings, but these are rare.

I'd like to include the more important settings in the toolbar, but because of the amount of form fields, I believe if we provide strong defaults, these settings could remain in the sidebar where most of the form fields for blocks tend to reside. Unless there is an above approach that is more desired.

Settings overview

Notes

• The Query block is expected to support various patterns/layouts. I have yet to explore how these integrate into the UI.
• This is the base-block that includes all settings and is meant to be a site-building block, not necessarily a common user-facing block.
• Block variations will be created that will be more simplified for common usage (ie. Latest Posts block).
• Yes, there are a lot of settings surfaced in the sidebar. Moving important ones to the toolbar means working in form fields into dropdowns or inline with the toolbar as displayed in previous mockups.
• To see the many other explorations, here's the Figma file.

Feedback

I'd like to get some theme developer's feedback on this.

• Am I missing any settings that you feel should be included here?
• Which ones do you think should be moved to the block toolbar?

[aristath]

A few notes on that last iteration:

• Does the "include sticky items" exclude sitckies when not checked? Or does it simply return them to their normal position, unsticking them? If the latter (which would be correct) then the title would need changed.
• Offset should be right below the number of posts (items/page) instead of in the sorting section
• Perhaps inside filtering we can merge categories & terms/tags with the taxonomies? After all, that's what they are... That should help clean up the UI a bit if all taxonomy terms are under one roof

Critical & missing:

• Post-type

[mapk]

Does the "include sticky items" exclude sitckies when not checked? Or does it simply return them to their normal position, unsticking them? If the latter (which would be correct) then the title would need changed.

It includes them when "on" and excludes them when "off". They would show as sticky in the block and remain at the top. cc @ntsekouras for confirmation.

Offset should be right below the number of posts (items/page) instead of in the sorting section

Good eye! I've been pulling and pushing settings back and forth between the toolbar and sidebar. If they reside in the sidebar, I'll make sure that happens.

Perhaps inside filtering we can merge categories & terms/tags with the taxonomies? After all, that's what they are... That should help clean up the UI a bit if all taxonomy terms are under one roof

I'm really unfamiliar with taxonomies, but are you imagining a dropdown that allows me to select between categories, tags, or taxonomies? Or just having them all lumped together?

[aristath]

I'm really unfamiliar with taxonomies, but are you imagining a dropdown that allows me to select between categories, tags, or taxonomies? Or just having them all lumped together?

I'm imagining selectors similar to the ones we currently have for selecting tags. So not exactly dropdowns... Rather textfields with auto-complete functionality and a "dropdown selector" for lack of a better word once you start typing. This can work well for all taxonomies, allows selecting multiple items and is so compact that we could fit together Categories, Tags and any other custom taxonomies the post-type might have, we'll need 1 text-field/tag-selector per-taxonomy.
It's simple, functional and takes a lot less space than the categories selector. Since in the context of a query we don't need to add new terms, there really is no reason to show the full categories UI.

[kellychoffman]

The UI in the latest design iteration to choose what to filter + display is that of -creating-. I think this is too confusing and the UI should use -filtering- patterns to make it more immediately recognizable as to what these settings are for. Doing so would have an added benefit of a more simplified and concise interface and perhaps could lead to a way to have some / all of this in the toolbar.

[mapk]

The UI for all the filtering components still needs some work. Feels inconsistent and some (specifically tags) will have issues working at scale. For example, tags are displayed inline but categories are listed block style. You can search categories but not authors, etc. I am not saying to make them all look exactly the same, but they feel a bit all over the place and its unclear why. Filtering should be a fairly quick process and we could apply some "don't make me think" here.

Oh, @kellychoffman, I've got an answer for ya!

• Tags can still work at scale much like the Categories do. The module would only show so many so as not to take up the entire sidebar if there are hundreds. But there is the "See all" if someone wanted to see everything. Otherwise, similar to the category functionality now, they can be searched.
• The reason why Tags are displayed differently from Categories is because tags are a single-level taxonomy. You can't add tags to a parent tag. Categories can exist in hierarchical levels meaning that a category can exist under a parent category. This is why I maintained a visual difference. It also breaks up the monotony of checkbox lists.
• As with any taxonomy, if the total exceeds a certain number, a search is revealed to make finding them easier. Authors, in the case of the mockups, doesn't exceed that number so there is no search needed since they are all visible.

I hope that helps!

I'll iterate to get these settings into flows soon! Thanks for your feedback.

[ItsJonQ]

Haiii!!! Hope you all are well. I poked around some of the query block UI as it feels like it's within the realm of "Design Tools", which helps me better understand use cases.

🥇 First idea

First off, I fully recognize how complex something like this is. The combination of things is (theoretically) endless, compounded by the amount of categories, tags, custom taxonomies a user may have. (I've seen WP sites with literally 10,000+ tags).

That being said... I think there may be a UI solution here - at least to handle the combinations.

My mind jumps to a "Condition Builder" UI.

Example:

This idea sparked from the following comments in the thread:

@ntsekouras
A solution might be here something like a dynamic (add/remove) list of taxonomy filters that would look like:
selectbox: with taxonomies || selectbox: include/exclude || terms input: like is now allowing multiple terms

@mariohamann
#25198 (comment)

🧬 Condition Builders

Condition builders are designed to handle this very thing. I may be biased as I've worked on a Condition Builder UI several years ago. It was, as you could imagine, wildly complex (as far as combinations of things goes). However, the nature of a condition builder was able to it.

A bonus is that folks may already be familiar with Condition Builder UIs, especially if they have experience in the analytics or marketing world where Condition Builders are standard (e.g. Email marketing platforms)

It is worth noting that Condition Builders are more of an "intermediate" feeling UI. Not as friendly as a couple of checkboxes. However, I think the Query block is "intermediate" by nature. Much more so compared to a "Paragraph",

🧠 Powerful logic

In addition to adding/chaining filters... operators can be added such as include, exclude, and, or. Each one compounding the flexibility of the query, while adding minimal UI. It's pretty amazing.

Something like... (pseudo code incoming)

* Include 'CATEGORY: TECH', 'TAG: APPLE'
* Exclude 'CATEGORY: REVIEW', 'TYPE: SPONSORSHIP'
* Post date within '3 years'

🌍 Query "Language"

The condition builder (query builder) is modelling after a "query language". In our case, WordPress's query language, which resembles MySQL a bit. An example to look into may be Jira's JQL (Jira Query Language):
https://www.atlassian.com/blog/jira-software/jql-the-most-flexible-way-to-search-jira-14

It's been a while since I looked into it deeply.. From what I remember, the UI is basically a condition builder. They also have a complimentary text field where you could write the query manually, not unlike the suggestion from @mariohamann.

I'm not suggestion we create our own query language.

Rather, I'm suggesting the UI solution for Query block should map to both the mental model of how users assume data can be queried and the API of the WP query parameters.

---

No need to run with this idea. You all have been at this much longer than I have! The idea of a condition builder may have already come up (hard to tell from the sea of comments).

Hopefully this helps though!

---

P.S. If a Condition Builder UI is what y'all think is best, I'd be happy to help prototype some ideas to try things out 🏗️ .

[ntsekouras]

Thanks @ItsJonQ! I would really love to see this idea being explored as well! I think it might suit us well!

[mariohamann]

I really like the idea of the query block being a flexible "Query builder".

I tested a concept some days ago, to see how we could use those builded Queries for the REST API to get the full power of WP_Query: https://github.com/mariohamann/rest-query-endpoint (Where I pointed out the idea of "JSON Builder", too. :)) After asking in REST-Slack channel for feedback, I've got the response, that the given REST endpoints could already handle most of the queries, but I hadn't the time to check it out.

The following GIF ist just intended to show how query builder and args-output could work together – not a proposal fo the UI. :)

GIven that, variants could still create some "pre selections" or "default filters". (E. g. for a Recent Comments block or similar).

Rather, I'm suggesting the UI solution for Query block should map to both the mental model of how users assume data can be queried and the API of the WP query parameters.

The output (and therefore in my opinion the UI) should match the current WP_Query Class. as far as possible.

[mapk]

While @ItsJonQ is working toward a condition builder, I thought to take a step back based on some of @ntsekouras' earlier endeavors. Currently WordPress.com has a Blog Post block that displays their filters in a simply search input that shows selections as labels. This follows similarly to the Tags module in WordPress.org right now.

This solution...

• Reduces the UI.
• Provides strong consistency throughout each filter.
• Is predictable and a pattern used already (somewhat).

I've also included the current iteration of the block's toolbar. Some of that interaction can be seen here.

[mariohamann]

Filters

I think it is a very good idea to stick to common behaviour with the filters → Really like the new explorations @mapk . 👍🏻 Building on @ItsJonQ proposal I had this quick idea I would like to bring in:

Clicking on "Open condicitional builder" opens a modal, which influences the shown JSON. Maybe it's too "technical" but maybe it helps for further explorations. :)

Sticky posts

tl;dr

For sticky posts the current UI seems to behave as a boolean (include, show only?), but we need three options (include, exclude, show only). Furthermore we need the option to "ignore_stickiness". @ntsekouras What are the planned options from code perspective?

Explanation

In the REST API (referring the docs) we have the parameter sticky [boolean], saying "Limit result set to items that are sticky." Therefore we have 3 options.

• : If not set, sticky and non-sticky posts show up. (Default)
• sticky=true: include only sticky posts (corresponding to 'post__in' => get_option( 'sticky_posts' ) in WP_Query)
• sticky=false: exclude sticky posts (corresponding to 'post__not_in' => get_option( 'sticky_posts' ) in WP_Query)

🔍 Example "Featured posts" and "Other posts": If one wants to list all featured (=sticky) posts in one Query e. g. with big pictures etc. and all other posts (= non sticky) in another Query without images, we need the option to include and exclude. If we only have the option to include only sticky posts, they would show up in both Queries.

Furthermore in WP_Query we have the parameter to ignore_sticky_posts. This ignores the "stickiness" of posts. If set, sticky posts still are shown but not at the top of the output. I couldn't find this option in the REST docs and didn't have the time to check the source code. But this option is very important.

🔍 Example "Recent posts": Sticky posts should show up, but they shouldn't stay on top.

Toolbar vs. Sidebar

tl;dr

Because of other blocks/plugins with similiar behaviour (e. g. Core/Recent posts, WP.Com/Newspack/BlogPosts, Elementor) the complexity (e. g. two steppers and descriptions inside pagination) and power (e. g. Post Type selector) of the paramaters, I think the options of the toolbar should stay in the sidebar.

New UI-Interactions

At the moment, I have the feeling there are way to many new UI interactions:

• "Toolbar option changes sidebar content.": The post type selector is responsible for the taxonomies showing up in the filter section. In my opinion this is lots of power for such a small button. :)
• "Inserters and steppers inside a toolbar option": Inside the pagination option there are steppers for pagination and offset. I had a look on some of the core blocks and could only find two examples, where options in the toolbar have such complex behaviour – but both are directly content specific: The color-selector in navigation toolbar and the URL selector e. g. in paragraphs or similar. Every other toolbar option have just some single options.

Complexity

Often toolbar settings are used for visual changes (e. g. bold, italic, text-align, image position) or for simple actions (add new row in tables, add link etc.). In my opinion many of those options are far away from being self-explanatory and simple, e. g. sticky posts (see above), offset, pagination or the technical term "post types". To support the users, I think they definetely need good and verbal descriptions. Furthermore, I really like the icons in the toolbar, but they are very tiny and e. g. the 10/0 icon is not self-explanatory enough. I think verbal descriptions and labels would fit the complexity of this block a lot more than icons – and therefore I think the sidebar is perfect.

Comparison to other blocks/plugins

I had a look on the Recent Posts Block, the Newspack Posts Block (thanks @mapk for bringing this in!) and Elementor Posts widget. All of them e. g. have the option for changing the amount of posts showing up, in Elementor you even have the possibility to select post types. All of them have those options in the sidebar. I think it is for good reason: You need way less clicks to change those settings and you can directly see all options at once.

[mapk]

For sticky posts the current UI seems to behave as a boolean (include, show only?), but we need three options (include, exclude, show only). Furthermore we need the option to "ignore_stickiness". @ntsekouras What are the planned options from code perspective?

From a design perspective, I did add those 3 options in a dropdown. Here's how I imagine the various display settings working from the toolbar. Icons would most likely need further iterations.

Post type
Each post type would be identified with an icon, and if none provided, we'd have a generic one for it.

Number of posts / Offset
This icon would change to reflect the numbers entered by the user.

Sort order

Pagination
I know there are conversations around adding more than one pagination block to the query, so by toggling this "on" would add a pagination block to the bottom (most common position) and also allow the Pagination block to show as a child block to add elsewhere within the query too.

Sticky posts
I've included the 3 options as suggested by @mariohamann.

[ItsJonQ]

Perhaps I may be overthinking things, but I think the designs may not accommodate more complex WP setups.
(But maybe those folks aren't the target users?)

What I mean by that would be folks with several custom taxonomies beyond Categories and Tags.
I think it gets trickier when taxonomy values are combined, like:

category:Apple, tag:phone, tag:budget, media_type:video, editorial_type:review

(just making up values above)

With the sidebar UI, we'd need to have 1 input per taxonomy.
(Not sure how it would work in the Toolbar, especially if values need to be combined).

That being said, I'm not opposed to anything. Just thoughts and observations from my side :)

---

For the Toolbar, I notice that it's showing custom icons for the Post Types.
I haven't looked into it, but I'm not sure how compatible the data from the REST API is with the editor (as far as icons are concerned, especially custom ones).

---

I have another question! Would the Query block support custom fields? 😱

If so, that makes it trickier considering the keys and values can be anything 🙈

(Not impossible. The UI just needs to accommodate the flexible nature of it :))

[mapk]

Thanks, @mariohamann! When I was exploring more robust filters, mixing the filters in the sidebar with the display settings was overwhelming. Now with more simplified filters, it might be okay to bring some non-essential settings back to the sidebar like sticky posts. It's good to keep these Gutenberg "best practices" in mind for informing the design.

The primary interface for a block is the content area of the block
The Block Toolbar is a secondary place for required options & controls
The Settings Sidebar should only be used for advanced, tertiary controls

So with that in mind...

"Toolbar option changes sidebar content.": The post type selector is responsible for the taxonomies showing up in the filter section. In my opinion this is lots of power for such a small button. :)

I think the Post Type is an important setting as well! It determines a lot of the other settings that can be used. Does moving it to the sidebar make it less important? Keeping it in the toolbar does give it more importance, but it's also a setting that once set is probably not often returned to.

To support the users, I think they definetely need good and verbal descriptions.

We might be able to provide descriptions in the dropdowns if needed.

Furthermore, I really like the icons in the toolbar, but they are very tiny and e. g. the 10/0 icon is not self-explanatory enough. I think verbal descriptions and labels would fit the complexity of this block a lot more than icons – and therefore I think the sidebar is perfect.

Icons aren't great at expressing changes and reflecting settings especially if they are new icons that users aren't familiar with. Moving it all to the sidebar seems to make the sidebar overwhelming and lessen importance of many values. Maybe post types should just be words as you suggested?

@ItsJonQ, thanks for chiming in!

With the sidebar UI, we'd need to have 1 input per taxonomy.

This is correct. I'm not all that familiar with taxonomies, or how often people have multiple taxonomies to choose from. Is this a common thing that could wind up showing 5-10 different taxonomies?

For the Toolbar, I notice that it's showing custom icons for the Post Types.
I haven't looked into it, but I'm not sure how compatible the data from the REST API is with the editor (as far as icons are concerned, especially custom ones).

This is correct. @ntsekouras has raised this issue as well. It's where I'd like to get to, but if it can't be achieved with the API, it will need to be displayed differently. Maybe just using words here instead of icons as @mariohamann suggested might work well.

I have another question! Would the Query block support custom fields? 😱

Great question. I not sure myself.

[mariohamann]

@ItsJonQ I think this block is perfect to overthink things (and needs it). 😄

With the sidebar UI, we'd need to have 1 input per taxonomy.

Two inputs. We need to seperate "Include" and "exclude" (e. g. including category:apple and excluding category:restricted). Here is an old draft we discussed.

I think the way @mapk shows above showing the main taxonomies (cateogry and tags) may be a very good one (as it may meet the expectations of about 98% of blogger...). And we could add "Advanced filters" with the Query Builder for the sophisticated rest of us. :) This would be inline with WP_Query where you can access those main taxonomies per default with cat (link) and tag (link)– and for the rest you need a more complex tax_query (link).

Custom fields: This would be just lovely. I think REST API can already handle them.

[annezazu]

As part of the fifth call for testing for the FSE, the experience around what lives in the toolbar vs the block's sidebar was mentioned as being quite confusing:

Having some query controls in the block toolbar and others in the block’s sidebar seemed confusing. Colocating them would seem more logical. I appreciate we’ve probably placed the “most common” controls in the toolbar for convenience but having to jump between locations when customising the query didn’t make for a smooth experience. Perhaps duplicate the toolbar controls into the sidebar?

EDITED TO ADD: This came up during the seventh call for testing as well as a point of confusion:

There’s a bit of a confusion point in the Query Block with Items per Page. Despite having multiple published posts only one appeared by default. I found the controls in the Block Toolbar to increase, but also found it a bit cumbersome to toggle between the Block Toolbar and Block Sidebar to refine the underlying query.

Currently, there is a lot of needing to jump around to both sets of settings. For example, you might want the block to display a certain category but only 3 posts from that category. To do that, you have to interact with the block sidebar settings first to set the category before then using the block toolbar to select the number of visible posts.

[mariohamann]

Currently, there is a lot of needing to jump around to both sets of settings. For example, you might want the block to display a certain category but only 3 posts from that category. To do that, you have to interact with the block sidebar settings first to set the category before then using the block toolbar to select the number of visible posts.

As I reasoned in detail in #25198 (comment) I still think it's much more intuitive to put every setting into the sidebar. Querying is complex, the block is complex, therefore hiding settings behind unfamiliar icons and distributing them across different places reduces usability.

(That's why I didn't use the toolbar in my prototypes.)

[annezazu]

More feedback around this experience has come up in the tenth call for testing for the FSE Outreach Program. This seems to be a repeated point of confusion:

Query Loop Block: this time I was able to set the number of posts shown in the query loop block as I knew that this setting was in the block’s contextual toolbar, yet I’d expect this feature to show on the main block sidebar, as it might be one of the most common things user look for, in my opinion.

[ntsekouras]

@jameskoster any design input for this? 🙇

[jasmussen]

There will likely be cases in the future where we have a particular control available both in the inspector, and in the block toolbar. I'm thinking for example background color options for the Cover block. Given that as a pattern, it could make sense to visualize what it might look like if a query options panel held these options, with the same contents of the panel duplicated in the block toolbar flyout.

[jameskoster]

Swimming the sea of Design Tools, I can't shake the idea that we might use that UX to create a query builder of sorts:

https://jameskoster.design/2021/10/07/concept-creating-a-query-builder-inspired-by-design-tools/

I know this is a much bigger thing, but I think we should be careful about arbitrarily moving things around without a clearer vision for where we want this block (and it's variations) to go. That said – and to Joen's point – if we wanted to put these settings in the Inspector in addition to the toolbar, I think that would be fine.

Edit: I opened a discussion for the query builder idea: #35760

[davewhitley]

To echo the past few comments on this post:

if we wanted to put these settings in the Inspector in addition to the toolbar, I think that would be fine.

Query Loop Block: this time I was able to set the number of posts shown in the query loop block as I knew that this setting was in the block’s contextual toolbar, yet I’d expect this feature to show on the main block sidebar, as it might be one of the most common things user look for, in my opinion.

Absolutely! It would be great to explore an advanced query builder, but I think the QL controls in the toolbar should at least be duplicated in the sidebar. That's where I first looked for those settings, and I didn't find them until several days later. I can imagine users might not ever find those controls if they aren't looking for them in the block toolbar.

I very much think of the block toolbar as an inline settings thing, like text appearance, paragraph alignment, width alignment, etc.