The columns a flatplan spreadsheet needs

Ask what columns a magazine flatplan spreadsheet should have and the results you get are a PDF written for schoolteachers, one editor's blog post about having failed to find anything, and that same editor's own file. That is the state of the answer.

I do not think that is neglect. Answering the question properly needs a corpus of real spreadsheets — files people actually made under deadline, not files made to illustrate a point — and almost nobody has one. Publishers do not hand their working documents out, and the people who would want to compare them are the same people who are too busy shipping to ask.

Two files is barely a corpus either, and I will not pretend otherwise. But it is two more than the search results have, and two turns out to be enough to settle one question, because the two do not agree.

Neither file contains page numbers. Not a page-number column left blank, not one filled in for some rows and not others — no such column at all, in either file.

What the files hold is an inventory plus constraints: the things that are going in the issue, roughly how long each one runs, who owes what, and the handful of rules someone has already been told about. The placement — which page each thing lands on, what faces what, where the advertising falls against the editorial — has not happened yet. And the placement is the actual job.

That reframes the whole question. The columns are not a description of a flatplan. They are a description of what you know before you make one.

The spreadsheet is not a flatplan

Here is what the two files do with the same job. Two issues of the same magazine, planned by the same person.

Same magazine, same author, and the shape moved anyway. Nobody did anything wrong here. I would guess the Designer column stopped being useful and someone deleted it, and that a page count that was a number in one issue became "3 or 4" in the other because that was the honest answer at the time. The file tracked the work instead of the schema, which is exactly what a working document is supposed to do.

Two files, one author, one publication. I cannot tell you from that what magazine spreadsheets look like in general — but I do not think a canonical column set exists, because the smallest possible test of one has already failed.

The status column is the one every import format assumes it understands. Nine distinct status values in the first file against six in the second, and none of them shared — not one string appears in both.

Categories held up better. Five labels matched exactly across the two files. The rows below are not those five — each row is one category written differently in each file, which is a separate count and a separate problem. Do not read the list below as the five that matched; it is the opposite of them.

One category per row, as each file spelled it

The second spelling in the third row is a typo, reproduced here on purpose and left uncorrected, because correcting it would hide the thing worth seeing. Among the differences: a capital letter, a dropped article, a transposed pair of characters — to a person reading the sheet these are the same category, and to any importer matching on strings they are different ones.

So an import that treats status as a controlled vocabulary has to invent the controls, and an import that treats category as an exact-match key will split one section into two or three on the way in.

Three values, verbatim, from one of the files:

in progress/ Lunia blue

in progress/ Lunia blue/ New picture needed

Not started/ Anina's piece

Status, assignee and outstanding task, all in one cell, separated by whatever punctuation was nearest. This is not sloppiness. It is what happens when the person holding the file needs to record something and the sheet has nowhere to put it: people extend the cell they are already in rather than adding a column, because adding a column means deciding what the column means for every other row.

Which is the trap for anything that reads these files. A parser that stores that string whole has not preserved the data — it has inherited the mess and made status useless as a filter, because no two rows agree on what a status is. A parser that splits it has to guess which fragment is the person and which is the task, and it will be wrong on the rows that matter.

This part is judgement, not a finding — I have two files, and two files cannot tell anyone what to build. But having read both, here is what I would keep: title, extent, status, category, notes.

And row order, which is not a column at all and is the most important thing in the file. The order the rows sit in is the editor's first-pass running order — it is the only placement information the document contains, and it was made by a person thinking about the issue rather than about the sheet. An import that hands the rows back sorted by title, or grouped by category, or ordered by status, has destroyed the one piece of the flatplan that was actually in there.

Notes is the other one people underrate, because it is where the real constraints live. "Must be on back page" is a placement rule. "Not Using" is a decision that has already been made and that no status column in either file has a word for. It is the field with nowhere to go in any fixed import format, and it is the field a producer would most want to keep.

Which is why I would not trust a template that called itself canonical, mine included. Every flatplan tool you are likely to evaluate will ask you to hand it a shape. The useful question is not whether your columns match the shape — it is what the tool does with the columns that do not.

A starting point, not a schema. Free, no email.