A Technical Subject as a Childrens Book

A technical subject becomes a childrens book when you stop explaining the technology and start following one character who wants something the technology stands in the way of. The manuscript is not a lesson with a story wrapped around it; it is a story whose plot only works because of how the technology behaves. Before you send it, check every technical word against a source you can name, because an editor will not do that work for you.

Why a computing topic needs a story first

An editor reads a childrens book proposal looking for a character with a problem, not a subject with a summary. If your pitch opens with what a database is, you have written an article, not a picture book. If it opens with a child who cannot find something, and the finding is what the technology does, you have a manuscript.

The practical test is simple. Write the plot in five sentences with no technical nouns at all. If the five sentences still make sense, the story is carrying the weight. If they collapse into vague gestures, the technology is carrying the weight, and the technology will not hold a childs attention for thirty-two pages.

This is the same discipline that shows up in technical writing aimed at working developers, where a short verified example beats a long explanation. A blog such as the Java and Oracle notes keeps its examples short for the same reason: a reader who can follow one concrete case learns more than a reader who is handed a definition. A child is that reader, with less patience.

What vocabulary has to be checked before the manuscript goes out

Every technical term in the manuscript falls into one of three buckets, and you decide the bucket before you write the sentence.

• Words the child already owns. These need no explanation. A door, a key, a line, a box. Use them freely.
• Words the story teaches through action. A child does not need the word partition if the character opens one drawer of a cabinet and finds the drawer empty. The action teaches the idea; the word can appear once, in the characters mouth, and then be dropped.
• Words that belong only in the authors note. These are the terms an adult reader might want: the real name of the mechanism, the version, the standard. They go in a short note at the back, not in the story.

Checking means looking each term up in a source you can cite: a language dictionary for the plain word, a standards body or a vendor manual for the technical one. If you cannot name where you checked it, cut it. An editor who spots one invented term will doubt the rest of the manuscript.

How do you turn a computing topic into a proposal an editor can read?

A proposal is four pages, and none of them is the manuscript.

Page one is the pitch: one paragraph of plot, one paragraph of why this subject suits a picture book rather than a chapter book, and one line on the age band. Do not describe the technology here. Describe the child.

Page two is the plot in beats. Twelve to sixteen beats for a picture book, each one sentence. Mark the beat where the technology does something the child cannot do alone. That beat is the reason the book exists.

Page three is the vocabulary list. Three columns: the word as it appears in the story, the plain meaning in one line, and where you checked it. This page is what separates a proposal from a wish. It also protects you later, when a copyeditor asks why a term is spelled a certain way.

Page four is the authors note and the back matter plan. Say what the note will cover and how long it will be. Editors want to know that the technical material has a home that is not the story.

Send the proposal before the full manuscript unless the submission guidelines say otherwise. A proposal that is wrong costs you a month; a manuscript that is wrong costs you a year.

Which technical ideas survive the picture book form

The form has hard limits, and they are not about difficulty. They are about whether the idea can be shown in a single spread.

Ideas that survive usually involve a visible change of state. Something is hidden and then found. Something is locked and then opened. Something is copied and the copy differs. Something is counted and the count matters. A child can see all of these on one page.

Ideas that struggle usually involve scale or sequence that cannot be drawn. A concept that only makes sense across a thousand records, or across a process that takes an hour, has no single image. You can still write the book, but you will spend the whole manuscript inventing metaphors, and metaphors that carry no plot read as decoration.

A useful exercise is to sketch the spread before you write the text. If you cannot sketch it in thirty seconds, the idea is not ready for this form. This is the same reason a technical article opens with a short case rather than an architecture diagram: the reader needs one thing to hold before the rest arrives.

How do you keep the technical material honest without slowing the story?

The honest version of a technical childrens book does three things at once.

First, it never states a fact the story does not use. If a character never relies on a rule, the rule does not belong in the text. Facts that are not load-bearing are the most common reason a picture book manuscript reads as heavy.

Second, it keeps the authors note factual and short. Two hundred words is plenty. Name the mechanism, give the real term, and say where a curious adult can read more. Do not turn the note into a second book.

Third, it separates the story voice from the explanatory voice completely. The narrator never steps out to explain. If a term needs explaining inside the story, a character explains it to another character, in dialogue, in one line, and then the plot moves.

A fourth habit helps more than any of these: read the manuscript aloud to a child who does not know the subject. Mark every place the child asks a question. Some of those questions are the book working. Most of them are the book failing, and the fix is almost always to cut a term rather than add a sentence.

What to do when the subject is too large for one book

Most technical subjects are too large, and the answer is not to compress. The answer is to pick the smallest true piece and let the rest stay out.

A book about a whole system is not a book. A book about one operation inside that system is a book. The operation has a beginning, a middle, and an end, and a child can follow it. The system has none of those things from a childs point of view.

If you find yourself writing a series proposal to justify the scope, stop and check whether the first book stands alone. A first book that needs the second book to make sense will not sell the second book. A first book that works alone gives an editor a reason to ask for more.

Finally, keep a file of the terms you cut. That file becomes the authors note, the school visit script, and the answer to the copyeditors questions. Nothing you checked is wasted; it just does not all belong in the story.