2018-08-05 Recipe Wiki

I was thinking this Recipe Wiki, again.

How do we want to proceed?

As a general principle, I think we need to focus on “stories” – or “use cases” if you want. If we can talk about the kinds of things to do on the site, then people writing the code (like me) can then use the tools at their disposal, make their own decisions regarding database, architecture, and so on. In my specific case, for example, I’m not ready to spend the necessary time and effort to write a new app from the ground up, or learn a new technology or framework. That obviously limits the scope of what I can offer to do significantly. It basically has to be doable with some hacking of Oddmuse, or I won’t have the time to do anything. This is a terrible position to start a project, I know. But we’re all constrainted in various ways, and these are my constraints, unfortunately.

Oddmuse

Why do we need a simple recipe wiki?

Most of all I hate the fact that my wife suggests chefkoch.de when we’re looking to do something with whatever is at hand. Right now it’s pumpkins and zucchetti.
I hate the fact that many of these sites are full of ads.
I hate the fact that many of these sites are agressively using copyright to protect themselves. This of course is only necessary because they are making money using ads. If they weren’t making money, what would be the point? In Germany in particular, the entire business of Abmahnungen is a disaster.
When I look at the Cookbook at Wiki Books, the best contender so far, I am confused. I am confused by the size, the many people on the site, the namespacing, the user interface. I think I’d do a bad job moderating such a site. How can I check all the edits, defend against vandalism and spam?
And yet, when I see pictures of what people cook for themselves online, I often wonder: how did they do it? Would I like to try? So I ask them: is the recipe available online, on their blogs, or some other site? And when it’s not: I’d love to tell them that there is a site that would gladly take their recipe.
So now we have the criteria: the user interface must be simple (what this means is open to debate, of course – less widgets, sidebars, special pages); it must be small (for moderation, for community); it must be editable by strangers (so that I can tell others to put their recipe on it); it must be free (or nobody will use it); it must have no ads (or I will hate it).
As such, as a collection of timeless things, a wiki is best. An old recipe is neither better nor worse than a new recipe, which is why a blog would be the wrong thing to do.

Abmahnungen

Cookbook at Wiki Books

But what about *demand*? I have no idea. Is a site for a dozen active editors demand enough? It will never make financial sense, of course. In that sense, there will never be *enough* demand. But I would like it. Perhaps three of us would like it. Perhaps we’ll find more. And if we don’t, let there be an export function to get the plain text of all the wiki pages and we can do with the recipes whatever we want.

What about growth? What will we do when we’re suddenly popular? The simple answer is that we will deal with it when we get there. We could also encourage others to put up a copy of their own. We can write setup instructions and provide a way to download all the recipes so that they can upload them on to their own site. There are various ways we could interoperate. The following technologies already exist:

Sister Sites – this is an old concept where related wikis exchange their list of pages and when a visitor looks at a page X on one of these sites, links to all the “sister sites” having a page X will be shown. This makes sense if the topics are the same but there are natural variations. If one site were to specialize in desserts, for example, other food wikis could make the Dessert Wiki their sister site and whenever somebody looks at their Tiramisú page, visitors would also get a link to the Tiramisú page on Dessert Wiki.
Near Links – this is a later concept that works on the same exchange of page titles but now, if you link to a page X which doesn’t exist on the local wiki, you are automatically linked to the same page on a “sister site” or you are presented with a list of “sister sites” that offer the “missing” page X. This would allow me to link to a Tiramisú page and it would automatically redirect to Dessert Wiki unless I create a local copy. And if I do have a local copy, a “Sister Sites” implementation would make sure that a link to Dessert Wiki’s Tiramisú page still existed. “Near Search” is part of this: if you’re searching for Tiramisú, you might want to limit your search to the local wiki, or include all the “sister sites” and thus you might find Dessert Wiki’s Tiramisú page.
Transclusion – this is an old concept where we include pages from remote sites. We might want a local Tiramisú page but we don’t want to maintain it. We could create an empty page and just say: “include the Tiramisú page from Dessert Wiki” and it would always show the latest copy. It’s unclear how search would handle this situation, though. Is the Tiramisú contant actually available, locally? Maybe not. The current implementation doesn’t actually copy the content and so it cannot be searched for, locally.

Sister Sites

Near Links

Transclusion

These are related concepts which don’t actually exist. Prototypes were developed years ago and never went anywhere.

“Copy on Write” – this solves the Transclusion problem: on the master page (Dessert Wiki’s Tiramisú page), indicate the URL(s) where a copy of said page should also be posted. Posting on the Dessert Wiki now takes longer because all the copies need to be posted as well, or there’d have to be a copying queue.
“Subscribe to Feed” – have the wiki subscribe to a feed from another wiki and apply the incoming edits to the local copies. This will overwrite local content, of course, or we would need to implement some conflect resolution mechanism.

In short, many ideas exist but none actually got any traction. I think Wikipedia and the like all grew along the conventional axis: big, centralized, easier to maintain, no fragmentation, maximum value. That doesn’t mean other wikis have to follow that model, though.

#Cooking #Wikis

Comments

(Please contact me if you want to remove your comment.)

⁂

Well, Ward tries to solve this with his Federated Wiki. Or so I think. To be honest whenever I look at it I don’t really understand it.

But why do you need to solve this as a service? Set up your own wiki for your own recipes. Tell your friends to have their own (wiki, blog, github page whatever). Maybe maintain a “blogroll” (remember those?). And if you have someone without their own space, invite them to use yours.

Anyway, here are mine: http://notes.splitbrain.org/rezepte:rezepte

http://notes.splitbrain.org/rezepte:rezepte

– Andreas Gohr 2018-08-05 21:32 UTC

Andreas Gohr

---

I like the way you are thinking! I guess for a moment I was hypnotized by the Mastodon/Fediverse groove I’ve been caught up in. Not everything needs to be federated, for sure. And perhaps the simple fact that almost no wiki is goes to show that no such need actually exists.

And now I’ll take a look at your recipes. 😄

– Alex Schroeder 2018-08-05 22:25 UTC