DEV Community: Chris Gustin

How was your week? - March 1, 2024

Chris Gustin — Fri, 01 Mar 2024 14:49:23 +0000

Happy Friday devs! We’re through another week and it’s almost the weekend. So, how was your week? Did you learn something new? Figure something out? Discover new music/shows/movies? Fun plans for the weekend? Feel free to share in the comments.

Level Up Your Design: Quick and Simple CSS Box Shadows for Beginners

Chris Gustin — Tue, 11 Jul 2023 14:12:14 +0000

When used well, a subtle CSS box shadow added to an element can create depth and elevate the design of a page. However, getting them to look good can be trickier than it seems. And with so many properties to tweak and set to get the box shadow just right, trying to create them on the fly can be overwhelming.

There are quite a few CSS box shadow generators out there that do a great job, but I’ve found that if you’re in the flow state and working on a design, even something as simple as navigating to another site to generate a box shadow can take you out of the flow.

Luckily, over the years of working with some talented designers, I’ve discovered an easy system for box shadows that make them simple and effortless to spin up, easy to tweak, and most importantly, look good in the majority of designs.

A quick overview of the box-shadow property

If you haven’t worked with the CSS box-shadow property before, here’s an example of how you might use it:

.shadow {
  box-shadow: 2px 4px 8px #000000;
}

There are quite a few options, properties, and variations, if you want to learn more about it in-depth I would recommend the official MDN spec.

For our purposes, we’ll be using the 3 properties with a color definition at the end. The properties are as follows:

box-shadow: offset-x, offset-y, blur-radius, color;

Offset-x and offset-y specify the horizontal and vertical distance of the shadow while blur-radius specifies the amount the shadow will be blurred. Higher values mean more blur while lower values mean a sharper shadow. The color value defines the color of our shadow.

There’s no need to memorize these, but knowing approximately what each thing is doing doesn’t hurt.

The technique

When I’m in the flow working on a design and I’m looking to add a box shadow to some element, I always start here every single time:

.shadow {
  box-shadow: 2px 4px 8px rgba(0, 0, 0, 0.3);
}

In my opinion, this is the one to memorize. It’s a gentle box shadow that looks good in the majority of contexts, and is easy to tweak and modify. It’s fairly simple to remember too. Here’s a Codepen demo:

https://medium.com/media/5c543cf82d1242ef33f71c56419e724f/href

The first 3 properties are multiples of each other, and then the color is defined with an RGBA value that sets it to black with 30% opacity. If you’re not familiar with CSS RGBA functions, I recommend giving this article a quick skim.

Modifying the box shadow

Once you commit that line to memory, modifying it to suit is simple. If the shadow is too light, you can increase the last value of the rgba() function to darken it, or decrease it to lighten it. For example:

// Darker
.dark-shadow {
  box-shadow: 2px 4px 8px rgba(0, 0, 0, 0.6);
}

// Lighter
.light-shadow {
  box-shadow: 2px 4px 8px rgba(0, 0, 0, 0.1);
}

If you want the shadow to spread further, or sit tighter to the elements, I recommend adjusting the first 3 values at the same time, and always using multiples of 2 or 3 when possible. For example:

// Bigger shadow
.big-shadow {
  box-shadow: 4px 8px 12px rgba(0, 0, 0, 0.3);
}

// Tighter shadow
.tight-shadow {
  box-shadow: 1px 2px 3px rgba(0, 0, 0, 0.3);
}

// Multiples of 3 shadow
.three-shadow {
  box-shadow: 3px 6px 9px rgba(0, 0, 0, 0.3);
}

In every instance, the important thing is that the property values increase going from left to right, and the rgba() value is always set to black with only the opacity (the last digit) changing.

Conclusion

There are lots of ways to do box shadows, and tons of great generators out there, but with so many options and properties available, having a system to knock them out quickly and on the fly can be an invaluable tool to keep yourself in the flow, or to mock up a design for a client.

By using a great starting point, and limiting the properties we modify to get the results we want, it really helps simplify a process that can otherwise feel a little overwhelming.

And if you’ve got your own technique or system for making box shadows, drop a comment and let me know!

Animate on scroll with the Intersection Observer API

Chris Gustin — Wed, 31 May 2023 14:06:01 +0000

Photo by Pankaj Patel on Unsplash

If you’re building websites these days, it’s a good possibility that your clients will expect animations as part of the deliverable. In the past few years, elements that animate as the user scrolls down the page have gone from “cutting edge” to “status quo.” As such, there are lots of great libraries and plugins for achieving this effect, but it’s also fairly simple to roll your own as it turns out.

Why build your own if there are pre-built solutions available? In many cases, using a library can add a significant amount of extra code and overhead to your project. You may only need a few animated effects, but an animation library will likely load a whole stylesheet full of animation options that will never be used. Likewise, the JavaScript file may include more code than is needed for your situation, as it will be trying to anticipate all the needs a user might have. So while rolling your own is not necessary, it can help reduce code bloat, makes troubleshooting faster, and can help you deliver exactly what a customer or client might be looking for.

Some (subjective) notes about animation

While it might be tempting to throw every animation you can at a page, and go for big dramatic movements, I find it’s often better to go for a few subtle animations that work well together and add interest to the page without going over the top. In my personal opinion, gently fading in elements, or sliding them left/right/up/down a few pixels into their final position (or combining a fade with a slide) generally looks and feels better than elements that wildly spin or bounce onto the page.

Likewise, when choosing how long an element should animate, there’s a sweet spot around 250ms. You can go longer or shorter depending on the style and effect you’re after, but keep in mind that if an animation is too long, the user will start to lose interest, and if it’s too short, it may feel rushed or hurried. You can of course play around to see what you like best, but I’ve usually found the best feel working within these parameters.

With that said, let’s build out our plugin.

The HTML

Let’s start with the HTML and add some elements to our page.

<div class="animate fade-in">I'm going to fade in</div>
<div class="spacer"></div>
<div class="animate fade-in-up">I'm going to fade in and up</div>
<div class="spacer"></div>
<div class="animate fade-in-left">I'm going to fade in and left</div>
<div class="spacer"></div>
<div class="animate fade-in-right">I'm going to fade in and right</div>

(The .spacer elements are included purely to spread out the animated elements in this demo so we can see them animate on scroll and are not required for the functionality.)

For the animated elements, I’ve given each element a class .animate so we can target all elements we want to animate with one JavaScript selector. I’ve also given each element a class that specifies how it will animate, which we’ll define in our CSS file. This way, the code to trigger the animation will live in the JavaScript file and the actual animation logic is handled through the CSS and HTML, making it easy to animate elements or add new animations by simply adding two class names.

The CSS

The .animate class is strictly a JavaScript selector and gets no CSS styling, so we simply define our CSS animations:

.fade-in {
  animation: fade-in .25s ease;
  animation-play-state: paused;
}

.fade-in-up {
  animation: fade-in-up .25s ease;
  animation-play-state: paused;
}

.fade-in-left {
  animation: fade-in-left .25s ease;
  animation-play-state: paused;
}

.fade-in-right {
  animation: fade-in-right .25s ease;
  animation-play-state: paused;
}

.animated {
  animation-play-state: running;
}

@keyframes fade-in {
  from {
    opacity: 0;
  }
  to {
    opacity: 1;
  }
}

@keyframes fade-in-up {
  from {
    opacity: 0;
    transform: translateY(4px);
  }
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

@keyframes fade-in-left {
  from {
    opacity: 0;
    transform: translateX(-4px);
  }
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

@keyframes fade-in-right {
  from {
    opacity: 0;
    transform: translateX(4px);
  }
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

/* For the demo only, not required for functionality */
.spacer {
  height: 100vh;
}

Each class uses the animation keyword to define the name of the animation, the duration for each animation, and the timing function to use (there are lots but I tend to stick with ease as my go-to).

Underneath the classes, I’ve used the @keyframes keyword to define each animation. If you’re not familiar with these, the syntax may look a little weird, but we’re just defining the start position of the animation with the from keyword, and the end position with the to keyword.

Finally, because we only want the animations to play when the elements are visible, I’ve added animation-play-state: paused to each animation class. We’ll use JavaScript to add the .animated class when an element is in view which will switch animation-play-state to running and start our animation.

The JavaScript

While figuring out if an element was in view used to require quite a bit of math and performance draining scroll listeners, the Intersection Observer API makes the task quite a bit simpler and much more performance friendly. To set it up, we simply create a new instance of Intersection Observer like this:

const observer = new IntersectionObserver(callback, options);

The new keyword indicates we’re creating a new instance, which receives callback and options as arguments (we’ll define these in a minute). We’ve stored the result in the variable observer so we can use it other places in our code.

Once the observer is initialized, we can tell it what elements we want it to watch. In this case, we want it to watch any elements with the class .animate and add the .animated class to them if they’re visible. To watch a single element, we would call observer.observe() and pass in our element. However, we want to watch multiple elements, so we’ll need to use a forEach loop like this:

const observer = new IntersectionObserver(callback, options);

const animatedElements = document.querySelectorAll(".animate");

animatedElements.forEach(element => observer.observe(element));

We’ve initialized our observer and told it what elements to pass, however we still need to define our options and our callback before everything will work. Let’s define options first:

const options = {
  root: null,
  rootMargin: "0px",
  threshold: 0.3,
};

const observer = new IntersectionObserver(callback, options);

const animatedElements = document.querySelectorAll(".animate");

animatedElements.forEach(element => observer.observe(element));

Options is an object that we pass to observer that tells it the root element to observe (in this case null since we want to watch the whole document), the rootMargin (0px in this case), and the threshold where an element should be considered visible (in this case 0.3, meaning an element will be considered visible if at least 30% of it is in the viewport). You can play around with different threshold values to suit your needs.

Next, we need to define our callback function, which will be invoked every time the observer finds a matching element. The callback function receives two parameters by default: entries and observer . In our case, we’ll be interested in entries which is an array of elements that match the ones we told observer to watch (any element with a .animate class in our case).

const options = {
  root: null,
  rootMargin: "0px",
  threshold: 0.3,
};

const callback = (entries, observer) => {
  console.log(entries);
}

const observer = new IntersectionObserver(callback, options);

const animatedElements = document.querySelectorAll(".animate");

animatedElements.forEach(element => observer.observe(element));

For the moment, we’ll just log entries to the console so we can make sure everything is working, and to take a look at what sort of information entries will make available to us.

From the console.log we can see that entries returns an array of IntersectionObserverEntry items, each of which has an isIntersecting property (true if the element is past the viewport threshold, false if not), and a target property which gives us a reference to the specific HTML element we may want to work with.

With these two properties, we can modify our callback function to loop through the entries list, check if an entry is in the viewport, and do something with that element (add the .animated class in our case). Here’s what the final function looks like:

const options = {
  root: null,
  rootMargin: "0px",
  threshold: 0.3,
};

const callback = (entries, observer) => {
  entries.forEach(entry => {
    if (entry.isIntersecting && !entry.target.classList.contains("animated") {
      entry.target.classList.add("animated");
    }
  })
}

const observer = new IntersectionObserver(callback, options);

const animatedElements = document.querySelectorAll(".animate");

animatedElements.forEach(element => observer.observe(element));

Since we don’t want to add the class every time an element goes in our out of the viewport, we use an if check to make sure the entry is in the viewport (isIntersecting) and that the element’s classList doesn’t already contain the “animated” class.

Conclusion

If you’ve been following along, you should now be able to scroll through your page and see the elements animate in as they come into view (or feel free to check out my Codepen with the final result here).

Best of all, the JavaScript and CSS to achieve this effect are relatively lightweight, and since the JavaScript is just adding a class when an element scrolls into view, there’s a lot of flexibility for the type of effects you can achieve with just this little bit of code.

The hard thing about JavaScript

Chris Gustin — Tue, 28 Mar 2023 14:06:02 +0000

Photo by Gabriel Heinzer on Unsplash

Among the many things that make JavaScript unique from other programming languages I’ve worked with, there’s one nuance that can really trip you up when you’re starting out. Because I’m self-taught, I was quite a ways into my efforts to learn the language before this nuance was explained to me clearly and once it was, JavaScript programming became a lot easier overall.

The unique thing is this : unlike other programming languages, with JavaScript it matters where you load your code in your HTML document. In PHP, you can weave your code in and out of the HTML (technically a PHP file that compiles to HTML), and with Python or C, you can use templating languages to inject conditionals or variables. The language itself handles generating the final HTML, so there’s no need to tell the document, “Load this script here.” But with JavaScript, the programmer is in charge of telling the document where to execute the script. And there’s a pitfall to this that may not be obvious.

The Pitfall

Let’s say you’ve learned some basic JavaScript, and you decide to test out your new skills by making a basic webpage. You add an h1 tag that says “Hello” with an id of hello and a JavaScript block that targets that element, and changes the text to read “Hello world”. Your code looks like this:

<html>
  <head>
  ...
  <script> 
    document.getElementById("hello").innerText = "Hello world";
  </script>
  </head>
  <body>
    <h1 id="hello">Hello</h1>
  </body>
</html>

You refresh the page and nothing happens. The h1 still says “Hello”. So you open the console and see an error that says Uncaught TypeError: Cannot set properties of null (setting ‘innerText’) which seems to indicate that document.getElementById("hello") is returning null , but you can see the h1 with an id of hello in the HTML document. Why isn’t JavaScript finding it?

Let’s say you rewrite your code like this:

<html>
  <head>
  ...
  </head>
  <body>
    <h1 id="hello">Hello</h1>
    <script> 
      document.getElementById("hello").innerText = "Hello world";
    </script>
  </body>
</html>

Now when you refresh the page, you’ll see the h1 text change to “Hello world”. So why didn’t it work when the script was in the head?

It may already be obvious, but the answer is that when an HTML document loads, it evaluates from top to bottom. During that loading process, when a JavaScript block is encountered, that script block is executed immediately, and while it executes, the document stops loading. So if a script block is inserted before the DOM elements it needs to interact with, the HTML document will fully execute that JavaScript block before continuing on to load the DOM elements that script block would have been looking for.

One fix then, as shown, is to simply insert your script after all the DOM elements have loaded, typically right before the closing body tag. This way, the DOM elements are loaded first, then the JavaScript block is executed.

The order that things are loaded matters. A lot.

But what if my script needs to load in the head?

There may be cases where your script absolutely needs to load in the head, but also needs to interact with DOM elements. Or maybe you’re writing a plugin or third-party code and won’t have control over where your script is added in someone’s project. Luckily, there’s a fix for this too.

The document emits an event that signals that all DOM elements have finished loading, called DOMContentLoaded . If we pair this with addEventListener , we can tell a JavaScript block to wait until that event fires before our code is executed:

document.addEventListener("DOMContentLoaded", function() {
  // All DOM elements have loaded, start executing code here
})

So in the original example, instead of moving the code to the bottom of the page, we could rewrite the script like this:

<html>
  <head>
  ...
  <script>
    document.addEventListener("DOMContentLoaded", function() {
      document.getElementById("hello").innerText = "Hello world";
    });
  </script>
  </head>
  <body>
    <h1 id="hello">Hello</h1>
  </body>
</html>

Now when the page reloads, the h1 text changes to “Hello world”. Because of the DOMContentLoaded event listener, the script block won’t execute until the document has finished loading and the DOMContentLoaded event is fired.

I think this is incredibly important to understand when starting out with JavaScript, and it’s a nuance that doesn’t come up in many other programming languages, so I think it’s easily overlooked. Especially since the tendency is to learn CSS first, and CSS does just fine with selecting and styling DOM elements, despite being loaded in the head. It’s not farfetched then to think JavaScript would behave the same way, although as demonstrated, it doesn’t.

Understanding this distinction can really help cut down on the overall JavaScript learning curve, and lots of wasted time troubleshooting bugs.

WordPress Tip: Internal categories for pages

Chris Gustin — Tue, 28 Feb 2023 15:06:01 +0000

Photo by Justin Morgan on Unsplash

I recently had a feature request for a WordPress site I’ve been working on, and as I went Googling to see what info was already out there, I was surprised to come up a little empty. So I decided to put together a quick article for anyone else who might end up in the same boat.

The request: The site is big and has hundreds of pages and posts. In the admin area, when viewing “Pages”, there was a need to be able to internally categorize pages as a certain type, e.g. “Landing Page”, and then filter pages by that type. And since these categories would be for administrative use only, it was crucial that they not show up on the front-end or be accessible by regular users.

The (almost) solution: My first pass at this was to enable the built-in WordPress categories and tags for pages using the register_taxonomy_for_object_type() function. The code looked like this (added to functions.php):

function register_category_and_tag_for_pages() {
  register_taxonomy_for_object_type('category', 'page');
  register_taxonomy_for_object_type('post_tag', 'page');
}

add_action('init', 'register_category_and_tag_for_pages');

At first glance, it worked. Under “Pages” in the admin area, I now had “Categories” and “Tags” as options. However, when I clicked into Categories, all of the categories that had been added for blog posts were already in there, and same for Tags. I needed a solution that would keep the page categories and post categories separate (I ended up not needing tags, but tried on the first pass to see if they would work), since the page categories needed to be private and the post categories needed to be public.

The working solution: In WordPress, categories and tags fall under the larger umbrella of “taxonomies”, which is just a fancy word for ways to group or sort items based on similar properties. And WordPress allows users to create custom taxonomies, which are just variations of the built in category and tag taxonomies. For my use case, I registered a “Page Category” taxonomy:

function create_page_category_taxonomy() {
  register_taxonomy(
    'page_category',
    'page',
    array(
     'label' => __('Page Category'),
     'hierarchical' => true,
     'public' => false,
     'show_ui' => true,
     'show_admin_column' => true
    )
 );
}

add_action('init', 'create_page_category_taxonomy');

register_taxonomy takes three arguments: the slug for your taxonomy, what to apply it to (posts, pages, custom post), and an array of customization options. For mine, I set hierarchical to true so the taxonomy would behave like a category (categories can have sub-categories and create a hierarchy, tags cannot). Setting it to false would cause it to behave like a tag.

I set public to false to ensure the taxonomy can’t be queried from the front-end, since these would be for internal use only. I set show_ui to true so they would be easy to edit and work with in the Dashboard, and I set show_admin_column to true so they would be visible when viewing the list of pages on the site.

The last step was to make it so a user could filter by a specific category from the “Pages” view in the Dashboard. Thanks to this article https://thestizmedia.com/custom-post-type-filter-admin-custom-taxonomy/, it was a snap to set up. This snippet adds a dropdown box above the list of pages that allows for filtering by page category (make sure to change the code on the two lines indicated in the comments):

add_action('restrict_manage_posts', 'tsm_filter_post_type_by_taxonomy');

function tsm_filter_post_type_by_taxonomy() {
  global $typenow;
  $post_type = 'page'; // change to your post type
  $taxonomy = 'page_category'; // change to your taxonomy
  if ($typenow == $post_type) {
    $selected = isset($_GET[$taxonomy]) ? $_GET[$taxonomy] : '';
    $info_taxonomy = get_taxonomy($taxonomy);
    wp_dropdown_categories(array(
      'show_option_all' => sprintf(__('Show all %s', 'textdomain'), $info_taxonomy->label),
      'taxonomy' => $taxonomy,
      'name' => $taxonomy,
      'orderby' => 'name',
      'selected' => $selected,
      'show_count' => true,
      'hide_empty' => true,
    ));
  };
}

And this snippet processes the actual query (again make sure to update the two lines indicated):

add_filter('parse_query', 'tsm_convert_id_to_term_in_query');

function tsm_convert_id_to_term_in_query($query) {
  global $pagenow;
  $post_type = 'page'; // change to your post type
  $taxonomy = 'page_category'; // change to your taxonomy
  $q_vars = &$query->query_vars;

  if ($pagenow == 'edit.php' && isset($q_vars['post_type']) && $q_vars['post_type'] == $post_type && isset($q_vars[$taxonomy]) && is_numeric($q_vars[$taxonomy]) && $q_vars[$taxonomy] != 0) {
    $term = get_term_by('id', $q_vars[$taxonomy], $taxonomy);
    $q_vars[$taxonomy] = $term->slug;
  }
}

And with those three snippets in place, the feature was up and running. I hope that helps anyone else who might have need for a similar feature!

Building a JavaScript Yak Bak clone with Tone.js — Part 3

Chris Gustin — Tue, 21 Feb 2023 15:06:01 +0000

Building a JavaScript Yak Bak clone with Tone.js — Part 3

Part 1: https://medium.com/@cgustin/building-a-javascript-yak-bak-clone-with-tone-js-part-1-cb01b3b10529

Part 2: https://medium.com/@cgustin/building-a-javascript-yak-bak-clone-with-tone-js-part-2-1a262aa82c5

In part 1, we set up our HTML and used JavaScript and Tone.js to add functionality to our Yak Bak. In part 2, we used CSS to style it and build out a design system. At this point, we could consider this project done and move on, however an important part of product development is to look for opportunities to go beyond what the user expects and up the excitement level. Some product dev philosophies refer to these as “delighters.”

Our original scope had two “nice-to-haves” or “delighters”: features that aren’t critical for the app to function, but will add to the excitement for the user. The first was adding a reverse playback feature, and the second was giving our users the ability to change the color scheme of the Yak Bak. With the work we did in part 2 with setting up CSS color variables, this step is simpler than it sounds.

Step 1: Planning

Before we start writing code, it’s a good idea to think about how we want this feature to work. There are a couple ways we could go.

Should we pre-define color schemes and let the user pick them with a select element? This may be too restrictive for users who want to pick their own colors.

Should we use a text input to have the user type in the hex values they want for each color? This would work, but it sounds like a less than ideal user experience.

Ideally, we want the user to choose their colors from a palette using a color picker, and see those changes update in realtime. These color pickers should be displayed at the top of the screen above the Yak Bak so they’re easy to get to. Luckily, HTML5 includes a “color” input type that makes this step simple.

Step 2: HTML

Our user interface for the color changing feature will be two HTML color picker inputs at the top of the page. We’ll house these in their own div so they’re structurally separated from the Yak Bak markup. Let’s add a div with an ID of options (there are lots of name possibilities for this id, but “options” leaves room to add other features to this section down the line, whereas something like “colors” would lock is in a little more).

<div id="options"></div>
<div id="yakbak">
...
</div>

Now we’ll add the two HTML color inputs like this:

<div id="options">
  <input type="color">
  <input type="color">
</div>
<div id="yakbak">
...
</div>

And since we want to hook them up to our JavaScript, we’ll give each one a descriptive ID:

<div id="options">
  <input type="color" id="primaryColor">
  <input type="color" id="secondaryColor">
</div>
<div id="yakbak">
...
</div>

Finally, we can set the initial value for each input using the “value” property. It defaults to black, let’s instead set each one to the primary/secondary color values so it’s clear to the user what colors each input controls:

<div id="options">
  <input type="color" id="primaryColor" value="#4abbb8">
  <input type="color" id="secondaryColor" value="#f79b1b">
</div>
<div id="yakbak">
...
</div>

Our color pickers are in place, but they don’t do anything and they could use a little styling. Let’s knock out the CSS, and then work on the JS.

Step 3: CSS

Right now, the color picker inputs are at the far left of the screen. During the planning phase, we decided we want them centered over the Yak Bak so they’re easy for the user to get to. We can use Flexbox to move the inputs to the center. In our CSS, let’s target our “options” div and set it to display: flex to initialize Flexbox.

:root {
  ...
}

#options {
  display: flex;
}

#yakbak {
  ...
}

We can use justify-content: center to move our inputs (and anything else we might add) to the center of the container.

:root {
  ...
}

#options {
  display: flex;
  justify-content: center;
}

#yakbak {
  ...
}

Now they’re centered, but the color inputs are touching each other and the Yak Bak. Let’s move them off of the Yak Bak first by adding a little margin-bottom .

:root {
  ...
}

#options {
  display: flex;
  justify-content: center;
  margin-bottom: 20px;
}

#yakbak {
  ...
}

For the inputs, we could add a left/right margin to each input to separate them, but Flexbox gives us a gap property that will let us put space between our elements without having to add an extra CSS selector and target the elements separately. Let’s set it to 10px to stay consistent with our 5px grid scheme.

:root {
  ...
}

#options {
  display: flex;
  justify-content: center;
  margin-bottom: 20px;
  gap: 10px;
}

#yakbak {
  ...
}

Our styling is done, let’s move on to the functionality.

Step 3: JavaScript

When the user clicks into one of the color inputs and changes the color, we want the colors on the Yak Bak to change too. We can use JavaScript to accomplish this. The first thing we need to do is create a reference to each input using document.getElementById

Let’s add those underneath the const yalpButton that we declared earlier:

let initialized = false;
let mic, recorder, player;

const sayButton = document.getElementById("say");
const playButton = document.getElementById("play");
const yalpButton = document.getElementById("yalp");
const primaryColorInput = document.getElementById("primaryColor");
const secondaryColorInput = document.getElementById("secondaryColor");

Now that we have a reference to each input, we need to hook them up to event listeners so we can do stuff when the user uses the inputs. At the bottom of the JavaScript file, let’s add an event listener for each color input.

According to the docs, HTML color inputs have two events we can listen for: input and change . inputfires anytime the color changes, while change only fires when the user closes the color picker (a little unintuitive, I know). We want the user to see their changes right away, rather than picking a color and closing the input to see it take effect, so we’ll listen to the input event.

primaryColorInput.addEventListener("input", function(event) {
  // Do stuff when color changes
})

secondaryColorInput.addEventListener("input", function(event) {
  // Do stuff when color changes
})

These look just like the event listeners from part 1, but you may have noticed we’re passing an event argument in the functions that we’ve attached to each listener. This is an optional argument that gets passed to an event listener function anytime the event is triggered and contains important information about the event that happened.

In this case, we can use the event to find out the current color value each input is set to. The event has a property called target , which refers to the element that triggered the event. And that element has a value property, since it’s an input. Let’s console.log this for now to make sure everything is working so far:

primaryColorInput.addEventListener("input", function(event) {
  console.log(event.target.value);
})

secondaryColorInput.addEventListener("input", function(event) {
  console.log(event.target.value);
})

Now if you open the console and change the color values on the inputs, you should see those hex values logged in realtime.

We’re a little bit closer, but we still need to get those values in to our CSS somehow, so we can see the Yak Bak itself update. Luckily, JavaScript gives us a way to target CSS color variables using document.documentElement.style.setProperty(propertyName, newValue)

By passing a CSS variable name and a value, we can update our CSS variables programmatically, and because we set up our stylesheet to use those variables instead of hardcoded values, we don’t have to target and update multiple CSS properties. Let’s hook up our primary color variable first, remembering that event.target.value has the new hex code from the color input:

// Color Inputs
primaryColorInput.addEventListener("input", function(event) {
  document.documentElement.style.setProperty("--primary", event.target.value);
})

secondaryColorInput.addEventListener("input", function(event) {
  console.log(event.target.value);
})

Now if you choose a new color on the primary color input, you should see the body of the Yak Bak update. Let’s get the secondary color hooked up too:

// Color Inputs
primaryColorInput.addEventListener("input", function(event) {
  document.documentElement.style.setProperty("--primary", event.target.value);
})

secondaryColorInput.addEventListener("input", function(event) {
  document.documentElement.style.setProperty("--secondary", event.target.value);
})

Our color inputs are hooked up and working and we’re almost done, but you may have noticed that the border color of the Yak Bak isn’t updating. This border is set to the color variable that’s a 10% darker shade of the primary color to give a little bit of depth effect. So when our primary color variable changes, we also need to calculate a 10% darker version and update our primary-dark CSS variable at the same time.

With some Googling for “javascript make color darker by percentage” (don’t judge me), I came across a StackOverflow thread where a user had come up with a function that would take in a color value and a percentage value, and return the darkened (or lightened) value, which is exactly what we need. Color theory is a little outside the scope of this tutorial, but the StackOverflow thread is chock full of great info if you’re curious. For now all you need to know is that we’re pasting this utility function at the top of our JavaScript file before the rest of our code:

function lightenDarkenColor(col, amt) {
  var usePound = false;
  if ( col[0] == "#" ) {
      col = col.slice(1);
      usePound = true;
  }
  var num = parseInt(col,16);
  var r = (num >> 16) + amt;
  if ( r > 255 ) r = 255;
  else if (r < 0) r = 0;
  var b = ((num >> 8) & 0x00FF) + amt;
  if ( b > 255 ) b = 255;
  else if (b < 0) b = 0;
  var g = (num & 0x0000FF) + amt;
  if ( g > 255 ) g = 255;
  else if ( g < 0 ) g = 0;
  var string = "000000" + (g | (b << 8) | (r << 16)).toString(16); 
  return (usePound?"#":"") + string.substr(string.length-6);
}

We can update our primaryColorInput event listener to dynamically update our darkened primary color value too, using our helper function to calculate the 10% darker value:

primaryColorInput.addEventListener("input", function(event) {
  document.documentElement.style.setProperty('--primary', event.target.value);
  document.documentElement.style.setProperty('--primary-dark', lightenDarkenColor(event.target.value, -10));
})

Now when we change the primary color, the border color updates too. Our inputs work great, but what if the user wants to reset back to the default values? It would be nice to give them an easy way to do that. Let’s add a “Reset” button in our HTML and add some JavaScript logic to make it work.

<div id="options">
  <input type="color" id="primaryColor" value="#4abbb8">
  <input type="color" id="secondaryColor" value="#f79b1b">
  <button type="button" id="resetColors">Reset</button>
</div>

And we’ll create a reference in our JS file like this:

const sayButton = document.getElementById("sayButton");
const playButton = document.getElementById("playButton");
const yalpButton = document.getElementById("yalpButton");
const primaryColorInput = document.getElementById("primaryColor");
const secondaryColorInput = document.getElementById("secondaryColor");
const resetButton = document.getElementById("resetColors");

Then because we’re going to listen for and respond to the click event, we’ll set up our event listener at the bottom of our JS file like this:

resetButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Reset!");
})

Notice that we’re not passing the event parameter, because we don’t need any of the information that would be passed on the event. Instead, when the reset button is clicked, we want to set all our CSS variables back to their original state, and the two color inputs. We could hardcode those default values into our CSS, but then if we change our default color values in the future, we’ll have to remember to update not only our CSS variables, but our JS file and our HTML input values too.

Let’s instead set it up so our CSS variables are the single source of truth, and our JavaScript instead grabs and stores those values dynamically. First, in our HTML, let’s delete the hardcoded value properties that we set on each color picker.

<div id="options">
  <input type="color" id="primaryColor" value="">
  <input type="color" id="secondaryColor" value="">
  <button type="button" id="resetColors">Reset</button>
</div>

Next, when our page loads, we want use JavaScript to get the primary and secondary color values, and set those values on each color picker. Just like JavaScript gives us a setProperty function, it also has a getProperty function for fetching CSS property values. However, we also have to call getComputedStyle on document.documentElement before we call it to make sure we’re getting the final compiled stylesheet first, then trying to access the properties on it (including our CSS variables). Underneath our const resetButton let’s add a const primaryColor and set the value using getProperty:

const resetButton = document.getElementById("resetColors");
const primaryColor = getComputedStyle(document.documentElement).getPropertyValue("--primary").trim();

We’re also chaining .trim() to the end to remove any whitespace before or after the value that gets returned. If we didn’t do this, the hex value we get back would have a space in the front and cause errors. Let’s set our secondaryColor and primaryDark values the same way:

const resetButton = document.getElementById("resetColors");
const primaryColor = getComputedStyle(document.documentElement).getPropertyValue("--primary").trim();
const primaryDark = getComputedStyle(document.documentElement).getPropertyValue("--primary-dark").trim();
const secondaryColor = getComputedStyle(document.documentElement).getPropertyValue("--secondary").trim();

And we can initialize our color pickers by setting their value property equal to their corresponding color value:

const resetButton = document.getElementById("resetColors");
const primaryColor = getComputedStyle(document.documentElement).getPropertyValue("--primary").trim();
const primaryDark = getComputedStyle(document.documentElement).getPropertyValue("--primary-dark").trim();
const secondaryColor = getComputedStyle(document.documentElement).getPropertyValue("--secondary").trim();
primaryColorInput.value = primaryColor;
secondaryColorInput.value = secondaryColor;

Now when the page loads, the color pickers are set to the default color values automatically and everything will stay in sync.

Finally, when the reset button is clicked, we can use our stored color values to set our CSS variables and the color pickers back to their original settings:

resetButton.addEventListener("click", function() {
  primaryColorInput.value = primaryColor;
  secondaryColorInput.value = secondaryColor;
  document.documentElement.style.setProperty('--primary', primaryColor);
  document.documentElement.style.setProperty('--primary-dark', primaryDark);
  document.documentElement.style.setProperty('--secondary', secondaryColor);
})

With that, we’ve finished all the features in our scope, and wrapped up our project. If you’ve followed along this far, thanks for taking the time, and I hope you learned a few new things! You can view the complete working code at https://codepen.io/cmgustin/pen/ExpRLJj

Building a JavaScript Yak Bak clone with Tone.js — Part 2

Chris Gustin — Tue, 14 Feb 2023 15:06:01 +0000

Building a JavaScript Yak Bak clone with Tone.js — Part 2

Part 1: https://medium.com/@cgustin/building-a-javascript-yak-bak-clone-with-tone-js-part-1-cb01b3b10529

If you followed along with part 1, welcome back! We built the HTML interface, wired it up to some JavaScript event listeners, and added recording and playback functionality with Tone.js. Function-wise, our Yak Bak is acting like a Yak Bak, but in terms of looks, it’s not quite there. To fix that, let’s add some CSS styles.

Step 1: HTML

Our HTML in part 1 was pretty bare bones, since our focus was around getting the functionality in place first, and worrying about the styling elements second. Here’s where we left off:

<div id="yakbak">
  <button type="button" id="sayButton">Say</button>
  <button type="button" id="playButton">Play</button>
  <button type="button" id="yalpButton">Yalp</button>
</div>

And here’s what our interface looks like:

In the final version, there’s a decorative speaker element at the top, and the buttons are in a vertical column underneath. Let’s add an empty div with id “speaker” for the speaker, and wrap the three button elements in a div with id “buttons” to make them easier to arrange and position as one unit:

<div id="yakbak">
  <div id="speaker"></div>
  <div id="buttons">
    <button type="button" id="sayButton">Say</button>
    <button type="button" id="playButton">Play</button>
    <button type="button" id="yalpButton">Yalp</button>
  </div>
</div>

Our interface still looks the same, but structurally our HTML is done. Let’s start working on the CSS!

Step 2: Colors

The original Yak Bak had a bunch of color schemes you could choose from, but we need to pick one to start. Rather than pick colors at random, we can find some reference images and use a color sampling tool to get more accurate color values for our project. I used this reference image since the colors were relatively flat:

Source: https://www.ebay.com/itm/304238222534

And for color picking, I use the ColorZilla Chrome extension, although there are loads out there so feel free to pick your favorite. Using the color picker on the green and yellow sections in the image, I came away with “#4abbb8” for the tealy-green color, and “#f79b1b” for the yellow.

The speaker is also more of a dark gray with black holes, so I chose “#262729” for the dark gray color. This also works well to soften text that should appear black, since using the full “#000000” black hex value can be intense on light backgrounds.

We could set these colors directly in our CSS like this:

background: #4abbb8;

This approach is fine for a small codebase, however we’re going to use these values throughout our CSS and it would be nice not to have to remember these hex values if our codebase grows, or have to change them in multiple places if we decide to use different colors down the road. Luckily, we can use CSS variables to set our hex values in one place, then use them throughout our code. Then in the future, updating our colors is as simple as updating the values in one place (and since this comes up frequently in client requests, it’s worth taking this extra step).

At the top of our CSS file, we can declare our CSS variables like this:

:root {
  --green: #4abbb8;
  --yellow: #f79b1b;
  --dark-gray: #262729;
}

Then we use them like this:

:root {
  --green: #4abbb8;
  --yellow: #f79b1b;
  --dark-gray: #262729;
}

#yakbak {
  background: var(--green);
}

The :root selector is a pseudo selector, like :hover , that targets the root of our document, meaning these variables will be accessible to all selectors we use in our CSS. We could also declare the variables on specific elements, which would make them available to only that element.

This code works, and our main wrapper now has a green background, but there’s a small problem with our variable names. If we decide later that we want our green color to be purple, our --green variable name no longer makes sense, and we would need to do a lot of find-replacing to fix this if we had a big codebase. To avoid this, we can instead think of our app color scheme in terms of primary, secondary, tertiary, etc. colors, which gives us more flexibility if we decide to switch out colors in the future.

Looking at the Yak Bak example image, green is the main color, and yellow is used as an accent for the buttons, so we’ll change --green to --primary and --yellow to --secondary . We’ll leave --dark-gray as it is since we can always update the shade of gray without needing to change the variable name. This not only gives us more flexibility, but having a system for our colors will help us make better design decisions in the future, and give our app a more consistent feel. Our CSS now looks like this:

:root {
  --primary: #4abbb8;
  --secondary: #f79b1b;
  --dark-gray: #262729;
}

#yakbak {
  background: var(--primary);
}

And if we update our primary or secondary colors in the future, it’s as quick as changing two hex values at the top of our CSS file.

Step 3: The body and the speaker

With our color system in place, we can start to style out our elements. Starting from the outside and working our way in, the first thing we notice is that our container element is too wide and goes the width of the screen. To fix this, we could explicitly declare a width for the #yakbak element using something like width: 200px; which would work, but we would then have to update that value if any of our inner element widths change in the future. Instead, we can use width: fit-content so our container automatically sizes itself to the content inside. Now if the content size changes, we don’t have to update the container width as well.

:root {
  --primary: #4abbb8;
  --secondary: #f79b1b;
  --dark-gray: #262729;
}

#yakbak {
  width: fit-content;
  background: var(--primary);
}

It would also be nice to center our Yak Bak in the middle of the screen rather than have it all the way over to the left. We can do this by setting the left and right margins to auto , which will evenly distribute the free space and center our container.

:root {
  --primary: #4abbb8;
  --secondary: #f79b1b;
  --dark-gray: #262729;
}

#yakbak {
  width: fit-content;
  margin-left: auto;
  margin-right: auto;
  background: var(--primary);
}

For now, this finishes our container. We have a green background and a flexible width that will resize to the inner content. Let’s get our speaker in place.

Since the speaker is the largest element and doesn’t need to flex or change size, we’ll set an explicit height and width and allow it to determine the overall dimensions for the Yak Bak. I chose 200px since the smallest smart phone screens clock in around 320px, so this frees us up from having to write separate mobile styles or tackle responsive design. This also looked closest to the reference image I was using.

:root {
  --primary: #4abbb8;
  --secondary: #f79b1b;
  --dark-gray: #262729;
}

#yakbak {
  width: fit-content;
  margin-left: auto;
  margin-right: auto;
  background: var(--primary);
}

#speaker {
  width: 200px;
  height: 200px;
}

Since we used a div for the speaker element, we don’t need to declare display: block since that’s the default setting for div elements. Let’s also give it a dark gray background so we can see the space it’s taking up.

:root {
  --primary: #4abbb8;
  --secondary: #f79b1b;
  --dark-gray: #262729;
}

#yakbak {
  width: fit-content;
  margin-left: auto;
  margin-right: auto;
  background: var(--primary);
}

#speaker {
  width: 200px;
  height: 200px;
  background: var(--dark-gray);
}

We need to turn it into a circle, which we can do by adding border-radius: 100% .

:root {
  --primary: #4abbb8;
  --secondary: #f79b1b;
  --dark-gray: #262729;
}

#yakbak {
  width: fit-content;
  margin-left: auto;
  margin-right: auto;
  background: var(--primary);
}

#speaker {
  width: 200px;
  height: 200px;
  background: var(--dark-gray);
  border-radius: 100%;
}

Finally, we want some space between the speaker and our buttons. We could set this with a margin-top on our #buttons element to push the speaker up, but I prefer to use margin-bottom to push elements down. Either way is fine, but I recommend sticking to one or the other as much as possible in your design system to help keep a consistent flow. Let’s add margin-bottom: 20px to push the buttons down off of the speaker.

:root {
  --primary: #4abbb8;
  --secondary: #f79b1b;
  --dark-gray: #262729;
}

#yakbak {
  width: fit-content;
  margin-left: auto;
  margin-right: auto;
  background: var(--primary);
}

#speaker {
  width: 200px;
  height: 200px;
  margin-bottom: 20px;
  background: var(--dark-gray);
  border-radius: 100%;
}

Note: Instead of adding margin-bottom at the bottom of the other style declarations, I’ve added it under height. This is not strictly necessary, but it is good style to group your declarations by structural (display), spacing (padding and margin), and finally decorative (borders, fonts, colors). This helps add an extra layer of organization to your CSS code.

Our speaker and container still need some polish, but for now we can move on to the buttons.

Step 4: Button alignment

Looking at the reference image, we can see that the buttons should be in one column in the center of the Yak Bak. At the moment, our buttons are in a row and smashed over to the left. Flexbox makes this fairly easy to accomplish. The first thing we need to do is declare display: flex on our #buttons element.

:root {
  --primary: #4abbb8;
  --secondary: #f79b1b;
  --dark-gray: #262729;
}

#yakbak {
  width: fit-content;
  margin-left: auto;
  margin-right: auto;
  background: var(--primary);
}

#speaker {
  width: 200px;
  height: 200px;
  margin-bottom: 20px;
  background: var(--dark-gray);
  border-radius: 100%;
}

#buttons {
  display: flex;
}

Now we can switch our buttons from row to column by declaring flex-direction: column and we can center our buttons with align-items: center

:root {
  --primary: #4abbb8;
  --secondary: #f79b1b;
  --dark-gray: #262729;
}

#yakbak {
  width: fit-content;
  margin-left: auto;
  margin-right: auto;
  background: var(--primary);
}

#speaker {
  width: 200px;
  height: 200px;
  margin-bottom: 20px;
  background: var(--dark-gray);
  border-radius: 100%;
}

#buttons {
  display: flex;
  flex-direction: column;
  align-items: center;
}

Our buttons are centered and in a column, but they’re all touching at the moment. We could fix this by setting margin-top or margin-bottom on the button elements themselves, but we can also do it using the flexbox gap declaration, which defines how much gap should be left between the elements in the flex container. We’ll set ours to 15px

:root {
  --primary: #4abbb8;
  --secondary: #f79b1b;
  --dark-gray: #262729;
}

#yakbak {
  width: fit-content;
  margin-left: auto;
  margin-right: auto;
  background: var(--primary);
}

#speaker {
  width: 200px;
  height: 200px;
  margin-bottom: 20px;
  background: var(--dark-gray);
  border-radius: 100%;
}

#buttons {
  display: flex;
  flex-direction: column;
  align-items: center;
  gap: 15px;
}

Note: When choosing sizes, try to stick to multiples as much as possible. In this tutorial I’m using multiples of 5 (15, 20, 200), although I see multiples of 4 used commonly too. Doing this will help give your designs an extra layer of consistency and coherence, and save you time when deciding on sizes.

Our buttons are aligned where we want them, let’s move on to the actual buttons.

Step 5: Buttons

Looking at our reference image, our buttons share the same styling. On some models, the “Say” button is bigger than the “Play” button, and on the Yak Backwards, the “Yalp” button is the inverse of the “Play” button (yellow text on black background).

From a design standpoint, I think these are nice tweaks. The inverted colors help visually communicate the “Yalp” functionality, and the extra size on the “Say” button emphasizes that it’s the core feature, or the first step in using the device.

Apart from those differences though, our buttons will have the same shape and font. Rather than target each button ID and rewrite the same styles for each one, this would be a perfect situation to use a class , which will allow us to target multiple elements while writing one set of styles. Let’s use a base class of button . In our HTML, we’ll add the class to each button element, then add the class selector in our CSS.

<div id="yakbak">
  <div id="speaker"></div>
  <div id="buttons">
    <button type="button" id="sayButton" class="button">Say</button>
    <button type="button" id="playButton" class="button">Play</button>
    <button type="button" id="yalpButton" class="button">Yalp</button>
  </div>
</div>

:root {
  --primary: #4abbb8;
  --secondary: #f79b1b;
  --dark-gray: #262729;
}

#yakbak {
  width: fit-content;
  margin-left: auto;
  margin-right: auto;
  background: var(--primary);
}

#speaker {
  width: 200px;
  height: 200px;
  margin-bottom: 20px;
  background: var(--dark-gray);
  border-radius: 100%;
}

#buttons {
  display: flex;
  flex-direction: column;
  align-items: center;
  gap: 15px;
}

.button {

}

Right now, our buttons look like default browser buttons. To change this, we can add appearance: none which will remove any default browser button styling and give us a blank canvas to work from.

Since our Yak Bak isn’t going to change size, we can also declare an explicit height and width (the more flexible option would be to use padding, but this will be fine for our purposes). I’m going with 55px to stick with the multiples of 5 in our design system.

.button {
  appearance: none;
  width: 55px;
  height: 55px;
}

Let’s set the background to our secondary color, the font to our dark gray, and set the font weight to bold.

.button {
  appearance: none;
  width: 55px;
  height: 55px;
  background: var(--secondary);
  color: var(--dark-gray);
  font-weight: bold;
}

We can set our font family on the button class itself, but we likely want to use the same font for our whole app. We don’t have other text right now, but defining the font family on our container, or even on the body element, means our app is more flexible if we decide to add more text in the future. I’m going with “Arial” for mine with a fallback of “sans-serif” since it’s well supported, but feel free to try out different fonts here if you have a preference. Alternately, if we knew we were going to have multiple fonts in our app, this could be a perfect place to use CSS variables again, although it’s not necessary for our small project.

...

#yakbak {
  width: fit-content;
  margin-left: auto;
  margin-right: auto;
  background: var(--primary);
  font-family: 'Arial', sans-serif;
}

...

.button {
  appearance: none;
  width: 55px;
  height: 55px;
  background: var(--secondary);
  color: var(--dark-gray);
  font-weight: bold;
}

We can make the buttons round with border-radius: 100% , a border to help them stand out, and force our button text to be uppercase with text-transform: uppercase

.button {
  appearance: none;
  width: 55px;
  height: 55px;
  background: var(--secondary);
  color: var(--dark-gray);
  font-weight: bold;
  text-transform: uppercase;
  border-radius: 100%;
  border: 3px solid var(--dark-gray);
}

To finish them up, we’ll explicitly declare the font size, and add cursor: pointer so the users cursor will turn into the little glove hand that indicates an element is clickable. Normally we would want our font sizes to stick to the pixel grid we’ve chosen (5px in this case), but there’s some flexibility there. In this case I’ve gone with 13px, which could also be thought of as 12.5 rounded up, so it sits in between 10 and 15 and is still on our grid.

.button {
  appearance: none;
  width: 55px;
  height: 55px;
  background: var(--secondary);
  color: var(--dark-gray);
  font-size: 13px;
  font-weight: bold;
  text-transform: uppercase;
  border-radius: 100%;
  border: 3px solid var(--dark-gray);
  cursor: pointer;
}

As a final touch, it looks like the button text in the reference image isn’t on a straight line. We can rotate our buttons slightly to get the same loose feel for ours. To do this, we can use the transform property and set it to rotate() with a specific value passed in. Let’s rotate ours 10 degrees counter clockwise, so the whole line will be transform: rotate(-10deg)

.button {
  appearance: none;
  width: 55px;
  height: 55px;
  background: var(--secondary);
  color: var(--dark-gray);
  font-size: 13px;
  font-weight: bold;
  text-transform: uppercase;
  border-radius: 100%;
  border: 3px solid var(--dark-gray);
  cursor: pointer;
  transform: rotate(-10deg);
}

With that, the base styles for our buttons are done and we can move on to the button variations.

Step 6: Button variations and active state

Our base buttons are done, but they don’t give the user any indication that they’ve been pressed, and our Say and Yalp buttons have a few design differences from the base styles that need to be addressed. Let’s start with giving the user some feedback when they click a button.

Our buttons have different states that we can target and style separately from the base styles using pseudo-classes. We want the styles to change when the button is pressed, so we’re going to use the :active pseudo class.

When the button is pressed, we’ll thicken the border to give the impression of the button moving down and getting smaller. We’ll also lower the font size slightly to add to the effect:

.button {
...
}

.button:active {
  border-width: 4px;
  font-size: 12px;
}

Now when the user presses a button, they get visual feedback showing the state change.

We also need to make our “Say” button bigger than the “Play” and “Yalp” buttons. If we change the size on our .button class, it will change all three buttons, so we’ll need to add a second class that overrides the base button width and height. Rather than use a class like .say-button , we’ll use .button--large so we can easily add more large buttons in the future if needed, and to communicate that this style is a variation of the base .button class. We’ll add it to our CSS, and add the class to the “Say” button in our HTML:

<div id="yakbak">
  <div id="speaker"></div>
  <div id="buttons">
    <button type="button" id="sayButton" class="button button--large">Say</button>
    <button type="button" id="playButton" class="button">Play</button>
    <button type="button" id="yalpButton" class="button">Yalp</button>
  </div>
</div>

.button:active {
...
}

.button--large {
  width: 70px;
  height: 70px;
}

We also want the colors on the “Yalp” button to be the inverse of the “Play” button. Let’s add a .button--inverse class to our CSS and to the “Yalp” button in our HTML:

<div id="yakbak">
  <div id="speaker"></div>
  <div id="buttons">
    <button type="button" id="sayButton" class="button button--large">Say</button>
    <button type="button" id="playButton" class="button">Play</button>
    <button type="button" id="yalpButton" class="button button--inverse">Yalp</button>
  </div>
</div>

.button--large {
...
}

.button--inverse {
  background: var(--dark-gray);
  color: var(--secondary);
}

Our button states and variations are done and we’re nearly there, but the design still needs a little polish.

Step 7: Final touches

Right now, the buttons are touching against the bottom of the Yak Bak container, so we’ll want to add some space there. We could do this by adding a margin-bottom or padding-bottom to our #buttons container, but if we take this element out in the future and replace it with something else, we’ll have the same problem again. So we’ll want to add the padding to the #yakbak container itself to ensure we always have a little bit of padding there. Full disclosure, the values in this section came from trying and tweaking things until it looked right, although I stuck to the 5px grid as much as possible. Let’s add some padding to our #yakbak selector in our CSS:

#yakbak {
  width: fit-content;
  margin: 0 auto;
  padding-bottom: 30px;
  background: var(--primary);
  font-family: Arial, sans-serif;
}

We can also use border-radius: 100% to round off the container. In this case, because our container is a rectangle and not a square, we’ll get an ellipse shape which is perfect for mimicking the oblong Yak Bak. Alternately, you can set your border-radius values to half the container width (100px in this case), or a little bigger, to get rounded edges and still keep the rectangle intact.

#yakbak {
  width: fit-content;
  margin: 0 auto;
  padding-bottom: 30px;
  background: var(--primary);
  font-family: Arial, sans-serif;
  border-radius: 100%;
}

In real life, if a colored object has rounded or curved edges, they will be slightly darker than the main color of the object. We can mimic this by darkening our primary color value by 10%, and applying it as a border to the #yakbak container.

https://www.cssfontstack.com/oldsites/hexcolortool/ is an excellent tool for darkening or lightening colors easily. Let’s enter our primary color value “4abbb8”, select “darken” and “10%” and click “Submit”. The second value is the 10% darker version “31a29f”. We’ll add it to our CSS as a color variable:

:root {
  --primary: #4abbb8;
  --primary-dark-10: #31a29f;
  --secondary: #f79b1b;
  --dark-gray: #262729;
}

And then add it as a border color to our container:

#yakbak {
  ...
  border: 3px solid var(--primary-dark-10);
}

Let’s add it to our speaker element as well to give it a little depth, and help cover up the bump sticking out at the top.

#speaker {
  ...
  border: 3px solid var(--primary-dark-10);
}

That’s better but there’s still a little bump at the top from the container sticking out. We need to shift our speaker element up a few pixels to cover it, which we can do by setting margin-top on #speaker to a negative value, which will pull it upwards. We’ll add this above our margin-bottom property:

#speaker {
  width: 200px;
  height: 200px;
  margin-top: -4px;
  margin-bottom: 20px;
  background: var(--dark-gray);
  border-radius: 100%;
  border: 3px solid var(--primary-dark-10);
}

Finally, our speaker needs a dot pattern to simulate the speaker grill on the Yak Bak. I’ve used https://doodad.dev/pattern-generator/ to generate the pattern, and clicked “CSS Background Image” to get the CSS property we need to add to our code. The site gives the code assigned to the background property, which will overwrite the background property we already have assigned for color. We can change it to background-image to work around this (we could also add our hex color code before we define our image URL to keep it on one line):

#speaker {
  ...
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' height='100%25' width='100%25'%3E%3Cdefs%3E%3Cpattern id='doodad' width='20' height='20' viewBox='0 0 40 40' patternUnits='userSpaceOnUse' patternTransform='rotate(135)'%3E%3Crect width='100%25' height='100%25' fill='rgba(26, 32, 44,0)'/%3E%3Ccircle cx='40' cy='20' r='0.25' fill='rgba(0, 0, 0,1)'/%3E%3Ccircle cx='0' cy='20' r='1' fill='rgba(0, 0, 0,1)'/%3E%3Ccircle cx='40' cy='20' r='1' fill='rgba(0, 0, 0,1)'/%3E%3C/pattern%3E%3C/defs%3E%3Crect fill='url(%23doodad)' height='200%25' width='200%25'/%3E%3C/svg%3E ");
}

And with that, our Yak Bak is done. The functionality works, and we’ve given the interface some style.

In the final part, we’ll go through how to add an option for the user to switch to a different color scheme.

Building a JavaScript Yak Bak clone with Tone.js — Part 1

Chris Gustin — Tue, 07 Feb 2023 15:16:29 +0000

Building a JavaScript Yak Bak clone with Tone.js — Part 1

If you don’t remember Yak Bak’s, or you’re not familiar with them, they were these little handheld recording toys that came out in the mid-90’s. The original version was pretty simple: you hold down a button to record a sound, then push another button to play it back. Later versions included sound effects, and the Yak Bakward had a button that would play your sound back in reverse. As a kid who was obsessed with spy gadgets and James Bond movies, I loved them. And as a web dev obsessed adult, I thought a Yak Bak clone would be a fun weekend project, while getting to take a trip down memory lane.

Here’s the finished project:

https://medium.com/media/76a7a9f72a864dda8a9e110b3c584daa/href

Step 1: Scope

Before you start writing any code, or even open your IDE, it’s important to understand exactly what you’re trying to build. This doesn’t have to take long, and it doesn’t have to be a super official document, we just need to take a few minutes to outline the main features, and maybe brainstorm a couple nice-to-haves. I’m partial to the user story format, so using a Yak Bak as an example, here’s what our project scope might look like:

The user should be able to press a button to begin recording audio, and release the same button to stop recording audio
The user should be able to press a button to play back the audio they recorded
[Nice-to-have] The user should be able to press a button to play back their audio in reverse
[Nice-to-have] The user should be able to change the color scheme of their Yak Bak

Pretty straightforward. We have two key features, and two features that aren’t necessary, but will add to the users overall experience. When writing a user story, it’s important to keep it simple and avoid making technical judgements or recommendations. We’re simply describing how the feature should work from the users point of view, and leaving the implementation details for a later phase. Doing this allows the scoping phase to move quickly, while avoiding getting bogged down with technical details.

Now that we’ve outlined our scope, it’s time to start writing some code. For this tutorial, I recommend following along in CodePen.

Step 2: HTML

In most of my web dev projects that include HTML, CSS and JavaScript, I usually like to start with the HTML, then tackle the JavaScript, and finally the CSS. Typically, the HTML is the least technically intensive piece, which is a great way to build momentum. It also creates the interface elements which your JavaScript will hook into, and it can give you an idea of how much additional CSS will be needed to get the styles you’re after.

For our Yak Bak, the first thing we’ll need is a container to put our interface elements in. A div is perfect for wrapping or containing other elements, so let’s add an empty div with an id of yakbak to our HTML:

<div id="yakbak"></div>

[Note : in a larger project I would avoid using ID’s to tag elements, however in a small project like this where I’m the only developer, there are only a few elements, and I have a lot of control over the id names, I find that it helps keep things simple.]

Inside the container, our interface will have three buttons: one to record (and stop recording when released), one to playback the recording, and one to playback the recording in reverse. On the Yak Bak, these buttons are labeled “Say,” “Play” and “Yalp.” Let’s add those to our HTML using button elements:

<div id="yakbak">
  <button type="button">Say</button>
  <button type="button">Play</button>
  <button type="button">Yalp</button>
</div>

[Note: type="button" is the default type for button elements, so technically we could leave it off. However, explicitly declaring it ensures that the buttons behave exactly how we expect in all browsers.]

We also need a way to target these buttons with our JavaScript. There are several ways to do it, but document.getElementById() is easy and performant, so it’s perfect for a small project like this. Let’s add an id to each button:

<div id="yakbak">
  <button type="button" id="sayButton">Say</button>
  <button type="button" id="playButton">Play</button>
  <button type="button" id="yalpButton">Yalp</button>
</div>

Including “button” in the ID name will make it clear what element is being targeted when writing the JavaScript and help keep our code readable.

Our interface still needs some decorative elements, but in terms of core functionality, we’re good to go. Let’s move on to the JavaScript!

Step 3: JavaScript

We’ve added the buttons to our HTML, now we want something to happen when a user presses those buttons. The first thing we need to do is target our button elements in our JavaScript file. We can use document.getElementById("some-element-id") to target an element by its ID, and we can assign the result to a variable so we have a useful reference to that element that we can use throughout our code. Let’s target each button and save it to a variable:

const sayButton = document.getElementById("sayButton");
const playButton = document.getElementById("playButton");
const yalpButton = document.getElementById("yalpButton");

Note: In JavaScript, variables can be declared with var, let or const. If you’re unfamiliar with the difference, FreeCodeCamp has a great rundown. For our purposes, it’s important to know that const, short for constant, is used to define a variable that will not be reassigned. In this case, it’s perfect for defining these interface elements since they will not be reassigned in our code (and we will get an error if we try to reassign them).

We’ve identified each of the buttons and saved it to a variable, but they still don’t do anything when clicked. To change this, we can add an event listener to each element that will wait for a specific user event, then fire off a function when that event happens. We want the “Say” button to start recording when the user presses down, so we’ll need to target the mousedown event. We can do that like this:

const sayButton = document.getElementById("sayButton");
const playButton = document.getElementById("playButton");
const yalpButton = document.getElementById("yalpButton");

sayButton.addEventListener("mousedown", function() {
  // Do stuff while pushed down
  console.log("Say button pushed down");
});

We’ve added a console.log inside the event listener so we can test our button and make sure our code is working as expected so far. When you click the button, you should see the text in the console (on CodePen, click the “Console” button in the bottom left corner to open the console).

We also need the “Say” button to stop recording when released, which we can listen for with the mouseup event. The “Play” and “Yalp” buttons will play back the audio when clicked, so we’ll listen for the click event on those. Here’s how our code will look:

const sayButton = document.getElementById("sayButton");
const playButton = document.getElementById("playButton");
const yalpButton = document.getElementById("yalpButton");

sayButton.addEventListener("mousedown", function() {
  // Do stuff while pushed down
  console.log("Say button pushed down");
});

sayButton.addEventListener("mouseup", function() {
  // Do stuff when released
  console.log("Say button released");
});

playButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Play button clicked");
});

yalpButton.addEventListener("click", function() {
  // Do stuff when released
  console.log("Yalp button clicked");
});

We’ve built our HTML interface, and used JavaScript to target the interface elements and listen for specific actions, now we’re ready to add our recording and playback features.

Step 4: Tone.js and wiring up the “Say” button

Tone.js is a JavaScript framework that adds a layer of abstraction to the Web Audio API that’s included natively in the browser. While we could work directly with the Web Audio API to set up our recording and playback functionality, Tone.js makes achieving those things a little bit easier.

The first thing we need to do is include the Tone.js framework in our CodePen. In your CodePen, click the gear at the top right of the “JS” pane and under “Add External Scripts/Pens” search for “tone” and click on the package when it appears (the description should say “a Web Audio framework for making interactive music in the browser”).

Alternately, you can paste this URL https://cdnjs.cloudflare.com/ajax/libs/tone/14.8.49/Tone.js directly into one of the fields underneath the search bar.

Click “Save and Close.”

Now that we’ve added the package, we have access to the Tone.js framework within our code.

The first thing we want to do is record some audio from the user when they click the “Say” button. Looking through the documentation, Tone.js comes with a Tone.Recorder() class that is able to record audio. However, it needs some sort of input. In our case, we want to record from the users microphone, which we can do with the Tone.UserMedia() class.

So we’re going to access the users mic, feed it into a recorder, and eventually play back the result. We want this to happen when the user presses the “Say” button, but we also need the mic and recorder variables to be available to the other event listener functions. Let’s add an empty variable for each, and then initialize each one within the mousedown event listener.

const sayButton = document.getElementById("sayButton");
const playButton = document.getElementById("playButton");
const yalpButton = document.getElementById("yalpButton");

let mic, recorder;

sayButton.addEventListener("mousedown", function() {
  // Do stuff while pushed down
  mic = new Tone.UserMedia();
  recorder = new Tone.Recorder();
});

sayButton.addEventListener("mouseup", function() {
  // Do stuff when released
  console.log("Say button released");
});

playButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Play button clicked");
});

yalpButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Yalp button clicked");
});

We have our mic and our recorder, and they’ll be available to the other event listeners. Right now, mic and recorder will be re-initialized each time the user pushes the “Say” button, which is unnecessary. Let’s add a variable to check if they’ve been initialized or not, and then only initialize them if that variable if false.

const sayButton = document.getElementById("sayButton");
const playButton = document.getElementById("playButton");
const yalpButton = document.getElementById("yalpButton");

let initialized = false;
let mic, recorder;

sayButton.addEventListener("mousedown", function() {
  // Do stuff while pushed down
  if (!initialized) {
    mic = new Tone.UserMedia();
    recorder = new Tone.Recorder();
    initialized = true;
  }
});

sayButton.addEventListener("mouseup", function() {
  // Do stuff when released
  console.log("Say button released");
});

playButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Play button clicked");
});

yalpButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Yalp button clicked");
});

We have our mic and recorder initialized on the first press, now we need to connect them together and start the recorder. Connecting the mic and recorder should only happen on the first initialization, but starting the recorder should happen every time the user presses the button. We use mic.connect(recorder) and mic.open() to prepare the mic for recording, and recorder.start() to start the recording. Here’s our code so far:

const sayButton = document.getElementById("sayButton");
const playButton = document.getElementById("playButton");
const yalpButton = document.getElementById("yalpButton");

let initialized = false;
let mic, recorder;

sayButton.addEventListener("mousedown", function() {
  // Do stuff while pushed down
  if (!initialized) {
    mic = new Tone.UserMedia();
    recorder = new Tone.Recorder();
    mic.connect(recorder);
    mic.open();
    initialized = true;
  }

  recorder.start();
});

sayButton.addEventListener("mouseup", function() {
  // Do stuff when released
  console.log("Say button released");
});

playButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Play button clicked");
});

yalpButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Yalp button clicked");
});

Finally, we need to add Tone.Context.Resume() after the user pushes the button, but before we start initializing our variables to fix a bug that otherwise pops up in some cases (full details here if you’re curious https://github.com/Tonejs/Tone.js/issues/341). Our code should now look like this, and when clicking the “Say” button, you should get a prompt to allow the browser to access the microphone (or see a “recording” indicator if you’ve already allowed access).

const sayButton = document.getElementById("sayButton");
const playButton = document.getElementById("playButton");
const yalpButton = document.getElementById("yalpButton");

let initialized = false;
let mic, recorder;

sayButton.addEventListener("mousedown", function() {
  // Do stuff while pushed down
  Tone.context.resume();

  if (!initialized) {
    mic = new Tone.UserMedia();
    recorder = new Tone.Recorder();
    mic.connect(recorder);
    mic.open();
    initialized = true;
  }

  recorder.start();
});

sayButton.addEventListener("mouseup", function() {
  // Do stuff when released
  console.log("Say button released");
});

playButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Play button clicked");
});

yalpButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Yalp button clicked");
});

Our “Say” button is halfway there, now it’s time to stop recording and retrieve the audio when the user lets go.

Step 5: Finishing the “Say” button

When the user lets go of the “Say” button, we need to stop recording, retrieve the audio clip, and load it into a player for playback. The player that the audio will get loaded into, like the mic and recorder variables, will need to be accessible in other event listeners, meaning we need to declare it outside of any other functions. Let’s do that now:

const sayButton = document.getElementById("sayButton");
const playButton = document.getElementById("playButton");
const yalpButton = document.getElementById("yalpButton");

let initialized = false;
let mic, recorder, player; // Add the player variable

sayButton.addEventListener("mousedown", function() {
  // Do stuff while pushed down
  Tone.context.resume();

  if (!initialized) {
    mic = new Tone.UserMedia();
    recorder = new Tone.Recorder();
    mic.connect(recorder);
    mic.open();
    initialized = true;
  }

  recorder.start();
});

sayButton.addEventListener("mouseup", function() {
  // Do stuff when released
  console.log("Say button released");
});

playButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Play button clicked");
});

yalpButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Yalp button clicked");
});

Next, when the user releases the “Say” button, we want to stop the recording. This can be done by calling recorder.stop(). When we call this method, it’s going to return the recorded audio data, so we want to not only call the method, but assign the result to a variable so we can capture the recorded audio data it returns. Here’s how we can do that:

const sayButton = document.getElementById("sayButton");
const playButton = document.getElementById("playButton");
const yalpButton = document.getElementById("yalpButton");

let initialized = false;
let mic, recorder, player;

sayButton.addEventListener("mousedown", function() {
  // Do stuff while pushed down
  Tone.context.resume();

  if (!initialized) {
    mic = new Tone.UserMedia();
    recorder = new Tone.Recorder();
    mic.connect(recorder);
    mic.open();
    initialized = true;
  }

  recorder.start();
});

sayButton.addEventListener("mouseup", function() {
  // Do stuff when released
  const data = recorder.stop();
});

playButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Play button clicked");
});

yalpButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Yalp button clicked");
});

We use const because the data variable is only assigned once and will not be reassigned. To load our raw audio data into our player, we need to first convert it to a URL which the player will be able to read from. We can use the built-in browser method URL.createObjectURL(data) to convert the raw data to a URL.

const sayButton = document.getElementById("sayButton");
const playButton = document.getElementById("playButton");
const yalpButton = document.getElementById("yalpButton");

let initialized = false;
let mic, recorder, player;

sayButton.addEventListener("mousedown", function() {
  // Do stuff while pushed down
  Tone.context.resume();

  if (!initialized) {
    mic = new Tone.UserMedia();
    recorder = new Tone.Recorder();
    mic.connect(recorder);
    mic.open();
    initialized = true;
  }

  recorder.start();
});

sayButton.addEventListener("mouseup", function() {
  // Do stuff when released
  const data = recorder.stop();
  const audioUrl = URL.createObjectURL(data);
});

playButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Play button clicked");
});

yalpButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Yalp button clicked");
});

Finally, we initialize a Tone.js player and load the file URL into it so it’s ready for playback. We use Tone.Player(url) to initialize the player and pass in the audio, and we chain the method toDestination() to route the audio through the users default audio output.

const sayButton = document.getElementById("sayButton");
const playButton = document.getElementById("playButton");
const yalpButton = document.getElementById("yalpButton");

let initialized = false;
let mic, recorder, player;

sayButton.addEventListener("mousedown", function() {
  // Do stuff while pushed down
  Tone.context.resume();

  if (!initialized) {
    mic = new Tone.UserMedia();
    recorder = new Tone.Recorder();
    mic.connect(recorder);
    mic.open();
    initialized = true;
  }

  recorder.start();
});

sayButton.addEventListener("mouseup", function() {
  // Do stuff when released
  const data = recorder.stop();
  const audioUrl = URL.createObjectURL(data);
  player = new Tone.Player(audioUrl).toDestination();
});

playButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Play button clicked");
});

yalpButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Yalp button clicked");
});

We need to do one last thing to get this to work. The recorder.stop() method is an asynchronous function, meaning it returns a Promise object and behaves a little different from a normal JavaScript function. If you’re not familiar with asynchronous JavaScript, I would recommend digging in as it’s an important concept to grasp, but it is also a little advanced so if you’re just starting out, all you need to know is that we can add the async and await keywords to make everything behave more like the synchronous JavaScript we’re used to.

const sayButton = document.getElementById("sayButton");
const playButton = document.getElementById("playButton");
const yalpButton = document.getElementById("yalpButton");

let initialized = false;
let mic, recorder, player;

sayButton.addEventListener("mousedown", function() {
  // Do stuff while pushed down
  Tone.context.resume();

  if (!initialized) {
    mic = new Tone.UserMedia();
    recorder = new Tone.Recorder();
    mic.connect(recorder);
    mic.open();
    initialized = true;
  }

  recorder.start();
});

sayButton.addEventListener("mouseup", async function() {
  // Do stuff when released
  const data = await recorder.stop();
  const audioUrl = URL.createObjectURL(data);
  player = new Tone.Player(audioUrl).toDestination();
});

playButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Play button clicked");
});

yalpButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Yalp button clicked");
});

We’ve made it through the meat of our Yak Bak functionality, now we just need to get our audio to play back.

Step 6: The “Play” and “Yalp” buttons

We’re recording input, converting it to audio, and loading it into a player, but we still need the audio to play back when the user pushes the “Play” button. This part is as simple as calling player.start() from within the playButton event listener.

const sayButton = document.getElementById("sayButton");
const playButton = document.getElementById("playButton");
const yalpButton = document.getElementById("yalpButton");

let initialized = false;
let mic, recorder, player;

sayButton.addEventListener("mousedown", function() {
  // Do stuff while pushed down
  Tone.context.resume();

  if (!initialized) {
    mic = new Tone.UserMedia();
    recorder = new Tone.Recorder();
    mic.connect(recorder);
    mic.open();
    initialized = true;
  }

  recorder.start();
});

sayButton.addEventListener("mouseup", async function() {
  // Do stuff when released
  const data = await recorder.stop();
  const audioUrl = URL.createObjectURL(data);
  player = new Tone.Player(audioUrl).toDestination();
});

playButton.addEventListener("click", function() {
  // Do stuff when clicked
  player.start();
});

yalpButton.addEventListener("click", function() {
  // Do stuff when clicked
  console.log("Yalp button clicked");
});

Just like that, you should now be able to hold down the “Say” button, record some audio, let go to end the recording, and hear it play back when you click “Play”. The last piece of functionality is playing the audio back in reverse when the user presses the “Yalp” button.

Luckily the Tone.js player has a reverse property, so reversing our audio is a simple as setting this property to true, then calling the player.start() method from within our yalpButton listener.

const sayButton = document.getElementById("sayButton");
const playButton = document.getElementById("playButton");
const yalpButton = document.getElementById("yalpButton");

let initialized = false;
let mic, recorder, player;

sayButton.addEventListener("mousedown", function() {
  // Do stuff while pushed down
  Tone.context.resume();

  if (!initialized) {
    mic = new Tone.UserMedia();
    recorder = new Tone.Recorder();
    mic.connect(recorder);
    mic.open();
    initialized = true;
  }

  recorder.start();
});

sayButton.addEventListener("mouseup", async function() {
  // Do stuff when released
  const data = await recorder.stop();
  const audioUrl = URL.createObjectURL(data);
  player = new Tone.Player(audioUrl).toDestination();
});

playButton.addEventListener("click", function() {
  // Do stuff when clicked
  player.start();
});

yalpButton.addEventListener("click", function() {
  // Do stuff when clicked
  player.reverse = true;
  player.start();
});

We’re almost there, but we have a small bug. When the user clicks the “Yalp” button, it causes the “Play” button to playback in reverse too, since they both share the player variable. To fix this, we just need to set player.reverse to false when the user clicks the “Play” button. Here’s our final code:

const sayButton = document.getElementById("sayButton");
const playButton = document.getElementById("playButton");
const yalpButton = document.getElementById("yalpButton");

let initialized = false;
let mic, recorder, player;

sayButton.addEventListener("mousedown", function() {
  // Do stuff while pushed down
  Tone.context.resume();

  if (!initialized) {
    mic = new Tone.UserMedia();
    recorder = new Tone.Recorder();
    mic.connect(recorder);
    mic.open();
    initialized = true;
  }

  recorder.start();
});

sayButton.addEventListener("mouseup", async function() {
  // Do stuff when released
  const data = await recorder.stop();
  const audioUrl = URL.createObjectURL(data);
  player = new Tone.Player(audioUrl).toDestination();
});

playButton.addEventListener("click", function() {
  // Do stuff when clicked
  player.reverse = false; // Make sure reverse playback is off
  player.start();
});

yalpButton.addEventListener("click", function() {
  // Do stuff when clicked
  player.reverse = true;
  player.start();
});

And just like that, the core functionality is done, plus one of the “nice-to-haves” on our list. In part 2, I’ll walk through the styling and some UI enhancements, and in part 3 I’ll go through how we can allow users to change the color scheme.

If you’ve made it this far, thanks for following along!