Block Idea: Shop Directory Block

[nerrad]

Now that we have the All Products block and a number of Filter blocks available. I think there'd be value in creating a container block that has the All Products block setup with filter blocks in a curated layout so merchants can just drop this in a page and have it ready to go. Some thoughts:

• ability to adjust the layout of the inner blocks (all products, filters etc) selecting a patterns.
• everything contained in the container would be in it's own context so that search results/filter selections etc will be specific to that container. This will feasibly allow for merchants to setup containers on the same page for various targeted types of products.

Primary purpose behind this work would be to enable merchants to get started with a Shop Directory out of the box with little to no configuration. It could also be used in various contexts (and potentially replace the current shop page view).

[issue-label-bot]

Issue-Label Bot is automatically applying the label type: feature request to this issue, with a confidence of 0.87. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[haszari]

Seems like a great idea - at the moment the user needs to know how these blocks work together.

Another area where this is a little confusing – these blocks are "different" from the other self-contained woo blocks. Perhaps they could be grouped in the block chooser or identified in some way – i.e. new user choosing between Filter Products by Attribute vs. Products by Attribute blocks. cc @jwold

[nerrad]

Another area where this is a little confusing – these blocks are "different" from the other self-contained woo blocks.

Yes, I very much agree with you here. It'd be good to differentiate between "atomic" blocks that generally work best in context with other blocks, and "curated" blocks which are either stand-alone or container type blocks which are drop and go. Also I think we need to do some explorations around what terminologies we use (which would fit into your idea how how we group things).

As a starting point, we probably should tighten up the description for these blocks so the description can give some insight into where they are typically used.

[jwold]

Great points @haszari and @nerrad. I'm definitely open to ways we could change up how atomic blocks vs larger blocks are shown. There's been some discussion by folks where we've looked at ways to improve the organization of blocks overall when you go to look for them. This is one such example:

Wondering cc @pmcpinto and @garymurray if prioritizing this sooner than later may make sense.

[pmcpinto]

Gave my feedback here: p1574848938295000-slack-wootenberg

While I 100% agree that we should improve the block organization, I think that in the upcoming cycle we should focus on Cart/Checkout blocks and/or the homepage templates, mainly because:
Cart/Checkout blocks:
They have a direct impact on the store conv. rate
Improving the cart/checkout experience is something that the merchants are longing for
It can be a key driver for increasing WC Blocks usage
Homepage templates:
In the new activation flow we’re going to push users to create a homepage, so it’s crucial that we provide good options
It can also be a key driver for increasing WC Blocks usage, as it will probably be the first point of contact that new Woo users have with Gutenberg
And if we think about the product adoption curve, I would say that we’re reaching the end of the early traction stage, so it’s important to work on initiatives that unlock exponential usage and then help users to navigate between all the options that we offer. Based on this, I think that exploring how we can organize our blocks and how WC blocks will be discovered/used within the new WP block directory should be a topic for exploration in the next cooldown period (or even in the HACK week).

[garymurray]

We could work on this as part of the block patterns work later this year imo.

[nerrad]

This is still a good candidate for block patterns, however I realized that we still need a container block for defining the context of all the elements within it. So patterns would be simply different arrangements for the inner blocks in the Block Directory container block. Or it's possible we may just use the block variation api (slightly different than patterns) within the container block.

[nerrad]

I don't think we should do any engineering work on this until there's some direction given on the design part of this.

cc @LevinMedia aside from the original description, what other details do you need to help with understanding the need for something like this block?