Tuesday, August 31, 2010

Why authors should future-proof their notes

[Originally hosted on my tech blog prior to NaNoWriMo 2010. It has been moved here as it is writing related.]

So, I explored using OneNote to take notes for my novel. I concluded with the realization that if OneNote can not maintain compatibility with templates hosted on the official site between versions, there is no hope for any notes I take to be readable if I later upgraded.

While the integration with Windows (and MSIE) is nice, and might be beneficial in terms of research, once that research is compiled the result should be something portable and yet still modifiable. So, I may plumb the depths of the Internet with OneNote at my side, but before I move on to writing my novel, I will have converted my research in to plain-text documents.

Plain-text documents are one of the only ways to future-proof your writing. As a writer, you need to think about the future. If you're working on ideas for a new novel you may sketch out ideas for a number of different novels before you decide on the idea to use for the current project. If the sketches are written in a proprietary word-processing format you may find that in 10 years time you have no programs that can access the older documents.

Now, you might be saying to yourself, "I don't care if I don't have access to my notes from 10 years ago. Any of my ideas from then will be so out-dated I should just use a new idea." That's well and good, and is a valid perspective on the matter. There is one problem with it: Sequels. Right now you may be plotting six different major stories that don't overlap in any way. However, if one of those stories sells well, you could be asked to write sequels.

One huge example of this is the fact that Isaac Asimov wrote the Prequel to the Foundation decades after writing the original trilogy. More than that, within a few years he wound up writing books that took place both before and after the original trilogy. With modern computers and proper backups you can easily store backups of both your stories, your outlines, and your research. The expected life-span of a typical CD/DVD is only 10 years, so every so often you need to make new backups, but these backups are only useful if you have software that can read them in the future.

Already recent versions of Microsoft Office don't support as many of the older file formats of Microsoft Office as Microsoft forced through a file standard in an attempt to gain acceptance, though there are massive things missing when it comes to how to deal with many files in their misnamed "OpenXML" file format. To go on their track record, it will be a long-shot as to whether they support any of their current file-formats ten or twenty years from now.

Then you have the second problem. When when file formats are "supported" you rarely see full format retention. Things are usually a little off if you're not dealing with the primary file format. This means that whatever formatting work you do today will be wasted in the future. You are just wasting your time.

The solution, then, is to file format that will work in the future regardless of what system or applications may occur. The safest format is plain-text using with either US-ASCII or UTF-8 encoding.

In recent years there have been a number of file-formats which use plain-text files incorporating certain unobtrusive light-weight markup. These files are easily read by humans and still able to be read by the computer and turned in to prettier formats. WikiText usually falls in to this category, though reStructuredText and MarkDown both have explicit support for converting the files to other formats., though I know others also exist.

I am not advocating the use of a particular light-weight markup, only that you consider using one. In my next post I'll be showing an example of a template for use with the Snowflake Method using reStructuredText. This example will look like plain-text because it is plain-text.

Worst case, I can directly read the text-file by any plain-text editor or word-processor in the future. Best case, whatever tool I use in the future may have direct support for reStructuredText. Now, though, I can convert it to whatever format I need (or whatever format other folks need from me).

[Instead of a separate post, the original reStructuredText (.txt) template is available as well as a rich-text version that was uploaded to Google Docs.]