A few weeks ago, RevUnit launched our new website and blog. This is the third version of our website in about 3 years, the previous versions had grown a bit stale from a content and design standpoint and needed some refreshing. In this post I want to describe the technical aspects of how we built the website and blog, and give some insight into the decision making process we went through along the way.
What did we want to accomplish?
We’ve all heard the phrase “use the right tool for the right job”. As the CTO I’m often in the position of choosing how to go about using the “right” technology to solve for a business problem. The first step in that process is truly understanding the business problem itself.
As a company, we defined our two target markets as potential clients and current or future job seekers. We drilled down even further from there, but that’s more detail than I’ll go into in this post.
So, with our market defined, we outlined our primary objectives:
1: Clearly Communicate RevUnit’s Capabilities
What we do is sometimes a bit hard to articulate. We’re part innovator, part creative, part dev shop, and part marketing agency. We wanted to make sure that site visitors can understand the full breadth of what we do at RevUnit.
2: Provide Clear Paths to Contacting Us
Nothing surprising here. If someone likes what they see on our site, we wanted them to be able to quickly and easily contact us.
What tactics help us accomplish those objectives?
To accomplish those objectives, we felt like we needed a few things. First, we needed to be able to create some semi-permanent content around things like our services, our processes, our team, company values, etc. This content will be updated from time to time (“Iterate often” is part of our mantra after all), but for the most part it will be relatively static.
Next, we needed to have a blog to post ongoing, timely content that doesn’t necessarily fit into the hierarchy of the site. We also wanted the ability to quickly create targeted landing pages.
Lastly, we needed very clear calls to action and ability to get in touch with us through various channels.
What platform(s) best help us achieve those tactics?
First, we knew we wanted a completely custom design for the bulk of the website, and we wanted to make sure we had very little limitations imposed by our platform. Given our web team typically uses Ruby on Rails as our web framework of choice, we had a strong bias towards building the primary content of the site within Ruby on Rails. That would allow for maximum flexibility and would mean I would never have to say “Sorry, [insert platform name here] doesn’t support that functionality”.
For the blog, however, we went a bit of a different direction. Our Marketing and Metrics team members would be the primary blog users. So we wanted to use a platform that gave them access to all the authoring features to which they were accustomed as well as a well-tested, mature blogging platform. Also, while the website’s primary content was custom-built by our dev team, we knew occasionally the Marketing and Metrics team might need to create a number of landing pages for specific types of content. So while we absolutely avoid WordPress as a development platform or as the foundation of a large-scale build, we felt like this was the perfect use case…that is using a blog platform for the creation of a blog.
Let’s dive into each of those individually…
The Website: Ruby on Rails
As I mentioned, we chose Ruby on Rails as the platform for building the bulk of the website. As you’re browsing the site, if you’re on http://revunit.com, then you are viewing the Ruby on Rails site.
Lets go from the back-end to the front-end. First, we host the majority of our properties on Heroku. It’s hard to beat the price and simplicity if you’re dealing with relatively low-traffic properties.
Next, for most of the static pages, we used the High Voltage gem from Thoughtbot. I’ve seen a lot of approaches to static pages within Rails apps, but this seems to be one of the cleanest and simplest I’ve come across. Basically, this gem lets you create views for your static pages without having to concern yourself with routing and controllers as the routes are inferred from folder and file naming.
We also used another interesting gem called NavLYNX to help with highlighting the current page the user is browsing. For example, if you navigate to http://revunit.com/services/services-business-strategy, you’ll notice that both Services and Digital Business Strategy are highlighted. NavLYNX handles adding the “selected” CSS class for you if it determines that the user is currently on that nav link’s page. That wouldn’t be hard to write, but we’re always happy to save some effort and use someone else’s well-tested code when possible.
Given that most of the site is static pages, there isn’t a lot of really interesting Ruby code. The Hire Us form is a pretty straightforward form using the Simple Form gem and a mailer on the backend. The blog post that gets pulled into the bottom of the home page was an interesting challenge. We could have chosen to use RSS or some other way to basically scrape the latest post from the WordPress site, but we ultimately went with WP REST API plugin to expose the data from the WordPress blog via JSON. From there, we just grabbed the latest entry and made sure and cache that so as not to make each user wait for the API hit to WordPress. We had to do a little cleanup on the encoding, but so far so good.
I mentioned the Hire Us form being a pretty basic mailer form, but we all know email can be unreliable. So, we plugged in a relatively new admin platform called Administrate. We’ve used Active Admin for quite a while and wanted to try Administrate to compare and contrast. Each Hire Us submission in addition to being emailed to a group alias is also saved to a database and accessible via Administrate. In order to lock down Administrate to only our team, we used omniauth and omniauth-google-oauth2 to require Google logins to access the form. Basically, if a user logs in with a revunit.com Google account, we let them in. Eventually, we could go deeper into roles and permissions, but this is working great for now.
On the front-end, it’s pretty straightforward. Most of the styling including the grid was hand-rolled. We used Wistia for hosting the home page video as it seems to offer better load times and provides a variety of valuable analytics on the backend. We plan to do more with video on the site in the coming days, so wanted to go with a professional-level provider. We stuck with the tried and true Google Analytics for web analytics as that’s a pretty standard decision for us given the breadth of capability and our team’s experience from implementation to analysis.
The Blog: WordPress
Any of the pages (including this one) that are on the http://blog.revunit.com domain are part of the WordPress blog. We wanted an attractive site, but mostly wanted to focus on the content. The Creative and Marketing and Metrics team chose a highly-customizable template, and we refined from there. There weren’t a lot of code-level customizations, but the team is using a number of plugins and tooling to improve content creation and optimization.
As I mentioned above, we are using WP REST API to expose the content to our website.
We are also using the AMP plugin to create AMP-compatible versions of our pages. You can see the AMP version of this page by navigating to [current-page-URL]/amp. The AMP Project is still in its infancy, but something we’re keeping an eye on and want to support from the beginning. Maybe we’ll tackle that topic here in the future.
Next on the list, we’d like to work on a few things. First, we want to integrate phone call tracking to better understand which pages are converting to phone calls. This entails using a tool that creates dynamic phone numbers that will track users’ locations when they choose to call us, and we’re looking forward to digging into that data.
We also have plans for using a bit more video to spruce up the home page. When we created the RevUnit Brandumentary video, we created a lot of great footage we want to utilize to better and more creatively communicate who we are.
Finally, we’re looking forward to more tightly integrating our job openings. We’re using Workable and they’ve got a great API that would allow us to more tightly integrate with our site as opposed to bouncing people out to our existing jobs page via Workable.
So far, we’ve been pleased. Our search traffic is up due primarily to the increased richness and density of content. We’re relatively pleased with the conversion of users contacting us although that’s obviously an area to improve on.
Most importantly though, we feel like (and have validated with others) that it better meets our objectives of sharing who we are and what we do with others. One of our values at RevUnit is “A little better all the time”, and we’ll continue to improve, but we’re pleased with the results.