Save recipes in different file formats

[geeseven]

trafficstars

I feel that some sort of mobile friendly option is 'a must have'. A dedicated mobile app would be preferable, but I got brainstorming if there are other easy to implement options that could be good enough.

First off, I have to admit that the web interface looks nice within a mobile browser. That being said, personally it is impractical. I want my password database and 2FA codes to be on septate devices. This makes it hard to access recipes on the go without a laptop.

Since the app already uses files as its back end, could there be some ways to access recipes on mobile. Here are some ideas I came up with.

Prettyprint json: Use a more human readable json format. The file extension would also need to get changed to txt to read the recipes within the Nextcloud files app.

Markdown: Add markdown files for each recipe when added or edited. Markdown is fully support within the Nextcloud files app and is easier to read than prettyprint json.

PDF: Like Markdown, a PDF for each recipe could be created. A third party PDF app would be needed. There is already some code written to create PDFs.

@mrzapp, I am curious on what you think of these ideas or if you view them as out of scope.

[Schlaubischlump]

Duplicate #190 and #158

If you use an iPhone / iPad / Mac you can use this application I wrote: Cookbook-Client. There once was an android app in development, but I don't know if this is still the case.

[mrzapp]

@geeseven thank you for suggesting solutions, it's very appreciated. I'd prefer not generating more files, but I don't see anything wrong with pretty printing the JSON.

If you want, you can check it out here and make the output suit your needs. Just make sure the data is still intact and machine readable.

[mcorteel]

Still, I think markdown would be worth thinking about, as I mentionned in #138 about Kookbook integration (Kookbook uses markdown).

Anyway, if we did #138, it would automatically provide this functionnality.

[hitam4450]

I think, we should have a stable and most usable nextcloud app first, before starting the development of a mobile app!

[hitam4450]

Duplicate #190 and #158

If you use an iPhone / iPad / Mac you can use this application I wrote: Cookbook-Client. There once was an android app in development, but I don't know if this is still the case.

I do own am ADROID system, no iOS!

[mrzapp]

@mcorteel alright, it would make sense, then, to export the files both as JSON and markdown, if it even grants Kookbook compatibillity.

[mcorteel]

I'm not saying we should always have both, but it could be some kind of option. What I would suggest is:

• Add a global option to set the default file format (for now MD or JSON) which will be used for recipes created by the nextcloud cookbook app
• Handle recipe files transparently, regardless of format. This way, we can import existing files from other applications and mix JSON and MD files:

To sum up:

• When reading a file, check its format before parsing
• When writing a file, if it exists check format and use this format, if it doesn't exist, create it using the default format.

[mrzapp]

@mcorteel You're right, it could be problematic to have both at the same time. Like, if you edit one of the files, which recipe is the right one? I suppose we could just read from the file with the latest modification date, but my common sense is tingling, and it's telling me that it's a can of worms. Also, it doesn't seem to me like the Kookbook format even maps to schema.org 1:1.

I've got another proposition: We could keep the recipe.json file as the master, and then store other formats in a .compat folder, naming the files after the format they represent, like kookbook.md. Then, in the event that a recipe.json file is missing, but a .compat/kookbook.md file is present, we could generate the recipe.json master file from it, and the app could otherwise function as normal.

How's that?

[sparagi]

I like @mcorteel's suggestion about reading all the [currently supported] formats, but writing the selected default format.

I like this suggestion better than requiring the native format to be schema.org JSON because as @mrzapp points out, recipe formats don't always correspond directly. In particular, I'm pretty interested in Open Recipe Format because it looks like it would help solve problems like recipes that don't scale properly, eaters with food allergies, and consistency across cooks for my use case (essentially an amateur community kitchen). Converting from this format to schema.org's format seems inherently lossy; that's why I'd prefer to store our recipes in ORF.

But, if this were the solution, it would require some significant UI and API design, and also some minimum requirements for adding a new file format.

The minimum requirements for adding the file format would be at least:

• A file parser
• Glue to hook the correct fields to search queries
• A view page (or updates to the existing one, but that gets hard to manage as the number of supported formats goes up)
• An edit form (or updates to the existing one)
• CSS

Design-wise, some challenges I see are:

• Ensuring uniform look & feel when recipe fields are inconsistent across formats
• If a recipe were added in a non-default format, then edited, it seems like the editing user would like to be able to choose which format to save in, but the one they choose could lose information compared to the original, so now one needs to have a way to resolve conversion problems

Some advantages I see, design-wise:

• Easier import of people's potentially massive recipe databases in other formats

[mrzapp]

@sparagi The reason we're using the schema.org format is that it's the most portable, as it is the de facto recipe format on the internet. Unless a superior format suddenly takes over, and everyone abandons schema.org, this will remain unchanged in the cookbook app.

Which exact fields are you missing from the schema.org format? If you're referring to dietary restrictions based on food allergies, the suitableForDiet field is probably what you're looking for (IMO we could allow the field to be plain text, if the RestrictedDiet enumeration doesn't meet the needs)

We can always submit change requests to the schema.org format too, if our needs cannot be met by the current standard.

[sparagi]

Yes, if you're going to support only one format, schema.org is clearly the one to use for compatibility purposes; I was not intending to imply otherwise. The title and some of previous entries in this discussion were about the possibility of saving recipes in multiple different file formats, not just one, so I wanted to provide my use case and support for the idea of storing in multiple formats. To me, "import from additional formats" is a different feature.

Things missing from schema.org's format, that are both present in ORF and cause someone associated with our kitchen extra work on a regular basis:

• USDA reference numbers for ingredients. I want this so I can support medically mandated dietary restrictions, voluntary diets (e.g. Paleo), and dislikes (e.g. turnips). The "suitableForDiet" enumeration from schema.org arguably covers 1 allergy (gluten). It does not cover any other allergy (e.g. peanuts, shellfish, corn), unusual custom math (e.g. specific oxalate targets), or diets that focus on must-eat instead of must-not-eat (e.g. anti-age-related macular degeneration). These are all real examples from people I have cooked for on multiple occasions. In my current database, I use tags for parts of this now, and do the rest in my head. In some cases, I have multiple variants stored as multiple recipes. It is awkward for me, and nigh-impossible for other people to navigate successfully alone.
• Uneven scaling of ingredient amounts, e.g. a 2 lb loaf of bread may not need 2x the amount of yeast or salt in a 1 lb loaf. If you're making spaghetti for 20 vs. spaghetti for 2, you probably don't want 10x the amount of water. Right now we either enter multiple recipes or make notes in the recipe, but some of our cooks tend to plunge in without reading the notes so an actual solution would be better.
• Substitutions. I store these as notes now, but I'd like to store them in a structured way, again so I can construct working meal plans faster.
• Amounts that have units as part of their structure. Our current database (not Cookbook yet) regularly mistakes parts of items as a unit & vice versa, e.g. 9" zucchini. Mostly this causes trouble after meal planning, when preparing a shopping list. I don't think it's possible to parse these automatically from free-form text in all cases, so I'd like to take care of it once per recipe.

Things missing from schema.org's format, that I saw in ORF and want to try:

• HACCP control points, so e.g. I remember to tell people who grew up in the city to wash the lettuce from the garden.
• An extension mechanism for when users with very different needs from the current user base (e.g. me) try to represent their recipes in this format. I half-suspect I missed this one, because it seems such an unlikely omission.

On the plus side, I like the schema.org inclusion of tool and supply on HowTo elements, and I also like HowToSections and the isBasedOn relationship; these things are missing from ORF.

Since storing in multiple formats is out of the question, my use case is off-topic for this feature request & I'll have to figure out where to try next. I'll strongly consider your suggestion of trying to add to schema.org's format as I weigh my options. If you want, I can open separate issues with the feature requests that motivate my desire for a different underlying format. Some of them are probably edge cases of interest only to us, but some might resonate with you or other Cookbook folks, and the proportion might help us both figure out whether our type of use is in-scope for Cookbook.