Adding new features to my publishing tool

Published on under the Website category.

After I published my blog post announcing my new blog post publishing tool, I started to think to myself: I have solved the root problem: publishing a blog post on this site was a convoluted, slow process. Now I can think about what features would make my editing experience better. With this sentiment in mind, I started thinking about two things:

  1. How can I improve the user interface of the editor so I can see more of the post content I am about to publish, and;
  2. What parts of my publishing process have caused particular friction in the past?

To address the first issue, I decided to change the layout of my editor from a single column to a dual column layout. Now, the metadata fields – title, category, post slug, etc. – are on the left and the post interface is on the right. This allows me to see more of the text box in which my content is stored, making edits easier. I also made the entire page wider so that I could create more room for the box. I am still thinking about further ways to improve the content field.

The question of parts of my publishing process that caused friction was fascinating. This is the first publishing tool I have worked on for my blog. Because I am building the tool myself, I can think big about what features I want. I can think about features that are useful to my process.

I identified a few features that would be useful to have. These were:

  1. Custom snippets in a “Useful things” section that I can copy-paste. These would include the HTML to embed a video, which I always forget, and the code I need to render highlighted code snippets.
  2. The tool should automatically take the post title from the top of the document I paste in to the content field. A blog post almost always has a title that starts with ## (the markdown level-2 heading indicator, and what I use to start all my blog posts). I need this in the title form field, so it would be great if the title was moved to the title field from the content body.
  3. A monitor that tells me if my content includes:
    1. [add image, which is a placeholder I use when writing to indicate I need to add an image in a specific place.
    2. Three backticks in a row, used to indicate code snippets in markdown. These need to be replaced with custom HTML code to ensure the code snippet within the backticks shows up properly.
  4. A tool that makes it easy for me to find URLs to add as links in a post. I don’t usually add links to other blog posts I have written because I often forget to do so. If I had a tool to find URLs within my publishing tool, I may add more links.

I started thinking through each of these problems one by one.

Useful snippets section

I decided the useful snippets section should go below all of the metadata form fields, but above the publish button. This is prominent enough to be above-the-fold on my computer, but not so prominent that it interferes with the flow of the page. I called this section Useful things. I want my publishing tool to be a bit playful!

Here is how the section looks:

Useful things code snippets

Thus far, I have added snippets for code snippets syntax and videos. These are the two most common snippets that I used to have to find in another article and copy-paste when publishing. This was a tedious process. My changes now make it easy for me to find the markup I need.

Post title extraction

I added an event listener on the content field to check for new input. When there is a new input – a keystroke – in the content field, my publishing checks whether the content starts with ##, indicative of a title. If the ## pattern is found, the post title is extracted and moved to the title field:

This is implemented with the following JavaScript:


document.getElementById('content').addEventListener('input', function() {
const warning = document.getElementById('warning');

if (content.includes('[add')) {
    warning.innerHTML = '⚠️ Please remove the [add] tag from your content.';
    warning.style.display = 'block';
} else if (content.includes('[image')) {
    warning.innerHTML = '⚠️ Please remove the [image] tag from your content.';
    warning.style.display = 'block';
} else if (content.includes('```')) {
    warning.innerHTML = '⚠️ Please add code blocks using the "Useful things" section code.';
    warning.style.display = 'block';
} else {
    warning.innerHTML = '';
    warning.style.display = 'none';
}

Since my blog posts are usually no more than a few thousand words, this should work well for now. I may optimize this in the future.

Here is an example of a post where a warning has been triggered:

A screenshot of a prompt asking the user to remove a placeholder

I added the warning to the left side so as not to cause a layout shift in the content editor. Such a layout shift would be jarring and make it difficult for me to keep track of the position where I am editing.

Finding URLs to link in a post

Most of my blog posts do not contain URLs to other posts on my website. This is because I prefer to focus in my writing tool while preparing a blog post, leaving only to check reference materials or to take a break.

My preference for focusing on writing in my tool is also why I use add image] and similar placeholders. I don’t want to leave my post to add a link to another of my own posts or to find an image. (I will often leave to find citations for other sources, though, since doing so ensures that I have given proper attribution to am external source to which I am referring.)

When it comes to publishing, I am usually so excited that I forget to link to my own content.

I dreamed up a feature that lets me highlight text and opens a text field in which I can select from a few relevant posts. In my first and current implementation, I wrote code that reads my sitemap and gets the slugs of all blog posts. These slugs, and their associated URLs, are then saved in a lookup table. When I highlight text in the content field with my cursor, a HTML dropdown appears from which I can choose any post whose slug contains the same text I have highlighted.

I think this implementation will need a bit more refinement. I may create a new sitemap.json file that contains a list of all post URLs and titles through which I can search. Searching titles is likely to be more effective than slugs, since slugs are shorter and contain less information than titles. Also, this implementation means I need to find an exact keyword match. Whether this is useful is yet to be seen.

Here is a video showing the current implementation:

Above, when I highlight “publishing”, I see the first blog post I wrote on my publishing workflow.

By scanning my sitemap, I can ensure all of my content is searchable through this feature.

I am keen to experiment, however: I have a point of friction (remembering to find internal links, and actually adding the links), and I would like to come up with an elegant solution.

The plan? Continue to refine.

I am keen to focus on problems I have in my publishing workflow and implement easy-to-use, reliable solutions to those problems.

Above, I listed a few problems I have, from finding certain snippets of text I need to format blog posts to checking to make sure I have filled in all image placeholder text with appropriate images. I plan to continue working on the auto-link solution after I use it for a while. I may look at algorithmic improvements to the required changes checks, too, since they are inefficient. With that said, I am happy with what I have. First, make it work, then make it fast and beautiful.

While publishing this post, I found out there are limits to the length of the post contents allowed in the auto-fill URL to GitHub. I will need to figure out a solution to this. I may figure out the maximum length then make sure only the maximum length is in the URL, then inform me to copy-paste the rest. This isn’t ideal, but is out of my control.

Go Back to the Top