About Our New Site

We’re pretty excited about our new site. We’ve been working on it in one form or another for about a year, and much of the interesting stuff that we’re doing is actually invisible to the reader — it’s happening backstage — so I thought I’d talk a bit about the improvements we made when refreshing our visual design and rethinking our technology stack and our workflow.

The previous Fireside site was organized around the conceit of issues. That led us to build the site using a deeply customized version of WordPress which relied heavily on plugins and custom themes. This site served us well, but it was very complex. Over time bit rot set in, and the site became slower and slower, both for readers, and for Brian, Elsa, and I when working on editing and publishing the magazine. So when we set out to rethink the site to reflect our shift to a more blog-like publishing schedule, we doubled down on simplicty as one of our core guiding principles.

This preoccupation with simplicity manifests itself most obviously in the refreshed visual design of the Fireside brand and the magazine site. For the site, we maintained our minimal aesthetic, with the same clean reading interface that we’ve always favored — if it ain’t broke, don’t fix it. But we also made some iterative improvements: we tightened up the typography a bit, and improved the accessibility of the text, increasing color contrast and using heavier font weigths throughout the site.

When rethinking the broader visual identity of Fireside Fiction Company, we got rid of the separate typeface we were using for the Fireside logotype, and reduced the number of colors on the logo mark to just one: Fireside Red (#610C0D). This led to a starker and bolder visual presentation, in keeping with our newly affirmed focus on antifascist resistance. We first tried out this new look in our #BlackSpecFic series last summer, and we’ve been refining and expanding it since into a full identity system.

When we decided to rebuild as well as redesign, we wanted to make sure our new site was damn fast — nobody likes to wait for a webpage to load, especially when it’s basically just simple, static text and the occasional image. So we also worked on keeping complexity out of the structure of the site and out of the workflow that we use to update it.

I’d been keeping an eye on the work being done with static site generators, and realized that since all Fireside is doing is working with text files, static site generators and their focus on simplicity and portability would work nicely for us as well.

Wait, so what is a static site generator? OK, this is where it gets geeky. Strap in, nerds:

When someone visits a site running a CMS like WordPress, Drupal, or Joomla, they request a piece of content from a server. At that moment, the CMS software running on that server will jump into action: it will query a database for the content that the visitor has requested, run it through a pre-made template, and finally generate an HTML file with the content to send back to the visitor. This all happens in the moment when the visitor calls up the page on their web browser. For very complex sites, this can create a bit of a lag, and slow the site down. (There are ways to mitigate this issue using caching, but that introduces its own complexity.)

A static site generator, in contrast, does all that work ahead of time, when the content is first added to the site by an editor, so that by the time the visitor shows up and requests a page, the HTML file is already waiting for them. Instead of a database of content, static site generators work off of plain text files. (For a good primer on this technology, check out David Walsh’s Introduction to static site generators. If you want to read about practical applications, check out the work that Vox Media has been doing on publication sites like The Verge and the work 18F has been doing inside the U.S. Federal Government.)

The world of static site generators is relatively new, so there are lots of players. After spending a few months messing around with a few of them, like Hugo, Octopress, and Middleman, I settled on using one called Jekyll.

Using Jekyll gave us three big advantages: first, we’d be able to write really lean templates for Jekyll to use, which would result in a lightweight website that would load super-fast, since the server would have to do none of the work to generate pages on the fly.

Second, building the site off of plain text files meant that I could get Brian and Elsa to edit the site content directly using their text editors of choice, rather than having to work within an online admin interface designed to edit entries in a database. Additionally, working with text files removes the distraction of visual styling from the editing process. In order to give the text semantic meaning (emphasizing words, setting headers, etc), we use the Markdown notation system, which Jekyll then takes and transforms into proper HTML.

Third, working with plain text files meant we could use proper software version control on our site. Designing websites and apps for a living means working with software developers and engineers. I’ve had the privilege of working with some top-notch technology teams over the years, and they’ve taught me the value of good version control. Once you’ve gotten used to working with tools like Git to manage collabroation and iterative work, it’s really hard to go back.

Git is the open-source version control scheme of choice for working with software, and GitHub is a private company that hosts many of the biggest (and smallest) code repositories out there. If you work with software, chances are that the first thing you do when you start a new project is to create a Git repository for your code on GitHub.

GitHub offers a service called GitHub Pages, which allows you to serve a website directly from the code in your GitHub repository. As an added bonus, GitHub Pages works really well with Jekyll, specifically. This allowed me to automate the last bit of complexity: telling Jekyll to build the site files whenever an editor adds or edits content, and updating the site with the new files.

So, putting all this together, it turns out that with a little bit of Markdown and Git knowledge, we could make Fireside production as simple as editing some plain text files in a shared folder, and making a push to the Fireside git repository.

Having the entirety of the Fireside site living in a GitHub repository brings a ton of useful benefits: from the ability to automatically document the work we do and piping it into our Slack team (which improves our communication as a team), to being able to roll back changes if and when we do something that breaks the site. We’ve also made sure that the entire site can be edited and updated from our iPads and iPhones, since both Brian and I do the majoritiy of our work on iOS these days. Elsa uses a Windows tablet, and she’s covered too. This has come in particularly useful as visitors to the site have emailed us with bug reports after we launched — being able to very quickly fix a small bug or typo on your phone is very useful if you suffer from “something is broken and I need to fix it” anxiety.

Additionally, the Fireside repository is public, which means that anyone can can check out the repository’s readme file to see how the site is organized, log issues, submit pull requests, and otherwise keep track of all of our updates to the site— from big stuff like new stories, to little things like fixing typos and bugs, or refining the design. This plays directly into our commitment to transparency as one of our core values.

Working in this way is a big departure from how most editors and authors work — there’s no Microsoft Word, there’s no WordPress admin, just a bunch of text files and the GitHub Desktop app (or Working Copy on iOS). I was afraid that Brian and Elsa would have trouble getting used to this new way of working, so a big part of the process of putting the site together was teaching them how to use Markdown and Git, and making sure that our documentation is comprehensive but easy to understand. I shouldn’t have been worried: even though neither of them is terribly technical, our workflow is simple and straightforward enough that after I went through the readme with them, they both jumped in with both feet. I’m really looking forward to seeing how well they do working with the site on a day to day basis (and adjusting course when problems come up). I’m also really looking forward to trading snarky code commit messages with Talkwordy and the Bat.

My experience working with Brian and Elsa to get this site up and running has left me more convinced than ever that publishers would be very well served in rethinking their workflows to use the concepts and tools in the software development toolkit. The more forward-thinking publishers, like Vox, O’Reilly, and even Macmillan are already figuring out that these tools are often better than what they’ve had before, and that the changes are worth it.

So what’s next? Well right now, I’ve got other jobs to do, and I want to let things lie for a bit to see how well the site is working for Brain and Elsa. But we’ve got a small roadmap planned out with improvements and enhancements, which we’ll be working on throughout the year. As long as we continue getting your support on Patreon, we’ll keep making the site better. Faster. Stronger. We have the technology.

© 2017 Pablo Defendini

About the author