Display price per unit on variants

[Jana]

Clarification

One note to avoid confusion when watching the videos
When inventory is used, the unit price should always be based on the inventory.

As stated in the Acceptance criteria:

• If enterprise user is using the product list only, display unit price from product list
• If enterprise user 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)
• The unit price reflects the price of the shop, not the unit price of the original product (or variant) in the product list

Thanks for your feedback @tschumilas! Commenting on some of your points:

Agree that price per 1 item is redundant, because that´s the purpose of the unit price: indicating the price per unit (whatever this is, kg, g, l, item, bunch) in which it is sold.

Columns in Admin
Regarding Theresas suggestion to have it as the last column in Admin: the reason why we have it next to price is because unit price and selling price are very much connected logically. This is why they have to be close to each other for shoppers, both offline & online. So the same thing should apply also for Admin users.

Here is an example of how unit prices are used in supermarkets. Maybe that helps with the confusion around items:

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

Item is simply the unit used per definition if goods are not sold by weight or volume but in pieces. No matter if you name that piece bunch, quiche or lemon.
(Also from a technical point of view it is much simpler if it is always price per item as soon as a user chooses Item as Unit Size when creating the product

And sure, the column can be hidden as the other columns (we would not hide it per default though, as users should be aware of this being a new feature).

[tschumilas]

Thanks for this @Jana. Like I said, I’m not blocking anything - for me, as a farmer using this, it would be clearer if it was what the units are, versus the word ‘item’
One other question occurred to me - in a situation where the shopfront (producer shop or hub shop - doesn’t matter) has fees that are added to the product list or inventory price, the unit price that shows in the shop to consumers, and the unit price that shows to the user in the backend will be different. Right? (Just like product prices are now). I’m just making sure I understand.

[Jana]

Currently the acceptance criteria are like this:

• if the enterprise user is a reseller (buy and sell a product with a markup) the unit price of the product should adjust to the new price including the markup
• if the enterprise user sells distribution services (they don’t add a markup but they invoice a service fee, on top of the original price of the product from the producer) the unit price should not change.

In case you see a case that is not covered by those, let us know which additional cases you feel are missing. This will also be useful when we think about testing.

[tschumilas]

If the enterprise user is a reseller, the unit price should adjust to the new price including the mark up - in the shopfront. For sure. But in the supplier’s product list too? ie - the unit price in the supplier’s list will always be the same as the unit price in the shopfront? Is that true? If so - that will be another thing to explain I guess. Producers will not know how to calculate it - since many suppliers/producers don’t know what the markup is for the re-seller. So - good to know this and note in the user guide for sure.

I had no idea some people invoice a service fee outside of OFN!! Thats interesting to know.

[Kirsten]

I got about half way through the videos before getting lost because it’s too small for me to see clearly on my tiny screen and I wasn’t following the differences between the cases. If it’s not too hard, would it be possible just to have a nice big screen shot of each case? So it’s easier to scan and go “yep that makes sense” “yep that too” etc?

If that’s too much of a hassle (which is fine) I’m happy to assume /trust that enough other people have watched through them all and are ok with this!

[Erioldoesdesign]

Is it possible for you to navigate around the Figma file using this link: https://www.figma.com/file/EPKyXwl5VDQaw8IBHalCEZ/Unit-Prices?node-id=0%3A1

Happy to do screenshots but if the figma file is navigatable then that saves time on my end.

You can also add comments directly to Figma by using the little comment bubble:

Just flagging in general, I’ve been through these comments and have some responses, I’m just making sure that they are useful and make sense re. my typing before posting!

[Erioldoesdesign]

Okay, folks so it’s been a couple of weeks on this in ‘feedback stage’ so we’re officially closing this for feedback and now updating on the changes that we made relating to community feedback and clarification and what we’ll not be taking forward in this ‘V1.0’ of this feature.

Firstly, there was a fundamental misunderstanding that design made (sorry) about the link between price and unit price* unit price can never be ‘not connected’ to the price. However, producers *in inventory) can create multiple products with different price+unit prices depending if they sell at different prices to different stockists. Therefore, we’ve removed the little chain link icon and column because this was a click function that intended to have you edit price and unit price independently which is not allowed.

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

List of changes for V 1.0

1. No more chain icon + price/unit price future edit functionality
2. Added a tooltip box in the ‘add product’ section next to the field for the unit price calculated.
3. Removed the integer of ‘1’ from the shopper view so it reads: ‘£3.00 / item’ rather than ‘£3.00 / 1 item’

List of considerations for V 1.1

1. Changing shopper copy from ‘£3.00 / item’ to ’ ‘£3.00 / bunch’ ‘£3.00 / cake’ the display being intelligent enough to discern the ‘item type’ and display that.
2. Implications on import into the product list
3. Implications on reports
4. Implications across other parts of the back office (invoices et.c or other areas user raise once live)
5. Editable unit price (that then changes the price of a product)

General considerations raised

1. OFN’s design files in Figma currently don’t work on an ‘accurate’ grid system that corresponds to the FE dev environment. An alignment of button issue was raised. We’re considering what efforts and collaboration is needed to work on accurate grids and numbers in our design files that accurately reflects the FE of OFN.

This is now going into the next part of the design process where design hands over/works with product and dev to create epics and issues

[konrad]

Hey all,
I can see this is in an advanced stadium already. Maybe this comment can still be considered.
I am quite confident that the international notation for units like this is x/y, like km/h (kilometers per hour), N/m² (Newton per square meter = pressure), V/A (Volts per Ampère = Watt (Power)). So the same accounts for price per unit (€/item, $/100 g, …).

To comply with this standard and make this wonderful new feature look “even nicer” I am recommending to drop the blank spaces before and after the slash /.
Does anyone agree?

Thank you for reading!

[Erioldoesdesign]

I thought the spaces would make a screen reader pace the reading out loud of the text which is why I had the spaces. Do you know how quickly a screenreader reads ‘€/item, $/100 g’ out loud?

[konrad]

According to my research most of the screen readers do read the “/” out loud. This and the reading speed seem to be independent of the blank spaces before and after them.
Most read “/” as “slash”. So it’s not very nice either way, but nothing we could change by design. Users can configure their reader to read “/” as “per” - but this isn’t always correct of course.
Interesting: Google actually reads “1 €/g” correctly as “one euro per gramm” but “1 € / g” as “one euro per g”.

Anyways, I think we should drop the blank spaces because they don’t affect the screen reading positively and it is according to the standards.