Practically Paperless with Obsidian, Episode 25: Five Use Cases for Managing My Writing in Obsidian

Welcome to my blog series, “Practically Paperless with Obsidian.” For an overview of this series, please see Episode 0: Series Overview.

Years before I began using Obsidian, I’d wanted to consolidate all of my writing into a single format–preferably text files. I wanted all of my old writing files accessible in plain text, and wanted to do all future writing in the same format. Ideally, I would use a single editor for all of this and would only have to know a single set of keyboard mappings. Once I started using Obsidian, and learned more and more of its features, I began to do what I’d I’d always wanted: centralize all of my writing–all of it–in a single place.

This episode, and the several that follow will describe how I’ve centralized all of my writing in Obsidian. I’ll begin with how I use Obsidian for my “professional” writing, illustrated through 5 use cases.

Professional writing?

In addition to this blog and my day job as an application developer and project manager, I also write stories and articles for publication. I began to write with the idea to sell stories almost 30 years ago, while still in college. It took 14 years of writing, submitting, and collecting rejections before I made my first professional story sale. Sales came quicker, and I branched out from writing stories to writing articles as well. Writing short fiction and nonfiction pieces was never going to take over from my day job as my primary source of income, but it was my avocation: something I’d always wanted to do and something that I really enjoyed doing.

Over the years, I’ve used all kinds of tools for my writing. When I began to write in college I was composing my stories in Microsoft Word 5.5 for DOS–still my favorite word processor to this day. I moved onto other tools. I was a long-time user of Scrivener, and later, Google Docs. When I began using Obsidian more than 15 months ago, I decided that I wanted to do all my writing there. Moreover my vault could serve as the repository for all of my writing.

Writing as a profession–even one as humble as mine–involves more than just typing words onto a page. I have identified 5 tasks I perform as part of the overall process of managing my writing. They are:

1. Writing drafts
2. Managing writing projects
3. Tracking submissions
4. Tracking sales and contracts
5. Seeing the big picture

Prerequisites

There are a couple of tools I use in conjunction with Obsidian to make the overall process smooth and seamless.

• Templater plug-in. I use this to build a set of writing-related templates so that I am not re-inventing the wheel every time I create a new draft manuscript note, or a new submissions note.
• Quick Add plug-in. I use this to speed up the process of creation and to populate some of the meta-data in my templates.
• Dataview plug-in. I use this in my “writing project” notes for collecting together related information about the project in one place. Because the dataview plug-in does not actually link notes together, I have, as you will see, taken additional steps to ensure that all of my writing notes have links within them to keep them related to their projects. This serves as a kind of backup to the dataview plug-in.
• Pandoc. I use this to automate compiling a draft note into standard manuscript format. Standard manuscript format is used by most of the professional publications that I have worked with. It is a simple set of guidelines for formatting a manuscript that takes the job of figuring out how to format a document out of the writer’s hand. This is a good thing since getting bogged down in formatting is a good way to avoid writing.

Use Case 1: Writing Drafts

My process for actually sitting down to write in Obsidian is straight-forward:

1. Create a new note using a New Manuscript Draft template via the Quick Add plug-in. This creates a note with the appropriate meta-data at the top (the YAML frontmatter) and a callout footer with a link to the project. It also automatically files the note into my “Working Drafts” folder.
2. Write. This is the activity where I try to spend the bulk of my time.

There isn’t much formatting involved in the types of manuscripts I produce. I use simple markdown for things like italicized text. I use markdown headings for sections or parts of a story or article. Otherwise, I just write. I do, however, have a process for working through my drafts that has evolved over the years and I have built that process into my workflow in Obsidian.

1st draft and 2 second drafts

When I create a new note using my New Manscript Draft template via the Quick Add plug-in, I am prompted for several pieces of information:

• Draft title. This is often a working title. My first published story was called “When I Kissed the Learned Astronomer,” for instance.
• Project title. A name of the project that this piece is associated with. This is often an abbreviated version of the title. In the case of my first published story, the project name was “Learned Astronomer”
• Draft: The draft version, 1st draft, 2nd draft, etc.

After providing this information, a new note is available to me with the meta-data in the YAML frontmatter of the note file, and a footer containing a hard Obsidian link to the project note. Now I can begin writing. Here is what it looks like in action:

At the bottom of my template, you’ll notice a callout section called “Note” which contains a link to the project name. Many of these notes are surfaced through the dataview plug-in, as you will see. However, the dataview plug-in does not create actual links between notes. The “footer” in my templates create links between the note and the project: in this case, between the draft and the project. This serves as a way to see the relationships in backlinks, or the graph view. It also serves as a kind of backup to the dataview itself.

For me, a typical story or article goes through two drafts. On rare occasions, I’ll have a third draft. Each draft gets its own note so I can see the evolution of the piece from one draft to another. These drafts are accessible from the project note, as I will demonstrate in Use Case 2.

Submitted and publication drafts

In addition to “1st”, “2nd”, and “3rd” draft, my template also provides me with two additional options: “Submitted draft” and “Publication draft.”

• Submitted draft. This is a version of a piece that is formally submitted to a specific market. There can sometimes be several submitted drafts, each one tied to a specific market, slightly different based on feedback I have received, or changes I have made between submissions.
• Publication draft. This is a version a piece that is ultimately published. This may differ slightly from the submitted draft. Some magazines and publishers provide authors with “galleys” of their piece set in type from which minor corrections can be introduced prior to publication. Changes I make on a galley get reflected in the publication draft.

Writing

Ultimately the creation of the new manuscript draft note takes just a few seconds. The templates and plug-ins help speed that process along and keep everything standardized so that I can get to the writing itself, which is what matters.

These templates and plug-ins eliminate a lot of overhead and allow me to focus on writing.

Compiling a manuscript with Pandoc

When I have a submission draft locked down, I will compile a manscript using Pandoc. Pandoc, for those who aren’t familiar with it, is a tool that takes one format of text and converts it to another format. For my purposes, it takes a plain text markdown file and generates a Word document (or sometimes, a PDF) in standard manuscript format.

I have a simple command I run at the command line to do this. Because I’ve already set up a “standard manuscript” template in Pandoc, I run my command against a given note in Obsidian, and out comes a properly formatted Word document ready for submission. After running my command, Pandoc generates the manuscript. Here is an example of the first page of a manuscript that is produced (header information is made up for this purpose):

Once again, this saves me time. I want to spend as much of my available “writing” time actually writing.

Use Case 2: Managing writing projects

If I manage to complete a draft, I create a “Writing Project” note. (If I give up, I trunk the draft.) I have a “New Writing Project” template that I use to create the project. Like the “New Manuscript Draft” template, it prompts me for a bunch of information, and the resulting project file gets places in a project folder.

There are five sections to my New Writing Project template:

1. Drafts: a dataview table listing all of the drafts associated with the project.
2. Submissions: a dataview table listing all of the submissions associated with the project.
3. Contracts: a dataview table listing all of the contracts associated with the project.
4. Appearances: currently, a manually maintained list of places the piece has appeared, with links if available.
5. Notes: notes and other items related to the project.

Here is an example of a Writing Project note from my first published story from back in 2007:

Everything on the template, with the exception of the “Appearances” is automated so long as I use the same project name throughout the process. Below is what my actual Writing Project template looks like in source mode so that you can see the dataview queries:

Once again, because the “footer” in my Manuscript Draft, Submission, and Contract templates contains a link to the project note, there are hard links between the notes, in addition to surfacing the related notes through the dataview plug-in. For instance, from the project note, I can see the backlinks to all of the related notes (drafts, submissions, etc.):

As indicated, the {{VALUE:Project Name}} comes from a Template configuration I have in the QuickAdd plug-in. That configuration looks as follows:

The result is that when I create a new draft, submission, or contract that uses the same project name in the meta-data, it will appear on the MOC for the project in question, surfaced in the dataview tables as well as the backlinks to the note.

I have a writing project MOC for every writing project for which I completed a first draft, even if the story or article was ultimately trunked. More on this in Use Case 5 below.

Use Case 3: Tracking submissions

When a story or article is ready for submission, I use my “New Submission” template. This prompts me for two pieces of information:

• Project name
• Market name

The market name is typically an abbreviated version of the market to which the piece is submitted (e.g., IGMS for InterGalactic Medicine Show, Daily Beast for The Daily Beast, etc.)

When the note is created, it is automatically filed in a Submissions folder. I then manually add a couple of additional pieces of information:

• Submission date
• A note link to the the submitted manuscript draft.

Recall that some projects may have multiple submission drafts. This link is what ties a specific draft to a specific market. Here is what a submission looks like:

When I hear back from a market, I will update the submission note. I’ll update the status, as necessary, and the status date. I will also make running notes in the note itself. For instance, if an editor requests changes, I’ll note the changes in the submission note that need to be incorporated into the published draft.

As I make these changes, or add new submissions, they are automatically captured on the Writing Project MOC for the project in question.

Here is a look at my New Submission template:

Use Case 4: Tracking sales and contracts

When a piece is sold, a contract usually follows that contains the terms of the sale, how much I am to be paid, and what rights I am selling. When this happens, I create Contract note using my New Contract template via the QuickAdd plug-in. The contract template collects information like:

• project name
• market
• contract date
• payment
• contract terms/rights

This information goes into the meta-data of the note. I then manually add an embedded link to the PDF version of the contract. This note gets autmatically filed into my _documents folder. The contract is automatically listed in the “Contracts” section of the project MOC for the piece. For some projects, there may be more than one contract. This will happen for reprints or foreign sales, for instance.

Here is an example of what a contract note looks like. This one is for my story, “Take One For the Road” which appeared in the June 2010 issue of Analog Science Fiction:

The contract is automatically listed in the “Contract” section of the corresponding project note. Like my other templates, the contract template also has a “footer” with links to the project note and the corresponding market note, thus creating hard links in Obsidian between those notes.

Use Case 5: Seeing the big picture

Finally, I have a “Writing Projects MOC” note that lists all of my writing projects using the data view. It has three parts:

• projects in progress
• projects that have been complete/published
• projects that have been trunked

This is the 50,000 foot view of my writing. It lets me see everything and then drill down into those project MOCs that I am interested in seeing in greater detail. Here is what my Writing Project MOC looks like today:

The screen capture above cuts off after my first four “trunked” stories, but there are at least a hundred of them in that list, going back, as you can see to as early as January 1993, when I first began submitting.

There are other views I have as well. I can see tables showing me how much I was paid in a given year–useful for tax season. Or I can see a listing of publications by market. One thing I am working on is creating a template for appearances; this will essentially automate my bibliography.

Final thoughts

No solution is perfect for everyone. This one works well for me because it allows not only to do all of my writing in Obsidian (and in plain text files), but it allows me to manage my writing in plain text files as well. The dataviews are convenient for this, but not required. As I have shown, my templates also create hard links between projects and related notes so that I can see the relationships in backlinks, and graph view, in addition to the dataview tables.

There is certainly room for some improvement in my process. But that comes with time. I should also point out that I use this process for my paid writing. I have a similar, process for how I managed my writing here on the blog — but that will be the subject of next week’s episode.

I know there is a lot in this post. I am happy to try to answer any questions, technical or otherwise about managing my writing in Obsidian in the comment thread.

Prev: Episode 24: Use Case: How I Capture Field Notes in Obsidian
Next: Episode 26: Use Case: How I Manage My Blog Writing in Obsidian (coming April 12, 2022)

Written on March 24-26 and April 1, 2022.