mealie-recipes / mealie

Mealie is a self hosted recipe manager and meal planner with a RestAPI backend and a reactive frontend application built in Vue for a pleasant user experience for the whole family. Easily add recipes into your database by providing the url and mealie will automatically import the relevant data or add a family recipe with the UI editor
https://docs.mealie.io
GNU Affero General Public License v3.0
5.59k stars 608 forks source link

feat: Allow to scale down below original recipe #3755

Open bartkummel opened 1 week ago

bartkummel commented 1 week ago

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

Kuchenpirat commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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

bartkummel commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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: