New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Iterations on "Latest Posts" Block #1594

Open
melchoyce opened this Issue Jun 29, 2017 · 51 comments

Comments

@melchoyce
Copy link
Contributor

melchoyce commented Jun 29, 2017

This description has been edited — please see issue history for older mockups!

Why

In preparation for working on page templates in Gutenberg, we'll want a robust set of dynamic blocks that can be dropped into any post or page. Expanding this block will put us in a better position to tackle more complex dynamic or global blocks in the future.

Users shouldn't have to know how to write custom queries or understand the loop to add some posts to their homepage. The Recent Posts block is a great start, but to be a fully functioning solution, it needs to support more than titles and post dates.

What's changed

Before

image

image

After

recent posts list all

recent posts grid all

  • Added support for featured images, post content and excerpts, and post meta.
  • Reorganized the sidebar settings into groups.
  • Used the new Toolbar grouping design (unsure if this has been implemented yet).
  • Updated the icons, but this is optional, we can continue using the existing Dashicons for now.

View the complete prototype.

Next steps

  • Featured image support, in its own sidebar section. (WIP: #13698 )
    • Include core image size controls.
    • Include core alignment controls.
  • Post content support, in its own sidebar section.
    • Toggle on/off post content.
    • When post content is toggled on, choose between excerpt or full post. (Am I missing a default core option? If it's just the two, maybe this should be a radio button instead).
    • Slider to control excerpt length when the excerpt is selected.
  • Post meta support, in its own sidebar section.
    • Move "Display post date" into here. #13698
    • Add toggle to show/hide post author. #13698
  • Organize settings
    • Move "Order by" and "Category" into its own sidebar section, "Sorting and Filtering." #13698
    • Group "Number of posts" and "Columns" (when grid is selected) into their own sidebar section, "Display Settings." #13698

Future iterations

h/t @paaljoachim for a couple of these suggestions:

  • Expand on taxonomy offerings, like tags.
  • CPT support.
  • A way to update the "read more" text.
  • A way to rearrange all the elements inside of the block — move up meta, move featured image below title, etc.
  • Potentially display comment information (like # of comments).

Note to new contributors

This issue itself is big but can be divided into smaller tasks which should be a great way to start contributing to Gutenberg with code. If you want to help please leave a comment and we will discuss what would be the best next step.

@melchoyce melchoyce added the Design label Jun 29, 2017

@westonruter

This comment has been minimized.

Copy link
Member

westonruter commented Jun 30, 2017

I love this. Pairing these initial display attributes with eventual query attributes will be extremely powerful. I agree that adding query attributes could be a separate issue, but it will be amazing to have a component that allows for query building. Imagine a UI that allows you to construct the params for WP_Query. Not only would that allow for the block to pull posts from multiple post types, but there could also be a UI for selecting specific posts to show in a specific order, and as such it would be a curation block as well. Maybe that should be a separate block type.

@brentjett

This comment has been minimized.

Copy link

brentjett commented Jun 30, 2017

I love the idea. My only thing is it should be as close to effortless for theme authors to support as possible. If it can output all the layouts without any styling burden on the theme then 💯

This could be a great way to accomplish "related posts" blocks (echoing what Weston said above about curation)

@paaljoachim

This comment has been minimized.

Copy link

paaljoachim commented Jun 30, 2017

Actually prettifying the archive block as well would be helpful.
#1464

@StaggerLeee

This comment has been minimized.

Copy link

StaggerLeee commented Jun 30, 2017

Would be perfect for Related Articles (manual, not by tags). Just one search field at the top (Post setting is best place for search) where we could type title of Post, and make Related Articles block after all content.

Still I find it as more used than simple listing of Latest Posts. If navigation and structure of website is done well Latest Posts blocks are not needed.

Have to say all the time, it is my personal experience. I dont know how others use it, and how much.
I never used Latest posts widget. Used several times Related Posts plugins, or ACF field for it.

@melchoyce

This comment has been minimized.

Copy link
Contributor Author

melchoyce commented Jun 30, 2017

agree that adding query attributes could be a separate issue, but it will be amazing to have a component that allows for query building. Imagine a UI that allows you to construct the params for WP_Query.

This is what I love about the Make theme from Theme Foundry! It allows someone like me, who struggles with development, to build a more dynamic site. I think this is one of the reasons themes like Make and Divi are so popular — you can build pretty decent sites for clients even without a whole lot of development experience. So many of the freelancers I encounter are jack-of-all-trades, rather than specialists, and rely on themes and plugins to do the heavy lifting. If we make this easier and standard in core, we open up a lot more opportunities for folks with broad skills to make a living using WordPress.

Have to say all the time, it is my personal experience. I dont know how others use it, and how much. I never used Latest posts widget.

I haven't really used it either, because IMO it's not particularly useful in its current form. This is why I think we should enhance it. Imagine building a homepage where you have a nice cover (hero) image at the top, a list of services, and then some of your latest news posts in a grid. Previously you either had to build this yourself, or find a theme that does it — and even then, setting up themes can be super hard. Hopefully blocks can make something like that much easier.

@celloexpressions

This comment has been minimized.

Copy link

celloexpressions commented Jul 3, 2017

there could also be a UI for selecting specific posts to show in a specific order, and as such it would be a curation block as well. Maybe that should be a separate block type.

I opened #1651 for this. This is where menus can be integrated with widgets and editor blocks.

@folletto

This comment has been minimized.

Copy link

folletto commented Jul 3, 2017

it will be amazing to have a component that allows for query building

If we make this easier and standard in core, we open up a lot more opportunities for folks with broad skills to make a living using WordPress.

What if it's a reusable sidebar "panel" that can be added inside the inspector sidebar, so we can design it once, and any component that does queries can show that. Universal, standardized, yet allows each component to decide what to do with that data?

@melchoyce

This comment has been minimized.

Copy link
Contributor Author

melchoyce commented Jul 4, 2017

What if it's a reusable sidebar "panel" that can be added inside the inspector sidebar, so we can design it once, and any component that does queries can show that. Universal, standardized, yet allows each component to decide what to do with that data?

Having trouble understanding your idea — can you draw up a quick sketch?

@folletto

This comment has been minimized.

Copy link

folletto commented Jul 4, 2017

gutenberg-standard-posts-filter

It's ugly as hell, and I would probably never ship something like this but yeah, just to give the idea...

In short, it's a "WP Query Panel".

It's an API, provided by the Editor, that any block can make use of. Any block that filters content can just declare "show that Filter Content UI" and they have it, without any need to write it from scratch. It's basically a way for the block to say "give me a list of posts for me to work on, and show the standard UI to the user".

It can start super simple (just number of returned items and sorting maybe? or just categories?) and then it can evolve and become as complex as research will tell us to evolve, the limit being just the power of WP_Query.

Benefits:

  1. Any developer that needs to get content in their block, can simply implement it, without having to program the UI from scratch.
  2. If WordPress updates and there are upgrades to the UI of the "Filter Content" panel, every block that makes use of it will get automatically upgraded too.

Cons:

  1. I can't see any cons to this approach, except deadlines: we might want something VERY simple to start with, so Core and new block plugins can use it, and then start upgrading it over time as it can blow up in a fairly complex UI.

I hope it's clearer.

@westonruter

This comment has been minimized.

Copy link
Member

westonruter commented Jul 8, 2017

@folletto Eventually, what about this WP Query Panel being similar to the Inserter? All of these fields you have mocked here could be hidden, and then there could be an “Add filter” button that pops open an Inserter dialog similar to the Inserter for blocks, and then you could select from that dialog the conditions that you want to filter by, whether that be categories, tags, other taxonomies, meta, authors, date ranges, and so on.

@StaggerLeee

This comment has been minimized.

Copy link

StaggerLeee commented Jul 8, 2017

It is difficult one, very difficult. After so much time dealing with WP I still have no clue what are my favorite WP_Query parameters. Somehow ends you allways use different ones. So, what to put inside this block, what options. All parameters ?

Only if WP fields API had repeater field, so we could type parameters manually, and add next one after another. Space is problem, parameters are many. Not so many, but for right sidebar to much.

@mtias mtias added the [Type] Task label Jul 9, 2017

@folletto

This comment has been minimized.

Copy link

folletto commented Jul 10, 2017

It is difficult one, very difficult.

Absolutely. That's exactly why I think providing a standardized UI is better than leaving it up to every single block author. :)

what about this WP Query Panel being similar to the Inserter?

It can totally be! To be clear: I don't mean at all to propose the one I designed above to be a good solution, it's just a mockup to make clear what I was referring to.

If we think it's a good idea (as it seems to be), I'd suggest to split it in a new issue and at least 2 phases, if not more:

  1. Define a few minimal fields to ship quickly, with the API at the code level, so author can make use if it from launch, even if it's not exhaustive. This could have a design with simple dropdowns / text areas as it's just a couple of fields.
  2. Once that's in place, do a more extensive research and design and define a richer filtering UI, which might look like the one to Insert blocks, or others (could be a tag system, could be like Automator, etc – needs to be done separately).
@westonruter

This comment has been minimized.

Copy link
Member

westonruter commented Jul 10, 2017

@folletto sounds like a good plan! So with these implemented, should the block be renamed from “Latest Posts” to something more general, like “Post List”?

@folletto

This comment has been minimized.

Copy link

folletto commented Jul 11, 2017

I think the block could be the same – at least for v1 – as that's a better conversion from the past – as well as I don't think we will build a super complicated Query Panel for v1 (I'm not sure if it should have sorting from the start, maybe yes, maybe no?). In the future as the Query Panel adds more option, might be a good idea.

@melchoyce

This comment has been minimized.

Copy link
Contributor Author

melchoyce commented Jul 12, 2017

I agree that we can release a simpler v1 (v2 at this point?) of the block, and then take more time to explore what more complex queries could look like — maybe in tandem with #1651. I think it's worth taking more time to get it right.

@StaggerLeee

This comment has been minimized.

Copy link

StaggerLeee commented Jul 30, 2017

Latest Posts block has some delay od 4-6 seconds when increasing number of Posts with "Number of posts to show" (Localhost. Website has a bit more over 1500 public Posts).

This delay is of course maybe normal, but under this time no visual indicator is there that shows Post(s) is retreiving in background.

I am afraid it can result in many clicks around, or changing value in same option, again and again. User can think it is not working.

Decraeasing number of Posts is immediately, in millisecond.

@westonruter

This comment has been minimized.

Copy link
Member

westonruter commented Jul 31, 2017

Yes, there should be a loading indicator.

@melchoyce

This comment has been minimized.

Copy link
Contributor Author

melchoyce commented Jan 21, 2019

There's a category selector under Sorting and Filtering:

@melchoyce

This comment has been minimized.

Copy link
Contributor Author

melchoyce commented Jan 21, 2019

Related, but aside — I wonder if we should make a distinct Category list block, or if that's overkill?

@paaljoachim

This comment has been minimized.

Copy link

paaljoachim commented Jan 21, 2019

Lets say...
We have 3 categories
design, development and feedback.

The Latest Posts block can show for all categories or a specific category.
Latest posts = can mean latest design posts, latest development posts or latest feedback posts.
Or just general latest post.

How would a Category List Block be different from a Latest Posts Block? What options would exist in that compared to Latest Posts Block?

@melchoyce

This comment has been minimized.

Copy link
Contributor Author

melchoyce commented Jan 21, 2019

It would essentially be the exact same block, but you'd get a setup state where you can select the category up-front. Could do this for tags, too.

@melchoyce

This comment has been minimized.

Copy link
Contributor Author

melchoyce commented Jan 22, 2019

Updated the initial issue description with the updated mockups, what's changed, and how I see each piece broken down. (cc @gziolo)

@StaggerLeee

This comment has been minimized.

Copy link

StaggerLeee commented Jan 22, 2019

Please make option for excerpt limit in characters, not words. Words will never guarantee professional look. It will almost everytime give nasty empty spacing in columns.

Or at least some function to switch between those 2, as developer wish.

@gziolo

This comment has been minimized.

Copy link
Member

gziolo commented Jan 22, 2019

Updated the initial issue description with the updated mockups, what's changed, and how I see each piece broken down. (cc @gziolo)

That's amazing. Thanks for all your help. I can easily see how we can divide work into more discrete tasks. I totally see it as a great opportunity to onboard new contributors. We can start by reorganizing the sidebar (InspectorControls) and the toolbar (ToolbarControls) to look closer to the mockups proposed. Then we can start adding each separate section to the sidebar in its own PR.

@gziolo gziolo modified the milestones: Future, WordPress 5.x Jan 22, 2019

@gziolo gziolo added the Blocks label Jan 22, 2019

@ajitbohra

This comment has been minimized.

Copy link
Member

ajitbohra commented Jan 22, 2019

We have Needs Design Feedback & Needs Dev both is it good to work on this?

Would love to work on the PR.

@gziolo

This comment has been minimized.

Copy link
Member

gziolo commented Jan 23, 2019

I removed both labels, see earlier comment from @melchoyce:

I think it's final enough to start — if it needs additional feedback, we can do that in the PR phase.

Would love to work on the PR.

@ajitbohra feel free to start on it. You can pick whatever you want for the first run. Let's try to split it into smaller tasks to make the whole process easier to review and possible to share between more contributors.

@afercia

This comment has been minimized.

Copy link
Contributor

afercia commented Jan 30, 2019

I'm concerned by the amount of settings placed in the Sidebar inspector. The inspector was originally designed to contain secondary actions. Instead, there are many settings here that are important enough to be considered "primary", as they relate to formatting and appearance of the block.

In the accessibility team report published on October, it was pointed out the extremely difficult keyboard navigation between blocks and the sidebar is one of the main accessibility barriers. Ideally, the amount of settings in the Inspector should be reduced as much as possible. Anything related to important actions should be within the block.

I realize this is a difficult case, and it's related to all the widget-blocks including the ones in the new Widget page, see the related discussion there #13204.

On a side note:

  • the "classic" widget block will keep settings within the block, see #13511
  • in the Customizer, there's no room for the widget-blocks settings sidebar, see #13205 and I'd really hope to not see one more "sliding sidebar" there 🙂

As this seems related to all the widget-blocks, I'm not sure if a separate issue would be appropriate, or maybe better a dedicated meeting as proposed on #13204 (comment)

@afercia afercia added the Widgets label Jan 30, 2019

@ajitbohra

This comment has been minimized.

Copy link
Member

ajitbohra commented Feb 2, 2019

@afercia separate issue to track this would be good, we can add this to upcoming meeting agenda and start the discussion around it.

@ajitbohra ajitbohra referenced a pull request that will close this issue Feb 6, 2019

Open

WIP: Latest post block iteration #13698

@gziolo

This comment has been minimized.

Copy link
Member

gziolo commented Feb 6, 2019

Noting, that @ajitbohra opened initial PR with some changes proposed in this PR: #13698.

@gziolo gziolo moved this from To Do to In progress in Phase 2 Feb 6, 2019

@noisysocks noisysocks moved this from In progress to Widgets in Phase 2 Feb 7, 2019

@gziolo gziolo removed their assignment Feb 8, 2019

@melchoyce melchoyce moved this from Backlog to In Progress in Porting widgets to blocks Feb 14, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment