Earlier this year, we decided to update our company website. We wanted to update the graphic design and publish more content to reflect all the work we have done in the past few years. The only catch? We don't have a web designer on staff! In this post, I will explain how we treated the website like a software development project.
This was the first big change to the website in over four years! We had several goals to accomplish with this rebuild:
- Update the graphic design.
- Expand content to reflect everything we have been working on.
- Improve overall speed and handle spikes in traffic.
- Simplify the drafting and publishing process.
In short, this was a complete overhaul! The last website build was outsourced to a web design company, but this time around we wanted to do it all in-house. As I explained at the outset, we do not have a web designer on our staff, but we do have a team of software developers and a graphic designer. I suspect that we are not the only small software company to be in this position, so I will explain the decisions and process we used to build the new website.
But first, let's look at the results! Our old website is displayed on the left and our new website is displayed on the right.
As you can see, the new site is cleaner and more colorful. It also has shorter and more scannable text blocks. Yet it retains some of the feel of the original. By moving away from a single-page design, we were able to move content off of the home page and onto new pages, like About Us and Open Source. This doesn't just free up space on the home page, it also gives us more room to dramatically expand those sections on their own dedicated pages.
Of course, the first step is to come up with an overall design for the website. This step includes both graphic design as well as the "information architecture" of the new site, i.e. what pages it will have, what navigation links it will have, etc. After planning out the pages we would need to create ahead of time, we created a list of requirements to guide the new graphic design.
Given our budget and personnel, it was clear that we would need to customize a pre-made theme rather than build our own theme from scratch. If you search google for terms like "bootstrap theme", you will find hundreds of different themes available—some free and some paid. After screening a handful of themes, we selected one called Material Kit Pro, which is loosely based on Google's Material Design language. We liked the modern, minimal, and colorful feel of this theme. We especially liked all of the included example pages, which saved us a lot of time on designing our own page layouts.
Screenshot from the Material Kit Pro demo.
We set to work customizing the theme and migrating our content from the old site into these new templates, but this process led to some new challenges:
- How should we collaborate on the website?
- How do we draft and publish content?
- How do we make sure that shared elements like the navigation bar and footer are the same on all pages?
This is where our software development background comes into play.
We decided early in the project to commit to building a static site, i.e. a site that has no dynamic server-side software. This decision rules out using a content management system (CMS) like Drupal or WordPress, which would typically have the templating, drafting, and publication features to solve the problems posed in the previous section.
On the other hand, a static site can be very fast and cost-efficient to run, and it also eliminates entire classes of security vulnerabilities. Is there a way to combine the advantages of a CMS with the performance and security of a static site?
As it turns out, there is an entire ecosystem of "static site generators" that address this very problem. In fact, there are so many static site generators that deciding which one to use is overwhelming! There is an entire website dedicated to tracking static site generators, and right now it lists 226 projects!
A static site that lists static site generators!
We tried out a few static site generators that ultimately didn't work out before settling on Hugo, which is a static site generator written in Go. Hugo is very flexible and the project has a large and active community behind it. Hugo also claims to be the fastest static site generator, which wasn't a major concern for our small website, but it is a nice benefit.
The downside to Hugo is that it is quite complex. Hugo has a lot ofeatures, and it expects you to structure your website a certain way. If you want to structure your site differently, then you face a steep learning curve. We puzzled over Hugo for quite a bit while figuring out to make it do our bidding. Fortunately, Hugo has a good discussion board and a very active GitHub where we were able to find answers to most of our questions.
Directory layout and base template for hyperiongray.com
The screenshot above shows a bit of how we are using Hugo. Instead of a pre-made Hugo theme, we modified the Material Kit Pro theme and inserted it directly into our Hugo templates. The template shown here is called
baseof.html which for Hugo means the root template: all pages are rendered from this template. This example shows a bit of Go's templating language used to pull in the nav bar and footer markup from separate files.
Hugo has a built-in development server that we can run locally to preview our work. It rebuilds each file as soon as it is saved and refershes the page so that the change is visibile immediately, which is really a big time-saver for writing new content. Hugo natively supports drafts so that we can share content with teammates without publishing it to the live site.
The Hugo server refreshes the page after every save.
Finally, we chose GitHub to manage the collaboration and sharing between team members. Git provides version control and a simple form of backup. For the software developers on the team, Git is a very natural way to manage the source code for the website.
At this point, I (Mark) will yield the mic to DD, our graphic designer and renaissance man, so that he can describe his perspective on this web design process. DD does about a hundred different things for our company, but the most visible work he does is our graphic design, including our awesome company logo, project logos, and employee avatars.
Graphic Designer's Perspective
DD: Being far and away the least programmer-y member of the HG Gang, the website project was a bit like (forgive the cliché) drinking out of a firehose. I hadn't the foggiest of ideas as to how the web designing process went, and a cursory understanding at best of HTML and CSS, so when the project was handed to me, I felt more than a little underqualified.
But that's not to say that I didn't enjoy it! In truth, it felt like sitting astride a vehicle completely alien to me, facerolling the buttons and switches, and finding out what works and what doesn't. It didn't take very long to get a handle on how to make the vehicle creep forward, but creeping forward was such a tiny facet of what the vehicle could really do.
I was (delightedly) forced to learn more about the craft in order to do more things; my simple knowledge could only take me so far. With the help of the Guru, himself (ahem Mark), I was able to get all the freakin' neat tools just described and get to dancing. It was a constantly engaging and enjoyable (albeit sometimes unnecessarily frustrating) experience, getting to watch a website come to life with a few lines of code and an <href>, an <img class>, or a <div class>. I won't lie, I sometimes felt like I was on the cutting edge of technology, whipping around a wild and uncharted frontier on my mysterious vehicle of which 'nobody knows the true extent of its power'… Then I'd bog down on something and ask Mark for help, and it would be as simple as a misplaced semicolon or a misspelled word. -.- I may have come far, but I've still a long way to go.
Mark: Hey, I'm back!
We hosted the old site on a small virtual server with Nginx. That setup worked surprisingly well for us. Our normal web site traffic is pretty manageable, but occasionally we get bursts of traffic. In March, for example, we got 60,000 visits over a 2-day period after publishing our Dark Web Map. Remarkably, Nginx kept running smoothly through this burst of traffic, but it certainly made me nervous. And as good as Nginx is, serving our site from a single point in the US led to slow load times in other countries.
We really wanted to improve scalability and overseas load times, so moving our static site to a CDN seemed like a good move. We use a lot of Amazon Web Services here, so the first approach we tried was to upload the files to an S3 bucket and serve the site with CloudFront, which is Amazon's CDN. CloudFront has a lot of options—most of which we don't need—so we experimented with the configuration by migrating our hyperiongray.beer property over to CloudFront first. Once we had all of the kinks worked out, it was really easy to move hyperiongray.com to CloudFront, too.
Deploying the website is also really easy, thanks to Hugo and the AWS CLI:
~/code/hyperiongray.com$ rm -fr public ~/code/hyperiongray.com$ hugo build ~/code/hyperiongray.com$ aws --profile hg_website s3 sync --delete public s3://www.hyperiongray.com
Hugo builds the entire site to the
public directory, which we clear out to ensure there are no stale artifacts from a previous build. The
aws s3 sync command will only upload files that have changed since our last build and the
--delete flag will remove files from S3 that no longer exist in our build tree, which makes this a very efficient way to deploy incremental changes.
We haven't done much optimization on the new site's load time yet, but thanks to the CDN, the new site loads as quickly as the old site for users in the U.S, and overseas users have much faster load times. In addition to better performance, scalability, and security, our new site also costs less and requires less of our time to manage. Overall, our first foray into static site hosting has been a really successful!
Do you have any static site wisdom to share with us? Let us know @HyperionGray