Building an author’s website

I work through the concept of building an author's website, from content and design to the tech stack.

Building an author’s website
Photo by Hal Gatewood / Unsplash

Having decided to rebuild my website, I thought it prudent to ask what it is I, and my readers, need one to deliver. I’ve never consciously asked myself this before, and I think my site’s suffered accordingly. I’ve always had something of an identity crisis as a content creator, invariably labelling myself as a technical writer, blogger or novelist, depending on how I feel at the time.

When I build a website, I usually start with what tech I want to use, but this is a terrible place to begin. I start with tech because I’m a developer, and I like writing about tech. A designer, meanwhile, would probably ask what the site should look like, again coming from a position of strength and interest. However, an author’s website is ultimately a marketing tool to sell the author’s books and their brand. The design and tech, while obviously important, are to support that primary objective.

Before you read on, note this is a reflective article where I think through what I need to build my website from concept to publication. It’s not a how-to guide for other authors, nor is it an invitation for professional designers to berate the error of my ways and try to sell me a five-page bloated WordPress deployment for $3000.

So, what is an author’s site?

If an author’s website is there to promote the author’s brand and books, then it’s a place where authors and readers meet. An author writes and sells books, a reader buys and reads them.

What attracts readers to authors is subjective, and individual to each reader. I don’t actually spend much time on other author’s websites, even those whose books I like. Many authors I like are either dead, or don’t have much of a web presence for varying reasons. Then there are authors I avoid seeking because while I like their craft, I don’t necessarily like them as human beings — in that cases, it’s best to separate the art from the artist.

So, beyond the basic understand that authoring is about writing books, and therefore books need to be front and centre, what else should there be?

To answer that question, I asked my friend Mark Timmony, who, if I’m honest, cares far more about my career than I do, and since he works in book sales, is far more knowledgeable when it comes to marketing.

Anyway, Mark suggested that an author’s website needs the following elements:

  • Books — covers, blurbs, links to where readers can buy them
  • News page (or a subset of my blog in my case)
  • Maps and glossary — i.e. setting-specifics, especially for speculative fiction
  • About the author page — good place for contact and socials
  • Newsletter signup form (in my case, membership form for Scriptorium)

It’s solid advice for any author — or indeed, any content creator, if you substitute books for x. A quick scan of other author’s sites confirms these elements are consistent across the board. I reckon this list constitutes the bare minimum one should include. For me, I’d also like to add:

  • Character bios, backstory articles
  • Progress indicators for upcoming books
  • My reading list
  • Free and serialised stories

In other words, these elements showcase the value the author offers, in the form of their creative output, and to a lesser extent, the author themselves.

Design

I’ll admit design and the graphics arts are my weakness. While I have a technical grasp of CSS and design tools, I’m quite inept when it comes to things like composition, colour theory, etc.

Even so, I know what I like, and I know that design should reflect the author’s genre. Since I prefer to write grim, low fantasy, pink unicorns and rainbows probably won’t attract the type of reader I’m after.

Getting the design right is something I’ve struggled with in past versions of my site, but not for the reasons I described above. Rather, it was thanks to the multiple content types all competing for space. The site started life as my blog, and many posts were technical in nature. An author like Matt Gemmell does that well because he writes contemporary fiction. But for a fantasy author, it’s hard to create a design language suitable for both medieval grimdark, and tutorials on how to optimise low-cost Linux servers.

Common sense prevailed, however, and I’ve since either archived or moved all technical posts to Medium. This move should free me to pursue the type of design that best suits the themes and tone of my adult-oriented stories.

After talking to Mark about the types of content I should include, I started looking at other author sites and actually found a lot of structural uniformity in their design. Set aside genre and colours, and countless sites share the following elements:

  • Full width content blocks
  • Parallax scrolling effects
  • Stacked and flex-based navigation layouts
  • Card-based content elements for books and posts
  • Genre-specific images, a lot of it stock

In fact, there’s enough similarity to suggest plenty of authors are probably using the same WordPress plugins like Elementor to construct their sites. They’re also easy to build and are mobile-friendly, so I’ll likely adopt the elements I like best.

Even so, I’m afraid I won’t solve the design problem all at once, and will have to wait until I get my Weaver Cycle covers redone. At this point, it’s more important that I leverage design tools I can quickly adapt, and focus on user experience (UX).

UX

Design is only one part of a user’s experience. Years ago, I remember when Flash-based websites were still a thing. Many of them look beautiful, but man were they awful to use. There’s no point making a website look epic if it’s slow, insecure, and is hard to navigate.

Performance (speed) and security are essential to me, and those problems I hope to solve with tech.

The tech stack

99% of authors use WordPress to power their websites. I do not. I won’t hate on WordPress for clickbait, suffice to say that I dislike it, and it doesn’t work for me.

I noted above that ‘what tech should I use?’ was the wrong question to ask at first. That’s because my preferred publishing platform for the last three years has been Ghost. It’s great for blogging, sending newsletters and building a membership business, but less than idea for creating a platform to showcase an author. While I’ve done it in the past, it required a completely custom theme, with many elements hardcoded into handlebars templates. It was tiresome to maintain, and vulnerable to breakage on new releases.

For Scriptorium at least, I use an official Ghost theme augmented with a custom template to handle serialised stories. With Ghost being relegated to my members site, where it will also serve as a headless content management system, the less maintenance I need the better.

Yet, going into this process, I had already made up my mind to return to the JAMStack — that is a very broad range of technologies based on JavaScript, APIs and Markup. I made the decision for technical and monetary reasons. I want a site that’s very fast, secure and free to host— that’s only possible with the JAMStack.

The JAMStack though is a big umbrella term, with interchangeable components. Since Vue.JS is my favourite frontend framework, I’ve decided to use Gridsome as my static site generator. Gridsome can import all kinds of data, from a variety of sources, and generate a static website. It can read content from Ghost, any API, and locally stored data contained in Markdown, YAML or JSON files. So, I can import my blog posts from Ghost, pull in my bookshelf data, and store book data in a local YAML file. Upon an update, these all get transformed to HTML, and automatically deployed on a free web host like Netlify.

Concluding thoughts

Well, I have a blueprint of sorts, having worked through my thought processes, but like any plan, conception is easier than execution. While I’ve decided what to include and the general structure I’ll adopt, there’s still things like colours to choose and assets to source. I’ve still got some technical decisions to make, too, like if I use Tailwind or Prime as the basis for my CSS framework. But I have enough to start, and I’m keen to get cracking.