I designed this blog as it currently stands, in all of its fixed-width glory, back in 2008. Since then, as I have gotten a bit smarter, I have been slowing toying with updating some of the specific design elements. None of these are very revolutionary, and some are actually old hat for many, but time available is short in these parts. And what time was available was usually spent on the “getting smarter” part.

The key things that I want to accomplish are as follows:

1. Better typography with typefaces from Typekit and a solid vertical rhythm.
2. Since grids have become all the rage, get into some of that action.
3. A better color scheme.
4. Implement footnotes, or better yet, “sidenotes” in the margin , much like Jon Tan and Kilian Muster.
5. Make my home page more of a “hub” by including data from my Twitter, Flickr, and Pinboard accounts.

Some of the intermediate steps have been captured in the Lab section of the site. Specifically, the Prototype section is a living (and somewhat documented) work-in-progress of my efforts so far.

Many design professionals extoll the virtues of Photoshop to create comps and then translate those to HTML and CSS. I built some initial comps for type, colors and initial layout, but being that my Photoshop skills are infantile, I found the process long and laborious. I then changed to building an entire site of boilerplates: Home Page, Single Article Page, Archives List. I concentrated on building a proper HTML structure, using new HTML5 elements such as section, article and footer, before adding general and then specific style declarations.

Before I get into any specific elements of the new design, one tool that I have found invaluable in this process has been Sass, a CSS pre-processor. There are tons of tutorials on Sass and this won’t be one of them, but the key improvements I’ve taken advantage of are variables and functions.

Typography

I make no claim to any sort of design skills, but one area that I have studied a fair amount of over the years is good typography. ¹. A while ago I created a test page that implemented a vertical rhythm. The key aspect of maintaining a vertical rhhythm is to ensure that the line spacing of blocks of text (leading) and the spaces between text blocks or other elements on the page all equal to (or relate) to a specific value.

Here is a basic example, given a base font-size of 16px and a line-height of 1.5, our vertical rhythm is 24px. This example will also use ems for sizing type, so 1.0em = 16px.

1
2
3
4
5
6
7
8
9
10
11
12

body	{
  font-size: 100%  /* = 16px */
}
	
#wrap	{
  font-size: 1.0em;
  line-height: 1.5em; /* 24px */
}
	
p, ul, ol, img, h2, h3, h4 {
  margin-bottom: 1.5em; /* 24px */
}

If we wanted h3 headlines to be a larger size, say 18px, we use the formula:

Desired Em Size = Desired Px Size / Context Px Size.

So 18px / 16px = 1.125em. Just setting font-size: 1.125em; on h3 elements would break our vertical rhythm because the bottom margin of the h3 would no longer be the desired 24 pixels:

1.125em(h3 size) * 1.5em(bottom-margin) = 1.6875em

And 1.675em * the base font-size of 16 is 27px. So we have to change the bottom margin of h3 (and line-height) using the same formula:

1
2
3
4
5

h3 {
  font-size: 1.125em;    /* 18 / 16 = 1.125em */
  line-height: 1.333em;  /* 24 / 18 = 1.333em */
  margin-bottom: 1.333em;
}

That is all well and good, but if there are more than a few elements with different sizes, that is a lot of math to crank out. When I first started working on maintaining a vertical rhythm, I actually built an Excel spreadsheet to calculate everything:

However, if I decided to change the base font-size or line-height for whatever reason, I would have to go back and manually change all the CSS declarations.

Sass to the Rescue.

This is where variables and functions in Sass can make this easy. Here is an extract from the typography section of my Sass variables partial:

1
2
3
4
5
6
7
8
9
10

$base-font  : 16;
$base-lh    : 1.5em;
$base-vr    : 24;  // 16 * 1.5 = 24px

// Convert Pixels to EMs (Desired = Target / Context)
	
@function em($target, $context: $base-font){
  @if $target == 0 {@return 0}
  @return $target / $context + 0em;
}

The em function takes two arguments: my desired font-size in pixels and the pixel size of the context it is in. These arguments are variables and the em function is declaring both of them: $target and $context. This latter argument defaults to the $base-font variable that I declared in the beginning (which is 16px), if I pass it nothing else. In my redesign, here is the declaration for h2 elements in my Sass file:

1
2
3
4
5

article h2 {
  font-size: em(24);
  line-height: lh(1, 24);
  margin-bottom: lh(1, 24);
}

I’ve passed a desired size of 24px to the em function, which then does the following:

1
2
3

@return $target / $context + 0em
  24 / 16 
  = 1.5em

I have the + 0em to add em to the returned value since I’m using unitless numbers.

The lh function is used to help maintain the vertical rhythm. We’ll get to this function in a minute. Here is the CSS that SASS creates for the above article h2 declaration:

1
2
3
4
5

article h2 {
  font-size: 1.5em;
  line-height: 1em;
  margin-bottom: 1em;
}

With SASS doing all the math, and me doing none, I get the desired font size of 24 px converted to ems, and the line-height and bottom margin are also 24 pixels (1em * 1.5em, which is 24px). And 24px is my desired vertical rhythm.

A key aspect of a vertical rhythm is that it is a “rhythm” and not a rigid scale. Bringhurst writes about deviating from a vertical rythym, but doing so in multiples of the base “leading” or line-height in CSS terms. The lh function accepts a multiplier as its first argument and the context size in pixels as the second:

1
2
3
4
5

// Maintain vertical rhythm with Line Height
	
@function lh($amount, $context){
  @return em($base-vr * $amount, $context)
}

Here is another example from my Sass typography partial:

1
2
3
4
5
6
7

.entry h3 {
  font-weight: bold;
  font-size: em(18);
  line-height: lh(1, 18);
  margin-top: lh(1.5, 18);
  margin-bottom: lh(0.5, 18);
}

I want the top margin of h3 elements to be 36px (1.5 * 24px) and the bottom margin to be 12px (0.5 * 24). These add up to 48px, which is an even multiple of the base line-height. Let’s break this function down a bit.

Remember that the formula for calculating a desired em size is:

Desired Em Size = Desired Px Size / Context Px Size.

Since I have changed the font-size of the h3 element to 18px, the context has changed as well. Manually calculating the margin would be as follows:

1
2

36px (which is 1.5 * 24) / 18 (new context)
  = 2.0em

The lh function takes the multiplier (1.5) and the new context (18) as arguments. It multiplies the $base-vr variable (which I declared to be 24) by the multiplier (24 * 1.5 = 36) and passes the result as the first argument ($target) to the em function and passes the second argument (18) as $context to em:

@return em($base-vr * $amount, $context)

Again, the em function is just calculating the Desired Em Size formula: 36 / 18 = 2. The generated CSS for the .entry h3 declarations is:

1
2
3
4
5
6
7

.entry h3 {
  font-weight: bold;
  font-size: 1.125em;
  line-height: 1.33333333em;
  margin-top: 2em;
  margin-bottom: 0.66666667em;
}

The line-height passed a multiplier of 1.0 in order to keep it at the baseline vertical rhythm of 24px. If you never need to deviate from this rhythm, the lh function is not required and you could just use the em function to calculate margins for elements that have different font sizes.

WTF?

You could be forgiven for thinking that this is a lot of work, but what if you decide in a week or year to change your default font-size, or vertical rhythm? All that is required to update your initial variables:

1
2
3

$base-font  : 18;
$base-lh    : 1.5em;
$base-vr    : 27;  // 18 * 1.5 = 27px

Save your Sass file and…you are done. Every single CSS declaration that uses a em or lh function will recalculate in your updated CSS file. A Google search for ‘Sass vertical rhythm’ will return a plethora of pre-built functions and extensions that just need to be included in your own files. Or use mine.

More Sass Typography Goodness

Designer Mark Boulton wrote an article about incremental leading, which is changing the vertical rhythm of elements with smaller font sizes if the default leading is too large. The new rhythm for these elements is not a complete departure from the base line, but is in sync with it by aligning say every 5th line of smaller text with every 4th line of main text (just read the article if that sounded confusing.) Here is a Sass function I wrote that accomplishes this:

1
2
3
4
5
6
7

// Incremental Leading
// Every 'y' line of affected element will 
// align with every 'x' line of main text
	
@function incr($new-size, $x: 4, $y: 5){
  @return 1em * (($base-vr / $new-size) * ($x / $y))
}

Let’s say we wanted sidebar text to be 15px and use the above example values. Here is the Sass declaration:

1
2
3
4

.sidebar {
  font-size: em(15);
  line-height: incr(15, 4, 5);
}

With no more effort on my part, other than to hit ‘Save’ in my text editor, the following CSS is output:

1
2
3
4

.sidebar {
  font-size: 0.9375em;
  line-height: 1.28em;
}

Another area where I have found Sass variables to be helpful is with defining font-family groups like so:

1
2
3
4

    $serif-ff:	"ff-tisa-web-pro", Cambria, Georgia, serif;
    $sans-ff: 	"proxima-nova", Corbel, sans-serif;
    $title-ff:	"adelle", Georgia, serif;
    $code-ff :	"DejaVu Sans Mono", Consolas, "Courier New", monospace;

Throughout my Sass files I have declarations such as:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

h2, {
  font-family: $title-ff;
  font-size: em(24);
}
	
h3, {
  font-family: $title-ff;
  font-size: em(20);
  font-weight: bold
}
	
/* Couple of hundred lines later...*/
	
.description	{
  font-family: $title-ff;
}

If I want to change the typeface used for titles, rather than search through my CSS file for all affected elements, I just change the $title-ff variable, which are listed right below my other typography related variables.

Sass has a ton of features such as mixins and the ability to extend CSS selectors, but just using variables and functions has been a huge help in quickly experimenting with different aspects of web typography.

Upcoming articles in this redesign series:

1. Using Susy to create fluid grids
2. Colors by Solarized
3. Creating Sidenotes
4. Good web type with Tyepkit
5. Leaving Movable Type and the alternatives

The upper crust of the nerdier corners of the internet was all in a tizzy the last few days about App.net, an upstart social network and accompanying API that was following the Kickstarter model. Their “funding period” expired this weekend and they made their goal ($500K) with 37 hours to go.

Full Disclosure Up Front: I joined.

Dr. Drang and Macdrifter both have succinct and frank observations about the whole situation. Here’s Macdrifter:

I think App.net is more about wanting to cut-off an entire segment of Twitter’s users and paying for the privilege to do it.

And Dr. Drang:

An unstated, but I think powerful, motivation for people to sign up for app.net is the fear that it will take off and you’ll be late to the party. Too late, perhaps, to get the username you want. One of app.net’s appeals is thinly veiled extortion. Nice Twitter handle you got there. Would be a shame if somebody else took it.

I don’t have a high-minded explanation for why I joined, but the get-in-early factor was a consideration. I’m not sure it was about claiming my Twitter handle. I’m Twitter user #73,068,565 and ‘nealsheeran’ was still available.

I have no idea how App.net will turn out. I haven’t even gotten access to the “alpha” yet. I may have flushed $50 down the toilet, although I have wasted more money on much dumber things. But if it turns out to be the coolest thing ever, I can at least say I was in the initial group of a 1000 people that knew it would be.

Yesterday was John Gruber’s 10th anniversary of running Daring Fireball. Besides reminding me that my tenth year of “blogging” is approaching in a few months, I thought back to when I first read DF and up through to now.¹²

My first Mac was a Titanium PowerBook G4³ that I got in the spring of 2002. Shortly thereafter, after reading some blogs, I got interested in blogging and then learning about HTML and CSS so I could change the design of my site away from the default Movable Type template that it was born with. I don’t exactly remember how I first found out about DF, but I do remember pretty much blowing off a whole day in the office and going back and reading all of Gruber’s previous entries. This was sometime in early 2003, so that only took about a day. I enjoyed his succinct and sarcastic writing style and his articles were informative to a new Apple user.

One of the first web design books I ever purchased was Jeffrey Zeldman’s Designing with Web Standards and I found out about it because Gruber put a small picture of it in the corner of his site. Back then, a CSS selector looked about as complex to me as some sort of esoteric algorithm written in <insert obtuse programming language>. I remember admiring the simplicity of Daring Fireball’s design (pretty much unchanged to this day) and actually printing out Gruber’s HTML source and CSS file so I could try and learn how he laid out his site.

I have read DF pretty much every day since then. And I have to admit that I like the old John Gruber better. Back then, even though he was quickly becoming a big fish in the Apple blogging pond, that was still a pretty small pond. And Apple itself was still the scrappy player it had pretty much always been.

Now, Apple has become a behemoth. And I’m pretty sure Gruber wouldn’t be caught dead these days writing posts like An Anthropomorphized Brushed Metal Interface Theme Shows Up for the WWDC Preview Build of Mac OS X Leopard, where he assumes the identity of the OS X Brushed Metal interface to poke fun at its demise. And if you would have asked 2003 Gruber if he would have been invited to a private meeting with Apple to discuss a unreleased product⁴, I’m willing to bet his response would have been along the lines of “no f#$%ing way”.

That’s not to say that I think Gruber is a shill for Apple, not at all. But he has become such a huge player on the Apple scene, that I think the topics that he writes about (or doesn’t) have changed. And, at least to me, it seems that some of his entries to DF nowadays seem mailed in. I have listened to a handful of episodes of his Talk Show podcast, and maybe the arrogance was always there but there was no avenue for us readers to bask in it, but it is definitely on display. When I say “arrogance”, I mean acting utterly disinterested in the whole podcast affair, other than going through the motions in order to what one can only assume is to collect sponsorship dollars.⁵

I still think Gruber is an excellent writer and blogger. His post about the death of Steve Jobs was one of the finest pieces of writing I’ve read, regardless of medium, in a long time. This blog post, along with pretty much all the others, is written in Markdown, a web-writing tool that he created and used by thousands. He pioneered the Linked List-style blog post that has been copied by legions of other bloggers, including this one.

John Gruber is a blogging force, and his obnoxious love for the NY Yankees aside, I hope he continues to be one. I just wish he would be a little less lofty these days.

I came across this article about Phil Zimmerman, the inventor of Pretty Good Privacy (PGP) getting together with some former Navy SEALs (!!!) to create a new encrypted communications platform. A pretty cool concept that brought back a few memories.

I remember downloading PGP from an anonymous FTP server (!!!) back when I was in college. It was version 2.something or another and only ran from the DOS command line of my Gateway 2000 PC (!!..enough already). It also lead to my first O’Reilly book purchase. Part of my fascination with having a copy of PGP was this (from Wikipedia):

Shortly after its release, PGP encryption found its way outside the United States, and in February 1993 Zimmermann became the formal target of a criminal investigation by the US Government for “munitions export without a license”. Cryptosystems using keys larger than 40 bits were then considered munitions within the definition of the US export regulations; PGP has never used keys smaller than 128 bits so it qualified at that time. Penalties for violation, if found guilty, were substantial. After several years, the investigation of Zimmermann was closed without filing criminal charges against him or anyone else.

I have had a version of PGP installed on every computer I have ever owned. My first Mac was a Titanium G4 Powerbook and when I first got it, PGP only ran under Classic. Just a few months ago, I upgraded my current PGP install to be compatible with Lion.

In all those years (around 18), I have never once sent an encrypted email with it or encrypted any files other than to test it out. But it has been nice just having it. You never know.

In fact, if you have some super-secret info to pass on, my public key is here.

There has been more than a few posts in the blogverse about Apple withdrawing all of their products from the green registry EPEAT. As a result, the city of San Francisco (and maybe Berkeley to follow) will no longer purchase Apple products.

This is just dumb. Predictably dumb, for sure, as we are talking about San Francisco. But I do find it interesting that none of these bloggers called them on it. One can almost sense across the interwebs the conflict between calling a spade and spade (silly policies that make liberals feel good as opposed to actually fixing anything) and not upsetting the environmental apple (sorry) cart.

One sense of conflict could be that most of these bloggers couldn’t wait to get their own hands on the new and shiny, but can’t-be-recycled Retina Display MacBook Pro.

Update: Apple folds like a cheap deck chair.