search

openfoodfoundation / openfoodnetwork

Connect suppliers, distributors and consumers to trade local produce.
https://www.openfoodnetwork.org
GNU Affero General Public License v3.0
1.11k stars 718 forks source link

Allow shoppers to compare unit prices #6449

Closed jaycmb closed 3 years ago

jaycmb commented 3 years ago

What is the problem we are solving

Users would like to quickly compare the price of different products across different sizes/variants (possibly producers), displaying the price per unit (kg,l,oz,lbs..) enables them to determine which product offers the best value.

The need for this feature came up because legislation requires to display the price per unit in

Link to Discourse: https://community.openfoodnetwork.org/t/display-price-per-unit-on-variants/1712

Currently hubs and producers who have a shop on the OFN add this in the description field, but it is not clear enough for the buyer and there are cases where the workaround does not work.

Since the legal requirements are different depending on the country, but this information is valuable from a (shopper) user perspective we will display the unit price for all instances for simplicity, even if it may not be legally required for some instances.

This Epic inlcudes

Enterprise User | Admin

Shopper | Shopfront

Are there different versions?

V1: In the most simple solution, the unit price will automatically be calculated when the enterprise user creates a product. The enterprise will not be able to edit the unit price when creating a product nor to hide it on the shopfront.

V2 (Possibly):

Acceptance Criteria

These should be tested for both new products and already existing products

Shopper Side

Enterprise Side

Edit: (Dec 21st) As a high level rule for simplicity, : only on shopper side the unit price needs to be displayed including taxes + fees, at the various places where it is displayed on Admin side, no fees need to be displayed (but VAT/GST depending on if the instance selected ‘tax inclusive price’,)

Open Tasks / Questions

Questions? (Edited: after discussion with @RachL , added here to have all info in one place

Shopper Side

Enterprise Side

Design Indications

Unit pricing information must be:

Design Figma file:

Back-office: https://www.figma.com/file/JipdbYxaWxDN5i7L1coniF/Unit-Prices-Cleaned-for-dev-pipe?node-id=0%3A1 Front-office (including mobile): https://www.figma.com/file/EPKyXwl5VDQaw8IBHalCEZ/Unit-Prices?node-id=0%3A1

jaycmb commented 3 years ago

Comments on Design

Shopfront / Shopper User

Admin

jaycmb commented 3 years ago

Regarding the question for how to display in Australia, the legal information specifies:

The Code sets out the unit measurements that must be used for each kind of grocery item. Most products should be unit priced using the following forms of measurement:

if sold by volume - per 100 millilitres
if sold by weight - per 100 grams
if sold by length - per metre
if sold by number - per item for a pack of 40 or fewer items; or per 100 items for a pack of 41 or more items.

However, some grocery items must be unit priced using an alternative unit of measurement (see clause 11 of the Code). For example, fruit and vegetables, which are commonly sold by weight, must be displayed as per kilogram rather than 100 grams.

So I think going by kg/litres should be fine

Erioldoesdesign commented 3 years ago

Design acceptance criteria:

Acceptance Criteria These should be tested for both new products and already existing products

Shopper Side

@jaycmb @RachL I have a question about 'final price, including VAT and all other taxes' I don't think that this includes 'fees' that producers can add in the back office of OFN right? those are governmental legal requirements and they are more OFN related fees. So question is, unit price is inclusive of VAT and taxes if a producer is combining those into a final price and not using the fees part of ofn to add on VAT and taxes.

These AC's have moved to a further design stage:

TBD: cart page, checkout pages, order confirmation notifications? → tend to no

Enterprise Side

These AC's have moved to a further design stage:

TBD: Network product list UI refresh designs have been looked at and considered.

Responses to design feedback:

The font colour should be same grey or even lighter than the item price, so that unit price becomes not more prominent than the actual price

^ This is done

I find the "avg pack" info might be more confusing to the user than it helps, because it adds one more information in an already crowded space (item price, unit price, final price) and actually the unit price should help the user to compare prices without having to take different package sizes into account Admin

^ hmm I'm not convinced that this is more or less confusing. I personally find it hard when 'shopping' on various OFN shops that have '1 quiche' '1 cake' '1 loaf' because it's pretty ambiguous even if there is a good photo? Like is the quiche the size of my hand or my head? how many people can I feed with that? at least 400g gives me an idea of size and also, has been inputted by the producer in the back office so can be chosen or not chosen if we make the back office input fields non-mandatory. I would say user testing this with shoppers is the clear way to understand what direction to take.

JB: Tool-Tip: can we make this shorter and more explanatory? Maybe "Calculated based on the item price"?

^ Agreed and changed in the designs. This is the text now under the 'unit price calculation' field:

Screenshot 2020-10-13 at 13 12 43
Erioldoesdesign commented 3 years ago

Another AC i need to clarify is this one:

  • [x] The unit price reflects the price of the shop, not the unit price of the original product (variant) in the product list
Erioldoesdesign commented 3 years ago

Okay so I've updated the Figma file and believe from my perspective, all AC's are met.

This one:

The unit price reflects the final price, including VAT and all other taxes

I had a conversation with @tschumilas and @lauriewayne in the last US & Canada call and they said that producers/users across the USA and Canada are so familiar with tax and what category their produce is in that it's like second nature and the price they input into the price field is inclusive of this tax or there are tax categories that are added/pending to help this but because tax varies from state to state, province to province that the better way is for a producer to include tax in their price rather than using tax categories.

So I'm not worried about the price field not being inclusive of tax for USA & CA, which then calculates the unit price automatically.

I think I need a France, UK and maybe Australia tax 'deep dive' with someone who can 'play producer' (maybe customer support folks?) but also a developer.

But I'm also not too worried about tax generally as I think VAT is included in the price and applies when you select the appropriate 'tax category' from the drop down. But I'm likely making assumptions based off of my logic using back office and not a users actual process/understanding.

Screenshot 2020-10-19 at 14 26 54

But from my pov the price already includes the 'full rate' tax category and therefore, the calculated unit price does too.

Anyways! I'm gonna move this into review/QA and assigning @jaycmb and @RachL to review and also labelling as 'Blocked: Tehc input needed' and 'Blocked: Product input needed'

Erioldoesdesign commented 3 years ago

I've also made a video of this issue but it also covers some of the pipe process so skip that part if you want 🤦

Video in Drive: https://drive.google.com/file/d/1fR9-f8ItS6u142UvjGtmFT2Un1eKLN4B/view?usp=sharing

RachL commented 3 years ago

Hello @Erioldoesdesign this is great! It looks like we are going to be able to ship this one soon in delivery 💪

Two small comments on the screenshots:

  1. the color and aspect of the tooltip.

Currently the tooltip is blue and therefore a bit more visible (that's a personal feeling) than the pie:

image

The pie is not used all the time, but is super important in our model where we value transparency... So I wonder if others do see a more prominent tooltip than the pie or if it is just me?

I also wonder how it will look and feel on mobile. Aiming at one but not the other with you thumb might be tricky?

  1. This work made me realize we have different ways to show that something is not editable in our system. Do we agree that the cell will be greyed out like stock in inventory? If so, should it be the case on the product pages as well?

But I'm also not too worried about tax generally as I think VAT is included in the price and applies when you select the appropriate 'tax category' from the drop down. But I'm likely making assumptions based off of my logic using back office and not a users actual process/understanding.

Yes that's correct. I'm not a tax expert myself. So I won't be able to walk you through it 100% like a producer would. However I can send some info to users in France that particularly wait for this feature.

sauloperez commented 3 years ago

Regarding the "avg pack" @Erioldoesdesign pointed out in https://github.com/openfoodfoundation/inception-pipe/issues/2#issuecomment-707732058, it immediately came to my mind that would be really helpful when we are buying things like watermelons and such where you don't know how much you'll get.

I agree with @RachL that the tooltip icon in the shopfront seems too prominent. What about going with something more subtle like a dotted underline so users hover the unit price? I've seen this pattern on a few sites but I know it'd be new in OFN.

Erioldoesdesign commented 3 years ago

@sauloperez be careful encouraging me, a designer with the temptation of new UI components and styles! 😂 .

But I agree, a less 'prominent ? icon can be designed and would be better!

tschumilas commented 3 years ago

Thanks for this - @Erioldoesdesign - read through above and watched video.

Can I clarify my comment on taxes please (might not matter here - but just to be clear). In NA shop prices Never include tax. Our form of tax is NOT a value added tax (VAT). In NA, 'sales tax' or 'goods and services tax' is applied based on the buyer's tax zone. So it has to be calculated at checkout - not a priori. There are different taxes per municipality, state, and country. In configuration we have set the tax categories as needed (and we add more when we need more). The producer enters their product price WITHOUT tax, and selects the correct Tax Category. When the product is ordered, the OFN system finds the Tax ZONE for the BUYER and applies the right tax RATE, for that ZONE, based on the tax CATEGORY. So - these 3 things - rates, categories and zones all work together at checkout to calculate taxes applicable. So unit prices in NA cannot include tax.

Second - I think we need to talk through the situation where the unit type is 'item'. I am having a hard time imagining asking every producer to weigh or guess the weight of every product every week. In NA, relatively few products are sold by weight/volume. Most things are sold by item, and described in the product description field (ie: bunch is 8 carrots, or quiche is single serving, or lisianthus bunch has 20 open blooms......) . I"d suggest that most of our producers don't even have weigh scales on their farm - its just not very common (cheese, meat sellers are the exception). I would have no ability at all to guess the weight on a bunch of carrots - no idea frankly. Is it possible to do the unit price comparision for items sold by weight/volume only? I'm really not trying to be difficult - but weighing or even guessing the weight of products will be a VERY SIGNIFICANT problem for NA producers. What are other options?

tschumilas commented 3 years ago

One further question - if we do proceed to have producers enter a weight for all 'item' type products so a unit price can calculate,, will the product import file be modified to include this weight? (In OFN-CAN we have hubs with 2000 plus products being modified weekly - so being able to do this by importer seems necessary)

RachL commented 3 years ago

Regarding the "avg pack" @Erioldoesdesign pointed out in openfoodfoundation/inception-pipe#2 (comment), it immediately came to my mind that would be really helpful when we are buying things like watermelons and such where you don't know how much you'll get.

I agree with you @sauloperez but I'm afraid we are extending a lot what we are trying to do here. This item is here so that we become compliant. I would consider average weight as another feature that we need to prioritize. There is a lot to do around price per unit already.

I am having a hard time imagining asking every producer to weigh or guess the weight of every product every week.

@tschumilas I think it's the same everywhere. Items are heavily used. However it is for EU & AU a legal requirement, I think @jaycmb has found clear statement on that part. The only way I guess for countries without this regulation, would maybe be to introduce this as a super admin configuration (activating / deactivating customer unit prices). I think we've ruled that out at first because from a shopper point of vue it's interesting, but maybe we need to reconsider this.

Erioldoesdesign commented 3 years ago

@tschumilas re.

The producer enters their product price WITHOUT tax

Thanks for the clarification I think without being a person who operates this myself I got a bit muddled! Based off this information @RachL and @jaycmb we may need to discuss at a future point how to show unit prices after tax is applied for USA and CA, which is calculated after presumably, delivery address is entered. Better understanding this process is essential but could make up a new issue looking specifically at this context along with Tax.

Agreed that 'avg pack' is super nice as a feature and we can totally add a new improvement issue for it based off this work but it shouldn't stop us from proceeding with the compliance of unit prices.

On the more tricky topic of

I am having a hard time imagining asking every producer to weigh or guess the weight of every product every week.

I think we need to test this part out specifically with users and see how it lands and make adjustments accordingly. There are a few ways we can test this either with prototypes and user testing or by deploying items needing avg weight as a mandatory field in some instances (if we are able to A/B test)

I also don't expect producers to guess weight every time they update in the product list, just when they've added a new product so once in that process. But I 100% agree its a shift from a very loose and free way of adding 'items' to imposing more structure on producers to better define item weight so we can be legally safe from fines/consequences. It also does help the shopper massively to know that the unit price of 1 bunch of carrots which is 1kg is £X.XX price. More effort from the producer side allows shoppers to fully understand what they are purchasing.

I remember there was a comment that some producers put this in the product description so e.g. 'Cheese and onion quiche 7inches' which is good info, but when it's in the same field as other text doesn't help the system do a math calculation. Also not every producer does this so it's an inconsistent experience for shoppers and I can imagine they would favour producers that give them more accurate information (unless they have another bias like they know a producer or something)

The only other way around asking producers who use item a lot is a more technically heavy thing, which would be us, as OFN creating a suggestion database of average weights. So for example:

  1. Producer enters item as 'bunch of carrots'
  2. OFN has a database that suggests an average weight of a bunch of carrots is '500kg' we could build this database from our existing users and do an median value.
  3. Producer can accept or reject that suggestion and enter their own guess or weight
  4. Unit price is either calculated by the database or the entry from producer

This is risky for a number of reasons, were guessing mostly on average weights but at least were offering a suggestion. Also I cannot imagine how long it would take to put together that database! 😬 let along build it into the OFN back end.

Also in regards to @RachL 's

super admin configuration activating / deactivating customer unit prices

I'm cool with that, but I think what is a point of tension is something that helps shoppers make better buying choices means more data entry effort from producers (or more effort from OFN to mitigate that effort through suggestion)

So there are a couple fo actions that I can see need to be done:

  1. An issue/investigation spike that described unit prices and tax investigation work in USA & CS
  2. An improvement issue that describes 'avg pack' weight displaying in the shopper facing product list
  3. An An issue/investigation spike that delves into 'item' entry and how the weight of items can be manageable effort for producers while still benefitting shoppers.

And two small design changes to the existing flow

  1. Make the (?) icon less prominent by adding a new UI style
  2. Take a look and make a decision on 'deactivation fields' visual UI design (@RachL pointed out there is a new style introduced here in this work and an existing style in Inventory)

Regarding the deactive state currently:

Screenshot 2020-10-21 at 12 40 10

I mean, it does the job and also doesn't require another new UI style. I think I'll be making the deactive unit price fields visually follow this for ease of development.

jaycmb commented 3 years ago

A comment/ small correct on the video (which is great by the way to get a full tour across all areas where unit price affect the product) to avoid potential confusion for testing or acceptance criteria:

“Create a new product based on weight” example:

(- If user would choose volume (l), then the "Display As" is set to 1 l and same for the unit price, which is then price per l)

Tooltip: "In your country it is a legal requirement..."-> since this is not the case for all instances. I would suggest to make it more explanatory instead of saying why this has to be shown, i.e. what’s the users´s value?

"This is the unit price of this item. It allows you to compare the price of products across varying sizes and weights."

Design AC:

The last point have actually been 2 criteria

Also, there was an update regarding where the Unit Price should be displayed on Shopper Side after discussion with @RachL.

Shopper Side

should the unit price be displayed only on product list page or also other places (cart page, checkout pages, order confirmation notifications) -> for consistency and bc helpful for the user to compare prices let’s include unit prices on cart page and checkout page as well (if that fits the designs, to be checked by @Erioldoesdesign )

After checking the (current) checkout page, where items are not listed individually, displaying unit price there does NOT make sense though.

So it would be

jaycmb commented 3 years ago

Regarding the more complicated discussion on Items

There has been some confusion from the beginning if products sold by item are included in these regulations. "For simplicity" (one rule across all products) and because of user value we decided to apply the unit price for them as well.

But as this seems to be more complicated than expected - I looked into it again, and I cannot find clear indication across countries for goods sold per item (vs per weight or volume).

This is the little information available

EU “for products sold in bulk, only the unit price must be indicated”

AUS

products should be unit priced using the following forms of measurement:

That can be understood as if the unit chosen is “per item” then only the price per item is needed if I interpret correctly.

-> That would mean for a pack of eggs with 6 eggs (sold at 3€), the unit price should specify the price per egg (0.60€per item)

From a technical perspective, that would add some complexity though as we had to differentiate the logic between products per weight/volume and item.

Also to be considered from tech side: Effort for potential switch on Instance Level:

And lastly, regarding @tschumilas concerns: "flowers, including fresh, dried and imitation flowers" do not require unit prices (this is from AUS law, but I assume that can be appleid for other countries as well even if not explicitly stated. In the EU it says: EU countries may ...in the case of non-food products, draw up a list of the products to which the obligation to indicate the unit price will remain applicable.

Re @Erioldoesdesign

So there are a couple fo actions that I can see need to be done:

1. An issue/investigation spike that described unit prices and tax investigation work in USA & CS
2. An improvement issue that describes 'avg pack' weight displaying in the shopper facing product list
3. An issue/investigation spike that delves into 'item' entry and how the weight of items can be manageable effort for producers while still benefitting shoppers.

Agree, with 1 and 3 need to be done asap while 2 can be parked in "Ready for Inception" (or Wishlist, as not prioritized yet?).

RachL commented 3 years ago

From a technical perspective, that would add some complexity though as we had to differentiate the logic between products per weight/volume and item. Also to be considered from tech side: Effort for potential switch on Instance Level

I can't answer from a dev point of view, but from a tester: calculating a unit price in weight for weight, in volume for volume and in items for items is wayyyyy more easier to test and maintain than a switch at instance level. So if it is not legally required and it's easier for our users, it seems like a no brainer to me :-)

Re taxes. I'm not sure I understand the problem: in US/CAN the unit price will be shown without tax but I don't think this is a problem because the shopper is buying products without tax. So it makes sense to show him a unit price without taxes.

tschumilas commented 3 years ago

There is no problem with taxes and unit pricing - sorry I confused the discussion. I was just correcting information on the difference between a sales tax approach (NA) and a VAT approach (EU) - my comment didn't belong in this thread. Sorry - there is no issue re: unit pricing and how tax is calculated in NA - as RAchel notes above.

My main point on 'item' unit types is that there are many cases where a weight makes no logical sense. Just scanning some of our product lists, I see things like - a 'voucher' or a 'share' or we have instances that make 'pickup time' products to ensure social distancing in covid, or 'workshops' or 'plants' . Or often we have producers just using the term 'item' as the unit - so that could be anything ..... On OFN products are not just weighable food products.

So can the unit price in these cases just 'repeat' the same unit type that is listed for the product? So a producer enters a 'workshop' cost as $120, and the unit price field automatically populates as $120/per workshop. Or a producer enters 3 plants for $6, and the unit cost calculates and shows as $2 per 1 plant. What I have a problem with is trying to translate a non-weighed item into a cost per weight where it doesn't make sense. This would not add any value to the consumer's shopping experience because it would be based on the producer's best guess on a weight anyway (and at BEST - the producer will enter this weight for their item once and not adjust it as their sizing changes weekly anyway). So - it wouldn't yield useful data for the consumer.

I really don't want to hold up an issue that is needed to meet legal requirements. What if we went ahead and did unit pricing where unit type is weight or volume, and we put 'on hold' work where unit type is 'item' until we can get more input? I know that it won't meet the full legal requirement - but it doens't preclude any producer from entering their product by weight or volume to meet the requirement. And a hub can request this of suppliers. So - it would give a path for any hub to be fully legally compliant.

RachL commented 3 years ago

So can the unit price in these cases just 'repeat' the same unit type that is listed for the product? So a producer enters a 'workshop' cost as $120, and the unit price field automatically populates as $120/per workshop. Or a producer enters 3 plants for $6, and the unit cost calculates and shows as $2 per 1 plant.

@tschumilas Yes that's what I mean by we calculate the unit price per weight when the unit is weight and per item when the unit is item. So in that case you don't have the problem of translating into a weight, correct? I'm not sure why you propose to not consider item then? Maybe a call on this would be easier :)

tschumilas commented 3 years ago

yes - correct @RachL . I apologize for not communicating very well today. If - for unit types 'item' - we take whatever unit name the producer gives - and it automatically is used to calculate unit price - then we can, I think, absolutely proceed and include this in the feature - because we are not translating a non weight item into a weight. (I was actually trying to give 2 different options above)

RachL commented 3 years ago

@tschumilas ah all good! I didn't understood 🙈

Erioldoesdesign commented 3 years ago

Just noting I need to properly read back over these suggestions and maybe have a chat about them because I didn't easily understand.

however! this is, I believe, the best time to be raising concerns, clarifying perspective and offering information that could improve this feature for everyone using the tool so I welcome all this happily! 💐

Erioldoesdesign commented 3 years ago

Hi all, I've been making some changes to the Unit prices design work based off of multiple feedbacks. I'll make another video or two today and upload but here is the figma (same file) so far: https://www.figma.com/file/EPKyXwl5VDQaw8IBHalCEZ/Unit-Prices?node-id=0%3A1

Done

Not yet done

@jaycmb We'll need to think about the process of more feedback from other instances and find a good strategy for including them vs. not including them and why. But that's tbc until we know what feedback we're getting.

jaycmb commented 3 years ago

I had a quick look at the designs, 3 small comments

on the logic (just to avoid confusion also for testing):

Actually I am wondering where is the best place to collect all these indications for testing -> shall we update in the Epic? Or have in a separate comment?

on the design:

Re Feedback Process: yes I think the Discourse post is a good idea, pinging other instances there and then summarizing feedback from here in this Epic?

Erioldoesdesign commented 3 years ago

Re above @jaycmb I've made these changes including: The price change accuracy re. £2.90, Changed the text colour to the lightest accessible grey which is #555555, and increased the spacing between the pie icon and (?) icon generally.

I'll be finishing the cart pages today and then doing the discourse post 😃

Erioldoesdesign commented 3 years ago

Cart pages complete! I think this is the best way to deal with the cart but as always thoughts from @RachL and @jaycmb welcome: https://www.figma.com/file/EPKyXwl5VDQaw8IBHalCEZ/Unit-Prices?node-id=0%3A1

Doing videos ready for here/discourse now!

Erioldoesdesign commented 3 years ago

Overview and Unit price of item pack of 2: https://www.loom.com/share/06ce7a07f34c495d8848085d3055e04d

Single flavour item Quiches and pack of 5 example: https://www.loom.com/share/286d3d9233674555b3eb79948738f34c

Weight (g) to (kg) example: https://www.loom.com/share/13876752f4364bb58563566db9952722

Weight (g) & (kg) but added as their own products and not variants example: https://www.loom.com/share/7aefe6a03deb4038a3a696bd2eec0d7f

Inventory: https://www.loom.com/share/0ffcccf0dd4b46bd8102f7bb0b5e2060 There's still a question here about whether the unit price changes if the person using inventory changes the price of a product in the inventory list or whether unit price should always reflect the unit price from the producer.

Shopper product list: https://www.loom.com/share/d662d59909304577a49e249a30d1e7bf

Cart pop-out and edit cart and payment screen: https://www.loom.com/share/2f53681dbb2344b09037c6b350d0f264

RachL commented 3 years ago

@Erioldoesdesign

There's still a question here about whether the unit price changes if the person using inventory changes the price of a product in the inventory list or whether unit price should always reflect the unit price from the producer.

When inventory is used, the unit price should always be based on the price in inventory, not the product catalog price.

Thanks for the video links! I will check them out.

Erioldoesdesign commented 3 years ago

@RachL yup noted, so that's how it currently is proposed so we're all good!

Updated the discourse post here: https://community.openfoodnetwork.org/t/display-price-per-unit-on-variants/1712/10

jaycmb commented 3 years ago

Cart pages complete! I think this is the best way to deal with the cart but as always thoughts from @RachL and @jaycmb welcome: https://www.figma.com/file/EPKyXwl5VDQaw8IBHalCEZ/Unit-Prices?node-id=0%3A1

Looks good to me! One thing: The line break for displaying price / unit if not possible in one line should be 3€ / kg

i.e. the / goes on the same line as the price (that´s the way how slash is used as "per")

image

Also: not sure if we need / 1 item, I think / item is enough? No strong opinion here though

Erioldoesdesign commented 3 years ago

@jaycmb fyi I've actioned the above on the mocks.

jaycmb commented 3 years ago

Adding AC (for Tech Only, no implications for design):

CSV Import

Erioldoesdesign commented 3 years ago

Here's the 'cleaned' Figma files: https://www.figma.com/file/JipdbYxaWxDN5i7L1coniF/Unit-Prices-Cleaned-for-dev-pipe?node-id=0%3A1

All actions have been completed from last weeks wrap up meeting and a discourse post has been made: https://community.openfoodnetwork.org/t/display-price-per-unit-on-variants/1712/27

Design's next task will be supporting product & dev through the pipe with any clarifications/questions and once live conducting any usertesting needed to confirm early hypothesis about user behaviour.

Matt-Yorkley commented 3 years ago

I left a comment in this issue, but it's relevant to the whole epic: https://github.com/openfoodfoundation/openfoodnetwork/issues/6495#issuecomment-763044319