Feb 2, 2021 | me in real life

Revamping My New New Site

Deactive isn't even a word

Okay, so I revamped this website again 😕 with no reason other than I really felt that it could be better. If you've been following along, I recently wrote a post about the penultimate version of my personal site not too long ago with lofty claims that read a little bit like I was finally going to leave it be. Whoops.

But now we are here and I figured this is a better opportunity than any to discuss some of the newly implemented features that should result in fewer overhauls and allow me to focus more of my time on writing teachable content. Plus, I really need to highlight the developers and designers who inspired many of the decisions that I made here and that you are seeing in front of you now.

Blog page design

I can really appreciate a blog that relies heavily on images. Personally, I think that photos have a way of breaking up otherwise monotonous content, which is ultimately why I had attempted to bring them into my former design as one of the key features of my cards on my blog page. But holy hell, how does one capture a post titled "Coin Flip Probability with Python" with a Kodak moment? You don't. It's not possible and mixing posts with photos and those without just really didn't cut it for me. So I began to look for alternative solutions, which generally has me scrolling through Awwwards and then promptly ushers a wave of emotion most commonly described as self-inadequacy. Not today, Satan. Break it down, James. What exactly am I looking for? Blog cards! I refined my inner monologue. Stay focussed and search for something specific. So within Awwards, I typed in that exact concept, "blog cards" and very quickly I came across The A-Z of AI. What I saw was fun, animated and most importantly provided an alternative to blog cards reliant on images!

I've said it before, but I'm a sucker for a good animation and The A-Z of AI has good animation. I especially appreciated the little bit of flavor added to their cards as you hover over them. It shouldn't take long to figure out what happened next. With my first bit of design inspiration in hand, I set out to build something a bit similar. If you've been fortunate enough to peruse my blog page, which I assume you have since it's the happy path to this here line of text, then you've seen what I'm talking about. You're even luckier if you've visited while on a laptop or any device with a cursor because then the hover effect really shines. But, if you need a refresher on what I'm talking about, go ahead and hover your cursor over the card below.

Don't drink bleach

I shouldn't have to explain

Don't drink bleach

I shouldn't have to explain

Blog categories

Once I commited to card design change up, well I sort of had to go back to the drawing board on just about everything. This includes how I organized my blog posts. Fortunately, I didn't need to look too far to find some inspiration. Yes, once again I was looking to The A-Z of AI for a bit of a muse. Instead of making blog post tags searchable, I decided that instead I would lump my posts into larger conceptual categories that you, the user, could filter down to fit your mood. Believe it or not, this category filter actually took some of the most logic of any component throughout the entire app and for that reason, it will get its own "how to" sometime in the near future, but not today.

I really felt like partitioning my work into these categories would better fit my multifaceted personality. Much like myself, my blog isn't meant to be 100% programmer or 100% anthropologist, but I also realize that one day, my future tens of readers may be more inclined to read one category over the other. Adding this category filter allows for these readers to quicly navigate my blog for the specific topics that interest them. Plus, each category gets a fun color associated with it!

Editable code blocks

I'm a big fan of House Hunters. I don't care if it's staged (quite frankly, it would be stupid if it were not! ), and although I prefer when their must-haves list is completely ridiculous for such a small budget ( No, Mark, you're not entitled to a sauna for $500 a month with a three views of the Eiffel Tower just because you took a risk to move to Europe! ), the occasional reasonable person is quite refreshing. You know, the type who's like, I really want a single bedroom and room for a table and it would be nice to have a bathtub but it's not a deal breaker. Well, editable code blocks was my bathtub, something that I really felt like was more reserved for a "I drive a car with heated seats" phase in my life. Well, you know what, I've already dismantled this whole project, why can't my rebuild include a bit of a dream? In just an evening's time and a few rabbit holes later, I was finally able to make this a reality.


Confession. It actually didn't take that long. Like most things when I first try them, I simply turn to Google and within a couple of links I can generally find something that matches the picture in my head. In this case, I didn't need to look too far. The documentation for React Live, the driver behinding editable code blocks in React, actually had pretty decent examples. These examples also served as a major design influence for how I wanted to layout a the actual "live-edit" component, well this and Josh Comeau...

Layout and accessibility

One of the biggest influencers of my new design was a developer I discovered a couple of months ago when researching Gatsby. In fact, if you are just starting out with Gatsby (or even React), it would be difficult not to stumple upon the work of Josh Comeau. He, along with others such as Emma Bostian, really helped me understand web development as I started my journey into this field a year ago. I still regularly browse their blogs for helpful tidbits of development and design.

These two also focus pretty heavily on accessibility, which, in turn, has really made me think about whether my website is accomodating. It's obviously not perfect, but a lot of thhis re-work, particularly the parts that you can't see (cough cough the code), were written such that adding accessibility features were easily extensible throughout the entire application. A lot of what was getting on my nerves about my previous iteration was how messy the codebase looked, which is understandable because, I was still new at this. Actually, I'm still relatively new at this, which is why I lean so heavily on other people who have been doing this a lot longer than me. That's all to say that accessibility is a major goal of this and future applications of mine.


I've always been a bit jelly of those that had color theme switching capabilities. I knew that implementing this feature was, in practice, pretty straight-forward. In fact, despite not having ever done it, it was one of the few tasks that I felt fairly confident in my ability to add on pretty easily. However, the difficult part came when naming particular parts of my application that would then serve as a reference to their color attributes. Names such as categoryTextColorAlt or themeIconDeactive. "Deactive" isn't even a word. I think what we have here is a classic case of my brain slipping in terms of its referential vocabulary and replacing it with elementary-level etymology. Of course, I now realize that the proper word is "inactive" but am I going to change it? Nope.

Why was vocabulary so important though? Well, you see, even though the colors throughout are very few (probably around 10 to 12 including shades) how they can be used from theme to theme isn't the same. What I mean is that you can't just simply say that everything that was white in light mode is now black in dark mode and vice versa. It's more nuanced than that. This strategy may work for element relationships that need high contrast such as text and its container, but if you are playing with a third color or shades of the same color, how those colors interact from light mode to dark doesn't always look nice, even if you are just flipping the colors. Now, I've said this before, I'm new at this but the one way I found around this was to be specific in the parts of the component where color was applied.

import React from 'react';
import styled, { ThemeProvider } from 'styled-components';
// #abc light blue
// #fffff7 creamier white
// #303030 slate
const lighTheme = {
specialButtonBackground: '#abc',
specialButtonColor: '#fffff7',
specialButtonBorderColor: '#303030'
const darkTheme = {
specialButtonBackground: '#303030',
specialButtonColor: '#fffff7',
specialButtonBorderColor: '#303030'
const StyledButton = styled.button`
background: ${({ theme }) => theme.specialButtonBackground};
color: ${(({ theme })) => theme.specialButtonColor};
border: 2px solid ${(({ theme })) => theme.specialButtonBorderColor};
const CoolButton = () => {
return (
<ThemeProvider theme={darkTheme}>

The above example demonstrates what I am talking about. Even though I'm switching between dark and light modes, the font color of the button actually remains constant as does the border. The only thing that does change is the button background.


This is all to say that my previous theming solution was all over the place, which became... well... overwhelming. I'm not a perfectionist but I often get distracted by the things that I create that are imperfect. In fact, I believe that this was ultimately the reason why I made such substantial changes to what was already a new website, there were just too many things that disctracted me about that implementation so I went ahead and made a tiny detour to fix those things. The culmination of those fixes are what you are currently looking at, which means that I can try something new for once and actually blog about the things that I want to and make development feature incrementally.