Skip to content
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

New Block: Filter Products by Price #710

Open
jwold opened this issue Jul 9, 2019 · 16 comments

Comments

@jwold
Copy link
Collaborator

commented Jul 9, 2019

Issues in this epic:

  • Filter Products by Price: List view #784
  • Filter Products by Price: Slider component #783
  • Filter Products by Price: Query handling/core integration #785
  • Filter Products by Price: Block creation #786

User Story
As a merchant
I want a block that allows filtering my store's products by price
So I can allow users narrow down products based on that criteria

Acceptance Criteria

  • If no products published (with prices), block displays notification linking to create products
  • If the merchant has products with prices, he can see the block with the slider in the editor
  • The merchant can see the price range of all the products in his store: min: 0$ and max: most expensive product in the store
  • The merchant is not able to interact with the slide in the Editor
  • The slider only shows prices with round numbers. It needs to automatically round up to the next whole number
  • The slider will change color as it’s dragged around. The corresponding input field will also automatically adjust its number at the same time
  • The user can change the price range by dragging a handle or changing the price in the input field. Clicking in the middle of the slider won't change the price range
  • The user can collapse/expand the filter in the frontend
  • On mobile devices the filter should be collapsed by default
  • The slider uses a logarithmic non-linear scale (optional)
  • When the user sees the slider in the frontend, the min value should be 0 and the max value should be the price of most expensive product in the store
  • The merchant can show/hide the input fields (block setting)
  • If the merchant hides the input fields, the user can see the price in the same area but only change them by dragging the handle
  • The merchant can choose between displaying the filters as slider or list (block setting)
  • The block presents the slider as the default option
  • How to edit the price ranges that are displayed in a list (TBD)
  • The merchant can show or hide the filter button (block setting)
  • The filter button is hidden by default
  • If the filter button is hidden, in the front end the product list is updated when the user stops dragging the slider handle
  • The Block settings is expanded by default
  • Advanced setting is collapsed by default
  • The merchant can only see this block in the block library while editing the Product Archive Page
  • The block needs to be displayed in the Product Archive Page by default, to help with initial discovery

Additional links

@jwold jwold added the new block label Jul 9, 2019

@issue-label-bot

This comment has been minimized.

Copy link

commented Jul 9, 2019

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

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

@pmcpinto pmcpinto added this to wc-admin Backlog 🔙 in Isotope via automation Jul 9, 2019

@pmcpinto pmcpinto moved this from wc-admin Backlog 🔙 to 🧱 Blocks Backlog in Isotope Jul 9, 2019

@jwold

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 11, 2019

@pmcpinto, a few suggestions:

A. If no products published (with prices), block displays notification linking to create products

Perhaps change to: "If no products published (with prices), block displays notification in the editor linking to create products"

B. The slider will change color as it’s dragged around. The corresponding input field will also automatically adjust its number at the same time

For clarity I might say: "The slider and the slider handle will change colors as the handle is dragged round. The corresponding input field will also automatically adjust its number at the same time"

C. When the user sees the slider in the frontend, the min value should be 0 and the max value should be the price of most expensive product in the store

Should we also show this in the editor?

D. If the merchant hides the input fields, the user can see the price in the same area but only change them by dragging the handle

Good catch! I didn't even think about this one. I might change it to: "If the merchant hides the input fields, the user can see the price in the same area but only change them by dragging the handle. Refer to existing design of this widget"

@jwold

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 11, 2019

@pmcpinto and @mikejolley is a 13 size estimate a sign that we should reduce scope a bit on a feature? If so, we could consider backlogging something, such as the "list" view setting.

@mikejolley

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

@jwold yes this should be split up. It's fine to move things to new issues with their own estimates and then group them under this one master issue. We can discuss monday.

@pmcpinto

This comment has been minimized.

Copy link

commented Jul 11, 2019

@jwold

Should we also show this in the editor?

Considering that in the frontend we're going to show the slider with the min value as 0 maybe it will be less confusing for the merchant if he sees the same in the editor. Makes sense?

@jwold

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 11, 2019

Considering that in the frontend we're going to show the slider with the min value as 0 maybe it will be less confusing for the merchant if he sees the same in the editor. Makes sense?

Agreed. Makes sense.

@pmcpinto pmcpinto added this to the 2.5 milestone Jul 22, 2019

@mikejolley

This comment has been minimized.

Copy link
Member

commented Jul 31, 2019

@jwold Can you elaborate on these few:

The block needs to be displayed in the Product Archive Page by default, to help with initial discovery

The user can collapse/expand the filter in the frontend

The slider uses a logarithmic non-linear scale (optional)

Thanks

@jwold

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 31, 2019

The block needs to be displayed in the Product Archive Page by default, to help with initial discovery

I'm not sure if this is technically possible until we have block areas enabled. I am imagining I could open the Product Archive Page, start editing it in Gutenberg, and see something like this:

IMG_0237

So the filter block would be in a group block, and in the left column. The "all products" block (this doesn't actually exist) or a shortcode would be in the right. That "all products" block/shortcode would not be user editable, and maybe not even visible on the backend, in its place you'd just see this preview message.

Then, when someone comes to edit this page they're presented with the filter blocks already in place, which helps make it easier to know how to add and remove the filter blocks.

The user can collapse/expand the filter in the frontend

This is an another one, that as I started actually sketching it out, realized we might not be able to do. So I welcome feedback! This basically allows a customer to collapse/expand each filter on the Product Archive Page, so that they can more easily get to the attributes they want. This is especially useful on mobile devices because the filters can take up a lot of room as a customer scrolls through them.

IMG_0238

However, because the collapse/expand function requires the ability to select a toggle, and that toggle visually is tied to a block title... I'm not sure if we can make this happen technically. The reason being, we're not tying block titles to these blocks. What do you think?

The slider uses a logarithmic non-linear scale (optional)

On this page: https://baymard.com/blog/slider-interfaces, Baymard describes briefly how the Disney store uses a logarithmic scale. Here's the example they give:

slider-ui-03-86456534bf5c6794a5aa5b861b862476

"At the Disney Store, the price slider goes from $0 to $5,000. However, notice in the second image how Disney has cleverly used a non-linear slider scale as there are very few products that cost more than $1,000. This way the $1,000 - $5,000 range only takes up 25% of the slider width. Had the slider had a linear scale this upper price range would have consumed 80% of the width, which would have made it almost impossible to set a more common price range such as $25 - $45."

So for us this would require adjusting how movable the scale is based on the prices of the products in the store. It may be worth discussing this on a call and chatting more in depth about it.

cc @pmcpinto

@pmcpinto

This comment has been minimized.

Copy link

commented Aug 1, 2019

@jwold

The block needs to be displayed in the Product Archive Page by default, to help with initial discovery

Even if this block only works in the Product Archive Page I think we should display it in the block inserter on any other page to help with discoverability. If we choose this path, what would be the best pattern to inform the user about this block constraints?

However, because the collapse/expand function requires the ability to select a toggle, and that toggle visually is tied to a block title... I'm not sure if we can make this happen technically. The reason being, we're not tying block titles to these blocks. What do you think?

I think we should find a way that allows the user to add/change the title. Apart from helping to solve the dropdown problem, it's also a best practice to have a clear separation between filtering types.

@jwold

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 1, 2019

Even if this block only works in the Product Archive Page I think we should display it in the block inserter on any other page to help with discoverability. If we choose this path, what would be the best pattern to inform the user about this block constraints?

I had a conversation with this (I think with Gary) several weeks ago, where we went back and forth on whether to show the block on other pages, or just the Product Archive Page. Ultimately I felt that the friction of showing a block that couldn't be used on other pages would cause more frustration than the lack of discoverability by only showing it on a single page.

It was almost a tossup, but I opted for only showing it on the Product Archive Page to simplify things (we'd need to come up with a proper notification for it on every other page), and to reduce friction (frustration from seeing the block on a page where you couldn't use it).

If we chose to open that path up again, there's a few patterns I explored and would be happy to share.

My gut instinct at this point is that we should backlog this item for now in favor of getting this shipped and then revisiting.

However, because the collapse/expand function requires the ability to select a toggle, and that toggle visually is tied to a block title... I'm not sure if we can make this happen technically. The reason being, we're not tying block titles to these blocks. What do you think?

Right now the user is able to add/change a title by adding a secondary headline block. So it's not tied to the block, and it's on the user to add it. It's a bit of a friction point, but the reason we did it was feedback that from a development perspective including the title adds a lot of challenges (@mikejolley feel free to correct me if I'm off base on this).

@pmcpinto

This comment has been minimized.

Copy link

commented Aug 2, 2019

Ultimately I felt that the friction of showing a block that couldn't be used on other pages would cause more frustration than the lack of discoverability by only showing it on a single page.

My gut instinct at this point is that we should backlog this item for now in favor of getting this shipped and then revisiting.

@jwold good point, I'm in favor of keeping it as it is right now.

Right now the user is able to add/change a title by adding a secondary headline block. So it's not tied to the block, and it's on the user to add it. It's a bit of a friction point, but the reason we did it was feedback that from a development perspective including the title adds a lot of challenges (@mikejolley feel free to correct me if I'm off base on this).

It will be difficult from a dev perspective if we create a group block with the title and the "filter product by.." block? As Joshua mentioned without the title I don't see any way to apply the collapse/expand dropdown.

Currently 67% of traffic on stores using WC is coming from mobile, so it would be important that the user can collapse/expand the filter.

@mikejolley

This comment has been minimized.

Copy link
Member

commented Aug 2, 2019

@jwold @pmcpinto I don't really follow what this is about--adding a title to a block?

When blocks are in the widget system, do we know how titles of widgets will be handled then? I guess we should aim to be compatible with whatever happens there, and if collapse has to be handled at widget level instead, this would be out of scope.

@jwold

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 2, 2019

I don't really follow what this is about--adding a title to a block?

For the filter blocks it seems like we need to add titles to the blocks. Previously we weren't going to add those titles because I had heard it would be a development challenge to include them because:

  • The titles would need to be editable, which complicates things a tad by adding an editable text area next to a filter block.

But, since the titles are needed in order to have a proper selectable area to collapse/expand the block on a mobile device, we're wondering if we could find a way to put them in (Screenshot)

This topic is starting to get a bit hairy, so I'm happy to discuss live if that helps! :)

@pmcpinto

This comment has been minimized.

Copy link

commented Aug 5, 2019

@mikejolley, just to summarize: the idea is to display a dropdown to collapse/expand the options of each "filter product by..." block. This can be particularly important on mobile in order to have the filters occupying the entire screen above the fold and even beyond that. See this example on mobile with the current widgets where the filters occupy almost the entire screen real estate: https://cld.wthms.co/Zdo9GR

And as Joshua mentioned, it's only possible to have the dropdown if we have a title associated with each "filter product by.."

Is it easy/feasible to accomplish that for example with a group block containing a paragraph for the title and the filter block? If it's something that takes too long to accomplish we can always add it to the backlog and work on it in an upcoming release.

@jwold feel free to add anything else that may help in describing this use case.

@mikejolley

This comment has been minimized.

Copy link
Member

commented Aug 5, 2019

@pmcpinto I understand the use case but I'm concerned this may overstep what the blocks should handle. In the case of widgets for example, the theme controls the title and widget wrapper (and therefore any content toggle). So I'd like us to see how the blocks as widgets system will work before implementing toggles at block level. Make sense?

@pmcpinto

This comment has been minimized.

Copy link

commented Aug 6, 2019

@mikejolley that makes sense, I wasn't aware that the title and the wrapper were controlled by the theme. Thanks!

@pmcpinto pmcpinto moved this from 🧱 Blocks Backlog to Sprint 23 (August 13 - August 26) in Isotope Aug 12, 2019

@mikejolley mikejolley referenced this issue Aug 13, 2019
0 of 4 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
You can’t perform that action at this time.