Discussion on how to coordinate our efforts: Community curated editions - How best to coordinate our efforts?
What are the best features to have for a starter “recipe list” edition? What is needed?
Let’s share our experiences and solutions. And also ideas that don’t yet have a solution.
Let’s remember that the edition we want to create must be rather simple and must not be too rigid (customization must still be encouraged)
I have not built a recipies solution before but for me the ability to search for recipies according to some main ingredients you have on hand is a key value.
Some other ideas
Extended features
I can help on the technical side.
I do think it would be worth planning different releases so you can push somethings to later versions whilst keeping them in mind.
As someone who has tried his hand at creating a recipe TW, I would say keep it simple.
If you break ingredients into quantities, you quickly turn recipe curation into key-punch drudgery. Also, the units that recipes come in are so diverse, and the conversions between them so esoteric, that it’s better to just leave it to when you need the recipe.
Connecting the recipe to existing inventory would be exhausting. And if there’s more than one “chef”, virtually impossible.
So what sort of things would be easy and useful? Attractive premade categories (tags) with icons representing dessert, soups, main course, etc.
The ability to change the font size of ingredients and instructions. Ability to step through instructions with just one step showing at a time.
Ability to use tiddlyclip (or clipboard) to snip and clean up an online recipe, storing the url. Ability to comment on recipe and maybe save history of when used.
Moreover, I would say that anything more complex should be added individually to our current working wiki. We don’t need to plan too far ahead.
For instance, if we have a “source” field (which would make sense to me) it should start as a simple text field. It might hold “The Enchanted Broccoli Forest” or “Molly Katzen’s The Enchanted Broccoli Forest” or “from Grandma”. If we want to normalize cookbook references and possibly import a bibtex tool for them, we do it later.
Again I would expect to start with a simple list of ingredients, each one holding something like “3/4 cups sugar” or ”1 liter vegetable broth". I imagine we could write something at the appropriate time that parsed those into three fields.
Normalizing and converting units would be important for public recipe sites, but for a personal recipe list, that’s likely overkill. If we decide we want it, it comes later. Let’s not get bogged down on it at first.
I would expect that parsing would turn out to be crucial (so we can answer questions such as, “which recipes use cauliflower?”) and normalizing quantities an extra we might never get to. But rather than making those decisions up-front, I think we should defer then at first.
Agreed.
Yes, with instructions on how to add your own categories.
The categories would probably not represent a rigid hierarchy. My “Wintergreen Kisses” recipe would be tagged “Dessert” and “Cookie” and either “Christmas” or “Christmas Cookie”. And some "Pie"s would fall under “Desserts” while others go under “Main Course”.
As a one-time wiki setup or on a regular basis?
I hadn’t thought of that. But you’re right. It would be very useful.
That really brings forth the question of whether a recipe might have a collection of small tiddlers for the steps.
Agreed on all counts.
Yes, for sure.
That seems reasonable. But there are complexities we might not want to deal with, certainly not at first.
If we have one recipe that asks for “2 cups grated cheddar”, a second that asks for “250 grams of cheddar, grated”, and a third that asks for “1 1/2 packed cups grated cheddar”, I should probably be able to see those quantities and do my own combination (“Two blocks of cheddar, maybe three to be safe”) but I don’t think the wiki should even attempt that.
I might want to easily add ingredients to that list. If I haven’t written a recipe for my squash dish because… well, I know it by heart or I usually wing it, then I should still be able to add it to the list.
I personally find using field names like this problematic. I think there are too many edge cases to consider. I would rather have structured strings, probably JSON, for an ingredients field, or extract the ingredients as necessary from some structured part of the text. But I need to do more thinking on this
I agree with Mark that we probably don’t want to go down this rabbit-hole, at least not at first
Absolutely.
Yes, but it’s not clear if this is via transclusion or linking. It also demonstrates some of the issues with units. If the white sauce recipe makes one cup, and or recipe takes 1 1/2 cups of it, an automated version might well tell us to buy 1 1/2 eggs!
Definitely a later item.
Yes. Again, “which of my recipes use cauliflower?”
Here I mostly disagree. We shouldn’t be overly stupid about making it more difficult to achieve long-term goals. But I think we should be more nimble, working mostly on our current goals and refactoring if previous decisions make current work too difficult. In other words, I subscribe to YAGNI.
I’m hoping these go through a simple lifecycle: a lot of up-front work to get them as desired, followed by only two sorts of changes, bug fixes and upgrades to newer TW versions. The latter could involve more than simply avoiding backwards incompatibility. They should also try to use relevant new features. Thus 5.2.x → 5.3.0 would have probably included replacing macros with their modern equivalents. But we should need wary of treating them as demos for the recent TW. That’s only a nice secondary feature. First and foremost, they show one solid way to build your own TW for handling recipes.
Well perhaps you need not disagree.
I am suggesting if you have a nice to have feature you put it in the futures list as a possible, not implement it yet, that seems like your YAGNI. When implementing a must have, rather than ignore possible futures, just be aware of them. It is an advantage with a community collaboration, because all ideas can be collected but put aside until a suitable time. You don’t need to so much as accept and reject peoples ideas (and start a debate), but defer them to a possible date in the future, or maybe not implement them at all, in the long run, perhaps because they get superseded anyway.
Agreed, The versioning I am referring to is the recipes component only, although it may have a dependency on a tiddlywiki version, my interest is if I look at my current recipes solution, has a later version become available? and what is the difference. ie a simple version release log. I often include a releases and/or designer-notes tiddler in my solutions for this very reason.
I also like to maintain a manifest, for solutions that use multiple components, like plugin list or settings used etc… it helps us communicate changes and components.
the simplest way is to list all ingredients and let the shopper do this, ideally at least group them, eg;
Hm I need 3 1/2 eggs, I may buy half a dozen, or I have 4 in the fridge.
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.
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. 
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!
I would prioritize three general features, in this order:
Pleasant, easy-to-read, easy-to-follow display of individual recipes
Powerful recipe-oriented/cooking-oriented searching
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.
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.
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.
(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.
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.
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.)
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.
Agreed. That’s beautiful!
I was hoping this weekend to look for as many examples as I can find.
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.
Sorry, off on other things the last two weeks. But I’m back, and I have
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.
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.
Off-topic perhaps, but fascinating! Who knew there were quite that many variants?!