< Home

Researching Tech & Audience For My Blog

Don't overlook the research step. Even on small, non-consequential, projects you'll probably do some level of research before getting started. Here are the notes on how I planned my site.

It's easy to dive right into something as simple as a blog and have a completely viable result in no time at all. I want to be very deliberate in all the decisions I made from the CMS to how I format and style code blocks to how the audience dictates if I will have light mode, dark mode or just a single setting.

Choosing a CMS

There's no shortage in CMS options these days. In order to filter out which ones qualify to be considered we have to define a criteria for us to make a decision with.

Setting baseline requirements

While determining the viability of a CMS I typically look at, in no particular order, it's flexibility, usability and performance. These categories are somewhat vague so I'll explain.


Maybe more important for client work than a personal site, flexibility is how the CMS handles structuring and manipulating data. Does it allow various post types/collections? Can I easily add fields? How does it handle changing schema updates after content has been published? Determining if I'll be able to react to changes in the design or site structure is a major concern of mine.


When I say "ergonomics" I'm referring to both the ease of developing a theme, but also the usability of the admin area. A built in asset versioning system that prevents my styles and scripts from being cached is a huge plus. A clean template engine that responds to the flexibility in content modeling is a must. The admin area should be minimal, clean and structure in an obvious way so that anyone can figure out how to edit content.


I expect my platform to give me a little help in the performance area. Fighting against slow renders and a poorly implemented cache would drive me insane. Out of the box I'd like to have a flexible cache (ideally static page caching) and image manipulation that handles resizing along with webp conversion.

Statamic checks all the boxes

I've been using Statamic (this site being built on v3 beta) for years so I know that it does everything I need, plus so much more. One of my favorite features is that it is a flatfile CMS. This means that all content is handled in actual files that we can sync via git. No databases (they do offer db support, however) means no time wasted syncing between environments.

It ships with asset management built in. We can resize and apply filters to images with it's Glide support. This is a major benefit to our users as it means we're delivering optimized, aptly sized, webp converted images.

The admin is well organized and designed. In the past I've had to walk clients through or record screencasts explaining how to use other CMS admin dashboards. More often than not I can give a client access to Statamic and they can figure everything out for themselves.

The biggest selling point for me is the control. I can control anything I want on a page using fieldsets composed of generic field types or use a block style content flow with it's robust editor named Bard.

Check it out. Let me know what you think about it or if you need any help.

Defining an audience

Personal blogs typically have a natural audience defined simply because they are personal. You know who you will be writing for, but it's a good practice to remind yourself. I don't write true user stories too often, but I do put in some thought about who will be using my site.

In my case it's developers. My content is going to be technical in nature the majority of the time and there are some fairly safe assumptions I can make about this audience as it pertains to their preferences.

Dark editor theme, dark website

The majority of developers you talk to will say that they use a dark syntax theme. Initially my design was a much lighter theme, but after considering this I made a change. I'll spare my viewers eyes just incase they're making the jump from the editor to my site.

Long hours in front of the screen

A developer's job largely involves staring at a screen all day. I made a couple of design decisions In order to aid in managing their eye fatigue. The first was the font size. By bumping up the font size the reader can sit back and read without straining their eyes.

The second choice was to add an orange hue. Blue light tends to strain the eyes more so by tinting my background and text to more of a red/orange I can give the reader a little bit of relief.

Styling code blocks

My gut told me to grab a javascript library for styling code blocks with proper syntax highlighting. After some reading around the web I came across an interesting article. Robert Melton wrote "No Frils (AKA: Syntax Highlighting Off)" - an article about developing without syntax highlighting.

I personally never thought about doing this, but in the context of my website I thought it to be an interesting idea. When I read through his benefits, specifically "I get the overarching context faster and with less hassle. This helps a ton when reading other peoples code and helps a little when writing fresh code," I decided that I would forego syntax highlighting on my site.

Additional benefit: I'm not shipping 50kb of javascript and css just to display some fancy code.

Simple but helpful

I try to do most things with purpose. Determining which CMS to use and how I design my site for my audience are no different. By thinking about the people who will read my site most often I hope I effectively made it a better experience for them.