A Microcosm of Technical Writing in the Kitchen While Cooking a Banana Cream Pie
November 27th, 2009 | Posted in blog 17 Comments »
As part of my contribution to the Thanksgiving dinner, Jane tasked me to cook a banana cream pie. She had a simple recipe already printed out.
The banana cream pie recipe
All the ingredients were available in the kitchen. The kitchen even had a double oven. I thought this would be easy, except it wasn’t. Because I suck at cooking. I hate cooking. If I cook, I need a “man’s cookbook,” one that cuts through the jargon and explains cooking concepts in idiot-like detail.
For example, try to make sense of this step:
Stir a small quantity of the hot mixture into the beaten egg yolks, and immediately add egg yolk mixture to the rest of the hot mixture.
This does not make sense to me. Pour A into B, and B into A? No reason given for this. Just do it. Why not simply pour A into B or B into A, rather than doing a little of both at nearly the same time?
Jane explained that this back-and-forth pouring of the hot custard would bring the egg yolks up to a warmer temperature slowly without causing the eggs to curdle. Oh, I said. Now I see, but that connecting logic was simply assumed in the instructions.
Here’s another place I tripped up:
In a saucepan, combine the sugar, flour, and salt. Add milk in gradually while stirring gently. Cook over medium heat, stirring constantly, until the mixture is bubbly. Keep stirring and cook for about 2 more minutes, and then remove from the burner.
Uhm, if I put dry ingredients in a saucepan on medium heat, they start to burn. Also, am I to mix the dry ingredients before adding them to the saucepan? How long do I have to stir this mixture — 5 minutes, 10 minutes? Bubbly means … slightly boiling, aerated, or some other state?
I stirred and stirred, but apparently not violently enough to get out all the clumps. I swear the mixture never got bubbly, but about 10 minutes into this step the mixture became thick and creamy — something I wasn’t expecting because there’s nothing in the instructions that indicated a dramatic change of state. Again, was I just supposed to know that the state would change, and that the changed state would mean the mixture was done?
I guess I had questions throughout. Here’s another place where I ran into a problem:
Slice bananas into the cooled baked pastry shell. Top with pudding mixture.
The recipe calls for 4 bananas. After I added 3, Jane said to stop because there wouldn’t be any more room in the pie. But perhaps the pie’s final shape was meant to be convex, rounded at the top like a small hill? And if I put the bananas at the bottom and the pudding on top, wouldn’t that be uneven? Wouldn’t it be better to mix the two somehow for a more even distribution?
Finally, the banana cream pie recipe made no mention about whipped cream. Am I supposed to whip cream and add it to the top of the pie, like I’m accustomed to seeing in coconut-cream pie? Or is the custard filling the cream component of the pie?
I repeated several times my desire for a man’s cookbook, one that would provide more details, more straightforward explanations, and more hand-holding.
Yet for Jane, she preferred the abbreviated, concise recipe style because she’s familiar with the terminology and methods. When a recipe says to prick a pie shell, she knows about how many pricks to make, how deep to make them, and how much space between all the pricks. When I see instructions to prick a pie shell, I’m thinking up all kinds of scenarios about what this could mean.
Is not documentation exactly like this? You have the novices and the power users, and the instructions will inevitably frustrate one and appease the other.
Perhaps this is why I like online formats so much, because they allow you to add the extra detail in links pointing to additional pages, in drop-down hotspots, or through little information pop-ups. You’re not restricted by space.
My pie turned out well in the end. I’m guessing there was some wiggle room and leniency in the instructions, which is perhaps why some seemed vague. Overall, the Thanksgiving cooking experience was a perfect microcosm for the world of technical writing.
Sponsors
Tags: complex, cooking, idiot, power users, simple, Technical Writing, thanksgiving, versions
If you liked this post, keep updated with new content: Subscribe to I'd Rather Be Writing.
Both comments and pings are currently closed.
Mark Baker (5)
DiSc (3)
Jen (3)
Neal (3)
Richard Hamilton (3)
Ellis Pratt (2)
Jenny (2)
Sarah Maddox (2)
Sarah O'Keefe (2)
Stefan Kleineiken... (2)
Methinks you need http://cookingforengineers.com/, Tom.
Belated Happy Thanksgiving!
Karen beat me to it! I was also going to suggest Cooking for Engineers (http://cookingforengineers.com).
But you’re right — without the ‘back story’ of methods, interpreting even a simple recipe is difficult. Add to that your reluctance to cook and you’ll come at the instructions with a lot of ill will. Then when you find instructions that assume you know what beat, mix, baste, blanche, etc. are, you’ll be doubly annoyed, and even more reluctant to cook next time.
@Rhonda –
Of course, there’s also the train of thought that assumes the user has a certain level of knowledge before performing an action. Withholding certain information may be a type of filter to reduce the risk of catastrophes caused by inexperienced users. The filter can also be a crutch that unwilling users can employ to wriggle out of demanding tasks. This filter is not in place on cookingforengineers.com…
Recipes are the oldest form of technical communication! Even fire used for cooking was once regarded as technology
About a year ago here in the UK the TV chef Jamie Oliver had a show called Ministry of Food in which he taught adults to cook. None of his participants had ever cooked for themselves and lived in a low income, low achievement community in the North of England. During the show, Mr. Oliver found that he had overestimated his audience’s level of knowledge when he wrote the recipes. One participant didn’t know how to tell when water is boiling. Few understood the term “simmer”. Back to the drawing board, Jamie!
You’ve got it right, Tom. Most recipes are written for power users; you and I are novices. Fortunately, as you gain a little experience I think you’ll get up to speed fairly quickly.
Besides a “man’s cookbook” my other wish is that someone would invent a new display format. As I work around the stove I hate having to refer again and again to an open book, or even an index card, lying on the counter. Precious seconds are wasted as I grope to find it amid the clutter and then interpret the power-user text. And the odds of my spilling something onto the recipe are just about 100 percent. I’ll bet Jane Jetson has a video screen (with illustrations!) stationed right next to her work area. It’s probably even voice activated, so she can tell it when she’s ready to move to the next step.
I’m glad your pie came out OK. Sounds like you’re well on your way to becoming a power user.
>Perhaps this is why I like online formats so much, because
>they allow you to add the extra detail in links
True, but this can be overdone:
http://www.mikepope.com/blog/DisplayBlog.aspx?permalink=2155
The general experience you’re describing is one of a mismatch between reader and intended audience. It’s not a problem that can be solved entirely by adding information to the text (as with links, as you say). For example, is it possible that all the information that Jane provided could have been added into the recipe in such a way that you could have used only the recipe, but the recipe was still useful for a cook with more experience? As people are pointing out in the comments, sometimes you just need different documentation (e.g. Cooking for Engineers) for different audiences.
Mike, thanks for the link to the post you wrote about recipes. That’s so relevant to my post here — can’t believe I didn’t see it earlier. I see your point about not wanting to distract the reader into other paths. But I kind of like all those hyperlinks in there. What exactly is your solution for getting around this? Isn’t more information usually better?
Well, the writer can try to anticipate where there are going to be problems (ie, where the reader will be expected to understand something) and provides links to the relevant information before the steps of the procedure begin. A sort of “Before you do this, make sure you know the following …”. In my world, this might come out along the lines of “The following procedure assumes that you are familiar with the scaffolding model” or something like that, followed by a link.
The problem with the links scattered throughout is not that they’re not helpful for those who need them, but that they are a kind of “too much information” for those who do know all that stuff and would prefer a more straightforward trip through the steps.
To be sure, it’s not a cut-and-dried issue. When I was writing about this, I really exaggerated the effect of too many links; and of course, one of the major benefits of online documentation is the ability for “just in time” linking.
I think your example underscores, however, that it can be difficult to write for users of all abilities in a single piece of documentation. As we know, it’s tough to make everyone happy.
Fun post, Tom! For me, the best part of the recipe is the screenshot, err, photograph.
Come to think of it, another cool part of the recipe is the author’s name. “Ruby Pfeffer.” It conjures up impressions of something warm and peppery. Perhaps we should make up fitting nom de plumes for each type of document we write!
On a more serious note, thinking about a technical writer’s appreciation of the importance of audience, it’s hard to stop different audiences from reading the same document. This is particularly true of online documentation, where people enter the documentation via a Google search and may land on any page. I think we usually cater for the experts quite well, by adding “related topics” at the end of each page. But for novices, maybe we need a standard header for every page, with something along the lines of: “Have you read the “Getting Started” guide?”. This is something I’ve been mulling over for a while, and I haven’t come up with an elegant solution yet. I’d be interest to hear what others have done.
Thanks for the comment, Sarah. I agree that this is a common issue. Perhaps adding cross references and links to additional material like the getting started guide you mention is the solution. Had this recipe included a cross reference in the step about stirring the hot batter back and forth into the eggs — a link to an explanation in the back with more detail — it would have been perfect. Online help formats can simply include hyperlinks to pages with more details.
Something else that might help you and Larry — step-by-step cooking videos from sites such as Rouxbe (pron. ‘ruby’): http://rouxbe.com/
Thanks Rhonda. I appreciate the link. I’ll keep that resource handy the next time I’m in the kitchen. My larger problem with cooking is lack of desire, but perhaps that’s based on my failing experiences more than anything else.
Since originally reading this post last week, I’ve been ponding a particular point. The “pour (a bit of) A into B, then B into (rest of) A. No reason given for this”
(my inserts in parentheses)
Do you often give your audience a reason for every step in a task? Maybe this is messed up a bit with power user vs novice, but generally in our doco, we’re very presriptive and just tell the audience what to do in order to achieve their goal.
*If* there’s some potential for confusion, such as what kind of address to enter – the supplier’s address or the delivery address – then, we might give some further explantion, but otherwise we don’t really give a reason for putting data in the address field. It’s just one element of achieving the ultimate goal, which might be creating a purchase requisition.
That’s probably a simplistic comparison, and when we’re documenting entering data into fields, there’s nothing to me that seems quite like the “put a little bit of A into B, then the whole of B into the rest of A” example.
I have observed with my husband that he is much more literal with recipes than I am. That’s probably diminished over the last few years as he does all of the cooking, but even still he’s a “follow the rules” guy. I tend not to be, and will go with my gut more when I’m baking.
Oh, and I think the easiest way to become more accustomed to the user jargon in recipes is to do more cooking.
Kirsty, good point. I do tend to provide explanations in my documentation when I think a step is weird or unintuitive. But I also appreciate concision as much as the next person, so I can imagine that having this same explanation in 30 different recipes throughout the book would get old.
Tom, I think that links in the middle of procedures can be overdone. If there’s critical information that a reader needs to have to succeed with the recipe, linking to that information while the steps are underway isn’t always the best solution — when you’re pouring batter, you don’t want to stop and have to go read something.
Then again, few people don’t at least review a recipe before they get underway, probably.
Thanks for the recipe. When I see new recipe, I copy it in my notepad and try at home. If I found its nice and tasty, I will send a feedback. In this case too I will do like that.
There are lot of dishes that we can make from banana. All are delicious.