To kick off 2017, we’re excited to launch our new website!
We loved our previous website, but we found that it was a pain to maintain and update. This became a big problem when we went through our rebrand, which required us to completely overhaul our website. Instead of trying to work with the old site, we decided to start from scratch and build up something even better.
We formed a special team with 2 engineers, 2 designers, and 1 content writer, all working toward a single goal — finish the whole site, from empty codebase to full launch, in just 1 month. The website, which we already had mockups for, contains over 20 pages, dozens of uniquely designed panels, dozens of pages of written content, and hundreds of graphic resources.
Everyone Works With the Code
We knew from the outset that we wouldn’t be able to meet our timeline if we strictly separated design tasks from engineering tasks from content tasks. Instead, we took the time to make sure that any type of task could be completed by anyone on the team.
From the very beginning, everyone — engineers and non-engineers — worked with the code.
This went slowly at first, since some people on the team had never used HTML or CSS. But it was worth it. Now, if Christine (a content writer) needs to add a new html content page or change the link title in a menu, she knows how to. If Sahaj (a graphic designer) needs to experiment with a new color scheme or adjust the page spacing within the CSS, he isn’t dependent on anyone else.
We organized our team and project structure from the ground up to facilitate collaboration, not dependence, between team members. By using Git to store source code and track revisions, Quip to track tasks and bugs, and Slack for team-wide communication, we were always on the same page about how the website was being built and what needed to be done next.
Do it Right the First Time
At the beginning of the project, we had two options.
- Begin with the landing page. Finish it. Move on to the next page, and repeat until the website is done.
- Build a solid foundation, stylistic toolbox, and set of conventions to build all of the pages. Then divide and conquer.
Obviously we chose the second. In the first few days of the project, we did not begin any pages. Instead, we focused on making decisions as a team for how we would go about building the pages, and what steps we could take at the beginning to minimize our effort in the future.
Building a website is like building a house — without a solid foundation, the whole thing will inevitably fall apart.
We started by writing a lot of CSS, both utility classes and specific elements, that we knew would be repeated often throughout the site. We also established standards — such as where to use specific html tags, heading types, fonts, and colors — to make sure that the whole site would be be built consistently. By using SASS, we were able to use a shared set of variables and mix-ins for margins, media-queries, and color values, making global changes extremely easy.
One of our goals for the new website was first-class mobile responsiveness, and this goal helped to influence many of our decisions in that first stage. By building repeated page components and styles with a mobile-first philosophy, we could confidently build pages knowing that the layouts would automatically scale across different screen sizes.
Keep it Simple, Stupid
But why would we need to use any of those? Our goal was simply to build a static website.
All we needed was the simplest option, which would minimize the engineering complexity of the website and increase our productivity. That’s why we chose Hugo, a simple static website generator.
Hugo can generate a website from directories of content pages and layout pages, all just written in plain HTML with basic markup features. This gave us the simplicity of a framework-agnostic HTML/CSS/JS website, plus some added benefits — auto-generated sitemaps and metadata for SEO, and being able to write reusable blocks of HTML for page elements like navbars and footers.
Using Hugo, we were also able to improve the experience of working on the website. We segmented the HTML, CSSS, and image resources for each page into separate tightly-scoped files and folders. This made it very easy to make adjustments and find specific blocks of code, even if a team member had not worked with that specific component before.
We spent a lot of time optimizing the website for speed, efficiency, and responsiveness. In every step, we embraced a team-wide principle: arguments are good.
Every optimization is a trade-off, whether it’s spending more time writing and debugging CSS to avoid importing a bloated framework, or applying lossy compression to images to improve their load speeds. Since each team member was directly involved with all aspects of the website development, we were able to discuss each optimization as a team, weighing all the differing perspectives to make the most balanced decision for each choice.
We took the same approach with CSS, being very wary of new libraries and frameworks and always asking “Do we really need this?” Since our website is completely based on custom-designed mockups, using a framework was largely unnecessary — we would have to override most of the default styles anyway. That’s why we wrote the majority of the CSS styles and utilities ourselves. The only CSS library included in the project is “normalize.css” to reduce the headache of cross-browser compatibility.
We used a Gulp build process for all of the standard optimization tasks, such as bundling and minifying resource files, adding cache-busting hash suffixes to revised files, and auto-prefixing CSS properties for cross-browser support.
Regularly throughout all stages of development, we tested the website in a variety of environments. We all prefer Chrome for general debugging, but navigating through the staging website on Firefox, Safari, and Internet Explorer was essential, as was testing directly on iPhone and Android devices. Without these regular checks we would have had a ton of responsiveness issues to fix at the end of development, or worse, once the website was already in production.
To measure our progress with optimization, we set specific metrics using quantitative page-speed tools such as Google’s PageSpeed Insights and Lighthouse tools.
We are happy to report that, as of launch, our website currently holds a 99/100 on Google’s Lighthouse test, which measures everything from page-load speed to mobile responsiveness.
Further optimizations require real user data and cannot be done before the site is launched. So we integrated Google Tag Manager for analytics and A/B testing, and Hubspot for user-submitted forms, to help make these future optimizations in a data-driven way. The benefit of these tools is that their behavior can be configured directly from online admin dashboards, so we can run quick iterations without changing the codebase or worrying about clearing browser/server caches.
Save the Fancy Stuff For the End
We even added a “Progressive Web App” service worker to store resources in a special cache and make our entire website work offline! More about that soon 🙂
This is far from the end. We already have plans for some improvements and new pages — some nice and easy, and some slightly more idealistic — in the next couple of months. But we’re not worried.
We now have a toolbox of reusable elements and panels, all of which are superbly responsive, plus five people who know how to dig into the website code and make whatever changes we need. With this foundation, all future maintenance and changes should be a piece of cake, so we can move on to even more exciting things!