-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Description
The Posts List block improves the user-friendliness of the Query block in terms of discovery. But beyond that it is problematic because the underlying Query block (and all of its associated complexity) is exposed upon insertion.
- It is confusing to click one block in the inserter, and see a totally different block(s) inserted on the canvas.
Features like pagination will not work correctly on a post or page – this is a feature for templates only- Inheriting the query from the URL is useless in this context, and the current UX feels broken
Here's a quick video highlighting these problems:
posts.list.mp4
As you can see, when the Query inherits from the URL, the front/backend does not match. Also, the pagination doesn't appear on the frontend which feels buggy. It's just a confusing experience all-round.
It would be interesting to extend the variation so that it retains its "Post List" name post insertion. Since pagination will not work in this context there is scope to simplify the block structure by removing the confusing Query Loop, and restricting which blocks can be inserted inside the posts list. In a similar vein the "inherit query from URL" option can be hidden in the Inspector. Even the filtering options can be simplified as we wouldn't need to ask the user to specify which post type to display.
Thinking a little further down the road, a dedicated block for displaying post
s opens the door to:
- More targeted block pattern suggestions that focus on
post
s. - Other post-type specific variations to improve the UX
- Hiding the Query block in the post editor altogether
- Optimising the Query block for the template editing experience rather than having to entertain a dual purpose