-
-
Notifications
You must be signed in to change notification settings - Fork 763
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Allow to scale down below original recipe #3755
Conversation
…ust like ingredients
I know this is not done yet, but I'll go with some early feedback. However, I feel that changing the increment midway through is pretty unintuitive for the user. I think the right way would be to change the current behavior to increment/decrement by one instead of doubling/halving. |
Also while playing around with it i found a bug in the current implementation. When setting the serving sice to 3 and scaling all the way down the scaler does not calculate right (3 -> 1 1/2 -> 3/4 -> 3/8 -> 1/5) |
yeah, that looks a bit overly complicated for my taste. My idea is:
|
The thing is, that when you increment the scale by one, you actually double the servings. And just adding 1 to the servings does not always work. E.g. I have a recipe for a spices mix, that yields 50 gram of mixed spice. If the My take would be to keep doubling/halving because that's just very intuitive. If a lot of people think that's too course, we could consider a smaller step size, e.g. 0.5. Here's a comparison: Doubling / halvingI think this is the most intuitive, given the limitation of only
Step size ½ above 1, ¼ below 1Increasing the scale in half steps makes sense, but there's not really an intuitive alternative if the scale get below 1. We could make it more linear, by decreasing in 1/10th steps:
In this example it does work nice for "50 gram", but all the values (except 2) for the "4 portions" example are useless. An alternative would be to stick with halving below 1, but add one extra step between 1 and ½, like this: Compromise
This would make the code quite a bit more complicated, since we're introducing an extra break point or an exceptional case, depending on how we implement it. It's also not really intuitive, but I guess a user will get used to this quickly. My personal order of preference:
|
Ok, i think you missunderstood my idea. They are to increase the serving size by one. E.g. it is quite common to have serving sizes of two (between 2 and 4 is the norm i would say) for recipes. Tap the I would say your spice example is a bit of an outlier, but a good edge case non the less. For this i would either put 50g as something like one portion, or leave it at 50 and one can tap the servings button and type in manually the desired amount in grams that is needed. maybe other maintainers can wheight in as well, as it might be that my position is an outlier here |
I don't think changing the serving size instead of scaling it is a good idea. It defeats the purpose of the design where you can put anything in the serving size field. If we go the route of editing the serving size instead of scaling it, I'd suggest to change the serving size field to a simple integer. That leaves the question open what we should do for scaling down, below the serving size of the original recipe. ProposalHere's my proposal:
|
…eird results if the fractions became very small. The new code is shorter and more robust.
Good work so far, @bartkummel! What you've done is already a big step forward from not being able to scale down at all, though I do have some ideas that hopefully will be useful for future iterations of the idea: I think the most intuitive route for the user is to be able to just input the number of servings they want to make and have Mealie calculate the ingredients for that number of servings. It should be noted that the current implementation does sort of allow you to do this if you manually edit the scale by clicking on the servings button above ingredients. But this turns the focus from "what do we do about the scale" to "how many things does the person want to make" which is a better approach for useability. My thoughts on how to do this: For example, I create a recipe that serves 4 once cooked. I put in the ingredients, put a 4 in a field that says something like "number of servings," add my steps, and hit create. In the background, Mealie then divides my ingredient amounts by my number of servings to create a baseline 1 serving version of the recipe to use to calculate the ingredient amounts that are shown to the user in the future. The default number of servings is still 4 because that's what the user entered for the original recipe, but if the user wants a different number of servings they can just click the Servings button (where the current scale editor is), and enter the desired number of servings while Mealie calculates the new scaled recipe by simply multiplying the amounts in the "baseline" recipe it calculated at recipe creation by the requested number of servings. The only thing that would be complicated is the UX approach for displaying fractional ingredients that don't adhere to imperial measurements, but you could probably accomplish that by giving the user a warning that states the issue and offering an option to pick the next valid number of servings (by making sure anything fractional is divisible by 4). The benefits of this would be that it keeps the math much simpler than other approaches to scaling, standardizes all recipes, and does it all behind the scenes so the user won't need to know it's happening. It also allows the user a lot of flexibility in what they can do with their recipes (particularly avoiding the pitfall of scaling recipes that start out fairly large-- if it serves 8 but you need to serve 10, scaling by doubling means you're now cooking 16 servings). It should also be pretty easy to apply to existing recipes since most recipes should already have data on how much the serving makes. The downside is it increases the amount of ingredients data each recipe stores and there may be some mathematical artifacts or edge cases that need to be dealt with. Hopefully some of this is useful. I think the current implementation is most of the way there-- the goal should be reducing the fiddliness of the user experience and make the user feel less like they're having to do math to come up with a scale that gets them what they want. |
@aureateflux I think what you propose makes it more complicated than needed. By “standardizing”, you basically move the moment we do the math earlier. I don’t see how that makes things easier for the user. That said, I think it makes a lot of sense to let the user change the number of servings, instead of let them change the scale. In the background, we can then calculate the scale and scale the ingredients accordingly. The math is still simple: scale = desired servings / recipe servings. You can end up with things like “5/4 onions”, but that’s inevitable, even with your method of “standardizing”. As for the UI, I’d propose a number input, and + and - buttons on the side. The default number of servings should either be the recipe servings or a user-defined default. Note that I’m currently on vacation, and I don’t have my laptop with me. So I won’t be able to work on this for another ~ 3 weeks. |
This PR is stale because it has been open 45 days with no activity. |
This PR allows scaling a recipe down, lower than the original servings from the recipe. Also, it formats non-integer servings as fractions. I think that's more intuitive, especially since all the ingredients use fractions too.
What type of PR is this?
What this PR does / why we need it:
Currently, when scaling recipes, one can only scale up. But there are valid use cases for scaling down; e.g. where a recipe yields 4 servings, and you want only 2. This PR fixes that.
Which issue(s) this PR fixes:
Fixes #3754