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: https://github.com/WordPress/gutenberg/pull/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: https://github.com/WordPress/gutenberg/pull/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]

Thanks, @kellychoffman! Here's an iteration of filters looking more like filters.

NOTES

• I researched how filters are used on other sites in this Figma file and they are primarily lists of checkboxes. Some include range controls and others as buttons.
• I went with checkboxes, but iterated on tags a bit to add some variation that related to how people often think of tags (ie. some sort of container with text in it).
• I added a section for "Applied filters" (still thinking about this). Normally filters are all displayed together somewhere easy for the user to see and remove if desired.

[mariohamann]

Feedback

1. First of all, I think the sidebar is the right place for those options!
2. I think, if a tag (or "taxonomy without hierarchy") is selected, on should always be able to unselect within the same area. In the last exploration, "CMYK" and "dodge" don't look clickable and it seems one has to use the "applied filters" area to uncheck.
3. I'm not sure, if the overview of "Applied filters" in its current state is needed and suitable. To make it work, every "applied filter" should display what kind of filter it is, as e. g. "portfolio" could be a tag or category, too.

Attached my proposal for unchecking "taxonomies without hierarchy":

And to get a better overview of "Applied filters" I would suggest to use the taxonomy area again – here are two possibilites: showing the amount of selected taxonomies or a small circle, indicating "Inside, something is selected" (I think Ghost Blocks uses a similiar approach for e. g. individual margins and paddings):

Some other thoughts

• As far as I understand, the query block should make it possible to show every Post Type – event Custom Post Types? ( I think this should be the top selection, even before "display settings". At the moment I can't find the selection field. :)
• Will it be possible to list "Taxonomies", too (using WP_Tax_Query)?
• Will it be possible to add individual query arguments, e. g. date queries, meta field queries etc.? What do you think about adding a field, where one could insert queries in JSON format or PHP arrays? Or a button like "Add other query argument" showing a modal with every possible core query argument?

At least for the last one I think I should add a new issue. :)

[aristath]

I still feel that the tag-selector would be a more suitable UI element for this... This block will have way too many settings, so making the UI a bit shorter will help users have a better overview without having to continiously scroll. And in case the "tag-selector" I previously mentioned wasn't clear, I meant this one:

It will allow us to significantly shrink the height of things and can be used for all taxonomies (categories/tags/others)

[mariohamann]

I still feel that the tag-selector would be a more suitable UI element for this...

You are absolutely right! Please ignore my suggestion. :)

[ntsekouras]

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

For start pagination should be available to be added in many places and that would happen from the user by adding the QueryPagination block. For example a user might want to add pagination both on top and on the bottom.. Having said that, there is the possibility that the show pagination would not be needed and controlled by wether the user adds the pagination block. I'll have to check it better in code though so take this lightly.

Critical & missing: Post-type

Yes, this is to be implemented in Query block.

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

This is indeed an option and something that will become more clear when support for taxonomy_relation and taxonomies will be implemented. This is a hard one because it would be really difficult (IMO) to make it understandable. For example if you we have only one input about taxonomies and want to filter by a tag and a category, how these would show inside the input? Like a term with a label green:tag, news:category? And what about then if we implement the exclude, that might probably want to. That would mean two taxonomy inputs, include and exclude.

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. This could be so overwhelming with many taxonomies and I don't believe it would work..

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

I hope this makes sense and if not please tell me to clarify.

I still feel that the tag-selector would be a more suitable UI element for this... This block will have way too many settings, so making the UI a bit shorter will help users have a better overview without having to continiously scroll.

I totally agree with this.

[aristath]

This is indeed an option and something that will become more clear when support for taxonomy_relation and taxonomies will be implemented. This is a hard one because it would be really difficult (IMO) to make it understandable. For example if you we have only one input about taxonomies and want to filter by a tag and a category, how these would show inside the input? Like a term with a label green:tag, news:category? And what about then if we implement the exclude, that might probably want to. That would mean two taxonomy inputs, include and exclude.

I apologize for not making what I meant more clear. I meant We should merge them under the same section, not the same control. So they would still be separate selectors, but they would all be like the tag-selector to save some space. Having them all in a single selector would be pretty messy and shouldn't be done. But instead of having filters ordered like

• Categories
• Tags
• Authors
• Taxonomies

it should instead be

• Categories
• Tags
• Product Brand (or whatever taxonomy name we have)
• Author

or even

• Taxonomies
  • Categories
  • Tags
  • Product Brand (or whatever taxonomy name we have)
• Author

[mariohamann]

• Taxonomies
  • Categories
  • Tags
  • Product Brand (or whatever taxonomy name we have)
• Author

I like this best and – based on my experience – it fits the approach of creating WP_Queries in PHP.

Edit: If this block is a "UI" for the WP_Query-Class (and I hope and think it would be great, if this is the goal?) concerning to WP Codex this MIGHT match the code, if a developer uses tax_parameters even for the default taxonomies Category and Tags. But for those default taxonomies it is possible to use category_parameters and tag_parameters as well. Therefore, taxonomy_parameters is more flexible and less specified. This leads to...

Variant A: If the query block uses category__in (21, 32) and 'tag__in' => array( 37, 47 ) for the default taxonomies and tax_query for every other taxonomy this would be the right one to hierarchically match the code:

• Categories
• Tags
• Authors
• Taxonomies

Variant B: If the query block uses tax_query for EVERY taxonomy (even default) this would be the right one to hierarchically match the code:

• Taxonomies
  • Categories
  • Tags
  • Product Brand (or whatever taxonomy name we have)
• Author

[aristath]

I like this best and – based on my experience – it fits the approach of creating WP_Queries in PHP.

It does, yes - and it's very dev-friendly. But it's not as user-friendly... A normal user doesn't know what a "taxonomy" is, they just want to add a category :laughing: It's a thin line we need to walk.

[mariohamann]

It does, yes - and it's very dev-friendly. But it's not as user-friendly... A normal user doesn't know what a "taxonomy" is, they just want to add a category 😆 It's a thin line we need to walk.

Hm, that's right. But would you say, someone using the "Query Block" and its deeper settings is a "normal user"?

[mariohamann]

In my opinion it is very important to split "Order" and "Orderby":

• Order should only contain "Ascending ▲" and "Descending ▼"
• Orderby should at least contain "title", "date", "modified", "comment_count" and even "random". Personally I would love to see "meta_value" and every other possible option described in Codex as well. :) By the way: Theoretically it is possible to add an array of orderby parameters... but maybe that's something for later versions. :)

[aristath]

Regarding random order, it's a tricky thing and I don't know if it should be available by default... Various hosts (including WPEngine) disable random ordering so perhaps that should be opt-in via a plugin. Or even opt-out via a PHP constant so hosts can just disable it if that is their policy.

[mariohamann]

Regarding random order, it's a tricky thing and I don't know if it should be available by default... Various hosts (including WPEngine) disable random ordering so perhaps that should be opt-in via a plugin. Or even opt-out via a PHP constant so hosts can just disable it if that is their policy.

Interesting! I have to admit that I never used this parameter, but I thought that it may be interesting for some contexts. Thank you for this worthful clarification!

[ntsekouras]

But would you say, someone using the "Query Block" and its deeper settings is a "normal user"?

It probably will be used more from theme developers and the goal is to have some block variations like latest posts to be more user-friendly for common cases.

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

I just wanted to drop this here again for some thoughts..

There are only partial support for sorting by WP REST API. random I know for a fact that will not be implemented and has been discussed in core a lot, for performance issues. I have raised the issue about the supported options in core slack here: https://wordpress.slack.com/archives/C02RQC26G/p1598860035004400

[fklein-lu]

Assuming that the Query block mirrors the WP_Query class, a challenge that I see is whether users understand that these are all and filters, not or.

To illustrate let's take this query:

$posts = new WP_Query( [
    'category_name' => 'foo',
    'tag' => 'bar',
] );

Quite often developers think that this retrieves posts that either have the category "foo" or the tag "bar". But what it really does is get posts that both are in the "foo" category and have a "bar" tag. To have an or query, you need to use a tax_query.

I'm not sure how we could have an interface that does reflect this. I remember Jetpack's Widget Visibility feature having similar challenges for determining on which pages widgets should be displayed.

There are also other behaviours that are easier to understand in code, but difficult to represent. For example I can have this query:

$posts = new WP_Query( [
    'category_name' => 'category__not_in',
] );

This will show all posts, except the ones with this particular category. I'm not really sure how a UI could represent that.

[mapk]

I'm catching up! Thanks for this back and forth discussion, everyone! ❤️

I think, if a tag (or "taxonomy without hierarchy") is selected, on should always be able to unselect within the same area. In the last exploration, "CMYK" and "dodge" don't look clickable and it seems one has to use the "applied filters" area to uncheck.

@mariohamann, I hadn't shown the interaction yet, and probably should soon. The tags in that section would be clickable to deselect them again for sure. I agree with your request here. 😄

I'm not sure, if the overview of "Applied filters" in its current state is needed and suitable. To make it work, every "applied filter" should display what kind of filter it is, as e. g. "portfolio" could be a tag or category, too.

I think this is actually really important here. Because these are filters being applied to the results, getting it as close to a common filter pattern used throughout the web would be good. For example, take a look at this site, and notice that applied filters are highlighted at the top. Also notice they don't indicate what "type" of filter they are. It's a great way for the user to quickly see all the filters they've applied in one area.

And to get a better overview of "Applied filters" I would suggest to use the taxonomy area again – here are two possibilites: showing the amount of selected taxonomies or a small circle, indicating "Inside, something is selected" (I think Ghost Blocks uses a similiar approach for e. g. individual margins and paddings):

I like those mockups you did! However, when the modules are all opened, they are still so spread out that it's difficult to tell just what filters are being used.

I still feel that the tag-selector would be a more suitable UI element for this... This block will have way too many settings, so making the UI a bit shorter will help users have a better overview without having to continiously scroll.

@aristath, as a user, it's nice to see a list of items available to select from. I can't possibly remember all the tags on my site. For this reason, exposing this list somehow is important. However, it could be argued that when a user is building with this block, or a variation, they already have a in mind the specific filter they most likely want to use. 🤔

I do think the tags could be iterated to resemble the Categories with a list of checkboxes possibly. I just went with a group of tags alphabetically because it resembled a "tag" feel and broke up the list of filters with lists. 😉

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

@ntsekouras let's work through this together soon. I'd like to try this out, but need a few more details. Maybe we can hop on a zoom call and discuss it while I build it in Figma.

This will show all posts, except the ones with this particular category. I'm not really sure how a UI could represent that.

@fklein-lu you're right. I've only scratched the surface of the "not include" UI.

a challenge that I see is whether users understand that these are all and filters, not or.

I agree. However interaction will reveal this pretty quickly I imagine. As the user makes filter changes, the list updates in the editor providing the user real time feedback for how the settings are being applied.

[mariohamann]

I would love to see something like this:

Especially with some MAGIC-VARIABLES like %today%, %current_year% etc., combined with a good documentation and examples I think this would be just great! (And maybe it helps to make the UI of the block lighter and to focus on the most important elements, but still make the block very flexible).

[aristath]

I would love to see something like this:

The "custom arguments" thing would actually be pretty amazing... And could possibly help with https://github.com/WordPress/gutenberg/issues/25377 too :+1:

[ntsekouras]

I would love to see something like this:

I think this would cause more problems that it would solve:

1. This seems like an option for super super users :) It makes the feel of this block much more complicated.
2. The REST API doesn't support many things from WP_Query and that could result to errors that users wouldn't understand why it's not working. They could try many params and might lead to even frustration? Personal thoughts here..

Tax Query needs to be implemented and will, but needs to do it under the hood and hide that complexity.

[mapk]

Taking in more of this feedback, I've worked on an incremental change.

• Added Post Types
• Added Search Terms
• Iterated on the Tags UI

[mapk]

Applied filters

The applied filters act as a single area to identify all filters being applied to the query.

Feedback

• Should we show a msg when no filters have been applied as in the example above?
• Should we just hide that accordion module if there are no filters?

[munirkamal]

Hey @mapk

This is really coming out nice. Just a little feedback on your latest version.

I suppose the first thing to choose in the query block is the 'Post Type' then based on the selected post type you need to present the relevant 'Taxonomie' to choose. And then, finally, display the option to select specific 'Taxonomy Terms' based on the chosen 'Taxonomie'.

Not, sure if you have this already considered. The current design displays options to choose 'categories', 'tags', and even custom 'taxonomies' irrespective of the post type.

Hope you get my point.

[mariohamann]

Personally I'm a bit uncertain if the current way matches real needs and expectations. Therefore I would like to provide different use cases, to see if the UI fits them. I don't want to bring in further complications, but I think this block will be very important and therefore it should be build on a solid and scalable foundation.

Use Case 1: FSE – Blog-Archive

Description

Backend user wants to build a shiny theme. Therefore s:he edits the blog archive and would like to make the newest post bigger (as e. g. on WP Tavern). Of course on the second page the first item should be as big as the other posts.

Expected behaviour

The user visits the archive.php-settings and iserts two Query blocks. (Is this right? In fact that would be mine and one of mine @aristath 's https://github.com/WordPress/gutenberg/issues/25462#issuecomment-695978346 expected behaviour :) )

• Block 1: Items per Page: 1 and Pagination: OFF. Everything else should be default or inherited.
• Block 2: Items per Page: 9, Pagination: ON, Offset: 1. Everything else should be default or inherited.

Questions arising

• For sticky posts: Should there be three options like Include/Exclude/Only? (e. g. if someone wants to show only sticky posts)
• Is it ensured, that there will be only one "Pagination"-block that uses the arguments from Block 2 (especially the offset)? Maybe "Used for pagination" would be better? Or should the pagination block autoamtically select the last query block? Or you could select a query block in the pagination block?
• Will those settings be used for taxonomy/author archives as well? Does the user have any possibility to change the behaviour, e. g. that the first post shouldn't be bigger as the others on those specific archives?
• Will filter options be locked or invisible in FSE? I see a lot of problems coming if users select taxonomy filters as they would break the complete logic of specific archives.
• Of course there should be no option to select different Custom Post Types in FSE – I think?
• Therefore: Should all those settings be in scope of FSE and Query Block or are especially the filter settings more a "Theme thing" – and the Query Block inherits EVERY argument?

Use Case 2: FSE – Archive of Custom Post Type "Person"

Description

The user wants to style the appearance of the Custom Post Type "Person" which is provided by a plugin. The plugin provides some custom taxonomies e. g. "Department" and "Position" (e. g. Trainee, Employee, External). S:he wants to show every person and order them from A–Z, overwriting the plugin's/WP default being "Publishing Date Descending".

Expected behaviour

The user visits the person-archive.php-settings and inserts one Query block. S:he changes the settings to orderby: name and order: ascending". Furthermore s:he sets Items per page: 0 to get every person.

Questions arising

• In addition to the questions above I ask myself: If Items per page: 0 is set, will the option to paginate be invisible as it has no effect? Will there be a warning that this could break the page while loading if there are a lot of persons to display?
• The Custom Post Type has no option of "Sticky Posts" – will this option be invisible?
• Will there be an option reset the settings, taking default from plugin? And: Do have plugin authors the option to set the "default" state for the query block? (In this case A–Z make a lot more sense.)
• Again I think that there should be no option to select specific taxonomies to prevent the bevhiour of specific archives.

Use Case 3: Page Editor – Blog posts in "Hall of Fame" of specific tag

Description

Now it's getting interesting. We are leaving FSE – the backend user wants to dynamically provide the most discussed posts of the Tag "UX" on a static page.

Expected behaviour

The user adds a new page, writes some text and adds the Query block. S:he – deviating from standard – selects Post Type "Post" (Okay, maybe this is default :)), Items per Page: 3, orderby: comments. Furthermore the Tag "UX" is selected.

Questions arising

• The user exactly knows, what kind of tag s:he wants to select, as this selection is "content" driven. S:he always selects tags with the current tag selector – why should this behaviour change in this block?
• Should the option for pagination be hidden here? In my opinion there is no possibility this could work outside of FSE despite of implementing some AJAX functions – and I'm pretty sure this is no option at the moment... :)
• Making it one step harder: Show the most commented posts of 2018. (I would still love to see a JSON-inserter for for such cases. ;))

Use Case 4: Page Editor – Department page showing their "newest trainees"

Description

The last and maybe most interesting one. A department wants to motivate people to apply for an internship. Therefore, they want to show their current trainees dynamically. (Again the Custom Post Type "Persons" is used.)

Expected behaviour

The user adds a new page, writes some text and adds the Query block. S:he – deviating from standard – selects Post Type "Person", Items per Page: 0, orderby: date, selecting Department: "Design" and Position: "Trainee"

Questions arising

• The Post Type "Person" has no "Category" and no "Tags", therefore those two taxonomies shouldn't be shown?
• Instead the taxonomies "Department" and "Position" are needed (as described by @munirkamal https://github.com/WordPress/gutenberg/issues/25198#issuecomment-696565743 while I was writing this comment :D). The first one being with, the second without hierarchy. Again: In my opinion this should match the current interfaces, being "Checklist" for hierarchical and "Combo box" for not-hierarchical.
• Making it again one step harder: Show trainees with meta-field "employed: TRUE" → Still voting for JSON field. ;)

Interim conclusion

• The Query block is a complex one – I think it's settings need to be very dynamic depending on context (FSE, Page Editor) and selected Post Type.
• Personally I would try to match known UX interactions as best as possible, so the users immediatelly know: "Here I select my tags – like in the Post editor", "Here I can select my categories". Furthermore I'm not sure, if an unordered list of e. g. 100 tags without the possibility to search would be ideal (thinking of a WooCommerce shop I developed where the Shop manager added such a big amount of tags...), especially in terms of a11y (In fact I have to admit I don't know how accessible a combo box is...).
• In my opinion, the applied filters section is not needed.
  • If for unordered taxonomies a combo box is used, the user directly sees the selected the options. If we use the same list for ordered taxonomies, the selected categories will be at the top (mayber after saving – but that's the current behaviour when selecting posts).
  • Furthermore you would have to show, to which Taxonomy a single Term belongs ("is it Category? A Taxonomy? A Department? A position?)
  • I think it's strange that you can uncheck such filters in an backend at two positions.
• What about the possibility to insert single items (e. g. with Post ID), as in the WooCommerece Product block?
• I think you should add "Order" and "Order by" to display settings, too. (And please divide them. :))

The examples you have shown @mapk are from shops and I think this is a complete different use case.

• Shops want to show what they have, want to give possibilities. Shoppers use filters to look for specific items or to poke around. For frontend users, e. g. the tag-selection and the overview of applied filters as shown above would be great, because they switch those filters fast and often.
  • Query block users in my opinion don't poke around, trying to find a specific block. They are content driven and they know their content. If the block works as expected, they select their options and are done. They don't do a lot switching back and forth – I think?

As especially the filtering is very complex – maybe we should start with the display settings to provide the block for FSE and add the filter options later on?

[mapk]

I suppose the first thing to choose in the query block is the 'Post Type' then based on the selected post type you need to present the relevant 'Taxonomie' to choose.

@munirkamal, great point. I've noted for the next iteration that the Post type will directly impact the filter options. 👍

@mariohamann I love those user flows! Thanks for wrangling that. You've got so many good points and questions that I'll try to address.

The Query block is a complex one – I think it's settings need to be very dynamic depending on context (FSE, Page Editor) and selected Post Type.

Yes, I agree! This particular block is meant as a base block that would include all the settings that a block like this might need. For more targeted flows, as you've listed above, we'd most likely have a block variation of this one that would align better. For example, the Latest Posts block will be a variation of this one specifically focused on Posts, most likely sorted by publish date.

Furthermore I'm not sure, if an unordered list of e. g. 100 tags without the possibility to search would be ideal

This could be solved by including a search field which I'm not opposed to. But I think adjusting the UI to mimic a filtering system is still relevant here.

In my opinion, the applied filters section is not needed.

I understand your reasoning. Keep in mind there may be many screen sizes for which not all filters are visible on screen. Having them listed in one area helps alleviate this and provides a high level, easy review of what the block is filtering. I'm pushing for this because I believe its beneficial, but I'm open to opposition! If it proves unnecessary, we can easily pull it out.

Furthermore you would have to show, to which Taxonomy a single Term belongs

This more meta information can be found in the specific filters below. Adding that information here could cause it to become more messy, but it's worth an exploration. I'll mock this up.

I think you should add "Order" and "Order by" to display settings, too.

Do you think this is important enough to get into the first iteration of this block?

Query block users in my opinion don't poke around, trying to find a specific block.

While they may not be looking for a specific block (except in your use case 1, block 1) they are looking for a specific list of content. Turning on/off filters to get that content right could be an exploration for them. I doubt they do a lot of switching filters once they're accustomed to how the filters change their results, but getting to that happy place might involve toggling several settings.

As especially the filtering is very complex – maybe we should start with the display settings to provide the block for FSE and add the filter options later on?

I like that you're pushing for an MVP (minimum viable product). But I think the filtering is going to inform the block variations (and vice versa) as we continue. This means I'd like to nail down most of the filtering in this block right away since its providing the base to these other blocks. Please keep the feedback coming!

[ntsekouras]

Hey @mariohamann ! - Thanks for the detailed comment!

The examples you have shown @mapk are from shops and I think this is a complete different use case. They are content driven and they know their content

how these would show inside the input? Like a term with a label green:tag, news:category I believe it too and arises more UI problems as I have mentioned above(https://github.com/WordPress/gutenberg/issues/25198#issuecomment-693298641) about how to distinguish the filters. A tag can have the same name with a category and a custom taxonomy.

I think you should add "Order" and "Order by" to display settings, too.

Order settings are Query settings and not display settings.

@ntsekouras let's work through this together soon. I'd like to try this out, but need a few more details. Maybe we can hop on a zoom call and discuss it while I build it in Figma.

I think @mapk we should explore the option I propose as well. It might be more technical but I think will cover all the complexity of Query taxonomies.

As especially the filtering is very complex – maybe we should start with the display settings to provide the block for FSE and add the filter options later on?

Since there are many things to answer and consider, I think this a good direction. I have in mind to start adding some more display options to PostBlocks to enhance the current functionality/experience with Query block. Related PRs here: https://github.com/WordPress/gutenberg/pull/25341 (merged) https://github.com/WordPress/gutenberg/pull/25412 (needs review)

This doesn't mean to not progress Query block, but both being worked in parallel.

[kellychoffman]

Design feedback:

• Now that we have a handle on what settings to include, this might be a good time to see the design in the add and edit flow to make sure both are intuitive. (Meaning, seeing this in context will help inform and prove some of the decision decisions rather than continuing to view the sidebar and toolbar settings in isolation)
• Seeing what filters are applied is going to be very useful, but it needs to be more apparent that "Applied filters" applies to all filters below. Overall, the hierarchy of the sidebar could be a bit more clear.
• 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.