Community curated editions: "Recipe list" edition

,
#6

Regular basis. You’re at your computer, and regular viewing is fine. But when you have your phone set up on the kitchen counter, you (or at least me) want the ingredients filling up the entire screen so you (me) don’t have to lean over and touch the screen with your nose to see what’s next.

So some quick way to expand the font to make the text as viewable as possible for the current platform. On a phone, you can’t just zoom in or out, because the text will zoom off the screen. And given that your hands will be sticky with cooking stuff, you want to minimise contact with the device.

2 Likes
#7

Then I guess you’re right, and we mostly agree here. I thought you were saying something very different.

My objections have to do with the very nature of fields, and not their level of maturity in TW. Because there are an indeterminate number of potential ingredients, to use separate fields individually for them means we must either mark their names as ingredient names (most easily by prefixing or suffixing them, although there are alternatives) or we must maintain a list blacklist of fieldnames that should not be considered ingredients. The latter feels fragile; the former, burdensome.

I curious to see it, but I do feel like this is a fundamental fact of fields, so I’m doubtful. :man_shrugging:

I would hope we could manage most of that with responsive web design, but yes we would want to be able to trigger certain views on demand.

But I like the image of touching the screen with one’s nose to interact, sort of a recipe scratch-and-sniff!

#8

I would prioritize three general features, in this order:

  1. Pleasant, easy-to-read, easy-to-follow display of individual recipes

  2. Powerful recipe-oriented/cooking-oriented searching

  3. Simple and obvious creation of recipe tiddlers

While they are all important, #3 is well below #1 and #2. A user will presumably search for or read a recipe far more often than creating one. I would expect our development path to similarly focus first on those top two: figuring out tiddler structure, title conventions, field usage, and such necessary to support easily finding and displaying recipes in a useful manner. Only once we have a fairly good handle on that would we spend the effort on determining the best way to simplify recipe creation.

I know that these suggestions are overly broad. But I think that’s we should figure out a plan at this level first, before we dig too far into specific details we want.

2 Likes
#9

Well, I meant more in terms of how close you had to get to view the text. Never tested the nose as a part of a touch interface. Think it might be a bit inaccurate.

#10

Here are some ideas that I use in my recipe list. The content is in Polish, but the TW and most of the backstage is in English. It is a constant work in progress, so it’s a mix of old and new ideas on how to organize it.

I use a simple recipe structure with (transcluded) headings for ingredients, preparation, and sometimes I add links or comments section. The links section where I sometimes paste one or two links could be just as well solved by the source field discussed above.

I have a “add recipe” button, which creates a tiddler tagged “recipe” (“Przepis”), with the headers filled in.

All recipes (tagged with “Przepis”) are rendered with hard line breaks. This allows to easily split the preparation into new lines.

I input all ingredients as links, e.g. 1 cup of [[flour]]. I hope this will allow me to get to all recipes using a given ingredient, although I haven’t made any UI for it.
I have a rule that all ingredient titles start with a lowercase letters. This lets me easily filter for ingredients (e.g. in Auto Complete) even if they are missing tiddlers (as they are in most cases).
Having ingredients as tiddlers linked from the recipe lets me attach some notes to the ingredient itself, e.g. converting between g and cups for flour, or instructions on how to peel a pomegranate.

I used to keep the approximate preparation time in minutes in a dedicated field (czas). This didn’t turn up very practical. Even though it was supposed to be approximated, I usually wasn’t motivated enough to input even that. It also didn’t offer much help for dishes that require a lot of time to be ready, but not a lot of work (because they need to be cooked for a long time without much intervention). So I recently switched to an easier system with tags. I have two groups of tags to rate the preparation time and effort on a 3-point scale (e.g. “Time 3/3” and “Effort 1/3” for something that needs to be cooked a long time).

I use tags for the dish type, e.g. main course, soup, dessert. The tags themselves are tagged “Dish”.
I use tags for the origin cuisine, sometimes specific country like “Italian”, sometimes general region like Mediterranean. The regions are tagged with “Region”, and then countries are tagged with their respective region. Again, I haven’t come up with any UI to browse/filter by these.

I’m considering to tag the recipes with main/highlight ingredients.

Right now I have a “Home” tiddler that lists all recipes and their tags. It was enough so far, but it’s getting cumbersome the more recipes I add. I’m planning to create a UI where I could check some of the “structured” tags like Main course, Time 1/3, pasta (lowercase as in ingredient, not dish type), and immediately see the list of results. I don’t think it’s worth the effort with my current number of recipes, but I would gladly work on it if it should prove useful for the community as well.

5 Likes
#11

(moving this discussion to the appropriate thread.)

Yes, and I’m looking to find a balance for that. It doesn’t seem an easy balance to strike.

#12

That’s very nice. It’s like 85% of the way to a Recipe edition. Making the ingredients into links is a good thought. Having icons with the tags makes it feel professional.

It just needs a search at the top to filter by ingredients, type, etc. to limit the list. And maybe some tools to help set up new recipes. And a bit of documentation for those new to TW.

1 Like
#13

This is very clean and well-organized, @vilc!

You could do this with a ViewTemplate, e.g. (in a 5.3.2+ wiki)

<% if [<currentTiddler>!is[system]backlinks[]] %>
''Used in...''
<<list-links "[<currentTiddler>!is[system]backlinks[]]">>
<% endif %>

If tagged with $:/tags/ViewTemplate, this will display a list of recipes linking to an ingredient on that ingredient’s tiddler, whether or not it actually exists. (This filter doesn’t differentiate potential ingredients from any other tiddler with backlinks, of course, so you may need to refine it a bit, depending on how else you’re using links in your wiki.)

2 Likes
#14

Here’s another elegant example of a recipe list in the wild: Maple, by qrest on Tiddlyhost. I especially like the drag-and-drop meal planner—find it via the Apps tab in the sidebar.

3 Likes
#15

Agreed. That’s beautiful!

I was hoping this weekend to look for as many examples as I can find.

1 Like
#16

Thanks!

Filtering for ingredients is easy in my wiki, even if they’re missing, since I have the convention that ingredients and only ingredients start with lowercase letter1. So after adding that condition to filters in your example it works very well, see here.

1 This trick will not be useful or look bad in languages that capitalize nouns, like German (are there any other such languages?).

Edit: With some clever changes to the ViewTemplate and $link widget though, I imagine it could be possible to have the (for the most part missing) ingredient tiddlers start with lowercase, but display with uppercase. Quite a bit of a workaround, but it would only be needed for German (could be a plugin), and I don’t see any better way of discerning ingredients from other tiddlers by title only (since they will be usually missing). Any prefixes or suffixes or other character sequences would require more effort when typing links in ingredient list.

1 Like
#17

Sorry, off on other things the last two weeks. But I’m back, and I have

A list of some recipe wikis:

I was expecting to find more. They’re probably out there. If you have other examples, please share.

In a few days, I’ll present the most complete list we can find and kick off a discussion about what we like best from our examples, and about what we’d like to do differently.

2 Likes
#18

Slightly off topic but related A TW about Pasta Shapes

1 Like
#19

I have found this Recipe plugin to add to your list.

I vaguely recall seeing a cookbook wiki in German somewhere on the forum, but I believe it was in a discussion about solving a certain problem in it, not a showcase topic.

Edit: I have found one more example – Carnet De Recettes.

1 Like
#20

Off-topic perhaps, but fascinating! Who knew there were quite that many variants?!

#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)”.