On building a new Uptrends website

For the last couple of months, a couple of my colleagues and I have been working on a new version of the Uptrends website. And now that it’s live, I wanted to make some observations on the process we went through and my role in this project.

Wait what, from scratch!?

Yup. I’m usually not really into that kind of stuff. However, this time, there wasn’t really a way forward with the old setup. Let me explain:

• Content editors were having a hard time editing content. The CMS we used provided its editors with a complete WYSIWYG editor, which allowed them to edit the page HTML when necessary. However, to get the content to play nice with the layout, they often had to. We wanted a system that allowed content editors to focus on content, not layout.
• We couldn’t version content. We wanted to control when pages or changes were publised because of their ties with changes in our product. This was hard to do with the CMS (Content Management System) - so we copied the complete CMS with all its contents to the production server once every couple of weeks as a means of “releasing”. It worked - but it definitely wasn’t optimal.
• The content lived in the CMS. As per industry standard, the CMS we used allowed its users to edit the content, but kept tight control over where that content lived: inside the CMS. We wanted to move content editing to a more git-based workflow, which was impossible with the CMS we had.
• The CMS we used was outdated, and updating was a pain. This wasn’t necessarily an unfixable problem, but it was a catalyst for this project. We wanted to be fast & safe.

Out with the old, in with the new

After a thorough search and selection process, we ended up with GoHugo. GoHugo is not a CMS but a Static Site Generator, which means all dynamic content is resolved on build time, and a set of static files and resources is deployed to the website servers. Simply put: all the work (like calculating which content should be in the requested page) is no longer performed when the page is requested, but during a build process. The results of that build process are deployed to the server as static files - hence the term Static Site Generator.

Another benefit of GoHugo is its separation of content and layout. Content lives in MarkDown files, that are merged with theme template files in the build process. And since the content now lived in text-based files, we could put them in Git!

Some other benefits of GoHugo were its built-in ability to support multi-domain websites, the ability to easily crosslink pages between those domains, and its support of SASS and TypeScript for easier frontend development.

One of the brilliant features of GoHugo is the concept of shortcodes. Basically they are small chucks of HTML that can be included in a MarkDown file. These shortcodes allowed our content editors to be able to dicate some of the page layout, without getting into specifics. They’d use a shortcode to indicate text with an image beside it, or a couple of blocks of text in a row - or even more advanced features like our pricing comparison table or a signup form - all without having to write or maintain that HTML! It provided us with the flexibility we wanted, while maintaining a separation of concerns between content editors and site developers.

Retrieving our existing content

Since our existing content lived in HTML files, and we wanted to convert them to MarkDown, we had to come up with a plan to extract the existing content from the website.

We basically built a scraper tool that visited all our website’s pages, based on the sitemap, and converted its content to MarkDown using PanDoc, an automated conversion tool. It allowed us to not only convert the text, but also recognize components and specific layout structures and output them as GoHugo shortcodes.

An extra challenge for this tool was that this project took over five months, and the current website was still active in this period. Therefore, we had to run the scraper tool regularly to keep the new site up to date with the latest changes from the current website.

How I helped build the new website

I was one of four people working on this project. I spent most of my time implementing extra rules for the scraper tool and writing JavaScript for the pages with dynamic content, like the checkpoints overview page. I’ve written about half of the GoHugo shortcodes used in the project and was heavily involved in the integrations with our product, like signup forms and free tools. I also helped develop the new brand identity that was released together with this new website.

In hindsight

If we were to do this all again with everything we know now, I’d advise against releasing the brand identity with the new website. Those two projects partially required the same team, causing a strain on the team members and making the projects more complicated than they had to be.

All things considered, I’m really proud of what we pulled off, especially with the existing site changing regularly while building the new site. The new site looks fresh, is lightning fast and super maintainable. Check it out on uptrends.com and let me know what you think!