Hubs managers can choose the adapted weight and measure units for their shops given their own local situation

Software improvement 5-Done
, ,
1

What is the need / problem

Depending on the countries, producers and hub managers want to set up / sell products using different measure and weight units (kg, L or Pound, etc.). It seems that even in the US sometimes they use Kg. Also in the perspective of single instance, this needs to be thought carefully, and we need to understand if/how we manage “conversions” within the system.
Today only kg and L are supported.

Who does it impact

Today mainly US based users, who can’t really use the OFN local instance.

What is the current impact of this problem

USA can’t use the OFN.

What is the benefit in focusing on this

The community could significantly grow, with a potential large new base of users.

Links to more details

Potential solutions that will solve this problem

  • “To be forward looking, a slightly more resilient (but still small) step forward could be to add lb, oz, gal, etc. (instead of replace) and then have a map where we could filter which UOMs a particular instance decides to make visible.” (proposal from @rbarreca) with “We need to make these strings translatable by adding new keys in config/locales/en.yml and then adding the proper translation for each of the supported languages, including en_US.yml.” (from @sauloperez)
  • Later we will need to move forward and " In any case, this will have to be dealt with as we do with dates normally; We store data agnostic of the settings (UTC) and then that data is localized when displayed, according to the user settings." (from @sauloperez)

Ping @NickWeir @Kirsten @danielle @KatTheFarmer @tschumilas for info as I know you are looking for this, but it’s a bit bigger than we thought so let’s prioritize first and then really take the time to think that properly.

2

FYI - in Canada there is great interest in using imperial (lbs, ounces, quarts, gallons…) as well. Officially we are a metric country, and of course the OFN-CAN instance is metric, but almost every prospective user asks if they can ‘switch to imperial’ measures. Because the US is our major trading partner, our buying culture is heavily influenced by them. So most of us shop in lbs and quarts – and its common that shop owners do the conversion for us.
Are we assuming with the above that the instance would select the measures, or that these would be changeable at the hub level? In Canada, changeable by the hub would be ideal. BUT, I suspect this is fraught with problems. Just checking. (I’ve also thought that - given how many users have this issue in Canada - I might find a way to curate a set of tools - outside of OFN - to help them with conversions. Maybe there is a way to have a conversion tool library, a product photo library, … easily accessible from within the product editing screens or something - but linked to outside OFN ??)

3

This is interesting @tschumilas - how much of interest is this to Canadian users? If it is something that would be a significant benefit, and given your significant contributions to global pool, this would be another point in favour of bringing it into the pipe sooner rather than later

4

I think its a sig issue - users would like the option of imperial or metric. BUT really - I think I’d prioritize other things above this. Imperial-metric is a ‘convenience’ kind of thing - its pretty easy to work around. I think if we put a choice to users, improved UX, including options for different shop displays, would be improvements more valuable to them. I’m hearing that people like the flexibility of the OFN tools - but they wish the shops ‘looked nicer’ , and that it was ‘simpler’ to use. My ‘votes’ on priorities would shift in those directions I think.

2 Likes
5

Sorry I have taken my eye off this ball for a while and now the US team is nudging me. Please can someone update me as to where this has got to in the curation process or at the last global community zoom. What if anything can we offer to the USA team in terms of global dev attention to this need?

Thanks @MyriamBoure @danielle ?

6

Hiya @NickWeir ,

With June upon us and only a month till the next quarter we still have a lot of work in our Q2 roadmap that is either in progress (reports, standing orders, email confirm, bulk upload, spree upgrade) or waiting to be started (cookies). We also don’t have enough developers to take on all the work and spend all the money!!

So, the weights works will be considered as part of the roadmap for Q3. Hopefully we’ll have a lot of the above done and will free up some dev time to look at other things.

Cheers :slight_smile:

7

hello, black hat Kirsten here again @NickWeir :slight_smile:

My understanding of where we left this was that it is manageable (but annoying) for USA users to use as is, it is not a priority for anyone else and it may not be a trivial piece of work. Therefore USA needs to contribute some money to the global dev pipe before it can even be considered for prioritisation? Happy to be corrected if I am not remembering correctly

Am also going to update the description above, because my understanding is that the current impact is NOT that usa users CAN’T use without it?

8

Hi @Kirsten and @NickWeir and @danielle – I actually think this is a pretty important thing - IF we want to get the US instance operational. The US official measurement is imperial - so right now, all users are ‘forced’ to work in metric measure (yes, I know along with the rest of us ‘enlightened’ countries). It works - but it would be like AUS or UK … working in imperial. Its foreign to both buyers and sellers in the US. That said, I think its a really good fundraising ask. The problem of course is that there is not yet a clear organization in the US who could make such a proposal. What if I raise the dilemna on the next US call and see what people say?

9

I think the US team are going to definitely say this is a priority. Because of course it is. But they have no money to fund it right now.

Thus, IMO the bigger questions are 1/ whether the global OFN collective want to spend money and build this functionality for them, and if yes then 2/ given spree upgrade remains our biggest prioritiy, determining whether we want to dedicate the remaining dev time (matt yorkley, maybe some maikel time, maybe some rob time) to focus on this rather than cookies or invoices or network features.

And this is why filling in the product curation spreadsheet with votes is super super super important, so that the product curation team understands the overall priority of all the things for Q3.

10

Thanks all - this is really helpful. I want to involve @lauriewayne1 and @KatTheFarmer in this discussion as they are a lot closer to this issue than I am. Do they also get a vote in the product caution spreadsheet?

If metric is workable for them in the short term and given that this imperial work looks very fundable to me, I would be happy to wait.

Let’s see what they say…

11

Job for me and @oeoeaio from product-curation to do a micro-inception on this get some idea of how hard it might be. Here’s summary of our brief - 15 mins, not thorough - thoughts.

Think it breaks down into these 4 things

  1. Ability to display and use US customary measurement units - workaround (available now)
  2. Access to US customary units when creating products, including auto-adjust to pick sensible unit for partial or large variants (e.g. set kg and have 0.2kg auto-display as 200g)
  3. Which units available for products - instance / enterprise
  4. Conversions of units for different customers e.g. have a product set in kg but display in lbs for USA customers (as raised by @tschumilas)

1. Display and use US-custom units

First up, there is quick and dirty workaround that people could already be using - just select items and set the custom unit that you want e.g.

image
image.png1676×492 49.2 KB

and

image
image.jpg2112×416 68.9 KB

Within this ‘solution’ there is no way to have different variants within the same product display as say lbs and ozs . . so you could end up with weird looking units, but workable

2. Access to US-custom units in product creation

But that is obviously not ideal. So the next step would be to have additional (or replacement) unit options appear to choose from when adding a product so that you can actually select standard weight / volume measures
image

We think this is might be just a case of creating some additional lines in lib/open_food_network/option_value_namer.rb for us-weight and us-volume or something
def scale_for_unit_value
units = {‘weight’ => {1.0 => ‘g’, 1000.0 => ‘kg’, 1000000.0 => ‘T’},
‘volume’ => {0.001 => ‘mL’, 1.0 => ‘L’, 1000.0 => ‘kL’}}

and getting the conversions right to enable the auto-adjust of units, so it handles big and small for these units e.g.

image
image.png1254×480 37.6 KB

it looks like there is an additional - similar but different thing in product import code - app/models/product_import/unit_converter.rb - not sure if worth refactoring to have all handled from one place or if is different. didn’t spend time working it out.

and there is also a js side implementation to be considered - app/assets/javascripts/admin/products/services/variant_unit_manager.js.coffee

3. Which units are available for products?

Q: enable at instance level to choose which of these unit options appear and are available to enterprises AND/OR enable instances to customise for themselves - perhaps just tick on/off which ones they want to see

We didn’t discuss that, possibly could occur in inception - first cut could just be set in instance config so no need to even have interface for it, then deal with more customisability later if needed

4. Customise / convert display units for different Customers

The actual calculation to convert g to oz etc is obviously not complex (thanks to this etc ;). So the question is where or how this be handled. Options might include:

  • shop preference - and have a different shopfront for usa and canada customers for example
  • customer preference

Seems like this would be beyond ‘minimum viable feature’ and could be worked out after the basics above were done

Disclaimer: As mentioned above this was a quick discussion to fly a finger in the wind about how big / hard this is.

Assuming 1, 2 and maybe 3 - we think this is pretty doable. We had a bit of a discussion (with @sstead also) whether there are other places where unit conversions (just scaling within same unit) might cause problems - like group buy, bulk order management, reports etc and our first thinking is that it shouldn’t.

Rob had a slight concern about decimal places / not clean round conversions like metric - but we figured there must be a standard somewhere for how many places etc to keep if needed, and we’re only converting one way not then trying to use that and convert back, we think, so we think probably ok . .

Wonder if @Matt-Yorkley might be good person to do this, given head in all this stuff for product import recently. You may actually be more across / have better idea than Rob and I if there are other implications

Thoughts? Is this roughly what needs to happen? Have we missed many implications?

1 Like
12

NB. @oeoeaio @sstead here’s a really weird thing . .

I created two test products, here is the second one

image
image.png1588×334 34.5 KB

and here is how it is displaying in the shop

image
image.jpg1950×322 50.6 KB

WTF? is there something in there already that’s converting pints to ozs? that is reading items? in the javascript or something?

13

This looks like maybe some weirdness with cache invalidation of something? I’m 99.99% sure there is nothing that is converting unit for variants under items products.

14

Sounds like great investigation @Kirsten well done!

15

@KatTheFarmer @lauriewayne @rbarreca @tschumilas any thoughts on the above and which level of change is actually needed for mvp?

16

its been on my ‘to do’ list to play with this too but haven’t gotten to it yet - will do my best to look later tonight. So - the above example is wierdness. But I notice these are entered as ‘items’ vs by volume/weight anyway. So from my other experiences, we should be able to enter any terminology we want. We have users routinely describing things in ounces, pounds… (The issue is they can’t enter them as weights or volumes and have purchases calculated on a per lb, or per quart … basis) But as to the above test - I don’t get it - any words you put in should show in the shop (at least thats my experience.)
I’ll play later.

17

Hi all, sorry to have been so quiet! Alas, people in the US do still want to think in odd measures like gallons and pounds, ugh. In terms of adoption of the software by actual American users, I think it’s going to be a showstopper if that’s not easily available. I’m having a hard time getting my brain around what the best solution would be, and how to describe it as something funders would write a check for - @tschumilas, I think you are closest to my time zone. Would you be available to talk me through it, and the implications/benefits for Canada, when you have a bit of time?

18

Happy to do a call on this @lauriewayne1 - but I want to try to replicate @Kirsten 's experiment above first so I understand the issue myself. Will have to be into next week for me (sorry really busy on the farm right now.)

19

No problem - I can totally relate! Everything is growing so hard! :slight_smile: Please let me know when you have a window and I will try to make it work.

20

don’t get distracted by the ‘weirdness’ @tschumilasand @lauriewayne1, the key issue is how much of 1, 2 and 3 do you really NEED to get going - I think 4 is definitely beyond minimum viable product. Most likely the weirdness is a bug that we deal with separately