Refactoring 1.0 — Part IV permalink

June 7, 2020 — 6 min read

This is the last part of a series of posts about my recent refactoring in this site.

To read the previous posts go here:

Scroll down to continue reading about the final refactoring topics:

Improve the preloader UX in content pages
Refactor theme picker HTML architecture

Happy reading!

Improve the preloader UX in content pages permalink

The trippy dancing vampire smileys showing up for some milliseconds while loading content pages was not perfect.

I created a fake preloader UX, because I used a setTimeout method via JS.

Did I mention that when I created this site I did it fast in about a week? And that by the time I wrote the JS I was a bit lazy?

It was time I made a real preloader UX, and I went for it by using ES6 promises.

const loadingTime = 140;
const webFontPromise = getWebFont(fontName, fontUrl);
const imgLoaderPromise = getImgLoader(imgSrc);

Promise
  .all([webFontPromise, imgLoaderPromise])
  .then(() => wait(loadingTime))
  .then(() => hideLoader(loader));

One promise waits until the only custom web font I'm using loads if the browser supports the FontFace API, otherwise, it's resolved directly without waiting. The other promise waits for the repeated vampire smileys image to load.

Once those two promises are resolved, there's a setTimeout method inside another promise allowing the vampire smileys dance for some milliseconds [yep, it's a GIF], and right after that, I hide the preloader and display the content page.

References:

Refactor theme picker HTML architecture permalink

I took part in CSS naked day 2020 and stripped down the CSS of my site for 48 hrs.

By going back to the bare-bones foundation of my site, I realized the accessibility could be better in some places. One of them was the theme picker.

I used the Hylia Starter Kit by Andy Bell to build this site since I've never worked with Eleventy before. The default template came with a dark/light theme functionality toggled with a button element.

As I decided to have more than two themes on my site, I added more HTML buttons, which was the lazy road at the time.

When it comes to accessibility, this wasn't a good way to build the theme picker. A button element represents one choice of adding certain functionality. Rather, I had a set of three options for the site's theme.

Having HTML input radio buttons was more accurate to organize the choices for the user. Also, if desired, it'd leave me the option to add more theme selections.

I added an input type="radio" button with its label in each list item, instead of a button element.

<div id="js-picker" class="c-picker">
  <div role="status" class="is-hidden">Current theme color is <span id="js-picker-status"></span>.</div>
  <ul>
    <li class="c-picker__item">
      <div data-theme="blue-purple" class="c-picker__btn c-picker__btn--03">
        <input type="radio" id="blue-purple" name="theme" value="blue-purple" class="is-hidden" checked>
        <label for="blue-purple" class="is-hidden">Blue/Purple theme</label>
      </div>
    </li>
    <!-- More HTML -->
  </ul>
</div>

Visually you probably didn't even notice the change as the CSS and JS stayed the same but refactored.

Curious to experience my site with voice-over to hear coherent options for switching themes? Go to your device's settings, enable it, and come back to this page.

If you cannot find this accessibility feature in your system, follow the instructions from any of the first two references' links below.

There's still much more I could do to improve the accessibility in this site, but for now, it ends here.

References: