Hypsometry. Modal Synthesis.

On music, and simplicity, and success.

Muxtape is incredibly simple: Upload some songs and you’ve got a mix.

As a friend of mine wrote:

It feels like there’s nothing to it. But really, I like that. There seems to be little space for people’s overblown internet identities. Only jams.

So true. No friends, no profiles, no activity updates, no notification emails—just the music. All you need, and nothing more.

You can listen to my current mix at cboone.muxtape.com.

On tea, hand printing, layers, type, and the door to my kitchen.

Last week I spent a few days brainstorming the design of our new site. That included a lovely afternoon at Samovar, sketching, rereading Bringhurst, and looking through Typography 28, last year’s edition of the Type Directors Club annual.

The work in it – both the winners and the other selections – is superb, as it should be. The winning poster, for a Wilco show, was created by Hammerpress, a design and letterpress studio in Kansas City, Missouri. It’s a beautiful, subtle, and elegant piece of work.

Hammerpress and Brady Vest, the studio’s founder, have six other posters featured in Typography 28. All of them letter pressed in a style that’s old fashioned in its components – the typefaces, the decorations, the centered text – but contemporary in its execution. You can see more of their poster work in their site’s gallery.

One thing all the pieces have in common are colors that overlap in a dense, bright, but coherent jumble. Each print is built up from layers of ink, whether type or image or decoration, one atop the next.

Coincidentally, I bought a Hammerpress print the other day. Four layers of white ink on a brown stock.

I didn’t buy it directly from the studio, but from the Curiosity Shoppe, which just recently opened up a storefront down the street from me. They sell a variety of beautiful but odd things. Right now they’re showing a series of giant felt handguns by Sarah Moli Newton Applebaum.

But no, sadly, the new site will be neither felted nor letterpressed.

On tradition, harmony, pitch, the atonal, typography, Fibonacci, and coincidence.

Harmony and pitch.

In §3.1.1 of The Elements of Typographic Style, Robert Bringhurst draws an analogy between the sequence of type sizes traditionally used by typographers and the diatonic scale.

In the sixteenth century, a series of common sizes developed among European typographers, and the series survived with little change and few additions for 400 years. [...] This is the typographic equivalent of the diatonic scale. But modern equipment makes it possible to set, in addition to these sizes, all the sharps and flats and microtonal intervals between.

In other words, modern typesetting – done via software and printer, instead of type and press – allows the atonal. Unlike in music, however, alternate systems have not arisen.

Further, typesetting on the web makes it not just possible to avoid the traditional sizes, but actually difficult to set them. There are so many issues involved: Which browser is being used, what its defaults are, what units you use to specify sizes, the flow of inheritance of sizes through the page, etc. If you’ve done more than a dab of web design, you’re well familiar with how complex type sizing can be.

But what’s important here is not the precise size of each piece of text on your site, as rendered on the client by a browser. What matters is the size of each piece of text relative to the others.

To put it again in musical terms, the specific frequency of the note is less important than the overall structure of the scale containing that note. Harmony, not pitch. As if typesetting had returned to the days when one orchestra’s A was quite different from another’s.

The tradition.

Here’s a section of that traditional sequence, set for the web:

Long primer (10 point).
Small pica (11 point).
Pica (12 point).
English (14 point).
Columbian (16 point).
Great primer (18 point).
Double small pica (21 point).
Double pica (24 point).
Double great primer (36 point).

The traditional scale continues both above and below the sizes shown here. But this seems pretty much enough for the web. Much smaller, and the type is hard to read. Much bigger, and you’re dealing with a strange case.

Implementing this system is simple. Sticking to it rigorously, in the absence of any external constraints, is the hard part.

Implementation, in theory.

Following Richard Rutter’s text sizing method, I start by declaring the font-size of the document’s body:

body {
font-size: 100%;
}

This minimizes text size variation across browsers, especially in the extreme (large and small) sizes. 100% is, in theory, equal to 16px. User defaults and zooming can easily change that, even if nothing else does. But that’s okay: All I’m concerned with is the relative sizing of the type.

All the sites I’ve designed recently have had a wrapper div containing the entire contents of the page. Like so:

<body>
<div class="everything">
The whole damn page.
</div>
</body>

I can take advantage of that wrapper div to bring down the whole page’s font-size to 10px:

#everything {
font-size: 0.625em; /* 16px * 0.625 ≈ 10px, or long primer size. */
}

10px is great, both because it’s about the smallest size I care to use normally and because it simplifies the following math tremendously. All the visible contents of the page are contained within div#everything, so all the elements will inherit a computed font-size of 10px. So I can resize them in in terms of em, which is effectively a simple multiplier. To get 14px type all I have to do is multiply the inherited value by 1.4: font-size: 1.4em.

You might note that I’ve blurred the distinction between points and pixels. (Oh lord. Let’s not get into the whole pixel unit discussion.) And I’m talking about things in terms of pixels as if their sizes could be possibly be fixed. But again, neither matters here. What matters are the relationships between the numbers, not the actual numbers themselves. It’s a matter of harmony, not frequency.

You might further note that I’m not declaring the line-height of anything, nor discussing it at all. line-height is another story entirely, and one I’ll deal with separately.

At any rate, I can go on and declare the type sizes of some common elements based on the page-wide default of 10px I’ve set:

h1 {
font-size: 2.4em; /* 10px * 2.4 = 24px, or double pica size. */
}

h2 {
font-size: 2.1em; /* 10px * 2.1 = 21px, or double small pica size. */
}

p {
font-size: 1.2em; /* 10px * 1.2 = 12px, or pica size. */
}

Simple enough. Though, as I said above, the theory of the implementation is easy.

Systems.

This is not about blind adherence to tradition. A coherent, harmonious system is more likely to produce elegant and satisfying results than a haphazard jumble.

Other systems are, of course, possible. Bringhurst, in §8.2, suggests alternatives based on the Fibonacci sequence and the golden section, including two different double-stranded Fibonacci series, one used by Le Corbusier in his Modulor scale.

Those are intellectually satisfying, but their actual make-up seems less useful for typesetting on the web. The Modulor system uses fractional sizes, and browser sub-pixel rendering problems are ample enough in normal usage – no need to encourage them. And both sequences are lighter on sizes in the low end of the range, which seems the most useful part of it for web work.

The traditional sequence seems good enough for my purposes.

Coincidence.

Also note that today’s date, as written in the States, is 3-5-8, which makes today a sort of Fibonacci day.

On passwords, forgetfulness, and ease of use.

A problem.

Every site that allows password sign in has a little link on its sign in page. Sometimes it reads as a question: Forgot your password? Sometimes a first person statement: I forgot my password. Sometimes it’s just a terse fragment: Forgot password.

You click it and are taken to another page, where you can ask for a new password to be emailed to you. On the forgot-my-password page you have to enter your email address. Typically the form on that page is extremely simple: Some explanatory text, a text input field, and a submit button.

When the web application receives the submitted form, it checks its database to find the submitted email address. Assuming it finds the address, the application updates the user’s password and emails them a notice about it. If it doesn’t find the address, it returns the user to the same page and complains about the failure.

All of which is simple, straightforward, well established custom. Almost every web application has this feature, and this feature works in almost exactly the same manner across the board.

But there’s one problem here. It’s not uncommon for a user, hoping to sign in to a site, to enter his email address and then realize that he’s forgotten his password. In other words, it’s not uncommon for a user to realize that he’s only got half of the needed data after having already entered the first half.

What happens then? He finds the expected Forgot password link, clicks it, and is whisked off to the forgot-my-password page. And then has to enter his email address again.

This certainly isn’t a large problem. People type their email addresses into forms all day, every day. Lots of people use form managers to do it for them. (Though the form managers probably remember their passwords too, so they’re not in this bind in the first place.) How long does it take? A few seconds, at most. How much trouble is it? Not much.

But why cause your users any trouble at all? Even a little trouble is more than necessary.

A solution.

The solution I’m using on our new site is simple. The short explanation: The forgot-my-password link uses Javascript to grab the value of the email address already entered, then appends it, as a query parameter, to the forgot-my-password URL.

The forgot-my-password link looks like this:

<a href="/account/forgot_password" class="forgot_password">Forgot password</a>

We’ve rolled our own unobtrusive Javascript library, but it functions in many ways like Dan Webb’s Low Pro. Using that, I registered a behavior handler for the forgot-my-password link:

Event.addBehavior({
"a.forgot_password" : Account.Behavior.forgotPasswordBehavior
});

In other words, all links with a class of forgot_password get extended with the behaviors defined in Account.Behavior.forgotPasswordBehavior. That behavior is simple:

Account.Behavior = {
forgotPasswordBehavior : {
onclick: function() {
if ($F("email") != "") {
this.href = this.href + "?" + $("email").serialize();
}
}
}
}

In other words, forgotPasswordBehavior defines an onclick handler that rewrites the relevant element’s href to append whatever the user has entered in the email field. It uses Prototype to get the value of the field and rewrite it in name=value format, so that it can be passed as a URL query parameter. And it only does its work if the user has actually entered something in the email field. No point in adding the useless ?email= to the URL.

Then, in the forgot_password.rhtml view, the email field is generated like this:

<%= form.text_field(:email, :value => h(params[:email])) %>

Which creates the appropriate field using the email passed as a URL parameter as its value, if one exists.

Any user who has forgotten his password and wants to request a new one has implicitly declared his desire to use your site, and to use it now. Seems like anything you can do to help him with that is a good thing.

On nothingness, degrees of okay, bodies, success, and freaking out.

Sometimes, on Rails, you don’t want a controller method to render anything. For instance, an AJAX request might only need to know that the action succeeded. The status of the response is enough to communicate that, with no rendering required.

So you write render(:nothing => true). Rails renders nothing for you, and, by default, returns a successful status code (200 OK). Simple enough.

But how do you test for that? It’s easy to test for redirections (assert_redirected_to), successful template renderings (assert_template), and specific responses (assert_response). But testing for nothingness?

Rails renders nothingness as “ ”. Not an empty string, that is, but one space.

From a certain theoretical perspective, this is not exactly right. Nothingness in response to a GET should probably return a 204 No Content status code. After all, that is precisely the HTTP definition of “nothing to render”. And, in that case, the protocol dictates that no body be included in the response. Which seems perfect, right? Declare that you’ve got nothing to render and render nothing, communicating success implicitly. Simple and sweet.

(Things get more complicated when dealing with HEAD requests. In that case the client has explicitly asked for the headers and nothing but the headers, with no response body needed.)

However, theory tends to fall apart a bit when in the face of actual browsers. The good folks at Yahoo have looked into this while building the Yahoo User Interface Library, and have figured out that IE6, IE7, Opera, and Safari can’t handle the 204 when it comes via XMLHttpRequest. Errors result, headers are lost, responses are left undefined, and communication failure is wrongly declaimed.

(Just to complicate things further, Safari might actually have fixed this as of 3.0. I’m not clear on that, though. Either way, it’s still a cross-browser issue.)

In other words, 204 No Content will break on some of the most common browsers when used with AJAX.

What to do? Well, pass along the only appropriate status code that the browsers can handle, for starters: 200 OK. Having done that, though, you’ve now set the browsers up to expect some sort of response with their OK. And it seems that if you give Safari a completely empty response body, it freaks out a bit and doesn’t handle the response properly.

Thus the Rails hack of redefining nothingness, in this context, as a little bit of whitespace.

Knowing that, testing for the successful rendering of nothing is easy:

def assert_rendered_nothing
assert_equal(@response.body, " ", "The response was not empty.")
assert_response(:success, "The response was not successful.")
end

Check the body of the response for being “ ” and check the status code to be sure that it indicates success. Okay, and pretty good too.

An aside, though not too far: This makes my third post on nothingness this calendar year. (Cf. nihilism and the hinterlands.) I’m not sure what to say about that.

NB: The Rails definition of success is a simple one. Really, a successful status code is one that’s not in the redirection range (from 300 to 399), the client error range (from 400 to 499), or the server error range (from 500 to 599).