Developing the custom WordPress theme with Amber, Evan, and Corey November 24, 2020 | Deep Dives, The Simpatico Blog

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.

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.

Accessibility is really important to us, and the last version of the site (a quick template we had thrown together as the business began) didn’t reflect that at all. We made sure all of the animations were in a reduced motion query, (so users who had that turned off on their computers wouldn’t get any of the animations) which can help people who have vision problems or who are prone to motion sickness or seizures. We made sure all of our images had descriptive alt attributes, and that the HTML had proper hierarchy in regards to headings and semantic HTML. We also made sure the entire site was navigable by keyboard and ran several accessibility tests to make sure the site would make sense to someone navigating with a voice assist program. Another important factor to us was website speed – part of accessibility is making sure users on slower connections or with capped data could enjoy the site as well. We had to go through the site a couple of times to really make sure all the images were high quality, but optimized, and that we weren’t using any chunky Javascript that could break or slow down the site.

Amber’s the Accessibility Queen, so my job here was mostly to avoid breaking her work. 🙂 I will echo what Amber said on avoiding excessive JavaScript. JS is my great love in web development so I often want to use it, but it’s important to employ HTML/CSS solutions whenever possible to prevent unnecessary code bloat.

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.

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.

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.

Before going into development, Sinan and Bruce had a general idea of the animation style and its implementation. We worked together on translating that style and Principle mocks into a comprehensive set of animations utilizing CSS and JavaScript, when needed.

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.

All of us had some hand in the animations. I did a few versions of the squiggles and the ‘simpatico’ horizontal parallax you can see in some places, like on the Perspectives page. I always start out trying to do our animations in CSS first – which is what the squiggles are done in. This makes loading times faster and is a lot less likely to break than Javascript. The ‘simpatico’ parallax was done with one of my favorite JS plugins, skrollr.

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.

We always use CSS first before thinking about JavaScript for animations. We utilized JavaScript with our custom JavaScript scroll library, JazzyScroll, for triggering scroll animations (where the animation itself is done in CSS!)

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!