I launched a couple of sites today, both for my friend Sarah Warren:

• The Accidental Okie — her blog, based on an existing WordPress theme but with some substantial tweaks to typography, colors, backgrounds, etc.
• Swoon Designs — a site for her business selling custom invitations, stationery, and branding.

Sarah has been blogging as “The Accidental Okie” for a couple years now, but she spent that whole time on WordPress.com using one of their upgrades for a hosted site on her own domain. I was unsurprised to hear she was outgrowing WordPress.com, though — good themes are hard to come by and impossible to customize to the extent one would like, so most people who are serious about blogging end up moving to WordPress.org (if they stay with the platform). It made sense to do that and get her professional site launched at the same time.

The design for The Accidental Okie is just a tweak of an existing theme — completely new background, header, typography, and color scheme, but someone else’s work otherwise (and generally very good work indeed.)

The design for Swoon Designs was a custom design that Sarah and I brainstormed up together after looking at a number of other sites she liked. It’s built as a child theme of a popular framework theme, Reason 2.0. That, frankly, is a mistake I won’t make again. While the theme works well (and our final outcome was one with which we’re both happy), it was a chore getting it to work. The original template designer ignored some fairly basic rules of good design, especially in his CSS, and it showed rather painfully in making a child theme. In the amount of time I spent on it, we could have built Sarah a theme from scratch (and avoided quite a few headaches that came with this setup).

The original is also monstrous as far as these things go — some 36MB when compressed. By contrast, the compressed size of all the themes for chriskrycho.com, including all the child themes is about 394KB. Yes, that’s two orders of magnitude different. Nothing screams bad design decisions like a theme that size.

This experience further persuaded me that, while I’ll be happy to keep doing WordPress projects for friends from time to time,¹ I want to continue my move away from PHP and WordPress to other parts of the web. There is simply too much garbage in the PHP world, and I’m increasingly aware that one of the best ways to be getting better work is to get out of that world entirely. There are a lot of reasons for that — not least the “approachability” factor in PHP, which means a lot of non-programmers are doing it, and especially in the WordPress theme area — but moving further the way I already have been toward the Python community seems like a better plan every day. (Node.js is of course on my radar as well.) Things that require you to be a good programmer are better for getting work that pays well (as the market isn’t flooded with people who don’t know what they’re doing but are willing to work for a fifth of a reasonable developer rate), and they almost always entail better kinds of work to be doing anyway.

Speaking of which… now would be the point when I stop writing and go hammer out some more work on Step Stool, which is coming along nicely (albeit more slowly than I hoped). And of course, I’ve resigned myself to the reality that this site will certainly be getting a fresh coat of paint along the way with that project. Can’t pass up an opportunity to redesign the home page, right?

I’m a huge fan of the Modular Scale tool Tim Brown put together a few years ago, and I’ve used it on a number of projects to help me set up good vertical and horizontal rhythms on a number of sites I’ve designed. As soon as I read Brown’s original article at A List Apart (Off the top of my head, I know I used a scale on chriskrycho.com, independentclauses.com, jaimiekrycho.com, theinvitedbirth.com, and step-stool.io — which is to say, every site I’ve done a full design on in the last two years. Again: I’m a fan.)

That said, the modular scale can get away from you pretty easily if you’re not careful. I’m working on a couple different designs at the moment — the one for Step Stool and one for the simple, clean theme I’ll be distributing with Step Stool for anyone who cares to download and use it. (Wouldn’t that be fun — to discover one of my designs on some random blog or site? I can see where WordPress theme designers get their kicks.) In both cases, the modular scales I’ve generated have been pretty robust.¹ As a result, I ended up with a rather ridiculous SASS file with the modular scale embedded for both of them, with tons of sizes that I’ll never use.

More importantly, though, most of those sizes I should never use. This struck me tonight as I was looking at the Typeplate framework. One of the neat little SASS mixins they have defines a limited set of heading sizes — just nine sizes total, in fact. By contrast, the modular scale tool will happily spit out a table with 36 different values on it. Let’s be honest: if I use all 36 of those values, or even if I don’t choose from among them discerningly, my site is going to be just as much of a mess as if I eyeballed it. (Probably more.)

The trick, then, is to use the principles of good typography with the tools available to make good choices about which sizes from the scale to use. (Limitations are often one of the most powerful tools in any creative process.) As the folks over at Typecast put it:

Limiting your typographic scale can improve your typography considerably. And rather than arbitrarily plucking type sizes out of the air, ratios will ensure your intervals are consistent and your scale harmonious.

The modular scale tool gives you the latter bit. Limiting the number of pieces from the scale, and choosing those elements sensibly? That, you have to do yourself.

More reading

• “More Meaningful Typography,” Tim Brown, A List Apart
• “Scale and Rhythm,” Iain Lamb — itself both an essay and a tool for demonstrating both scale and rhythm
• “Contrast Through Scale,” Christopher Murphy, Typecast

As of a couple hours ago, my newest personal project has a website. Step Stool, the static site generator I’m writing in Python, now has a home at step-stool.io.¹ If you visit the site, you’ll see that, while it looks nice (at least: I think it does), there’s not much to it and most of the links don’t go anywhere. The link that does go somewhere tells you that the project for which the website exists doesn’t actually have any functioning code, yet.²

(That gorgeous logo? Designed by the absolutely brilliant Cameron Morgan.)

So why is it live? There are a few reasons. First, the whole point of the project is my having fun with programming. Web design may not be directly involved in finishing Step Stool, but it definitely scratches the fun itch just as effectively. Second, and more importantly, it’s allowed me to get some time in with other technologies I’ve been interested in for a while – specifically, SASS. I’ve been frustrated with all the problems SASS solves in CSS for a while now, and I’ve known I wanted to just go ahead and learn it for a while. I just haven’t had a project where it made sense – until now. Read on, intrepid explorer →

I discovered a fascinating, brilliant trick you can use with any YouTube video name string while talking with Stephen Carradini yesterday. I shared a Doctor Who clip (this one, if you’re curious), and it took him a bit to get around to watching it because the URL didn’t exactly make it particularly clear what video I had sent him:

http://www.youtube.com/watch?v=LakwV3P3qII

We started talking about how YouTube should tag the name onto the end of the link, so that people could actually tell what video they were going to see, and Stephen posted an example of how it could work:

http://www.youtube.com/watch?v=LakwV3P3qII_drwhoblink

Lo and behold: that link works. I got curious and started poking around at different videos on YouTube and quickly discovered that you can append whatever text you want after the video ID; you’ll end up at the base URL again. All of YouTube’s link IDs are 10 character strings, with some mix of letters, numbers, and underscores allowed. Everything after the tenth character gets stripped. (Almost everything, that is…)

That’s halfway to fantastic — but only halfway because, as noted, you just get pushed down to that stripped URL. Thus, when I clicked on Stephen’s link, it truncated back down to the original link I sent him. Fine and good for one person, but what if you wanted to re-share it? The link has been changed, so you’d have to go back to where I originally shared it with you, or you’d have to add it on yourself.

Knowing a whee little bit about how these things tend to work,¹ I wondered what happens if you use an & to tell YouTube that you want to add something to the query you’re sending it.² As I suspected, YouTube hangs onto that. Most likely, there are other queries that include more than just the video name — things like content source — so those parts get left in. In our case, that means that we can add a string to the link and it will be there for others to use if they want to reshare the video themselves.

Anybody who curiously hovered over (or clicked to) the Doctor Who video I referenced at the start of the post went to this link:

http://www.youtube.com/watch?v=LakwV3P3qII&name=DoctorWhoWibblyWobblySpeech

It’s like magic! You can see what the video is about, and even when you click the link, you still have the name of the video to share with all your friends!

And there ends your lesson in cool tricks with YouTube for the day, kids.

Markdown took over my writing life this semester, as I’ve mentioned. I took nearly all my class notes in Markdown (after a brief interval of using Evernote and an even briefer pass with Microsoft Word—neither of them quite worked for me, especially as my addiction grew). The only hiccup with my growing delight in the combination of Markdown and Byword was the challenge of writing papers in them. There was little question for me that it was worth the few additional wrinkles it entailed, however: a nice clean writing environment and the obviousness of Markdown (not to mention the revision-history– and version-control–friendly nature of plain text) inclined me strongly toward using it.

For main paper content—all those lovely paragraphs I hammered out—Markdown was sublime. The trick for my papers this semester, though, was something core to any academic writing: footnotes. Read on, intrepid explorer →

Things currently on my near-term radar, web development-wise:

• Finish up a web site that I’m doing pro bono for a friend. This one’s been on the back burner since we moved, but I’d like to actually get it knocked out at the beginning of the summer. Read on, intrepid explorer →