John PapaStraight to the Point
I like to write, and when I do, I prefer writing in markdown. Lately, people have been asking my writing process involves, so I decided to write it down in this short post. This is my process and in no way should you feel obligated to use it. Hopefully, this helps you.
My Writing Process
All of this assumes I have an idea and I know what I am writing. That in itself is a whole different topic and not covered here. If you want to know how I write, this is the right place to be.
My Goals
I have some primary goals with writing:
- Stable Tools: What I write in must be stable (I don't want to have to rewrite it!)
- Saving: I want to save my articles, so I can iterate, refer back, and always have it.
- Proofing: I want to spell check and grammar check my articles.
- Markdown: I prefer writing in markdown
- Offline: It must work offline
My Workflow
My workflow is short and hits my main goals. So let's get right to the workflow.
- 1 - VS Code
I use VS Code to write my articles. It has excellent markdown support and is super stable which satisfies two of my goals. Plus, I work in this for my coding all day, so I don't have to switch to another tool.
Here are the VS Code extensions I use:
- Markdown Lint
- Markdown Preview
- Spell Right
- Peacock - I color code my vs code editor for writing articles
- 2 - Proofing
I currently use Spell Right (see the link above) for spell checking in my markdown. I then copy and paste the content to a local doc in Grammarly for grammar checking. You can use any grammar checking tools including Microsoft Word.
I find this to be a good step because spell check only catches part of the story. Grammar checking helps to avoid confusing sentences.
- 3 - Push to a Private GitHub Repo
Saving my content and making sure I do not lose it (2 of my goals) are reinforced by creating a GitHub repository for my content. I prefer this to be private as it contains a lot of my writing. I also organize my repository in a way that makes sense to me. I can find my articles quickly, modify them, iterate on them, and move along.
VS Code integrates with GitHub well, and I use this every day for source control. I find comfort staying in my familiar tools to write articles, commit, push, and move along.
Here is an example of my meta in dev.to:
---
title: How I Write Online Articles
published: true
description: How you can write online articles
tags: devrel, vscode, markdown, discuss
cover_image: https://thepracticaldev.s3.amazonaws.com/i/n0ecqvxjrzh9qy6ekfgy.png
canonical_url: https://johnpapa.net/how-i-write-online-articles/
---
- 4 - Copy and Paste to Target Site
The target for my articles could be Ghost (where I host my blog), Medium, dev.to, or any number of platforms. Unfortunately, because they are all different, some support various features, and few have an API, I currently copy and paste. Copy and paste only takes a few moments, so it's not a big deal.
Once I paste into the target platform, I generally find something that looks a little awkward. I make my adjustments in the target platform, test it out in preview (not publishing it), and repeat till it is good.
Then I copy the changes back to my local VS Code editor, commit, and push.
- 5 - Publish on my Blog and then dev.to
I publish my content to my blog first, since it is my blog and I like having a home for all of my content. Then I copy the canonical URL for my blog post and that to the dev.to target in the headers by setting canonical_url. Then I'll publish the same article on dev.to.
Cover Image or SketchNotes
I like to add something visual to my articles. I find visuals in articles to help connect the concepts in my mind. Also, it's fun! There are a lot of ways to get royalty free images. Pexels is one of these.
Often I want a very specific image and it is much easier to draw one. This is where I use my sketchnotes. The sketchnote at the top of this article is what I use to plan out my article.
I'll share more on how and why I use sketchnotes in a future article.
Ideas for the Future
I'd love to have an open API for all writing platforms, especially dev.to. Imagine writing locally in your favorite tools like VS Code, and then pressing a command which publishes the article on dev.to! I'm currently discussing some ideas for how I could write such an extension to publish to dev.to. An extension would require an API from a target platform and a bunch of cool features which I could code in the extension (gist previews using liquid embeds, for example). But ... hey ... it would be a lot of fun and very useful.
The great team at dev.to are considering an API. I imagine it one feature in a long list of great ideas they are prioritizing.
Showing the Read Time
I like to see an estimate of how long the markdown will take to read. This helps me know if I hit the right length for what I am aiming for (whether longer or shorter). Here is a post I wrote about this new extension and a link where you can install it.
You can get Read Time here from the VS Code Marketplace
What Do You Do?
I shared my writing process. I'd love to hear about yours! Is yours different? What do you like about it? What do you wish you could change?
