By Page Wood • July 02, 2017

Last summer (2016) I finally decided that it was time to embark upon a full re-design and re-build of my personal website. This began when I started working on a light personal brand “refresh” in June which wrapped up sometime in July. The refresh consisted of a new, and relatively simple text-based logo (which you see here in the top left) that was used for some new personal business cards, and then as a starting point for the new website’s look and feel. Once I had a direction for the look and feel of my personal brand, I spent July – February working on this new website one piece at a time.

July through February, that’s a long time right? Indeed. The last time I re-built my website it took probably 1/3rd of that time. The previous version of this website was also mostly designed on the fly in the browser and had a lot of hard-coded content in a WordPress theme that I wasn’t overly proud of. This go-round I absolutely over-engineered the heck out of this website but I had a great time doing so and I learned a lot.

A Segmented Approach to UX & Design

The redesign of this website was done in a very methodical way compared to any of the previous redesigns of PageGWood.com. At Storyware we use a content-first design process with segmented design deliverables: style tiles, followed by wireframes, and then wrapping up with high fidelity mockups in Sketch. I wanted to apply the same approach to this website.

I started the design process by creating a content outline – a list of all of the pages on my site with bulleted bits of content for each page. Next I filled in the content outline, writing out all of the content for each page of the website. I moved on to wireframes in Sketch once I had all of the content mapped out. With a detailed set of completed wireframes, I created a style tile to outline all of my typography, color, and UI pattern decisions. I then semi-capped off the design process by bringing the wireframes and style tile together to create a set of high fidelity mockups in Sketch. I say semi-capped off because as I built out the site I continued to change aspects of the design, and I’m still working on some pieces now, months after launching.

The entire “design” process for this website took probably 2 or 3 months. You might ask, why not just throw together a quick mockup, call it a day, and worry about the content later? Content is king; a website without quality content is useless and design without content is simply decoration.

Taking a segmented design approach that is driven by content allows one to build exactly what a site needs, and in a very focused way. With content leading the way, I used my wireframes to establish functionality and the positioning of content. The style tile allowed me to focus on aesthetics, independently of content or layout. When I brought the wireframes and style tile together to create my high fidelity mockups, there weren’t any huge surprises and it just felt right. We’ve found the same thing to be the case with this segmented design process at Storyware – fewer surprises and a highly functional end-result.

WordPress on Bedrock, deployed with Trellis to Digital Ocean

Around October is when the real fun began; it was time to start developing this website. Back in the day I used MAMP for all local WordPress development. I’ve since moved into the world of developing on Virtual Machines with Vagrant. I have also become very accustomed to deploying via the command line as opposed to good ol’ FTP/SFTP cowboy way of doing things. I wanted to start developing my website on an infrastructure that would accommodate easy command line deploys and run on Vagrant with PHP 7.

At Storyware we use a custom vagrant setup with the Themosis MVC framework for WordPress which is great, but this was my time to play so I wanted to try something different and learn a bit. After much research and tinkering with various vagrant boxes, I discovered Trellis by Roots. Trellis gives you a modern WordPress LEMP stack, free SSL, a vagrant machine for local development, a very easy way to provision both local and production servers, along with simple command line deploys. Trellis literally accomplished everything I wanted, and then some.

Originally my site was hosted on a shared hosting account through my Go-Daddy reseller account, but for a multitude of reasons it was time to upgrade. Thanks to Trellis, deploying this new website to a lightening fast, inexpensive VPS in the form of a Digital Ocean Droplet was very easy.

Bringing Modern OOP Principles to WordPress with Timber and Lumberjack

With my infrastructure in place it was time to decide on a WordPress workflow. I’ve become very accustomed to the modern organization of WordPress that comes with using Themosis. When I decided to use Trellis to handle my deployments and provisioning, it was a no-brainer to also use the Bedrock WordPress Boilerplate from Roots. Bedrock manages the WP install and Plugins with Composer, and organizes WordPress in a very clean way. Bedrock and Trellis also fit together perfectly, as they’re both made by Roots.

With my development environment all set up and a design anxiously awaiting to be coded, I was ready to decide on a back-end workflow for my new WordPress theme. I wanted to use an MVC style approach to development, which Themosis does this incredibly well, but Themosis was out of the question due to my desire to experiment.

Over the past year I’ve heard a lot about Timber, which is similar to Themosis in the sense that it lets you separate logic from presentation and avoid writing vanilla PHP within view files. Themosis uses Blade syntax, whereas Timber uses Twig – something else new that I wanted to investigate.

I ended up working with Timber and creating a custom theme largely based on the Lumberjack theme from RareLoop, and Sage by Roots. I chose to use the name-spaced, OOP approach used for organizing logic in Lumberjack, and the Webpack powered build system used in the latest beta version of Sage.

Flexible Content Blocks

Instead of crafting WordPress “templates” I’ve spent a lot of the last year and a half crafting re-usable blocks using Advanced Custom Fields’ flexible content field. This shift towards creating components that can be used throughout a website has been monumental for us at Storyware. Taking this lego-like approach, I developed a set of “planks” or blocks that make up the various UI components of my WordPress theme named Wood. Crafty naming with “planks” and “Wood,” right?

So what is the significance of these plank components? Let’s look at the home page. Each section is a block that can be dragged and dropped on any page of my website, and each section has a number of configurable options. Here’s a screenshot of the home page admin screen:

When I expand one of the planks, I see a variety of options depending on the plank. Take a look at this screenshot of the “Posts” block on my home page:

I can specify various text fields, and I can get highly specific with the posts that I would want to display here: I can limit the latest posts to a certain number, to a specific category, a specific tag, or a combination of a category and a tag.

I took the same approach with the Projects block, where I made it easy to manually select specific posts from the project custom post type:

In terms of backend-logic, each Plank has its own Class where we define logic based on the values in Advanced Custom Fields along with the associated view file to be loaded. Using Illuminate, it’s very easy to create a collection of our planks on a page, and then simply iterate over plank’s view in the collection. See below from my PlankPage class:

<?php

namespace Wood\PostTypes;

use Illuminate\Support\Collection;
use Wood\Planks\Planker as Planker;

class PlankPage extends Page
{

  protected static $postType = 'page';

  public function planks(){
    $planks = get_field('wood_planks', $this->ID);

    if(is_array($planks)){
      foreach ($planks as &$plank) {

        $plank = Planker::createPlank($plank);

      }
      return Collection::make($planks);
    }
  }
}

These blocks may be a bit overkill for a small personal website like this one, but they sure are useful for delivering robust design systems to large organizations.

Atomic CSS

I’ve also been architecting CSS and HTML in a bit of a lego-like way for a while ago. About two years ago I realized that I was tired of overriding html heading sizes through clunky CSS modifier classes and so I started investigating alternative approaches to applying styling. I read about basscss, and similar atomic-ish CSS frameworks, and soon after saw a talk on taking an atomic approach to CSS at Full Stack Toronto. What do I mean by an atomic-ish approach to CSS? Crafting very specific, low-level CSS classes that do just one thing very well. Here’s a hypothetical example:

<h4 class="u-heading4 u-fontPrimary u-colorAlpine u-textUppercase">Hello World</h4>

The idea of chaining several CSS classes onto an element used to seem crazy to me. Then I gave it a shot and my mind was changed overnight; I’m able to build new features faster and spend way less time feeling like I’m wrestling CSS. My stylesheets are also dramatically smaller as I define common styles related to font size, font style, margin, padding, and color one time.

I haven’t gone 100% atomic in my front-end architecture approach, as I feel this would make it difficult to build some more complex components. For the components that do require some new CSS, I follow the SUIT methodology.

Fluid Typography Size

Responsive Typography has been something that’s felt quite hacky to me for a while. Typically for client websites, I’ve been setting a mobile heading size first, and then increasing that font size with a media query around 480 pixels or so; a fairly common practice. Then I saw Sara Soueidan give a talk about the recent Smashing Magazine Redesign in Barcelona where she went in depth about using flexible typography; setting max and min sizes based on viewport and letting the typography literally scale with the screen. I found this intriguing and I gave it a shot here. To see this in action (on desktop), take the corner of your screen and adjust the size of the window. Here’s a code snippet:

.size-h1{
	font-size: 36px;
	font-size: calc( 36px + (48 - 36) * ( (100vw - 400px) / ( 800 - 400) ));
}

In the above we’re basically saying the text should scale between 36px and 48px over a viewport range of 400-800px. For further reading on flexible typography, check out this post from Mike Riethmuller.

Advanced Caching with WP-Rocket

It’s common knowledge that loading a page in WordPress requires making a number of database queries, which can make for slower that desired page load times. Thanks to the WP-Rocket caching plugin, you’re viewing a cached, static version of this website; aka it’s pretty damn fast. If you haven’t checked out WP-Rocket before, I’d definitely recommend taking a look. It’s crazy simple to setup and the performance gains are quite nice.

Wrap Up

For the first time after building website for myself, I can say that I’m fairly satisfied with the majority of the code behind this site. As a matter of fact, feel free to go dig around in the code: https://github.com/pagegwood/pagegwood.

I began this project determined to take my time and to use it as a fun, learning process and I’m really glad I did. It only took 9 months to complete. And then another 4 months to finish this blog post 🙂

Still on the to-do list:

• Refactor sticky header
• Improve design of these blog articles
• Update the Photo archive
• Refactor prefix replacement in Planker class
• Add a search feature, and expose plank field data to search
• Cleanup atomic.scss file
• Integrate Purify CSS into build process

And more….