Giter Club home page Giter Club logo

Comments (8)

berrnd avatar berrnd commented on July 19, 2024

Quoting myself from the origin of this request:

Maybe that's how it works for you, but that's not necessarily the case for everyone.

Fun fact: That was exactly the case until v3.2.0. See #1718 and v3.2.0 changelog where this has been changed due to someone wanted to have this behaving differently. I already noted there that it doesn't make that much sense practically, but I've changed it anyways due to consistency reasons.

So obviously and kind of always, the bigger challenge is to make it fit everyone - feel free to propose an in-depth idea for that on the corresponding new Feature Request.

So I'm looking forward for such an in-depth proposal on how to make this fit everyone, everyone is invited to provide that. Changing it back and forth based on complains from the either and the other side is definitely not an option.

 

It doesn't really help with checking the stock since I'd argue that very seldom somebody has 300 tomatoes in stock. And it looks like a bug to the user if they find 1200 chickens and 300 tomatoes on their shopping list.

Lol, what an absurd comparison. You even mentioned yourself just minutes ago that you "don't like software that tries to guess what I want", but here it should magically guess that 1200 chickens or 300 tomatoes is not what you want? Hilarious.

from grocy.

berrnd avatar berrnd commented on July 19, 2024

Additionally quoting someone else from the mentioned origin of this request:

I suspect you'd find it more useful to put in a conversion with the average weight of a tomato
[...]
That'd let Grocy give you an idea if you actually have enough tomatoes in stock for the recipe and also let it give you an approximate count to buy.

Have you tried that? Sounds for me like a practically oriented very good solution for this "problem".

from grocy.

AllesMeins avatar AllesMeins commented on July 19, 2024

Fun fact: That was exactly the case until v3.2.0. See #1718 and v3.2.0 changelog where this has been changed due to someone wanted to have this behaving differently. I already noted there that it doesn't make that much sense practically, but I've changed it anyways due to consistency reasons.

I don't think #1718 applies here. If I understand it correctly, they were talking about a scenario where there is a conversion-rule available. And I'm completely fine with their wish. If there is a conversion defined for this ingredient or unit: Go for it and convert it.

I'm talking about the situation where their is no QU conversion defined. Currently grocy seems to go "I've no idea how much 300g tomatoes is, so I'm just assuming that one gram equals one piece of tomatoe" - resulting in a shopping list where I've entries like "300 pieces of tomatoe" and I don't see the benefit of this. Why try to convert a unit when there is no conversion-rule available?

So my proposal would be:

  • If "Only check if any amount is in stock" is selected, check whether there is any QU-conversion available for the given unit. If this is the case, everything is fine. Don't change the current behavior.
  • If this is not the case don't do a 1:1 conversion, but just add the amount and unit as specified in the recipe to the shopping list (and do the check whether stock quantity >1, as explained in the help text).

I don't have a complete overview over all the wishes out there. But this shouldn't break #1718. Of cause I only see the use-cases that I'm aware of, so if you're aware of any benefit of doing this 1:1 conversions, let me know. Maybe I can think of a way to factor those in as well.

It doesn't really help with checking the stock since I'd argue that very seldom somebody has 300 tomatoes in stock. And it looks like a bug to the user if they find 1200 chickens and 300 tomatoes on their shopping list.

Lol, what an absurd comparison.

But it isn't a comparison. It's an actual example what is currently happening for me. I created a recipe and provide that it needs 300g of tomatoes and 1200g of chicken and I end up with 300 pieces of tomato and 1200 pieces of chicken on my shopping list. How can this not look like a bug to an average user?

but here it should magically guess that 1200 chickens or 300 tomatoes is not what you want? Hilarious.

No, it should explicitly not guess what I want. It should just take the provided ingredients from the recipe and put it on the shopping list when there is no conversion-rule available.

Have you tried that? Sounds for me like a practically oriented very good solution for this "problem".

Sounds more like a workaround to me. Of cause I could go and guess the average weight of every produce that is sold by piece and by weight, but I still don't see why not just to add the one quantity that is known to be right (the one defined in the recipe) when there is no conversion rule available?

from grocy.

berrnd avatar berrnd commented on July 19, 2024

I don't have a complete overview over all

Just to mention two related other functions of Grocy which need then special handling for this, adding more complexity everywhere (most likely that's not everything which need to be touched when essentially allowing arbitrary units on shopping list items):

  • Recipe ingredient amount comparison with what's on the shopping list for missing ingredients. Such a comparison can't work without a conversion factor when different units are involved.
  • "Shopping list to stock workflow": Grocy necessarily needs the factor to get the QU stock from whatever is on the shopping list when adding anything to stock. It's therefore currently impossible to use a unit on the shopping list where no direct or indirect conversion exists for the related product / unit.

 

How can this not look like a bug to an average user?

You can input bullshit, Grocy does math based on its definition, probably this leads to output bullshit without that much surprise. If user-errors are now also treated as Bugs, I'll be most likely even more out here than I'm already be.

 

but I still don't see why not just to add the one quantity that is known to be right (the one defined in the recipe) when there is no conversion rule available?

I just mentioned two other implications involved, Grocy is not a simple and dumb shopping list tool, having proper conversion factors available is pretty naturally essential for having and being able to provide a proper stock management experience.

 
If this example here is how you use Grocy for each and every recipe (ingredient), maybe Grocy is just the wrong tool and you're probably happier with a simple recipe manager instead.

from grocy.

AllesMeins avatar AllesMeins commented on July 19, 2024

Just to mention two related other functions of Grocy which need then special handling for this, adding more complexity everywhere (most likely that's not everything which need to be touched when essentially allowing arbitrary units on shopping list items):

* Recipe ingredient amount comparison with what's on the shopping list for missing ingredients. Such a comparison can't work without a conversion factor when different units are involved.

* "Shopping list to stock workflow": Grocy necessarily needs the factor to get the QU stock from whatever is on the shopping list when adding anything to stock. It's therefore currently impossible to use a unit on the shopping list where no direct or indirect conversion exists for the related product / unit.

But this also breaks with the current solution?!? Maybe not in the technical sense that it throws an error, but I still can't use the workflow because it would add 300 tomatoes I never bought to the stock. And the amount comparison gives wrong results as well when it informs me that I've 10 tomatoes on the list and need 290 more. So it might not throw an error, but it still isn't usable for these cases.

You can input bullshit, Grocy does math based on its definition, probably this leads to output bullshit without that much surprise. If user-errors are now also treated as Bugs,

But where is the "user-error"? You give the option to use arbitrary units in recipes without being willing to properly deal with them. I say: The current solution is only working for anybody who uses grocy exclusively as a recipe-tool. Everything else in that whole chain of tools returns wrong results as soon as you check that "Only check if any amount is in stock" box.

I just mentioned two other implications involved, Grocy is not a simple and dumb shopping list tool, having proper conversion factors available is pretty naturally essential for having and being able to provide a proper stock management experience.

If this is example here is how you use Grocy for each and every recipe (ingredient), maybe Grocy is just the wrong tool and you're probably happier with a simple recipe manager instead.

No, it's not - I try to use base units wherever possible. But unfortunately the reality is, that you can't just force every ingredient into one base unit. If I'm making a sauce, shopping by weight is probably the right way. If I want to make sure every guest gets one stuffed tomato, I need to shop by pieces.

And in my opinion: Knowingly doing "bullshit conversions" (and sorry, just exchanging one unit for another is just that, because it will always give you wrong results) is the worst possible solution.

from grocy.

berrnd avatar berrnd commented on July 19, 2024

I say: The current solution is only working for anybody who uses grocy exclusively as a recipe-tool.

I say: The current solution works as defined. It doesn't need to fit your specific use case and it can't magically adapt to it. It does what it was told to do, now and unless someone takes care of making it "better" (this doesn't need to be me, this is Open Source, I can always only recommend to start working on the stuff which bothers you most right tonight).

 

that you can't just force every ingredient into one base unit

But you can use e.g. average weight conversions as already proposed on Reddit. Call it a workaround rather than solution, but that doesn't change that it practically pretty much works out great.

 

And in my opinion: Knowingly doing "bullshit conversions" (and sorry, just exchanging one unit for another is just that, because it will always give you wrong results) is the worst possible solution.

In my opinion: Falling back to a (maybe practically looking bullshit) conversion of 1:1 is the most user friendly way to do stuff, the other option would be to strictly forbid each and every special use case not defined end to end beforehand. Grocy is supposed to be an open system, so I decided to not do it that way throughout the whole application. Also this decision doesn't have to fit you or everyone living on this planet. I've learned one thing (obviously very important to many) in the last 7 years Grocy: I always do it wrong (and technically bad af), I can't make it right. And that's pretty much why there is that huge progress in the last couple of months you can review right on this platform.

from grocy.

AllesMeins avatar AllesMeins commented on July 19, 2024

I've learned one thing (obviously very important to many) in the last 7 years Grocy: I always do it wrong (and technically bad af), I can't make it right

Sorry to read that. But reading this thread, it isn't that much of a surprise. So maybe some word of advise from the other side (and from somebody who does such stuff for a living):
Don't blame it on the user. Nobody uses grocy deliberately wrong. Don't dismiss it with "that's just your use case". Don't call it "If you enter bullshit". Don't call it hilariously. There is this stupid saying that the "user is always right" - and it is true in the way that a user complaining usually shows you something where the design of a program doesn't properly communicate what is supposed to happen. Maybe there isn't an easy fix for that, maybe there isn't a fix at at all. But don't take it too personally. Most users taking the time to write a proper bug report or to think of possible solutions also just try to help to make the software better (admittedly with their own personal interest in mind).

from grocy.

berrnd avatar berrnd commented on July 19, 2024

Thanks for another round of wise advice on how to socially interact from an (I guess) expert - I don't do (or do I?) anything related to IT, software or such for living, so all that is pretty new to me. You really gave my Grocy-thrive another push, thanks a lot again.

You mix up your good principals, which are more grounded on a professional / business product, with a (free, that's most likely the problem) Open Source tool. I know of course that the vast majority of Grocy users never come here for complaining and just use and enjoy the tool how it is, maybe helping organize their daily life just a little better - exactly for what Grocy was born. Start such an Open Source project which has thousands of users and the (few, but loud) idiots will come after some time just like magic. You can also takeover this one if you want, I'd gladly forward then all the stuff happening not publicly (hundreds of private messages, at least a few calls per week, and more) - you'd get the full experience by that and maybe understand then a little better, giving maybe the same wise advice to yourself next week and painfully recognizing that "Don't take it too personally" is nothing more than a very stupid saying.

Enough off-topic for this here, what can be improved is pretty clear (so going to lock this) and you can start making it reality yourself right tonight, or simply wait for it for an undefined period of time (which could also be never).

from grocy.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.