Display price per unit on variants

What is the need / problem?

In Europe when you sell a product with unit weight or volume, legislation requires you to display the price per kg or per liter. L_1998080EN.01002701.xml
Currently hubs and producers who have a shop on the OFN add this in the description field, but:
1- it is not clear enough for the buyer.
2- if the hub is a reseller (buy and sell a product with a markup) the price per kg / liter of the product changes with the new price including the markup. The workaround used today doesnā€™t enable to adapt the price per kg if the distributor add a markup.
3- to complexify a bit the situation, some hubs are reseller (buy and resell with a markup) and some others sell distribution services so they donā€™t add a markup but they invoice, on top of the original price of the product from the producer (so same price per kg) a service fee. In this case the price per kg shouldnā€™t change.

Who does it impact?

All shops manager in France, but also all buyers that are used to compare price per kg.

What is the current impact of the problem?

The info is a bit hidden + some hubs canā€™t meet their legal obligation with the current OFN platform

What is the benefit of focusing on this?

More ability for the end buyer to compare prices, and better legal compliance.

Potential solutions that will solve the problem ?

1- Adding this as a new field? That would calculate automatically given certain setups, especially given the nature of the hub (hub buy and sell > price per kg = price including markup divided by nb of unit / hub sell only services > price per kg = original price per kg of producer). This is not possible with the current fee logic but might become possible when we have some ā€œpricing tableā€ later on.


Selection of a feature candidate

[value x ease matric if needed]

T-shirt size of our selected feature candidate

Metrics to measure if need is satisfied after feature is implemented

Feature owners

Epic/projet where you can follow implementation


Connected wishlist and discovery discussions*

[list precedent discussions]

This would be a field in the variant, maybe we can change the title of the post to variant?

Also, this is closely related to the already very messy list of fields we have around units and its descriptions in the variants modelā€¦

Correct! I changed the title. Also I made this post a wiki.

@Kirsten this morning BirutĆ© has mentioned to me that you have a similar legal compliance. I found this text but Iā€™m not sure it applies to OFN. Do you have more info? https://www.accc.gov.au/business/industry-codes/unit-pricing-code

Jana, Myself and Rachel have had two conversations about this project/issue and made a few notes.

Weā€™re currently validating the UX hypothesis ready to eventually test the idea across the community/users.

Very rough and ideas based notes (please donā€™t regard these as ā€˜final/decidedā€™ :slight_smile:

Why is this needed?

Who requested / WhatĀ“s the source?

Request came mostly from customers at OFN France

Challenges/To be Considered

Countryspecifics

  • In Australia, consumer price comparison is required in 100g, in EU in kg or per liter
  • What is the USA compliance?

For now letĀ“s assume itĀ“s country-wise and requested units are

  • per litre/kg (FR, D, ā€¦Europe but UK?)
  • 100ml/100g (apparently Australia)
  • US tbd

Method

  • Do we calculate the unit price from the price of the kg/ml/cl baseline price, or do we change the producer chosen price based on a unit price?
  • How can this work in the current UI particularly in the variant set of fields

Previous work

  • What has Mario done within this, any Network work that has touched this?

  • Inventory can override the unit price per shop-front depending on the scenarios involved e.g. when a producer is supplying a food hub restaurant and offers a discount to them based off of criteria they choose and they can lower the unit price.

  • Targeting types of producers who are trying to get a fair living cost for their produce.

  • How is the correct terminology: item price vs. unit price? price per item vs. price per litre/kg?

    • In retail, unit price is the price for a single unit of measure of a product sold in more or less than the single unit. The ā€œunit priceā€ tells you the cost per pound, quart, or other unit of weight or volume of a food package.

Many prices: 2 units of lemonade, unit price (per 1 bottle) that is sold by 75cl/ml, as a consumer they should know the price of a ā€˜unit of 1clā€™

Acceptance Criteria/Requirements

  • Unit price should reflect the price of the shop, not the unit price of the original product (variant) in the product list

    If the OFN user (=shop/hub) is using the product list only, display unit price from product list

    If OFN (=shop/hub) is using inventory to create a different price, display unit price from product inventory (because the inventory unit price overwrites the product list unit price )

Why is it necessary to have different unit prices?

  • As a producer I want to be able to put different prices for different customers, for example restaurants are usually buying larger quantities and paying a lower unit price than B2C customers

Options

V1: minimum requirements: make it compliant, by displaying the unit price

V2: give users the option to edited their unit price, play vice versa between item price and unit price

Just adding to this - in Canada, there is no national legislation that would govern unit pricing. This is under the authority of provinces. Only one province, Quebec, has legislation that requires unit pricing today. However, there has been a consumer advocacy movement pushing for national guidelines for a decade or more. The requirement in quebec is per unit - so $3/gram, $.50/kg, $20/1 litre, ā€¦

Iā€™ll leave @lauriewayne1 comment further (and correct me if Iā€™m wrong) but I believe the situation is similar in the US. There is no national legislation - the requirement for unit pricing is left to states to govern (and perhaps municipalities?) . BUT the key thing here is, there IS a legal requirement to use the weights and measures of the country - so in the US, this is lbs, ounces, ā€¦ (imperial measures).

In the absence of national legal requirements in Can and USA, and likely other instances too, I favour V2 above - where users have the choice. OFN, as a platform is thus legally compliant because we offer the option, and it leave the choice of being legally compliant (or not) with the user.

1 Like

given the complete lack of interest / demand to date from aus users, if it simplifies things to just go with the base unit rather than supporting a quirky Aus 100g/100ml Iā€™d support that. Then we can deal with something more complex if/when it ever comes up here

1 Like

Havenā€™t explored this under network, sorry @Erioldoesdesign. Iā€™ll keep an eye out on how this progresses since Iā€™m doing some UI uplift of the backoffice product list at the moment.
I wonder if we need to display (not edit) the price per unit in the backoffice at all for V1 or if we can add that later down the track?

1 Like

Updates for this piece of work on the issue here:https://github.com/openfoodfoundation/inception-pipe/issues/2

and a video here: https://drive.google.com/file/d/1fR9-f8ItS6u142UvjGtmFT2Un1eKLN4B/view?usp=sharing

New videos for Unit prices work!

These are ready for wider community feedback :raised_hands::tada:

However Iā€™d like to try at have particular, directed feedback in the form of question/problem statements if possible. Not to sound rude, but unless opinions on colour, size shape, placement have either:

  1. a technical reason to reconsider
  2. a proven and demonstrable accessibility/usability reason to reconsider e.g. any grey text that is not #555555 hex colour or above on a white background does not meet minimum WCAG AAA accessibility requirements.
  3. a core brand and communication reason to reconsider

Iā€™m more inclined to consider opinions/preferences. I design based off of usability rules, technical rules etc. and very rarely on ā€˜what looks niceā€™ (though I believe the most usable thing is the most beautiful :nerd_face:) . I leave beautiful for the artists!

So, the kinds of questions Iā€™d love to have you think about as you form feedback are:

  1. From your specific instance/job function context, what worries you most about the unit price for shoppers?
    e.g. We think bulk, large quantity shoppers might get confused between the item price and unit price

  2. From the point of view of producers using the back office, what will be the most difficult thing about unit prices in product listings.
    e.g. Customer support may find that they are concerned with how back office users see the non-editable unit price field

  3. From the point of view of a back office user and a shopper, how clear do we think the directions are for unit price? Do the tool-tip texts explain clearly? does text near input fields help users to understand?

Iā€™m really interested in hearing from:

  • Backoffice novices
  • Backoffice experienced
  • Instance managers
  • Customer Support
  • Shoppers
  • The above but from non-english speaking places!

Videos

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

Single flavour item Quiches and pack of 5 example:

Weight (g) to (kg) example:

Weight (g) & (kg) but added as their own products and not variants example:

Inventory:

Shopper product list:

Cart pop-out and edit cart and payment screen:


Design file to navigate and zoom in/out on


Iā€™ll give this at first, 1 week for feedback collection and then group any similar responses for consideration. If 1 week is too short, we can extend but just so folks have some ideas of boundaries.

Iā€™m gonna wait until after 1 week to respond to any direct questions, queries to give it some ā€˜breathing spaceā€™

3 Likes

ping @lin_d_hop @Kirsten @tschumilas @lauriewayne1 @Sophie_Duponcheel_BE @hhomann @Eugeni @hernansedano @romale @rafat-khashan @Permakai @thomaz Please have a look at this future feature :point_up: If you have any comments, now is a good time to raise them :slight_smile:

2 Likes

Thanks for @ ing the right folks, I was unsure which folks to @ :heart:

me neither :smiley: I must have forgotten some people :thinking: I was trying to do 1 person per instance, but maybe we should come up with a list somewhere or create a group we can ping easily. Otherwise itā€™s going to be difficult as we grow.

2 Likes

Such reflections. In the current version, the ā€œAddā€ position is somehow floating. It is clear that now ā€œAddā€ is in the center of the price list, but the eye is trying to select / define the entire line and the floating ā€œAddā€ button is a little confusing.

@Rachel, could there be a duplicate link to slack in instance-managers? that is, the entry point will be the manager of the OFN instance

Thanks for these Eriol. Feedback as per your questions:

From your specific instance/job function context, what worries you most about the unit price for shoppers?

This is a new concept for shoppers and producers alike here. (See my comments below on the back office.) Yes shoppers will get confused between item price and unit price. They wonā€™t know why its there. For me, as someone who never sees this when shopping online elsewhere now - Iā€™d suggest that the rationale for it seems quite similar to why we do the ā€˜price breakdownā€™ in the pie chart. We also as shoppers here, never see price breakdown like this elsewhere. I understand unit price to be part of full transparency to the shopper - and I agree with that. I am wondering, if we might handle it like we handle price breakdown then? A separate icon to the pie (not sure what) that the shopper has the option to click on to reveal unit pricing. Or a more elaborate explanation in the pie breakdown? Basically - as a shopper who never sees this anywhere I shop now - Iā€™m confused about what it means and why its here. I need a bit more coaching through it.
e.g. We think bulk, large quantity shoppers might get confused between the item price and unit price

From the point of view of producers using the back office, what will be the most difficult thing about unit prices in product listings.

I think this will be a very challenging learning curve in instances where we have no substantive history with or requirement for unit pricing. The entire concept is new - not just how we operationalize it.

The biggest confusing point for me as a user is the use of the term ā€˜itemā€™. If as a user I select my ā€˜unit sizeā€™ as ā€˜itemā€™ (when I create a product) - I then enter what I will call this item as the ā€˜unit nameā€™ (ie: slice, or lemon, or workshopā€¦) . But the unit price never uses the ā€˜unit nameā€™ I give it. That is confusing. I donā€™t understand what this is comparing when it says it is a cost for 1 item. I probably have entered 100 items. Is it doing a cost comparision across all my items? So the term item in the comparsion doesnā€™t make sense to me. Second, Iā€™m confused by the ā€˜1ā€™. Isnā€™t the 1 redundant? it will always be cost per ā€˜1ā€™ of whatever we decide we are comparing (either ā€˜unit nameā€™ or ā€˜unit sizeā€™). I THINK we are comparing whatever ā€˜unit nameā€™ the user enters. So canā€™t we do whenever the ā€˜unit sizeā€™ of ā€˜itemā€™ is selected? So - in your 2 slices example - the unit price would read as the cost ā€˜for each sliceā€™. the terms ā€˜for eachā€™ or ā€˜perā€™ would always be there - and the term ā€˜itemā€™ changes to match whatever the producer enters as ā€˜unit nameā€™. Iā€™m saying this because the comparison is not across all items - the comparison is for that specific kind of item (item name) - per slice, per lemon, per bunch, per workshop, per pickup time ā€¦We are not doing a cost comparsion across all ā€˜itemsā€™.

Sorry if this doesnā€™t make sense - but it is my first though as a user who has no familiarity with this. Its not clear what we are comparing, and why we are saying ā€˜1ā€™ when there doesnā€™t ever seem to be a comparision that is other than for 1.

Second - I just want to make sure - the unit price calculation on the producerā€™s product list - and on the shopā€™s inventory list - can be hidden from view (as per the ā€˜columnsā€™ selector). In the videos - Iā€™m assuming you just had these columns selected. So in both product list and inventory list, a user can hide it from view? Could we make it hidden from view by default? Could we make it the LAST column that shows when it is selected to show? This would lesson the confusion I think - a producer in an instance where we simply donā€™t use this concept at all - could just hide it. (just like they hide sku if they donā€™t use it)

Other back office things to consider: ā€˜display asā€™ field is not included in product imports now. Iā€™m trying to think this through - will it now have to be included in the product importer? Iā€™m just not clear on the implications for product import of the unit pricing. Also - will unit pricing appear anwhere in reports?

From the point of view of a back office user and a shopper, how clear do we think the directions are for unit price? Do the tool-tip texts explain clearly? does text near input fields help users to understand?

Iā€™m not sure where to find the tool tip text - so donā€™t know what that says so Iā€™m not sure if it explains this to the user or not. Will it be translatable so an instance can customize? Sorry if I missed this - but Iā€™m not seeing any directions.

Again - Iā€™m not blocking this. Iā€™m just saying the concept is a foreign one to me - and these are my initial reflections on it as a user and a shopper.

1 Like

@romale yes. I didnā€™t choose slack because a lot of things were already shared there lately, but you are right I should have done both!

@tschumilas thanks for this detailed answer. May I ask you for one more info: when you look at food-related product on Amazon do you have a price that is shown next to the price with brackets (parenthesis) ?
Iā€™m wondering if Amazon has developed it for all region or if Iā€™m seeing something particular because of my localization. Thanks! :hugs:

e.g. : image

very interesting question (I donā€™t shop much on amazon - but now you got me hooked! (just kidding)
I created an account and went shopping. Examples below:
mayonnaise - CDN$ 3.98
Then in small print and brackets it says (CND$ 3.98/count) - so - the ā€˜countā€™ must be equivalent to our ā€˜itemā€™?
It shows on the shopping page (screenshot below) but if I add to my cart - it doesnā€™t show this /count price in my cart again.

and it does this for various pre-packed things - sometimes it gives a cost per ā€˜countā€™ other times it is a cost per ā€˜itemā€™ - I canā€™t figure out why the difference. These were all examples of stuff in jars or cans where the volume on the can/jar is clear - so I donā€™t know why it wouldnā€™t give me cost per ml.

Other things come up with a cost per fl Oz (so in imperial measures - thatā€™s ridiculous - we use metric here!) But fluid almont beverage - 32 fl Oz package gives me : CDN$ 2.69 and then in brackets (CDN$ 0.08/FL Oz (I actually doubt that is legal!).

Also - I searched for several non food products that we would sell on OFN - seeds, plants, candles, wool - and none of these have the $/count pricing. So it seems its just for food.

I tried to go to whole foods (which is owned by amazon but sells closer to the kinds of things weā€™d sell on OFN - but I canā€™t create an account there because its not available for my location)

I tried 3 ā€˜alternativeā€™ other online grocery retailers - none of them have a unit price comparison on anything.

I tried our largest national grocery chain - and they use unit price comparisons. Below see red peppers and tomatoes on the vineā€¦ and for item things - they give the comparison price using the phrase ā€˜1 eaā€™ sometimes and by weight sometimes - so it doesnā€™t seem consistent (see meal kits below.)

Its curious to me how it seems conventional grocery is doing this online - but for food only. (And I never noticed this before because I never shop online at these types of stores). But ā€˜alternativeā€™ online (closer to what OFN does) - donā€™t seem to use it at all. Iā€™ve found no farm store or food hub that uses it.


I can shop more later if you want me too - just tell me what you want to buy.

Hi, Iā€™ve followed the conversation and watched the videos - thanks @Erioldoesdesign!

This feature makes sense to me both as a shopper and instance manager, since it makes so much easier to compare product prices, even though we donā€™t have legislation for this in Brazil.

I agree that this will porbably generate some confusion between ā€˜item priceā€™ and ā€˜unit priceā€™ though , even with a clear tooltip.

Iā€™m thinking how to translate the feature in portuguese. Probably we would use something like ā€˜price per kg/itemā€™, instead of ā€˜unit priceā€™. Itā€™s not so short but maybe more straight to the point? It also seems to me that treating this as we treat the ā€˜pieā€™ - as a transparency feature like Theresa mentioned - could prevent this sort of confusion.

Last, Iā€™m wondering if we should have a tooltip explaining the feature in the product back office as well, since managers could also misunderstand it.

1 Like

I can see the rationale for a unit price for certain commodities but feel it makes little sense for vegetables which are sold by the unit anyway $xx/kg or $yy each. My concern is that it will confuse the shoppers and add extra work to admins for very little gain.

If it is decided to implement this then please make it an optional field so shops that do not want, or need it can ignore it and continue as they are now i.e. If it is filled then display it, otherwise not.