Skip to content
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

Closed
wants to merge 4 commits into from

Conversation

bartkummel
Copy link
Contributor

@bartkummel bartkummel commented Jun 19, 2024

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?

  • feature

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

@bartkummel bartkummel changed the title Allow to scale down below original recipe feat: Allow to scale down below original recipe Jun 19, 2024
@Kuchenpirat
Copy link
Collaborator

I know this is not done yet, but I'll go with some early feedback.
First, thanks for putting in the work and trying to improve the scaler. It is, in its current form, a long way from perfect, and I feel your PR is already an improvement over the current behavior.

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.

@Kuchenpirat
Copy link
Collaborator

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)
Also in the same state an ingredient that has 1 liter originally looses its Quantity completly.

@bartkummel
Copy link
Contributor Author

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.

I'm not sure if I agree. I'm coming from Paprika, and this is how they do it:
IMG_6F448FF463FE-1
It sure is more flexible. But it's also more complicated. I really like the simplicity of just pushing + and .

Also while playing around with it i found a bug in the current implementation.
Thanks! I know there is also still a layout bug, where then new implementation makes the box around the scale too tall. I'll work on the PR a bit more before making it final.

@Kuchenpirat
Copy link
Collaborator

Kuchenpirat commented Jun 20, 2024

yeah, that looks a bit overly complicated for my taste. My idea is:

  • clicking plus: increment by one
  • clicking minus: decrement by one
  • clicking on the servings: allows you to enter custom amount including non integer values

@bartkummel
Copy link
Contributor Author

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 + button would add 1 to the yield, it would go to 51 gram. That's quite useless. It makes much more sense to use a factor, exactly what the scale is. Of course you can argue about the granularity, i.o.w. the step size. You need a balance, I guess: a big step size doesn't give enough flexibility, a small step size makes you click the + or - button too often.

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 / halving

I think this is the most intuitive, given the limitation of only + and buttons.

Scale "4 portions" "50 gram"
"½ portions" "6¼ gram"
¼ "1 portions" "12½ gram"
½ "2 portions" "25 gram"
1 "4 portions" "50 gram"
2 "8 portions" "100 gram"
3 "12 portions" "150 gram"
4 "16 portions" "200 gram"

Step size ½ above 1, ¼ below 1

Increasing 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:

Scale "4 portions" "50 gram"
1/10 "2/5 portions" "5 gram"
1/5 "4/5 portions" "10 gram"
3/10 "1 1/5 portions" "15 gram"
2/5 "1 3/5 portions" "20 gram"
½ "2 portions" "25 gram"
3/5 " 2 2/5 portions "30 gram"
7/10 "2 4/5 portions" "35 gram"
4/5 "3 1/5 portions" "40 gram"
9/10 "3 3/5 portions" "45 gram"
1 "4 portions" "50 gram"
"6 portions" "75 gram"
2 "8 portions" "100 gram"
"10 portions" "125 gram"
3 "12 portions" "150 gram"
3 ½ "14 portions" "175 gram"
4 "16 portions" "200 gram"

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

Scale "4 portions" "50 gram"
"½ portions" "6¼ gram"
¼ "1 portions" "12½ gram"
½ "2 portions" "25 gram"
¾ "3 portions" "37½ gram"
1 "4 portions" "50 gram"
"6 portions" "75 gram"
2 "8 portions" "100 gram"
"10 portions" "125 gram"
3 "12 portions" "150 gram"
3 ½ "14 portions" "175 gram"
4 "16 portions" "200 gram"

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:

  1. Doubling / halving: the most intuitive for the user, the easiest to implement. We still have the manual edit as a backup for cases where we need more flexibility.
  2. Compromise: as the name suggests, this is a compromise. If people insist, I can implement this as a second best option.
  3. Step size ½ above 1, ¼ below 1: this is both unintuitive and quite useless. I wouldn't recommend it.

@Kuchenpirat
Copy link
Collaborator

Kuchenpirat commented Jun 20, 2024

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 + button to get to the serving size for 3 people and the - to get to the serving size of 1. I know this is not currently how the code works (increasing serving by one is currently doubling the amount)

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

@bartkummel
Copy link
Contributor Author

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.

Proposal

Here's my proposal:

  • The issue I want to solve is that it's currently not possible to scale down below the serving size of the recipe with the button.
  • My PR fixes that (once it's finished), adhering as much as possible to the current implementation.
  • Let's defer the discussion of the step size for scaling up to a later moment, since this goes beyond the scope of my original request and PR.

@bartkummel bartkummel marked this pull request as ready for review June 21, 2024 11:52
@aureateflux
Copy link

aureateflux commented Jul 17, 2024

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:
When creating a recipe, Mealie could standardize what one iteration of the recipe is (makes 1 serving). Then it's just math in the background to adjust from there, and the math stays fairly simple, too. It may already do this in a way, except I think Mealie currently scales up and down from the number of servings the recipe says it makes, rather than finding a baseline first. Finding a baseline should make it easier to present the user the option of just entering the number of servings they want to make.

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.

@bartkummel
Copy link
Contributor Author

@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.

@hay-kot hay-kot marked this pull request as draft July 25, 2024 19:53
Copy link
Contributor

github-actions bot commented Sep 9, 2024

This PR is stale because it has been open 45 days with no activity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants