In 2023, we at Sparkbox have had some opportunities to work on ourselves–and by that I do mean we worked on Sparkbox.com.
For us to share how really, truly wonderful this new launch for us has been, I’m going to have to “air our dirty web technology laundry” a bit. Just between us, it was a well-engineered mess. We all know that a web agency’s website is the last thing that gets attention, and Sparkbox has been around for well over 10 years at this point. That’s a lot of time to keep a website running and updated (likely with duct tape and inline CSS).
So at the end of this, remember–the people at Sparkbox are extremely talented web designers, engineers, and project leadership who create elegant solutions crafted specifically for our clients’ unique needs and priorities. And when that client is Sparkbox itself, the solutions are to build the most sustainable thing possible with the fewest changes and the least amount of people. It’s a good thing! Really!
How it Started
I’ve been at Sparkbox for a long time. I’ve served as an individual contributor on our 2016 website redesign, and then a 2018 refresh. In 2020 I acted as technical lead for a full redesign (the design we mostly still have today; I’m particularly proud of the Work page hover animations.). Over the past year or two, I’ve stepped in here and there in my role as Technical Director to fill a need when it arises. I didn’t architect any of this rebuild, but I’ve worked on practically all of it in small ways here and there. Just like most of our team has throughout their Sparkbox tenure.
For the vast majority of our time online, Sparkbox.com (and seesparkbox.com before we acquired our real domain) has been running on ExpressionEngine (EE). EE is a traditional CMS, supporting not only our Marketing Pages (the stuff about our team and experience), but also The Foundry, a robust web content blog with about 750 published articles.
EE served us well for many years, but as time went on, it has grown out of favor in the web community in general. The clunky setup to run the application locally was improved by the addition of Docker, but still took our developers new to the project significant time to get it up and running the first time they were assigned there. People new to our team and unfamiliar with EE had a large learning curve to start contributing, and sparse documentation wasn’t much help. And, as we implemented quick and dirty changes to get things done, the codebase’s documentation grew out of date.
This all meant that our team was not well-equipped to make changes and improvements to the site. Our Outreach team, the people at Sparkbox who are the Product Champions of Sparkbox.com, grew frustrated with their inability to keep highlighted content up to date and interesting for our readers. While our dev and UX/UI teams were busy with client engagements, the website gained only incremental fixes–mostly when we onboarded a new team member in the weeks before their first client work.
Something had to change.
Building Frankenstein’s Monster
A common adage in the development community is “perfect is the enemy of good.” Our team of experts is incredibly passionate about building a better web, and this meant that our development decision-makers, myself included, were difficult to compromise with. We wanted our website to be technically perfect. But our development team is not and was not the Product owner of Sparkbox.com–that is the Outreach team. And the Outreach team needed the ability to rotate content on our marketing pages.
So we found a compromise. The Good. The old EE site was a pain point for everyone, but the Foundry itself worked pretty well, so we focused on identifying new options for the marketing pages specifically.
We settled on Webflow, a website builder that provides a design tool interface. Our Outreach team at the time had the ability to work in Webflow themselves, and they had capacity our development team did not. Yes, some of the engineers on our team had difficulty coming to terms with the idea that we’d use a website builder when our job is literally to build websites, but most of us eventually saw the economy of this idea.
The Webflow solution worked from a technical perspective. This is one of the areas I personally contributed to, learning to build interfaces in the Webflow designer. There were drawbacks, like difficulty in creating an accessible mobile navigation that didn’t match the known pattern anticipated by Webflow’s team. However, Webflow does provide quite a bit of flexibility in adding custom HTML, CSS, and JavaScript code. It also has one of the most user-friendly CMS content entry systems I’ve seen. Overall, it was a solution that met the needs of the Product Owner, and that’s a win from my perspective.
The tricky bit, and as I’ll call it, “Frankenstein’s Monster,” is that we needed a hosting solution for both the Foundry built on EE and our new marketing pages built on Webflow. We set up a proxy via Cloudflare, which rerouted traffic to the correct pages using a complicated setup that was difficult to maintain (and likely not super SEO friendly).
We had redirects in three places. We had weird ghost pages on Rackspace (where we hosted EE). Different people knew how different parts fit together, and none of us knew everything. The website definitely worked–and worked well–but caused no end of questions whenever we faced a new hiccup. (How many technical directors does it take to renew an SSL Certificate? More than you think!) We started dreaming about a better web again.
A Better Sparkbox.com
What would we do with Sparkbox.com if we could start over? What would we build if we were our own client? We wanted an interesting technology that our development team enjoyed working on. We needed a codebase that was easy to learn and contribute to, so that our junior developers and new hires could contribute effectively. We wanted a simple deployment method without too many fragile pieces. Our pages should be fast, and most importantly, our Outreach team must have control over the content displayed on any and all pages.
Our initial goal would be just the Foundry, as it is the most often updated and on the oldest technology. A few members of our team created proof-of-concept work for those pages. We looked at Strapi, Next.js, Eleventy, and more. We eventually chose a performant, sustainable tech stack: Netlify, Next.js (and ISR), Contentful, and TypeScript. And we decided to jump. We went full steam ahead on migrating the Foundry to this new stack.
The biggest lift–and the reason we’d put off changing technologies for so long–was migrating the ~750 articles from EE into Contentful. But our team has done several successful content migrations now, thanks to the popularity of Drupal 7 and its recent end of life work.
If you are here for the full technical deep dive, Ben, the project’s Technical Lead, has written a detailed case study on our Foundry migration effort: Incremental Static Regeneration with Next.js Combines Performance with Accuracy by Ben Goshow.
Contentful is a quirky but powerful headless CMS that integrates well with our technology of choice (TypeScript, in this case). We’ve trained our Outreach team on entering content in Contentful, an overall better experience than EE. We initially launched this new Foundry alongside our Webflow pages using the same Cloudflare setup as before, just to change as few pieces as possible at a time. Changes to the codebase can be made by any Sparkbox developer, as it is built in our core technologies and extremely well-documented. We’ve even planned a viking funeral for our Rackspace server. So long, old friend!
Once the Foundry was migrated, the technical directors met and asked the question: what if we just moved the Marketing pages into the new package now? We still have the old static Marketing pages from before Webflow. Our Outreach team members had changed since the initial choice to move to Webflow, and it no longer made sense to stay on that platform.
We could start by migrating the static pages, launch so everything is in one place, and then iteratively make those pages dynamic as we had team availability to do so. Static marketing pages remove quite a bit of content control from the Outreach team in the short term, directly counter to one of our original goals. One of our core values at Sparkbox is iteration, and we love a good minimum viable product (MVP). Our stakeholders were willing to start statically, knowing that we could achieve dynamic content relatively quickly after working on the Foundry pages this last year.
So we migrated the rest of the pages and moved off Webflow.
The Sparkbox.com we have today is lightning fast, easily editable, and a dream to work on. This article? The one you’re reading right now? It’s the new system. The new Marketing pages will be launched over the next few weeks. It was a long road to get here, but our tenacious team kept the goal in sight, and we were able to accomplish everything we set out for.
Here’s to another 10 years of Sparkbox.com.
