Normally I wouldn’t care enough to write up a simple re-skinning of my site, but it took me almost 12 hours, so it gets an honorary mention[1].

Previous Design: Old and Busted

I had last redesigned my site 6 years ago. There are tweaks I made since then, but otherwise it’s been the same aesthetic. Now, it doesn’t really matter what the design is, but sometimes it is broke, and you have to fix it.

Frontpage

The frontpage didn’t age too badly, but:

• The Tango icons were starting to look old skool[2].
• The icons would swap from black and white to color versions on mouse over, which was cute, but I didn’t do it right: the color icon would only load on mouse over, so there would be a split-second weird intermediate blank spot where the icon should be. To be fair, I knew this back in 2012, but didn’t care enough to fix it.

Blog

These are some of the design choices I’ve drifted away from:

• Why in the world is the header so large? If you’re on the site, you already know what you’re getting, no need to gratuitously take up so much space. Heck, the header was so tall it was pushing writing below the fold on smaller screens.
• What the hell was I thinking with that paragraph outdent? Right, I wanted to be a special and unique snowflake[3], and the CSS option was just staring at me… Now I think it’s just needless drawing down of my weirdness budget, when I’m pretty sure there’s more weirdness I’ll need to present in the future[4].

(If you’re not sure why outdents look weird, imagine a bunch of 1 line paragraphs, in which case all the text looks like it’s suddenly snapped to the right for no discernable reason[5].)

Behind the scenes

Every time I wanted to use a list, or headings past h1, I would copy this dollop of CSS into each post:

<style>h1 {font-size:28pt !important;} h2 {font-size:16pt !important;} h3 {font-size:14pt !important;font-weight:bold !important;} ol {list-style-type:decimal !important;} ul {list-style:disc outside none !important;} li {margin:1em !important;line-height:1.2 !important;word-spacing:0.1em !important;} sup {font-size:75%;position:relative;top:-0.4em;}</style>

Why? Well, I was using a reset stylesheet, which did its best to strip out every browser-specific style setting. This is great for making things uniform across browsers, but absolutely awful if you forgot to re-style everything the way you wanted them, including lists.

At that point, I should have just logged in to the server and updated the stylesheets to have sane defaults. Instead, I took the lazy way out and overrode those styles within each post itself. And then I kept copy pasting those styles, because if you’re too lazy once, you’re always too lazy[6].

So whatever, it’s a small ongoing cost. Not a big deal, right?

Except it took me a shockingly long time to notice that this was causing problems: “!important causes CSS problems, more at 11.” Take a look at this alternative view of my blog:

Something seems off: why in the world is the nav list on the left so spaced out? The tags I was copying everywhere were #1 operating on all the tags #2 marked !important so they ended up overriding everything.

Like the frontpage, this is also not too hard to fix in isolation. But wait, there’s more.

Mobile

Okay, here’s the real kicker, which is going to take some explanation.

First, my hosting service started caching in front of WordPress, which would allow serving lots of the same request quickly, like if an article becomes popular (har har). However, this meant that my site started looking like a mobile interface, but on desktops.

Wait, what?

Years ago Google announced that they were going to penalize sites that weren’t mobile optimized. After doing a minimal amount of research, I just threw a mobile plugin into WordPress (Carrington Mobile) and called it a day.

Fast forward to today, and whatever headers the plugin was using to decide whether to serve up mobile-optimized content weren’t treated as important by the cache. That meant it didn’t expect mobile and desktop users to receive materially different content from the server it was fronting for: if a mobile user visited while a page was out of cache, the page would get cached as a mobile page, and served to whoever came later, including desktop users. The same would happen vice-versa, so mobile users could get a desktop site, depending on who visited the site X hours ago.

Were there ways around this? Almost certainly, but taken together with all the other problems I’ve described earlier I decided I had to just throw out my current styling, and do it right this time: a fully responsive design, which would work across both desktop and mobile seamlessly[7].

Plus, the mobile design looks like it’s fresh from 2010.

New Site Plz

I’m not going to go into a blow-by-blow of the project, since there’s a good bit that can be just labeled as “WordPress fuckery”, and I’ll instead glaze over some of the major points.

Web fonts

Why in the world would you need custom fonts? Aren’t the normal websafe fonts good enough for everyone? Might as well slap Arial on everything and call it a day.

I was going to do that, but then I woke up one night with a logo idea.

Yeah, it’s just an underline, but it was just going to be text before, and now it’s text with an underline. Nice.

But that doesn’t include websafe fonts: if we’re going to blow up the font size and do some typographical butchery, we might as well go fancy with our base font choices. And after that door is open, it’s a hop and a skip to loading webfonts for the rest of the site.

(Which makes it ironic that I ended up shipping the logo as an SVG instead, so no web fonts were actually necessary.)

After some poking about the most popular fonts on Google Fonts, I decided on using the Ubuntu font for the logo, and Lato for the body fonts. Lato had a nice feel to it, but it had some complications: like, what is going on with that t? Specifically, what’s with the weird tapers? That would make it harder to join to an underline.

I couldn’t use a lowercase h, since once I cut down the ascender any h would look too close to an n, and Lato’s uppercase H was weirdly wide, which would make modifications difficult. The rest of the logo would be approximately evenly spaced letters without any other notable ascenders (the first t and last f would be reaching down to the underline), so munging the wider H would have been mildly more difficult.

So I relegated Lato to 14pt body font, and hacked up the Ubuntu letter shapes in Inkscape, as well as using it for headings for consistency’s sake.

Flexbox

Despite being not-really-a-frontend person, I’ve run into my share of HTML weirdness: margin:0 auto;, strange vertical-align behavior, float causing elements to waft off into the stratosphere.

The flexbox model and API is nice, almost like the designers of HTML decided to pack a fix for every mistake into flexbox as an apology. “Sorry about table based design, have a proper way to vertically center things.”

If you were stuck in the 2011s like me, you should check out a flexbox tutorial: I referred back to this one from CSS Tricks while designing.

(That said, flexbox does seem to be previous generation, so you might want to look into grids instead.)

Media queries

Flexbox gets close to laying out components the way I want them to, but sometimes things still need further mobile-specific tweaks. Say, the archive and blog post need to swap layout direction when the screen becomes too narrow, so people don’t get a faceful of links instead of sweet, sweet content. Instead of constraining our design, let’s go shopping just special case everything with media queries.

The main media query I used was max-width, which I used to detect when the site is being laid out on a width-constrained device. I’m using the query to change the styling in the following places:

• (As previously mentioned) Swap the ordering of the nav sidebar/blog content, so the content comes first instead of the list of all the months I’ve written things.
• Stop vertically centering the title on the homepage.
• Center the top nav bar of the blog once things get so packed it overflows beneath the blog logo.

Icons

So the business with the Tango icons in my previous design seemed to indicate that any icons I chose would run around and desert me. I would just make my own icons, dammit!

Well, it’s hard. I got stuck at the sketching and ideation phase: how do you signify writing without using a hackneyed pencil? A fountain pen? (Old) A blinking cursor? (Needs to be animated, not obvious) A quill? (HOW OLD ARE YOU GOING‽) At some point I threw up my hands and decided to sketch out a cuneiform tablet, because all our metaphors for writing are so outdated that you may as well go as old as possible.

After playing with ideas for a while, I finally brought up Inkscape, and faced with the task of actually vectorizing the rough 1cm² sketches I had made, I realized I was spending time on pure overhead, and ran out and got myself some icons instead.

Somewhat embarrassingly, as opposed to hand-crafted artisinal icons I had started out designing, I ended up literally searching for “black and white icons”, and pulled the Feather Icon set from the top 10 results.

vh/vw

Also slot this under “things the W3C was doing while I wasn’t looking”.

It used to be a gymnastics exercise to get elements to take up some fraction of the screen, especially if one needed to nest divs. Best hope you didn’t need fixed margins at some point in the stack!

So having viewport percentages be available as a unit is super useful: in my case, the blog content needs to reflow to fit the screen, especially in mobile. However, equations and the like might be longer that a mobile screen is wide, and push the blog content width out of whack. It was helpful to be able to constrain the prose to the width of the screen with “max-width: 100vw” and let the equations float around by themselves, especially when the content is nested within a series of divs.

Similarly, getting a footer to float at the bottom of a screen if there isn’t enough content to push the footer down? It used to be a bit of a production, but with “min-height: 100vh” and flexbox it was easy to get the footer to behave correctly.

Simplify

Some things changed from the original redesign conception, and were simplified once I started implementing the HTML/CSS.

First, on the frontpage, I wanted half the page to be black with white text and the other half to be white with black text. I planned on putting the split between thenovice and oof, which I figured should help people figure out the 3 words that make up the title. However, I also wanted to keep the icons on the left; when I tried to put the icons on the right, it just looked awful in some non-specific way. This meant that I would somehow need to split the page when one element had a wide left side, and another had a wide right side. On the desktop this isn’t a problem, because there’s tons of room in all directions, but on mobile there’s only so much horizontal space to go around, and both sides couldn’t be taking up tons of room.

So I thought about complicated solutions: once the screen width got small enough, I would pop in an svg that would show a swerving color split, so I could keep the thenovice and icons on the same side.

In the end, though, I couldn’t figure out how to make it happen in a reasonable amount of time, and threw up my hands once I noticed I was spending lots of time on a minor part of the site, and instead just changed the title split from thenovice and oof to the and noviceoof. Readability is still a bit of a concern, but I figured I would just add a bit of kerning and hope it was enough to carry the day.

Second, the blog title on the front page is fixed width. Ideally, it would size up and down with the available display width and take up nearly the entire width, but since the logo is split up into two different SVGs for each color, it was harder to do so[8]; after some attempts at getting it to scale correctly, I just sized the title to fit the default range of phone sizes that Chrome inspector came with, and called it a day.

Process

First I mocked up the entire site, adding styles to a static version of the site full of Lorem Ipsum. Working directly with the WordPress template would have been annoying: not only does it involve working directly with remote files (keystrokes slowly registering, one… by… one…), it doesn’t lend itself to a holistic view since it would need to conform to the WordPress theme structure, which would have made it harder to think about the header, body and footer all being part of the same flexbox.

So only after mocking out some example pages of the site, I then broke it up into a WordPress theme, and finally uploaded the theme for testing (Live testing‽ If I were more popular, it might make sense to have a test rig, but as things stand I doubt any human visited the site while I was testing, even while I was using “Preview Theme” behind the scenes).

Of course things broke, and I needed to bugfix. My favorite bug was when my latest post list was getting doubled. It turned out I had included my mocked list of recent posts in the template, which meant the lists looked doubled.

(Sorry if you visited the site while I was dealing with design bugs.)

Current Design: New and Shiny

And this is what it looks like now (as of 2018/03, you can also just look at the site you’re looking at):

Future work

That said, some old design elements still persist: for example, the project and about pages have some styling from my “put a round corner on it!” phase of my life. Maybe I will change it in the next redesign, when it happens.

[1] ↑ Never mind that this honorary mention took something on the order of 12 hours to write up…

[2] ↑ An argument could be made that Tango looked outdated by 2011, when I decided to include them. Whatever, I’m an engineer, not a designer.

[3] ↑ Is this still topical and political by the time I publish this?

[4] ↑ You fools, this is not even MY FINAL FORM!

[5] ↑ It is true that indents would also have this problem.

[6] ↑ Protip: the timeless decision theory diet.

[7] ↑ SECOND SYSTEM SYNDROME INTENSIFIES.

[8] ↑ It occurs to me that I may have been able to do this with vw.