Plan to Eat Mobile — Recipe Category Form

The Problem

A common customer complaint with the recipe form related to how recipes were categorized. Courses, cuisines, main ingredients, and tags were all available as categorization options, but it was often the case that a customer wanted to add a category to a recipe that did not yet exist, or else modify a category’s name while they were working on the recipe.

This feedback was confusing at first, because adding a category and immediately applying it to a recipe was a feature that had been available in the web app for years. But it turned out that the company had never ported the feature to the mobile app—instead, users were presented with simple <select> tags in the recipe form, and had to go to a completely different place in the app to change the categories they were presented with.

The Solution

My solution was to give users access to the same form while they were working on a recipe. An attempt to modify the courses, cuisines, main ingredients, or tags of a recipe would open this form, where all of the CRUD actions (create, read, update, and delete) were available to the user. Adding radio or checkboxes to the mix allowed them to select the categories they wanted for the recipe.

Challenges

One of the key challenges was to consider all of the possible actions the user might take when two unsaved forms were open on the Cook tab, and how the category form might behave differently in this situation than if the user went to modify the categories directly.

For example, we warn users about unsaved changes if they tap the back button or one of the tabs at the bottom of the screen. If the category form is accessed from within a recipe and the user made any changes at all, I chose to require the user to tap “Save,” because there are so many possible ways to interact with the form. The user might add a tag without checking its box, even though they meant to check it to assign the tag to the recipe. Since a recipe can have many tags, I decided against automatically checking them when they are added or modified.

This is different from how the form works when it is not accessed from a recipe. In that instance, there are no checkboxes for assigning the categories, so it made more sense to immediately save the user’s changes if they added a new category.

Technologies Used

  • React

  • Redux

  • Custom synchronization behavior through a Redux store listener

  • SASS

Plan to Eat for iOS

Plan to Eat for Android