Feedback on Query Loop Block settings language

[annezazu]

What problem does this address?

As part of the fifth call for testing for the FSE Outreach Program, the following feedback was shared highlighting how confusing it is to have mentions of pages showing when working with posts:

Should Max page to show read plural Max pages to show?
Items per Page doesn’t make a tonne of sense in a context where you might be adding multiple query blocks to a given “page”. We should consider calling this “Items to show” or similar.

This confusion led to not understanding how to use the setting itself as it's unclear what this setting actually controls particularly when using the Query Block to display posts:

I couldn’t work out how to make Max page to show work at all. I assume there’s a way to get pagination to show up? It wasn’t clear.

What is your proposed solution?

A few proposed solutions:

• Change the phrasing from "Max Page to Show" to something a bit more coherent/clear
• Remove "Page" language and use "Items" instead or have it be able to adjust depending on whether you're working with posts or pages.

I'm also a bit confused as to whether this setting somehow impacts the Pagination Block and if we should note that one needs to be added.

[annezazu]

More feedback on this setting as well from the tenth call for testing for the FSE Outreach program:

When selecting ‘Display settings’ one can set the number of items per page. But actually you pick the number of items in the column if you choose a layout with multiple columns. May be easier to understand if ‘items per page’ would be renamed to ‘items per column’ or something similar.

Seems like the safest option might be saying something like, "Items per query" or something similar.

[ntsekouras]

I commented in the post by I think the above feedback refers to Offset Query Loop pattern that has two Query Loop blocks inside a Columns block.

[annezazu]

That's correct!

[sereedmedia]

Per @annezazu's request to post my feedback here:

I feel that language like “Inherit query from template” is part of the problem for consumer adoption and provides some of the confusion over who FSE is being built for. The average WordPress developer knows what a "query" is or what "inherit" means. The average WordPress user does not (in my experience, which is, admittedly, primarily American). They may of course know the word in other contexts, but IMO the friction of having to reason that out is the difference between developer-focused language and consumer-focused language.

I don't have a specific suggestion for that phrase, but this is something I see throughout FSE. A lot of the language could be simplified or revised/standardized (e.g. calling the block inserter the "Block Panel" or "Block Inserter").

Ideally the language throughout the Site editor could simplified with more context (for the original example, it could be something like "Use the same content request this template is using".)

A further example: Currently there are tool tips, but the tool tip is the official language.

It could be that the tool tip was more focused on the user action rather than the technical action (e.g. "Add a block" or "Open Block Panel" vs. "Toggle block inserter").

TL;DR Developers can effortlessly understand simpler language, but beginning/non-dev users cannot effortlessly use the more formal, code-based language. If the goal of FSE is to be useable for non-dev users, then the language needs to reflect that.

[annezazu]

Agreed on the complexity of the query loop block. The intent has been for it to be a more advanced user/developer tool but, until Query block, Latest Posts block and Post Lists block are consolidated to provide better alternatives for end users, we're still going to run into this exact confusion: #32332 I'm going to see if we can get this emphasized more in the latest query loop block tracking issue: #41405 (comment)

[noisysocks]

Would love design input on a solution here.

[annezazu]

@WordPress/gutenberg-design for good measure :)

[jameskoster]

I still think the long term solution here is to make Query Loop a template-only block (that always inherits), and that we should provide contextual variations for registered post types. This simplifies everything by not forcing the Query Loop UI to entertain both use cases.

[michaelpick]

Thanks for inviting feedback on this, @annezazu! Francisco and I took a look and have shared a few ideas below. Happy to follow up on anything below or otherwise! As it’s quite an expansive block, let me know if there are any specific areas you’d like us to take a closer look at!

---

Initial state

I think there are a few things we could possibly improve here:

• On the UX side, is there more we could do to reduce the cognitive load of facing a blank slate with not a lot of guidance on what to expect at the other end of either click?
  • One way might be to reconsider the initial state altogether when the block’s invoked. For example, is there a way we could present a gallery of patterns first and include a ‘Start blank’ as the first option in that gallery rather than driving them to open the modal and ‘Choose’ or ‘Start blank’?
  • The subsequent pattern modal selection feels quite disconnected from the main editing experience in the current state. Could pattern selection be integrated into the editor, maybe as a sidebar or expandable panel or similar?

On the copy side, if UX changes aren’t ideal for now, I’d suggest the next best thing would be better signposting and expectation setting:

• Block title: how committed are we to calling this the Query Loop block? I appreciate that seasoned WPers will understand both terms and this may be levelled at advanced users, but if we want to make it feel more intuitive for the no-code crowd, could we be more descriptive? I’m not in love with any of the below options or 100% there’s a simple two-word title that will carry this much weight, so it could be that a supporting line of supplementary copy would help, but here are a few quick ideas in case it sparks further conversation:

  • Content Aggregation Block
  • Content Display Block
  • Content Loop Block
  • Filter and Display Block
  • Content Highlights Block
  • Filter and Highlight Block

• Potential supporting copy: it may help to follow the current or alternative block title with a short one-line description to better situate the user and set clear expectations. A few ideas for that:

  • Find, aggregate, and display a range of site content with beautiful design patterns.
  • Filter by author, post type, or category and display content from around your site.
  • Search, filter, and display content from around your site—from a list of authors to the latest posts in a category.

• For the current call-to-action: ‘Choose a pattern for the query loop or start blank’, and the accompanying buttons (Choose / Start blank), there are a couple of ways we might be able to set clearer expectations. Ideas:

  • More descriptive buttons, no description:
    • ‘Select a ready-made layout’ / ‘Create a custom layout’
    • ‘Choose a design pattern’ / ‘Create your own layout’
  • A clearer call-to-action with slightly simpler buttons:
    • Choose a ready-to-go design pattern or build your own layout from scratch: [[Choose a pattern]] / [[Build with blocks]]
    • Start by creating a layout for your {query loop} content with a ready-made design pattern, or build your own from scratch with blocks.
  • [[Start with a pattern]] / [[Start with blocks]]
  • Let’s create a layout for your content. You can pick a pattern, or build it from scratch with blocks.
  • [[Pick a pattern]] / [[Build with blocks]]

Start blank screen

If the user clicks the ‘Start blank’ option, they’re presented with 4 variations to begin building from, directly in the editor:

• Title & Date
• Title & Excerpt
• Title, Date, & Excerpt
• Image, Date, & Title

From a UX point of view:

• The current descriptor ‘Select a variation to begin with’ doesn’t entirely tally with the previous step’s ‘Start blank’, as it’s not entirely blank.
• It also isn’t entirely clear to me how content and design fit together with the specific query I select at a later step. We’re asked to make layout decisions before we’ve had chance to define the content to display, which feels counterintuitive in terms of sequencing. The same could be said for the previous step.
• In addition to the in-editor content, the sidebar provides a descriptor of the block: ‘An advanced block that allows displaying post types based on different query parameters and visual configurations’, which further adds to the cognitive load of understanding the block function and initial layouts before digging into the specific, immediate use case. It feels a little abstract and potentially overwhelming as a consequence. The layout toggle adds additional consideration at this early stage where we’d ideally want to optimize for immediate, sequential action given the functional complexity of the block.
  Is there a better way we could sequence the experience to allow us to put content first and have design decisions pared to match, or are use cases too broad for this to be possible?

From a copy point of view:

• Main editor current copy: ‘Select a variation to begin with’. Suggested variations:

  • Get started with a base layout to display your posts*.
  • How would you like to display your posts*?
  • Choose a base layout to display your posts*. You can customize and build on it afterwards.
  • Pick a basic layout to start with. You can customize it afterwards.

• Sidebar current copy: ‘An advanced block that allows displaying post types based on different query parameters and visual configurations.’ Suggested variations:

  • Display and feature posts* with granular control over the content and layout
  • Filter, display, and feature your posts* with control over specific content and layout options.
  • ((I shared a few alternatives in the previous section, too))

*If 'posts' isn’t all-encompassing enough, we could swap out for ‘content from around your site’

In-editor settings

UX and copy collide somewhat for this one, and lots of the feedback shared previous was around the choice of labels here.

• Current labels are: ‘Items per page’, ‘Offset’, ‘Max page to show’

Suggestions for potential alternatives:

• Content items per page / Skip first (x) items / Total item limit
• Items per block / Start from nth post / Maximum items to display
• Number of items / Offset first item / Item limit

Current supporting copy: ‘Limit the pages you want to show, even if the query has more results. To show all pages, use 0 (zero).’

Suggested alternative: ‘Set a maximum number of items to display. Enter to 0 to show all available items.’

Inherit query from template toggle and other sidebar items

This is another one that came up in feedback above.

Current copy: ‘Inherit query from template’

Suggestions:

• Use template’s content selection
• Use your template’s default content selection
• Use your template’s default settings

Post type

Current copy:
WordPress contains different types of content and they are divided into collections called “post types”. By default there are a few different ones such as blog posts and pages, but plugins could add more.

Suggested variations:

• Select the post type you’d like to filter and display. By default WordPress makes use of posts and pages, but others may be available here if they’ve been added with a plugin.
• Select an available post type supported by your site.
• Select which post type you’d like to display with the block.

Sticky posts

Current copy: ‘Blog posts can be “stickied”, a feature that places them at the top of the front page of posts, keeping it there until new sticky posts are published.

Dropdown menu options: Include / Exclude / Only

Suggested variations:

• Any post can be marked as sticky. Sticky posts appear above the latest posts on your blog.
• Include, exclusively display, or exclude posts marked as ‘sticky’, which typically appear at the top of your blog regardless of when they were published.
• Include or exclude sticky posts from those displayed in the block. Or display only sticky posts.
• Include or exclude posts marked as sticky from those displayed with the block. Or display only posts marked as sticky.

Force page reload

Current copy:
Browsing between pages won’t require a full page reload, unless non-compatible blocks are detected.

Notes:
I’m unsure if this means between items within the block (vs. pages), or specifically pages? It’s a bit odd to have the section title and description describe opposite things, so it would be better to align them. I’d like to understand why I would use this, though, to better convey that.

Potential variation (pending discussion of above):
Reloads the page when browsing between pages of items. This can help with incompatible blocks. ((<-- Is that the reason?))

Filters

I wonder if this section would be clearer with a couple of tweaks?

Suggestion 1:

Filter by:

• Category
• Tag
• Author
• Word or phrase ((Alternative: Search term))

Suggestion 2:

Filters

• Filter by category
• Filter by tag
• Filter by author
• Filter by search term

---

Let me know if we can clarify, expand, or iterate anything! Hope some of this helps!

[jameskoster]

@michaelpick this is great, thanks for your feedback and suggestions.

There's some activity around updating the 'Inherit query from template' and 'Force page reload' controls, it would be great to get feedback in these specific issues:

• 'Inherit query from template' setting is confusing #63598
• 'Force page reload' setting is confusing #63599

[michaelpick]

Hi @jameskoster, and sorry for the late reply, I was out for a few days. I'll take a look ASAP!