Research

A file on your own disk outlives the company that made it. Accounts expire, formats change, and exports are promises that nobody audited. When your notes live in plain files, the tool becomes optional and the work still stays yours. That is the whole argument... The method is plain. We kept a folder of plain text notes for a season, moved them between three tools and two file systems, and wrote down what happened at each move.

Nothing was lost, but not nothing was lost. Two notes were still on disk and gone in the way that matters, because nothing pointed at them any more and no search found them. A file you cannot find is a file you have lost.

The formats were the second surprise. Every word we wrote was plain text and every word still opens, but the structure around it was proprietary in practice. The links between notes, the tags, the order. The words survived the move. The relationships did not, and the relationships were the work.

The accounts were the third. We do not think that is a moral failing on anybody's part. Businesses close, software is dropped, and a service that promises your data is not yours has told you the truth about itself. The lesson is not distrust. It is that a tool holding your work has a future you do not control, and a file on your disk does not. So the studio keeps notes as plain files, in a folder structure a person can read. The tool is useful. The tool is also optional, and that is the part we wanted.

The sources for this note were the four tools we moved between, the folder of notes itself, the migration notes we wrote as we went, and a short comparison of the export options each tool offered. Everything was measured on our own files over about three months.

A word count is a number, and numbers are comfortable. It says little about a draft. The same paragraph can be short because it is clear, or short because it was cut. We use the count to notice drift, and never to judge the writing... The method is a small internal benchmark. We took three drafts of the same scene at three stages, counted them, and wrote down what the number missed.

The three drafts were a first pass, a cut, and a cut of the cut. The counts fell at every stage, which is the expected shape of revision. What was interesting was how little the numbers moved where the writing improved most.

In the middle draft a paragraph of around sixty words was replaced by two of about forty. The count went down by a few words and the scene got faster. Nothing in the count would have told you that. You can see the change by reading the two versions side by side, and no arithmetic does it for you.

We also counted what the tools count well: length, the number of repeated words, the average length of a sentence. The repeated word count turned out to be the most useful, because a word that appears nine times in a short scene is usually one the writer is leaning on, whether they meant to or not. What we do not do is set a target. There is no number at which a scene is finished, and a target turns a draft into a task, which is a different activity from writing and a worse one.

The sources for this note were the three drafts of the scene, the counts taken from the local text tool in this studio, the sentence lengths worked out by hand for the middle draft, and trial runs on earlier chapters to see whether the repeated word count held up elsewhere.

A desktop search box can be surprisingly good indeed, and a small index of your own files is easier to keep than a service. The trade is speed and housekeeping. You get answers that stay on your machine, and the cost is the daily upkeep... The method is a small set of trial runs. We built the same tiny index three ways over the same folder of notes, timed the answers, and wrote down what each version asked of us to maintain.

The first version was the simplest. It walked the folder on every search and read the files. It was slow on a large folder and instant on a small one, and it needed no upkeep at all. If your notes live in a few hundred files, this is the honest answer.

The second version wrote an index file, a list of the files, their modification times and the words they contained, so a search could look there and only open what matched. It was fast. It was also wrong whenever a file changed and the index did not, which is a bug you live with or fix.

The third version was the second one with a check. Before searching, it compared the times in the index against the files on disk and rebuilt what had changed. It added a minute of housekeeping and removed a category of wrong answer. The larger lesson was about expectations. A search box that is slow and correct is more useful than one that is fast and confidently wrong, and the difference is usually a file you forgot to reindex. That is housekeeping, not a database problem.

The sources for this note were the folder of notes we used as the test corpus, the timing runs from each of the three versions, the modification times recorded before and after each rebuild, and the failure list we kept for the second version.