Feature request: removing ingredients from recipe confirmation (or undo)

[opicron]

What's the feature 🧐

I noticed this has been spoken about a lot. I'd like to open the discussion if I may.

When adding of editing a recipe it seems very easy to remove a ingredient by accident.

To avoid saving I notice myself tapping the < button and not saving the recipe. And then edit the recipe again to avoid re-adding the removed ingredient. Which is removed so easily that I mostly miss which ingredient (and sub quantities) I removed in the first place.

In my experience it would be very helpfull to either confirm removal of an ingredient in an recipe.

An recipe is usally fixed, there will not be a lot of need to remove ingredients.

The current user experience benefits easy removal. While I believe removal shoud be somewhat 'protected'. Considering the nature of a recipe.

Extra information and references

I have tried understading the current UX. Im having issues seeing the benefit. Sorry ;).

[opicron]

To add to this point after a night sleep. In the settings we can select how ingredients are removed. Either by click or by confirmation. It would be nice to see this propagated into the recipes edit functionality.

Also I thought, maybe it is a good idea when removing (accidently) ingredients from an recipe to make them unselected as it where. So we can 'undo' the removal by reselecting them.

This last idea is not fleshed out, is it a good functionality to save unselected ingredients? For future additions to the recipe for example. It gives a lot more functionality. The only question will then be, how to actually delete the ingredient.

[TomBursch]

You're right that it's probably a bit too easy to remove ingredients. And I think the same could apply to meals in the recipe planner. From a UX perspective, it felt weird to have the same button react different in recipes and shopping lists (Although you're right, it currently differs anyway when using the confirmation behavior from the settings).

To add to this, would an undo/redo button be enough to solve this for you?

So now we have the following possible solutions:

• Honor the shopping list interaction settings while editing recipes and use the same removal system from the shopping list
• Add Undo/Redo
• Ask for confirmation when deleting an item
• Gray the ingredients out and only remove them once the recipe has been saved (I feel like communicating to a user what is happening will be difficult for this)

I'm not sure what I prefer.

[opicron]

Im right there with you. Not sure which flow would work best.

The consistent choice would be using the configuration setting. However, Im afraid some users might not dig deep for the setting and get demoralized by the default flow in editting ingredients.

Ive read that you would like to avoid multiple actions on the three dots (or holding the icon on phone). Actually I do see a use for a delete there, along with a change icon for example.

If no multiple actions are possible on the ingredients, I would prefer a confirm action on click of the ingredient. Regardless of settings.

Though call to make.

PS: transaction ref 9F334927PM0487602

[opicron]

I confirm this is working perfectly! Thank you very much. For now this is the best solution.

I keep wondering though. In terms of UI and Usability, what is the usecase most used during editting of an recipe and its ingredients? Deletion or editing the details of a ingredient? Recipes are refined over time by adding details to ingredients I asume. Deletions take place only when adding an recipe initially, while refinements would take place for years after an main ingredient is added.

If this applies, wouldnt a single click better lead to editing the details of a ingredients? And a long click, or right click, lead to the option of removing the ingredient?

IMHO, the benefit of looking at it this way is:

• less unintented deletions, less usage of undo
• more intuitive way of refining ingredient descriptions
• less time, click instead of longpress, to edit description
• most efficient ui/usability based on the most used usecase

Looking forward to your thoughts.