To make a dent on Medium, optimizing exposure is a must.

I’ve been on Medium for many years, and I learned a few tips on maximizing article exposure along the way. These tips and tricks made a difference for me.

1. If you plan to submit an article to a Medium publication, beware of busy publications: the exposure might not be what you expect. The turnover is too high, and your article won’t stay fresh for long. One example of such a busy publication is Mac’O Clock$^1$. I did publish many articles for them over time. My content does get some traction, but it is for a very short period of time.
2. Articles like “The Top 5 Utilities for macOS” are really popular. Opinionated articles tend to perform well, too. “The Rotten Side of Tim Cook’s Apple” is such an example. This article was published by The Startup$^2$****, not on the Apple-centric Mac’O Clock. It still receives regular views and reads.
3. Allow some content to be published outside the Medium paywall to increase your chances of being noticed (cross-post a link on Twitter, for example). It’s a difficult balance to achieve, though. If your article is interesting, people will get it for free; you’ll leave money on the table. Consider doing this as giving samples of your quality work.
4. Publish on your term. Some publications require submitting an article in draft mode (not yet published). Depending on the publication owner’s schedule, it may require up to a few days before your article gets published. Sometimes, timing is everything. Consider publishing on your own if that’s the case.
5. Reviews of hot tech gadgets are also popular, particularly from Apple.

Your mileage may vary. Many articles on how to be successful are already available on Medium. Search for them. You’ll get a better picture.

This article should have been published on Medium, behind their paywall, because it usually gets a lot of traction. Oh, well. I feel generous today$^3$.

1. I hate this magazine name.

2. Contrary to its name, the magazine has little to do with startups.

3. It will end up on Medium, but in a few days from being published here.

Simpler is better.

If you know about WordPress, you probably know how bloated your WordPress site can become with heavy visual themes and lots of more or less useful plugins installed. Those using WordPress.com for hosting their WordPress website know how pushy WordPress.com can be. They really want you to use WooCommerce or ExactMetrics. I decided to do some spring cleanup this week by removing WooCommerce. Why did I have it set up?

During my early days on WordPress.com, I had the idea to allow readers to support me financially. I implemented WooCommerce to enable payment options, but it turns out that readers don’t often tip bloggers. So, I made the decision to remove the Tips page and disable WooCommerce. The result? My website now feels more responsive and visually appealing, a testament to the benefits of decluttering.

I should continue to remove unneeded features. Next up is the footer portion, which contains redundant features, and my sidebar, which contains my most recent tweets. They don’t really add value to the content. My main blog is available here: https://numericcitizien.me.

I’m using Git to maintain this blog, which runs on Blot. Up until now, my Git knowledge has come from YouTube. Today, I came across this Git beginner’s guide that I wish I had on hand before starting this blog. The nice thing about this guide is that it covers the command line commands plus a GUI-based tool, Atom, in that case. I’m mostly a GUI type of guy, but it’s always interesting to see what happens behind the scenes when interacting with Git.

Editing and publishing on the go is a must, after all.

This weekend, I’m away from home. I thought I could get away with it and skip editing Blot posts on the go on the iPad. I was wrong. As I wrote at length here, the jury is still out on the best way to achieve this. For now, on the iPad, Working Copy is the best GIT client, and Ulysses is my preferred text editor. They have to work together.

So, I sat down and cloned the Git repo from Blot to my iPad using Working Copy. It took about a minute to complete. After confirming everything was set up correctly, I created an empty text file with the .md extension in Working Copy. From the Files.app, I tapped on it, and sure enough, Ulysses was launched. The file is shown in the “External Files” section in the library view. The publishing process went smoothly via a Working Copy commit followed by a push¹.

This blog post was not just created, but also edited, previewed, and published from my iPad, away from home. I guess I found a satisfying solution, and it feels great to have accomplished this.

Editing new content from the iPad for this blog poses some challenges.

I started writing this post using my iPad, Working Copy and Textastic¹. The file was initially created within Working Copy’s sandbox, but I fetched content from the Blot Git repo to store the most recent changes locally on my iPad.

As with every app on the iPad, Working Copy runs within its sandbox. When cloning the Blot repo locally, files were placed in the application’s sandbox, which is inaccessible outside the iPad². Ulysses uses external folders, so I can point it to my iCloud Drive, where I stored the cloned repo with Nova. Only Textastic can edit files with Working Copy’s sandbox.

Writing with Textastic and publishing with Working Copy feels geeky compared to a workflow based solely on Ulysses. It is geeky because I have to think about what I’m doing in regard to my local repo being up to date with the remote one. I must remember that after pushing this article on Blot, I’ll have to do a fetch when I go back to editing on the Mac. I’m not certain that I like this dance. Textastic is good, but not as a writing application like Ulysses. The former is more directed to developers, while the latter is for writers.

Textastic on the left, Working Copy on the right.

Make no mistake, this isn’t a review of Working Copy. Read this excellent review from MacStories instead. MacStories likes it because it enables better group collaboration. It sounds overkill for me since I’m alone editing my website. Working Copy can work in conjunction with Textastic. After re-reading their review of Working Copy³, I found out that, in fact, I could have replicated a similar setup to the one on my Mac: using Working Copy to edit the local repo of this blog sitting on iCloud Drive (instead of Working Copy’s sandbox)⁴. In that case, I would use Ulysses to edit files as usual, and Working Copy, you see them as uncommitted changes.

If I don’t redo my setup on the iPad⁵, compared to using Nova on the Mac, I find this to be much less intuitive. Maybe I should focus on using Ulysses everywhere for my writing needs and use the Mac to push content on my Blot blog. It’s not a big deal, and Numeric Citizen I/O is not a place where I’ll publish as often as on, say, Micro.blog. Having to sit in front of the Mac for the final posting isn’t a big deal.

One last thing: Working Copy wouldn’t be needed if my Git usage was limited to GitHub. Blot, on which Numeric Citizen I/O is hosted, uses its Git server, which requires me to use a Git client capable of connecting to it. I didn’t find a way to do this with the official GitHub client.

I’m still undecided about what to do to enable my iPad to edit this blog. My mobile needs are quite low as the pandemic continues, limiting our travel possibilities.

Thinking about text editor apps. Following a recent article from Jason Snell about finding the best markdown editor for the iPad, I started thinking about using Ulysses for all my text editing needs. Is it the best tool for all use cases? Probably not. But it is cross-platform, and for me, it’s a must. As I write this blog post, I’m using Nova text editor on my Mac to start editing, finishing in Ulysses. It depends. I’m unsure how my text editor selection happens when I start writing a new blog post. Maybe I should do the same as Mr. Snell, build a table of much-needed features, and see if Ulysses still fits my needs. On my to-do list, I plan to write a blog post about GIT clients for the iPad. Working Copy is a very popular one and includes a text editor. Jason Snell’s article refers to Textastic too. They compete against Ulysses, but the latter doesn’t do Git stuff. Like many blogs, it may be okay to use a different text editor, depending on the platform. I could use iA Writer on the iPad for this blog and Ulysses for the rest. Or maybe Working Copy would be a better choice because I’ll need to use it to push updates here anyway? As you can see, I’m constantly reflecting on the tools I use or plan to use and my workflow. It’s a never-ending process. Back to Ulysses. For now. Update #1: I’m not alone in rethinking my text editor choices. Chris Hannah, too.

You can leave a comment on each blog post, thanks to Commento, you’re not being tracked.

When I created the Numeric Citizen I/O blog, I thought it would need a way for visitors to be able to leave comments as they see fit. I decided to go the Commento route because of its tight integration with Blot, but also for a more profound reason: privacy protection. According to Commento’s website:

Commento is more than just a comments widget you can embed — it’s a return to the roots of the internet. An internet without the tracking and invasions of privacy. An internet that is simple and lightweight. An internet that is focused on interesting discussions, not ads. A better internet.

There are no ads with Commento, so there is no need to track users. The weight of the script needed to add Commento support is light. Commento is easy to use for end-users and doesn’t require an account to publish a comment. But, if you prefer, you can use your Twitter account, your Google account, your Github account, etc, to identify yourself with the service before posting your comments. The design is nice and simple. Commento is not a free service, but I’m paying $99/year for it. That’s the price that I’m willing to pay so my readers aren’t tracked.

Enabling Commento on this blog was dead simple

Do you want to try the end-user experience? Please respond to this blog post; you’ll see. Thanks in advance.

Update: 2022-11-15: Since this blog is no longer hosted on Blot.im, comments are handled “automagically” by Craft as a Craft-based document. Update: 2024-04-10: This content is now hosted on Micro.blog. You can reply to this post by using the provided buttons, below.

Testing a web-based blog post publishing tool for posting directly to Blot from a webpage.

I’m currently testing a straightforward blog post publishing tool running on a webpage. The tool is accessible at https://wall.blot.im. I wrote a front matter; I guess Blot will process it as usual. The editor provides a character count, a word count, and a way to export the current blog post or publish it directly on my Blot website. Once published, I guess that I’ll have to do a “pull” from my Git client to sync the newly published content with my local repo clone. Let’s try this. Nope. It won’t work unless I use Dropbox, not Git. Too bad. Returning to normal programming in 3, 2, 1.

I made a few layout changes to my archives page.

Someone on Micro.blog posted something from its Blot website and I noticed he was using an unknown meta tag in the post’s front matter: metadata.icon. He used a tag to add an icon to each of its blog post. I wanted to know how Blot actually used this tag to format the blog post, so I asked the guy. His answer made me look deeper into Blot processing of meta tags. After some readings, I decided to change the content of the archives page to use the “summary” tag after each blog post title. It is super easy to edit Blot templates. In that case, it was a matter of adding a {{summary}} tag like this:

Adding the summary tag to the archives.html template.

Using Git instead of Dropbox for Blot content syncing provides an unexpected benefit.

As I recently wrote, Blot supports two mechanisms for synchronizing content from my Mac to the web: Dropbox or Git. I chose Git. As I write this, I’m still testing Nova as the Git front-end (I’m a GUI type of guy). One of the great benefits of using Git is the built-in history of commits that is at the core of any Git repo. As shown below, as I push updates to my Blot-based website, I make sure to write a short comment in the commit action to document the commit action. I think this is an important asset in managing a blog and owning its content.

Commit history to the blog report using Nova

A better view at the GIT panel in Nova:

Nova GIT panel with commit message area