Filed under: “Posts”

New Sites Live

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 using one of their upgrades for a hosted site on her own domain. I was unsurprised to hear she was outgrowing, 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 (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, 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,1 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?

  1. Just to be incredibly clear: Sarah was a great client, and I have no qualms about working with her again in the future. Likewise, the work I’ve done pro bono for Mere Orthodoxy is just grand as far as I’m concerned, and I have another couple friends with similar projects potentially in the pipeline. But unless things get really desperate, the likelihood that I’ll be taking PHP or WordPress jobs from random folks on the web is… low at best. 

Modular scales: fantastic, but don’t overdo it

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,,,, and — 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.1 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

  1. In case you’re curious: the Step Stool scale and the Clean theme scale

YouTube Video Name trick

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:

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:

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,1 I wondered what happens if you use an & to tell YouTube that you want to add something to the query you’re sending it.2 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:

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.

  1. For the technically inclined (before you run away, note that footnote 2 is for those who are not technically inclined — confusing, I know): it looks like it’s probably a straightforward hashing algorithm designed to produce 10-character strings in whatever subset of ASCII the YouTube engineers settled on. Because of that, they can safely ignore everything after the tenth character: every single YouTube video has the same length ID. Your video could be named “Joe” or “John Jacob Jingleheimer Schmidt” and the result would be a ten-character string. This is quite smart: it prevents intersections between video names (your video named “Joe” ends up having a different string than my video named “Joe” because of how the hashing algorithm works), and it means that YouTube video links are never all that long. 
  2. For the not-so-technically minded: in other words, the string at the end of the website tag is a question: Can I watch the video (watch?v) you know by this name (={10 character string})? You can tell websites you want to ask another question at the same time by adding an ampersand character to it and extending the string. 

Markdown and Academic Writing

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 →

Current plans

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 →

Kindle Custom Fonts Paperwhite info

Just a quick note that I’ve updated my original post on custom Kindle fonts with info for the Touch and Paperwhite (at least if you have current firmware).

Why I Love Markdown

For about the last two months, I’ve steady been moving toward doing all my writing in Markdown. Truth be told, I’ve been moving that way slowly off and on before that, having been looking for a simple syntax like it for quite some time. I’d spent some time writing in Textile—a number of my posts for Pillar on the Rock were composed with it, and I’ve even used it on this site in the past with a (now-largely defunct and therefore unlinked) plugin. Textile is great in a lot of ways – if you’re looking for a syntax that maps directly to HTML. (In fact, if that’s what you’re looking for, Textile is much better than Markdown.)

Then, over the last six months or so, I’ve been using Markdown here and there. Read on, intrepid explorer →