I’m working on a pantry app. I want to use recipes compatible with Umai, but connected with a record of what ingredients are in the house. I have a more or less functional version that I’ve started using in my home. It’s rough around the edges and I keep thinking of new functionality that would improve its usability. But that’s a key part of why I’ve built it the way I have - the idea of enabling user control over both their data and the interfaces used to interact with it.
Rather than simply sharing my current version, I’m experimenting with writing a blog series that will break the app down and built it back up, step by step.
Three parts of the series are already published, covering showing an Umai-compatible recipe, browsing recipes and other resources in both the app and a data browser with dynamically registered panes, and connecting a pantry collection of groceries with recipes in which they are used.
I’d welcome any discussion related to making food-related apps interoperable, broader issues around interoperability that the blog series might raise, any thoughts about pantry app functionality - and anything else that might come to mind!
It’s great to see this, I love that we’re getting more apps working on the same data :D.
Regarding the duplication of ingredients/supplies; at first I wasn’t too convinced, but looking at my own recipes I agree that sometimes ingredients listed in a recipe are not enough to discern whether you can make a recipe or not. For example, in many recipes I have some ingredient as just “vegetables”, and I may use different vegetables every time I cook the recipe. So it would be very difficult to map vegetables to all the actual vegetables in the pantry. And sometimes, a particular vegetable may not be suitable to a given recipe.
Given this situation, I really like the UX of your app :D. I think it’s a good approach to show supplies in that way, and take advantage of the auto-complete to link them to the pantry. I could also see a way to auto-generate supplies for a recipe in the UI using some text parsing to have an initial version, and people can then amend whatever wasn’t parsed correctly.
Maybe the only improvement I’d suggest is to separate the “supply-driven” recipe from the recipe itself. Meaning, I may want to do a recipe multiple times, but each time I make it I use different ingredients. You could think about it as the recipe being a class definition, and the rendition with the supplies as an instance (I actually have something similar to this in Umai’s “kitchen” and I distinguish them by calling them “recipe” and “dish” respectively). Though honestly, you can just edit the supplies next time you make the recipe again. I’m just thinking out loud, food for thought .
Finally, I have some comments about interoperability that I just wrote in GitHub, in case we want to get more technical. But TLDR, even though it would be very difficult to get the Pantry data model interoperating with Umai, I think it’s great that different applications cover different use-cases. And the recipes themselves are interoperable, so that’s awesome :D. This would only be a problem if I were to implement a Pantry in Umai, or one of my other apps, but I don’t have any plans to do it at the moment so it’s nice to see other people covering different use-cases. It’s a perfect example of the power of Solid!
Thanks! I agree that the linking with ingredients could be further streamlined.
In a future part of the blog series I’ll actually be talking about the idea of specifying a “context” for the pantry that allows switching out different supply definitions, pantry product list, cookbooks and shopping lists. That might come close to separating the “supply-driven” recipe, though the focus is still on expressing the ingredients using a user-defined vocabulary rather than on describing a specific occurrence of making the recipe. For the latter, it might be interesting to think about how the Umai kitchen “dishes” might be persisted and shared between users? The BBC food ontology might be interesting in the way it uses a menu to combine multiple recipes ( Food Ontology )
I think any obstacle to interoperability is worth exploring - at the very least to identify how app requirements should be documented to enable cooperative interoperability, and perhaps even to identify practices that enable or prevent “interoperable serendipity”
They are already persisted to local storage, but I don’t think there is any value in sharing them because at this point the only thing they have different from the recipe is the number of servings (to recalculate ingredient quantities), and a checklist of whether an ingredient is ready or not. I don’t think any of this is useful beyond assisting during cooking, so it’s fine that this information is trapped on a single device.
I guess the ingredients checklist could be useful whilst shopping, but since you’re already doing that in the pantry app with the exact supplies, you’ve got it covered :D.
.