Openfoodnetwork: Show unit price in Bulk Edit Products

[sauloperez]

Description

- As an: enterprise user
- On page: /admin/products
- I want to be able to do: See the price of a single unit when showing the variants of a product.

Acceptance Criteria & Tests

The new form field needs to accurately reflect the unit price when the unit or price is updated. The field should also conform to the design spec specified in https://github.com/openfoodfoundation/openfoodnetwork/issues/6449#issue-756226197.

Note that unit price should also be available in the columns dropdown.

1. Go to /admin/products
2. Unfold the variants of a product
3. Change unit and price fields

The changes need to be reflected in the unit price field at all times.

See https://github.com/openfoodfoundation/openfoodnetwork/issues/6494 's "tech considerations" for reference.

[jaycmb]

As discussed during the Kick-Off-Meeting, clarification on the calculation of the unit price is needed around the use case of creating a variant (or potentially already at product level), that consists of multiple items

How it should /was supposed to work:
If a user creates a variant, e.g. "5 pack of Quiches" for €14,50,
then the unit price should be calculated as €14,50/5=€ 2,90

With the current field _"Unit"_ we are not sure, if the logic works like this

Next Steps

• [x] Check if the Unit field actually allows the user to specify the number of items within a packaging size or if in case of unit size item (vs. weight or colume) this field is not needed / functioning, since it is always 1 (@sauloperez or @andrewpbrett )
• [x] Check how users are currently using this field (Metabase @sauloperez )

Discussed Potential Solutions (tbd, after insights from above and potential user testing)

In the case that a user chose item as _Unit Size_ (while creating a product, the on Bulk Edit / Variants Page)

• Hide existing field of unit value (since it would be 1 per default)

• Display a new field to specify number of items, adding a tooltip like "Please specify the number of items in the packaging size. This helps your customer to understand the price per item"
  -> This would require new designs @Erioldoesdesign

[andrewpbrett]

I ran this query in Metabase:

select count(*) from spree_products inner join spree_variants on spree_variants.product_id=spree_products.id where spree_products.variant_unit = 'items' and spree_variants.unit_value=1;

And omitted the last and clause to get the total number of variants using "items".

In the UK, 84% of variants that use items have a unit_value of 1.
In FR, 75%
In AU, 70%
In ES, 70%

So based on that, it's clear that a significant portion of people are using this field to indicate, for example, how many items there are in the variant being sold (a five pack of something, for example). Looking through some of the descriptions confirms this ("two pack of pork chops"... etc)

If we assume that everyone is using it that way, then we can calculate the price per item based on that field. However, there are also plenty of examples (just glancing through) where the unit value is, for example, 1000. Often in these cases the person is using "items" but then specifying that they're selling in "grams" as the unit.

So we're going to end up with some non-sensical unit prices if we assume that everyone who puts a number other than 1 in that field is selling an [X]-pack of something.

[andrewpbrett]

To be a little more clear, and hopefully answer @jaycmb's second question:

Right now that field is used in two main ways (that I'm aware of, at least):

1) it's displayed on the shopfront (e.g. "1 bunch" in about 75% of cases, or in the case that someone has opted to use it to indicate multiple items in a pack it will show up as "2 pork chops")

2) it's used to calculate the weight of the order, relevant for calculating shipping costs if that's how a shop owner has set it up.

So even though there are definitely some people using it in weird/incorrect ways, I think that the easiest path forward is to keep the field as it is, use it to calculate unit prices, and more clearly indicate that it should be 1 except in the case of a multi-pack. We can then easily use it to calculate unit prices in the same way that we calculate them for non-item variants.

[Matt-Yorkley]

Uhh... I'm not sure sure we can show unit prices in some of these pages (including this one). I think it can only be in the shopfront. Prices can be modified by various things related to order cycles, and those price changes can't be seen in the context of this page. So whatever unit prices are shown here will potentially be totally different when a product is in the shop. For example; a product could have one price in one order cycle, and a different price in another, or different prices depending on which customer is looking at it.

Also, the requirement (on the legal side) is only that these unit prices are shown to shoppers anyway, right? Or have I missed something?

[jaycmb]

@Matt-Yorkley Yes, unit prices will be different depending on product areas they are displayed. See AC in the Epic https://github.com/openfoodfoundation/openfoodnetwork/issues/6449

And correct, legal requirement is only to display them to shoppers but we should also show them to the enterprise users so that they now what their customers see in the shopfront.

That´s why we included it in when creating products, variants and inventory.

It´s true though they might be not meaningful to the admin user at each stage..

[Erioldoesdesign]

re. showing it to admins in BO.

We either run on the assumption it is not useful

or run on the assumption it is useful

It's easier to test if we assume it is useful and then remove or change it later than the former, where we would have a more abstract way of testing with users if it is useful if they don't already see a way the BO connects with a shopper view.

[jaycmb]

My assumption was _is useful_ to Admin users, assuming it shows them what their customers see in the shopfront.

If this is not the case, because this is not the final price the shoppers see, then we

• a)either need to indicate this in then tooltip (like _"Unit price is based on the price of the product, it can differ from the final price that your customer will see due to OC or customer specific prices"_)
• b) not display at all but we might have admin users confused if there is new information displayed to their customers that they don´t know how it´s built or what it is for

I lean towards a), but b) would mean less effort and in the end the Unit prices are primarily about compliance and value to the shopper
Ping @RachL for your opinion?

@Matt-Yorkley , by

I'm not sure sure we can show unit prices in some of these pages

You mean can not in the sense of technical limitations (why?) or should not because of the stated above, prices are not reflecting final prices

[RachL]

If it was a "should not" I'm leaning towards a). as well. Hubs that do use fees - margins etc are rare. So the ones that have brought up the legal requirement often brought it up because now they are used to work like that. They know how much their product cost per unit and per customer, they don't know prices per packaging.

But if it's too complex, yes let's just focus on the shopfront: the legal requirement is the priority.

It's just sad we didn't catch that technical complexity earlier in the process :(

[Matt-Yorkley]

You mean can not in the sense of technical limitations (why?) or should not because of the stated above, prices are not reflecting final prices

I mean we technically can do it, but it won't match what the customer sees, so it probably doesn't make sense. It might end up being more confusing when they don't match. Also the idea that we can just compute the value when the product is saved and re-use that value is not correct, especially in terms of the shopfront. It'll need to be re-calculated on the fly each time, as it'll be fluid depending on the different contexts like order cycle, fees, tags, etc.

[sauloperez]

It'll need to be re-calculated on the fly each time, as it'll be fluid depending on the different contexts like order cycle, fees, tags, etc.

But that's the assumption we worked with I believe.

[Erioldoesdesign]

Just flagging this work is also included in the UI Uplift project as in, there are mock-ups of the back office where there is a column a back-office admin user can 'toggle' on/off that shows a column for unit price.

[jaycmb]

It'll need to be re-calculated on the fly each time, as it'll be fluid depending on the different contexts like order cycle, fees, tags, etc.

But that's the assumption we worked with I believe.

That was also my assumption. I m a bit confused here now.
@Matt-Yorkley, were you also referring to the shopfront with your concerns above?
Because yes, the Unit Price needs to be recalculated every time depending on context, for both
a) shopper (unit price displayed to the shopper in the product list can be different from unit price users sees in the checkout, unit price can be different for different customers)
and b) Admin user.

Since the calculations have to be done for a) anyways, we assumed that this goes for b) as well.

However, we need a decision here if we

• go as planned (if technically not too complicated)
• split into to phases V1: display unit prices in shopfront (to be legally compliant and provide value to the shopper), V2: display unit prices in admin (for improved admin experience)

[sauloperez]

I agree with splitting into phases. Once v1 is done, we can better assess @Matt-Yorkley 's concerns by running user interviews and/or A/B testing. That feels a safer bet.

[jaycmb]

My concern here is that if we split into V1 and V2, V2 won´t ever be done - being realistic ;)

So I would like to understand first the technical concerns: do they not also apply for the shopper side?

It'll need to be re-calculated on the fly each time, as it'll be fluid depending on the different contexts like order cycle, fees, tags, etc.

And a rough estimation of how much effort does it mean to implement also the Admin side.
Just because form a (admin) user perspective, it would be much better to have it.
As we know from user testing that our users like to see reflected what their customers see in the shopfront.

[jaycmb]

Notes from the call with @sauloperez

Regarding the original question: how to handle the unit_value field
we agreed on @andrewpbrett suggestion

I think that the easiest path forward is to keep the field as it is, use it to calculate unit prices, and more clearly indicate that it should be 1 except in the case of a multi-pack. We can then easily use it to calculate unit prices in the same way that we calculate them for non-item variants.

So for variant_unit = item same as for variant_unit = weight, unit price can be calculated as price/unit_value

We could do user testing to see if this is clear enough or needs more indication to the user in the case of multipacks, that Unit_Value should be the number of items per multipack.
(Worst case we will have unit price being the same price as the Multipack-Price, in example above €14,50 per 5-Pack-Quiche instead of €2,90 per single quiche)

Regarding: should we split up into V1 (Shopfront only) & V2 (Admin)?
we agreed to not split the epic into 2 phases, as it is important to have the information for the Admin user what their customers will see in the shopfront - even if it might differ from the final price, which will be indicated by tooltips.

Like this we will:

• Increase transparency & understanding for the Admin user
• Likely reduce incorrect information to the shoppers (due to incorrect unit_values)

However, we agreed the part visible to the shopper can/should be rolled out first (-> @sauloperez to discuss feature toggle with @jibees) while we are implementing the backoffice issues.

[jaycmb]

Note: Designs will be updated so that the unit price field, also contains the unit, not only the price.

E.G. Unit Price $5.00 / kg