Allow non integer quantities to be ordered

Thanks @sauloperez for those insights, I’ll let @Augustin comment if needed on the tech decision as this is beyond my skills :wink: not sure that’s needed at that step as I’m in fact questionning the fact togo in that direction. Let me explain.

About how we did in France, actually to be honnest it has never really been an issue, we explain all the time how to create a product, and variants, and people understand, “ok that’s a constraint we have, we are a free software that a community is developping step by step, and if when using the software you have needs that emerge we are happy to try our best to listen to them and answer them the best we can”. Concretey we tell people to offer 2-3 variants of the main “quantites options”, depending on what they want in term of their own organisation. For instance on the producer market, they are used to hear people requests for quantities, they know what quantities people usuallly buy, maybe they would offer 500g and 1k variants. Or if mushrooms, 200g variants. If herbs or spices 100g variants. You know, like in a supermarket where products are packed… people are used to buy “packs of” things as well, it’s really not an issue neither for hubs nor clients. You can also argue that it simplifies their management and manipulation, they can prepare “15 bunches of packs of 200g mushrooms” in a row instead of 150 on a side, 250 on another and look at the order list before each weighing.

The issue of non-integer quantities is not only a tech issue, it’s also a UX issue and I don’t really see how this is gonna work. It changes a lot the whole products logics, like in producer report, if “carrots” allows non integer quantities, the total is not anymore a sum of quantities ordered x a unit of a variant, it becomes just a sum of quantities.
Also in term of UX, if you have a product line with the price per kilo, is it user friendy for a client to write : I want 0,25 kilo of carrots? When you buy on the market you would talk in kg if more than one kg and in grams if less. So finallly having two variants, one 1000g and the other one 100g could potentially be more user friendly, and I would say that is something to test with your producers and their clients before investing time and money in this Spree extension, in an agile approach.
The producer want that because of their habits on the market, but the behavior on a platform is different, so maybe that’s better to say “we hear that request, let’s test first as an online interface is different from a face to face interaction on a market, and let’s see of that works well or not as it is”… I remember we discussed with Enrico about the fact that we shouldn’t always say yes to a usr request if that is not serving our product vision, so let’s study seriously the UX :wink:

I have looked at different food webshops and they all work the way we work today, they decide the quantity format and the client “add to his basket” or not, that’s the way people buy on onlline store, and thinking again about that to be honnest I’m not sure it is desirable to evolve the product in that direction.
Some examples:

Another way to handle that that comes to my mind could be to separate the “indicative price per kilo”, like add in the product description, whetever the existing field, another field : price per kg. Like in a supermarket, even when you buy by unit a jar of jam, you always have the indication of the price per kg, it’s mandatory to enable people to compare the prices of various products with different pack format.
So you could propose then a variant by 100g and display the price per kg as a side.
This is something anyway we will push from France at some moment as this is mandatory for us.
Happy to work on the ux with you if you want that to happen :slight_smile:

Looking forward to hear what you think about that, and happy to discuss over hangout or mumbe about it as we are in the same timezone :stuck_out_tongue: