Tell us about the technology you used to build the new site.
We wanted to keep things as simple as possible for both our current and future selves, so we started with the same custom WordPress theme we use for our client sites. For the CSS, we spent extra time making everything as modular as possible, so we could mix and match design pieces while still maintaining the right styles. This meant creating lots of CSS variables for things like colors, borders, shadows, the squiggles, and more repeatable elements across the design.
Just like Amber said, we chose our tech with an eye towards simplicity. That’s also why we chose WP Engine as our hosting platform. Whenever we’re building a fresh site for a client, we recommend them for their easy integration with WordPress sites. We’ve even helped a number of clients transition their existing sites from other platforms onto WP Engine.
As Amber mentioned, we start from our blank WordPress starter theme with useful global functions and snippets. We built upon the starter theme, using semantic HTML, PHP includes, advanced custom fields (ACF), and CSS variables, enabling our efficiency to create new pages. We put to practice a modular and reusable development system that made making new pages easier and aided in having multiple people working on the site at once.
Tell us about the collaboration aspect of having three developers working on the same site at the same time. What were each of your roles? How did you divide the work between the three of you, and was it difficult having three developers working on the same codebase?
I got the lucky draw on this project, and was able to spend the most time and energy on it, while Evan and Corey took care of all our client work. I tried to create a basic foundation so that they could hop in and out of the project as their schedule allowed, and that they would be able to easily pick up where I left off. Our coding styles have become so homogeneous, that a lot of times you can’t tell who wrote what. This allows us to code sites as neat as possible and makes updates to the codebase in the future easier.
Of the three of us I did the least work on this project, but I still managed to get a hand on the ball! I came in during our QA process to make sure the final product matched our designers specifications as closely as possible. Since I was looped in on the site’s architecture from the beginning of the process, it was easy for me to hit the ground running with QA.
Evan and I lagged behind a few weeks working on client work, while Amber created the custom fields, main styling, and responsiveness. I mainly worked on the bulk of the animations and interactions. Generally speaking, we made sure to work on different pages or components to all be actively working at the site at once without any merge conflicts. The squiggle was a big feature where all three of us had a chance to work on it throughout the project. We had gone through a few different ways of creating it, and each one of us took a stab at making sure it animated properly while working across multiple-lines and was sized differently depending on the heading size. The collaboration enabled us to find solutions and work on the parts of development we each enjoy doing.
What steps did you take to make the website more accessible than the previous version?
We wanted animations and motion to be a core part of the site, but recognize and understand that users might want the opposite. We added all of the animations, as Amber mentioned, to the ‘prefers-reduced-motion’ media query to adhere to the user’s preference. Part of optimizing for page speed and performance was optimizing the scroll animations. I worked on implementing a fairly new custom scroll plugin we call JazzyScroll, created for performance and efficiency, which takes advantage of the Intersection Observer API (if the browser supports it) or an array-based implementation based on scroll events and cached elements.
What was the hardest part of the coding process for each of you?
For me, the site was really really fun to code, but the difficulty lay in some of the fancier stuff the designers really wanted to do. Getting the animations and the sizes and shapes of the squiggles right were both really hard – especially when it came to making sure the CSS was modular and repeatable, and that we weren’t just adding a bunch of superfluous elements to the code.
Yeah – the squiggles were surprisingly challenging. Text underlines, believe it or not, are usually straight lines! We ultimately used repeating SVGs to achieve the infinite wiggling squiggles, and we’re resizing them on a variety of screen sizes to make sure they work regardless of the size of their corresponding text. Sometimes appeasing the designers can take a lot of work, but I have to admit…it sure looks good!
Sharing one codebase always offers its share of challenges, albeit fun ones, where we had to merge correctly in git and ensure that we did not repeat any code blocks. Back to the squiggles — we had gone through a few different ways of creating it, and each one of us took a stab at making sure it animated properly while working across multiple-lines and was sized differently depending on the heading size.
How did you collaborate with designers on the animations?
Animations are usually the most difficult part of the site, especially when you’re not sure exactly what you want. There was a lot of back and forth here for things like the squiggles, hover bounces, and parallax words. Sinan usually makes an animation mockup for us that makes translating it to the web a lot easier, but we’ll also sit down together and go back and forth fine-tuning things like the ease and timing.
Very closely! My work on the QA process meant that I was talking directly to our designers to make sure my changes had things pixel-perfect. Bruce and I actually had a few Zoom calls where I was making small adjustments in real time with him, just to make sure everything was just right.
The toughest part was translating the spring easing motion Sinan had used in the mocks. It became quickly apparent that replicating the spring function would not be possible using “transition-timing-function.” What we thought might break the whole idea of a bouncy, spring-like motion turned into us racing to find the perfect cubic-bezier timing function that ultimately turned the original motion into what we now refer to as StiffSpring™. It has the intended bouncy and bubbly movement while being contained, which ended up fitting right in.
The site has a lot of easter egg animations - how were they accomplished?
Like Amber said, the squiggles are done using CSS! We have an SVG set as the background image, which we repeat and then animate using CSS Keyframes. Using an SVG allows us to resize the image on different screen sizes, which create different thicknesses to match the different font sizes.
Is there anything you wish you could improve now, or in the future?
I’m really, really proud of the fact that I was able to take some extra time to optimize a lot of the code – especially in regards to elements that are reused more than once or twice. Since we’re currently rolling out the new site in stages, it’s nice to know that the site never really has to be “done” and we can keep editing and optimizing as we find things.
Really, the best part of the modular system that Amber created is that it can be improved and adjusted. There’s a wide range of possible pages that we can easily construct now, and if we ever determine that we need a new module we can easily build it to fit with the existing system. Having said that, I’m really happy with the site as it stands now!
This site truly shows how much of a collaborative effort and team Simpatico is. As Amber said, we are constantly iterating on our site, so I know we are all looking forward to taking advantage of the modular flexibility built into the WordPress admin and codebase while also adding new features.