Allow non integer quantities to be ordered

#1

We discussed with @enricostn and I just received another request from a user on the same topic…
Usually when you buy food on the market, you have the price per kilo and you say you want 400g or 750g or whatever quantity, and the produer will apply the price per kilo to the given quantity.
In OFN this is not as flexible today, you have only two options:

  • either you create multiple variants for some given quantities, like 500g, 750g with the corresponding price attached
  • either you create the product in “weight (g)” and you attach the price per g, so the client can tell the exact quantity they want in g, but it’s not at all usual to see the price per g, it doesn’t mean anything for the client

SO we would like … to allow a client to buy non-integer quantities of a given product.
This could be a checkbox at variant level “allow customer to buy non integer quantity”

We saw some previous discussions on that : Bulk and group buying - wishlist or Shopfront and Cart page fixes (user reported)
and it has been previously explored and was apparently pretty complex : https://github.com/openfoodfoundation/openfoodnetwork/issues/659
@enricostn do you think that becomes easier with the spree upgrade ?
Can we re-open the discussion on that ? :slight_smile:

3 Likes
Enable hubs to handle variable weights onsite sales
#2

This is really a deal breaker for us. I don’t know how it works in other parts of the world but as @MyriamBoure mentioned in these latitudes people are used to buy 1/2 kg or 250g while almost always the prices are per kg.

I still need to understand what was the technical limitation if any. I’m going to take a look.

1 Like
Bulk and group buying - wishlist
#3

I haven’t found much information about why there’s this limitation of line items with integer quantity. Pasting here the links for later reference:

The limitation was introduced in the following commit. No explanation why:

In 2015 someone had the same question as we have now an opened an issue:

The only similar case I found is this question in the mailing list:
https://groups.google.com/forum/#!searchin/spree-user/decimal$20quantity|sort:relevance/spree-user/q18ibXS-_ig/1_32cvQsTtoJ

#4

In the Solidus community they answered us with this PR: https://github.com/spree/spree/pull/4741. There’s still stuff to be done in Spree to fix this.

#5

Possible solution

With all this information we had an insightful discussion with @enricostn considering four ways to tackle this, assessing their pros and cons. These are: implementing it in the Spree core, with a Spree extension, by implementing it in our own fork of Spree or lastly, doing it in OFN as all our other features.

From the pros and cons of the image above we reached the conclusion that a Spree extension is the least bad way to proceed :sweat_smile: . You can see a warning next to the items that make each solution a deal breaker.

Way to proceed

Having that solution and its pros and cons in mind, a way to move forward could be to ask for a freelancer from the Spree core maintainers community that can implement this for us. At Katuma we are at 100% of our capacity and no one else can spend time on it. Besides, this feature requires a deep understanding of Spree.

We reached out to the community and freelancing is indeed a possibility but we need to keep asking to find someone. We did get precious information about the topic so far though.

Keep in mind that all this comes after OFN reaches Spree 2.0.

We kind of panicked initially because we were afraid this could have a negative impact on our user acquisition process, possibly risking the viability of Katuma. So, in the meantime, we need to know how each instance has temporarilly solved this issue cc @CynthiaReynolds @MyriamBoure @Kirsten .

The challenge for us here is to find a first source of funding to fix this.

Any feedback is very welcome.

#6

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:

Product prices with up to 5 decimal places or more
#7

Actually I want to add one point: all the big hubs using the OFN in France never even asked us that feature. Only a producer who wanted to open his own shop, I think it’s because he is used to sell that way on the market so he imagines that people would be the same and buy the same way online, but I think this is a wrong assumption. And maybe this is also our role to guide the producers in the online sells habits :wink:

#8

These are very interesting ideas @MyriamBoure. Definitely we need to investigate and find out what are the actual needs. For now we’ll try to make our way using variants. I still have to experiment with all of the available options but unfortunately none seems ideal to me.

Either way from the technical standpoint we had no luck finding any freelance from the Spree community but we did get the following insight from one of the answers:

I work on Solidus full-time and am not available for freelance.

I can tell you right now that changing quantity to be a decimal is simply never going to work in either Spree or Solidus. Every single system is written specifically for those to be integers.

It might be possible instead to add an additional “weight” field to line items, and change pricing to be determined by that.

so if we ever decide to fix this, this approach above is way more affordable.

1 Like