Community curated editions: "Recipe list" edition

,
#21

Thanks vilc. These are great, and I’ll add them to the next version.

I’m getting hungry!

#22

Yes I love this one. There is a “showcase” thread already. Absolutely worth visiting.

Virtual tiddlers
#23

These are the recipe wikis we’ve found

What features to people like about these? What do we think we want to have in the community edition?

I’ll go first:

  • In Przepisy, I love the simplicity of the markup. I really like the ingredients pages – even if the tiddler doesn’t exist, it gives useful information. I will have to investigate how this is done. I know @springer is a proponent of this style. I also like that as this uses the Notebook theme, it should work well in mobile, although I haven’t yet tested.

  • In Maple: recipes | meal-planning | grocery, I really like the images, but I wish they were tied more to the recipes and not merely to an overview screen. I like having the ingredients side-by-side with the instructions. When cooking with a tablet open, I really hate having to scroll too often, usually with food-covered fingers. So it’s useful to have both visible when the real estate is available. I personally would prefer the ingredients on the left, but that’s minor; and I’m even starting to envision a version where the ingredients appear both in a list and as annotations to the right of the instruction. (I’ll have to think more about this.) I don’t like the bullet used in the ingredients list. To me, it looks as though it should be a clickable link to show more information on the ingredient.

  • In Larry’s Cookbook mostly what I like is the focus on the categories; it shows a good use of tagging.

  • In RickL TW Examples: Chorizo Breakfast Casserole, I like the reporting back of the original source of the recipe. I would prefer this be in a field, though. I’m confused by what might be a shopping list. If we do decide to create one, I would think it should be derivable data, and not hard-coded in the recipe.

  • In cook — some recipes (Tobi Beer’s contribution), I love the simple markup and the multi-section layouts. (Again with the guillemots for a bullet; is it just me that expects something expandable when seeing these?)

  • In Seantaclaus' Recipes - unconventional goodness, I like that it has a shopping list interface, but I don’t really understand how it’s supposed to work or to connect to the recipes. I like the tabbed interface for the categories, but am not sure how far that would comfortably scale. The color scheme hurts my eyes!

  • In Kitchen - You hungry yet?, I mostly like the fond memories of older versions of TW. I didn’t find much else here that inspired me.

  • In Recipe plugin — For storing your recipes I like the fact that this is a plugin. While we might not build our edition with a single plugin for an empty TW, it’s worth considering, even if we don’t do it at first. More likely, I think would be a few plugins, plus other material, but we should look at this. I love the fact that it’s organized into a number of useful fields. I have mixed feelings about the edit UI. I would love to have one, but I would much rather it could be made by configuring the main edit UI for items tagged Recipe. I don’t know if that’s possible, but I suspect that it is.

  • In Carnet De Recettes there’s almost no content, and so little to call out. But it does include the number of servings, preparation time, and cooking time. These would probably be useful to have.

Your turn. What features to like/dislike about any or all of these examples?

(And if you have more examples, please post them, and I will try to keep this list up-to-date.)

2 Likes
#24

Thanks for the big tour! I haven’t yet gone far, but can still offer a thought or two:

One thing to focus in on is how much to make use of fields, how much to have everything just tossed into the text field.

At the maple site, I realized that some recipes were clearly ported over from some other html source. And I could imagine wanting to do that in a hurry, and then to follow up later with cleaning up if I’m interested. So, having a rigid system of view templates that draw on fields (in a way that looks bad or ill-formatted if those fields are empty) would inhibit this kind of casual recipe-dump.

That inclines me toward having fields available for anything that’s simple and important, but hiding (or greying/collapsing) any field in the view template unless/until it has contents. (In the edit interface, such fields ought to be arranged so as to be conveniently at hand. Maybe the user can select which fields matter. Some care about calories or dietary restrictions, some don’t…)

At that site, I also noticed how — in cases where the recipe had been entered by hand, like this marinated skewers recipe — css-classes were used to allow float-right boxes for ingredients.

And this particular recipe convinces me that something like “ingredients” should not be a single field. Not only because it would need to be multi-line (we can do that) but because some recipes have this compound structure, where you assemble elements for one part early in the process, and later pull together another part. Even if there is a single ingredients field, this particular recipe calls for some way to have a section for the marinade, and another section for the skewers, each with their own ingredients. The css-class display struck me as a good solution.

And of course nothing about that would inhibit combining with the Przepisy strategy of entering ingredients (and maybe other keywords) as links (even if missing), and enabling those links to serve as useful information nodes.

Question: is there a manageable way to search for a string within a css-class span? The only thing in favor of having an ingredients field is the ease of a field-specific search, but perhaps there’s a way to look for “baking” only between a @@.use string and the next @@. (I use that example because a million recipes might mention baking somewhere in the text field, but perhaps I need to filter for what does or doesn’t use baking powder, or whatever, as an ingredient.)

#25

It’s based on two conventions:

  • ingredients are linked to in the ingredients list, e.g. 1 cup of [[flour]]
  • all ingredients and only ingredients start with lowercase letter, so it’s possible to filter for ingredients with regex ^[a-z]

Combination of these two allows to make a view template that displays backlinks on missing ingredient tiddlers. Since the recipes have their own tag Recipe, it would be possible to check that these backlinks are only recipes.
Differentiating ingredients by name only (even if missing) would allow to construct a search step (for TW search or for Command Palette) that searches through ingredients only, so e.g. first search step displays recipes, the second displays ingredients.

I have modified the theme and Command Palette search a little bit, to get a decent search UI on a phone. Details and alternative approaches (using JD’s Mobile Layout or Thomas Elmiger’s Simple Seach) are discussed here: Mobile layout with easy-to-use search, alternatives to JD Mobile Layout.

I usually edit on PC and view on a phone when cooking or shopping. For a vertical phone screen, the simple recipe layout works well without any adjustments. I agree with your comment on Maple, on tablet screen it would be nice to have the screen space used efficiently.

With my way of linking to ingredients and having ingredients identified by first lowercase letter, it is possible to search links from a recipe and filter those that are ingredients. This does not strictly mean ingredients placed in the ingredients section, it could be an ingredient linked from the preparation section, but this shouldn’t be a problem.

Looking at my own thing from a perspective, I see that I have optimized the markup rules, so that I need as little “behind the scenes” code as possible, so that I can create and maintain it myself with little effort.

This is a quite opposite approach to the Recipes Plugin, which makes a lot behind the scenes, presents a custom UI for creating/editing/searching recipes. Advantage: little knowledge of the plugin and understanding of TW required to use. Disadvantage: limits freedom of having unstructured data (as pointed by @Springer).

I think we will have to balance between these two approaches in the Community Editions. That is, the more educative approach “see easy it was to do in TW (but you have to learn a few things how it works)” and more out-of-the-box approach “see this great, super simple to use web app for recipes made in TW (but don’t look inside, you wouldn’t understand)”.

#26

I think this balance is going to be fairly difficult to get right, given the competing goals of these community editions: creating useful out-of-the-box tools that help show users the power and flexibility of TW, and creating pedagogically sound wikis that teach users useful practices in extending TW to suit their own needs.

I would prefer to err on the side of the former. I think of this mostly as a showcase of useful things you can do with TiddlyWiki and less as user training. But I don’t want to lose sight of simplicity in doing so.

#27

I wonder if we can visually de-emphasize missing fields but offer quick in-place edits for them. A user clicks the edit icon next to the greyed-out calories fields and gets the choice of

  • Set calories ___________
  • Hide “calories” for this recipe
  • Hide “calories” for all recipes

I’m hoping we can build some standard templates that will let us apply such CSS across shared markup.

I like the idea of allowing users to enters markup copied from elsewhere and progressively enhance it to match our format as they desire. But I would hope we can get a compelling enough format that most users would choose to get there.

#28

@Scott_Sauyet there is no new input in this topic. Looking at the collection of existing recipe wikis, maybe we should put together a concise list of “features” (not their exact technical implementation) that we expect of our community edition, starting with the crucial ones and ending with nice-to-haves. We could then have more focused discussion on how to implement them and start drafting the edition.

#29

Yes, I was planning on doing this last weekend, but got busy.

I will try to take a swing at a first draft in the next few days. But if you want to do that, feel free!

1 Like
#30

Long thread, didn’t read it, so may be repeating some other suggestions.
I think auto recognizing ingredients and quantities will be great. E.g. if a recipe has ‘2 cups of sugar’, it’s easy to parse to ‘2’ units, of ‘cup’ for the ingredient ‘sugar’, format these into macros that save into fields and thus make the recipe a DB entry. This doesn’t need to be perfect, just some simple parsing rules so that when I enter the text I know how to format it so the rules will apply.

Then nice things that can be done with these:

  • automatic conversion of measurements (cups, spoons, etc.) to weights.
  • allowing to increase/decrease the product (e.g. from 4 servings to 6).
  • list of ingredients across recipes
#31

@Ittayd this all sounds good in theory, but such attempts often turn out not to be worth the effort for an average recipe list wiki user. There were some threads already dedicated just to this problem structured ingredient data, e.g. Suggestion needed - Writing Recipes - Discussion - Talk TW (tiddlywiki.org)

Not saying it’s not worth it, but that it should be well thought through so that it is not too stiff, easy to understand for new users, and easy to omit if not wanted.

A rough vision of how it could be:

<$ingredients>
!! Pizza dough
3, cups, [[flour]], type 000
1, cup, [[water]]

!! Sauce and topping
300, ml, [[tomato sauce]]
100, g, [[mozarella|cheese]]
</$ingredients>

Ingredients widget which contains the ingredients. Lines starting with ! are interpreted as headings. Other lines are interpreted as amount, unit, link to ingredient, comment.
The widget could have alternative mode=“wikitext” where the contents are interpreted as normal wikitext and its only function is to wrap the ingredients so they can be styled, e.g. displayed on the side for large screens.

Having this in a widget has the disadvantage of more difficult access to the information from outside the tiddler, but it does not clutter the UI as a separate field would.

This is just a rough idea that I haven’t seen before (but I have seen many other approaches). As you can see, this problem requires a lot of thinking in order not to make it too complicated for an average user looking for a simple way to store recipes. In any case, it should not be the first and most important thing to implement.

#32

I love it and hate it all at once! I like being able to simply edit the ingredients without a lot of ceremony, and the one ingredient per line simplifies entering and parsing.

But I really don’t like the commas, or the fact that we are still insisting on a rigidity that makes it harder to enter common ingredient elements. Is it 3, , beaten [[eggs]], or 3, [[eggs]], beaten, or 3, , [[beaten eggs]], or something else?

I wonder if we could use some version of this as the storage format, generated by a simple UI, but directly editable by power users. (I’m typing this as I think it, so it may not even be coherent.) Then the custom ingredients widget could display this with reasonable HTML and with overridable CSS that allows the user to do significant styling. That should allow a useful custom search

I’m imagining something that parses these lines, entered directly by the user:

300 ml [[tomato sauce]]
2 beaten [[eggs]]
4 cups plus 3 tbs [[bread flour|flour]]
1 large [[onion]], coarsely chopped

(and don’t ask what single recipe would have those particular ingredients! :smiley:) into an internal format like this:

<$ingredients>
{# 300 } {% ml } {@ tomato sauce }
{# 2 } {? beaten}  {@ eggs }
{# 4 } {% cups } plus {# 3 } {% tbs } {@ bread flour}
{#1 } {! large } [[onion]], {? coarsely chopped } 
</$ingredients>

(note)1 which would then render HTML like this:

<li>
  <amount><quantity>3</quantity> <unit>ml</unit> </amount>
  <a class="..." href="#tomato%20sauce">tomato sauce</a>
</li>
<li>
  <amount><quantity>2</quantity></amount> 
  <prep>beaten</prep>
  <a class="..." href="#eggs">eggs</a>
</li>
<li>
  <amount><quantity>4</quantity> <unit>cups</unit></amount>
  plus 
  <amount><quantity>3</quantity> <unit>tbs</unit></amount>
  <a class="..." href="#flour">bread flour</a>
</li>
<li>
  <amount><quantity>1</quantity> <desc>large</desc></amount>,
  <a class="..." href="#onion">onion</onion>
  <prep>coarsely chopped</prep>
</li>

(or we could use <span>s with classes instead of custom elements.) These elements would allow us to later work out things like shopping lists, or unit conversion.

The idea would be a simple line-by-line recipe entering UI, with visibility to what’s generated, and the ability to change the generated version as needed, with the ingredients stored in text. For easier searchability, I might also generate a single ingredients field that changes as this list is changed, but not trying to store anything but [[tomato sauce]] eggs flour onion. (No one is likely to search, “What was that recipe that had 300 ml of something?” or “What recipes will allow me to chop an ingredient?”!)

1 If that markup would give TW fits, we could put it all in a single string like this:

<$ingredients list="""
{# 300 } {% ml } {@ tomato sauce }
{# 2 } {? beaten}  {@ eggs }
{# 4 } {% cups } plus {# 3 } {% tbs } {@ bread flour}
{#1 } {! large } [[onion]], {? coarsely chopped } 
""" />
#33

My feelings exactly about this whole idea. Is seems co clever and useful, but actually implementing it seems to be a lot more complicated than the whole rest of this edition. And the reality is, a recipe wiki can work absolutely good without it.