Hypsometry

On music, and simplicity, and success.

hypsometry.blog@cboone.fea.st (Chris Boone) — Wed, 23 Apr 2008 02:59:00 GMT

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.

hypsometry.blog@cboone.fea.st (Chris Boone) — Wed, 12 Mar 2008 09:12:00 GMT

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.

hypsometry.blog@cboone.fea.st (Chris Boone) — Wed, 05 Mar 2008 09:30:00 GMT

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.

hypsometry.blog@cboone.fea.st (Chris Boone) — Mon, 25 Feb 2008 07:25:00 GMT

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.

hypsometry.blog@cboone.fea.st (Chris Boone) — Fri, 22 Feb 2008 17:41:00 GMT

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).

On the hinterlands, OpenID, cookies, jars, slippery beasts, indifference, patches of monkeys, and the difference between a general sort of nothing and nothingness in particular.

hypsometry.blog@cboone.fea.st (Chris Boone) — Fri, 15 Feb 2008 12:35:00 GMT

More news from the poorly mapped hinterlands of Railsia.

In our new app, we’re allowing people to sign in using OpenID. Which is cool, and progressive, and generally a Good Thing. Except for the bit that implementing it’s a nuisance.

Danny’s fully on top of the technical side, which eludes me to a surprising degree. But that’s okay, because the interface side is plenty complex enough to keep me up late. Today I’ve been working on finessing the details of the actual sign in flow, focusing on what happens when things go wrong.

We’ve got this combination sign in page with a tabbed interface, where you can sign in using either a password or an OpenID URL. Two forms, one per sign in option, although you only see one at a time.

If you try to sign in using an OpenID URL, we save that URL in a cookie called signin_openid_url. When the page is rendered, a helper method checks to see if the signin_openid_url cookie exists, and, assuming it does, renders the page such that the OpenID sign in form is visible.

Which form is displayed is determined by which form has .active applied to it. Using CSS rules like these:

#content form.content_tab
{
  display: none;
}

#content form.content_tab.active
{
  display: block;
}

Which form has .active applied to it is determined by the helper that checks the value of the signin_openid_url cookie. Here’s where we get to the hinterlands of Rails.

The helper we wrote initially was this:

def prefer_openid_signin?
  !cookies[:signin_openid_url].nil?
end

Pretty simple: Ask for the cookie identified by :signin_openid_url, check to see if it’s nil?, and return the inverse of that answer.

And it worked most of the time. Unfortunately, it only worked most of the time.

When you enter an invalid URL and submit the form, that URL gets stuck into the cookie and all is well. When you enter no URL, however, and submit the form, things go wrong. prefer_openid_signin? was returning false, even though the signin_openid_url cookie should have been set.

Examining the parameters that were being passed, and the cookies that were being created, I could see that params[:openid_url] => "" when the empty URL form was submitted. This is as it should be. According to Rails dogma, empty text fields should yield empty strings, not nil values.

Then the signin_openid_url cookie was being created, with the correct value of "". But when I asked for the value back again, using cookies[:signin_openid_url], I got nil instead of "". Clearly, the distinction between an empty string and nil was being lost somewhere along the way.

The loss starts with CGI::Cookie, which is the Ruby Standard Library’s HTTP cookie class. CGI::Cookie always returns an Array when asked for the value of a cookie. Always. No matter that most cookies have one and only one value.

Then, in its parsing of the values sent by a client to the server, CGI::Cookie manipulates things such that any empty strings become nil. To be more precise, when a client sends a cookie with an empty string as its value to the server, CGI::Cookie turns that value into an empty Array.

ActionController.cookies uses a container to hold the cookies created by CGI::Cookie. The container’s class is CookieJar, and CookieJar behaves mostly like a Hash. But not quite. More on that in a second.

Anyway, when you ask CookieJar for the value of a cookie: CookieJar checks the size of the Array that CGI::Cookie has given it, and if it contains more than one value you get the first value. But if it contains one value, or none, you get the value of what it contains. So if it contains no values, then the Array is empty, and CookieJar returns nil.

This is contrary to what the documentation in the source says, which is that nil is returned “if no such cookie exists”. Rather, nil is returned if no such cookie exists or if such a cookie exists but contains no value.

So it seems that cookies on Rails are slippery beasts. As I said above, a CookieJar behaves mostly like a Hash. The way in which it doesn’t is that it redefines the setter and the getter methods. Which borders on perverse, in my opinion. The reason for the perversity is that it needs to handle both the setting of outgoing cookies and the getting of incoming cookies. So the interfaces for the two actions are necessarily different. However, that still doesn’t explain why they chose to combine the two different actions into one pseudo-Hash is beyond me. Why not create a new, appropriate, non-confusing interface?

Double anyway. Even though getting and setting cookies in a CookieJar doesn’t work like a Hash, you’d think it would work like a Hash in other regards. You can’t rely on it to return the values you give it, but you’d think it would be able to tell you if it has a key in it or not.

I’d think. Or I thought, so I rewrote the prefer_openid_signin? helper to just check the CookieJar for the presence of the relevant key. (Which corresponds to the existence of the relevant cookie.) As follows:

def prefer_openid_signin?
  cookies.has_key?(:signin_openid_url)
end

No. No luck. Bah. Back to the source.

CookieJar, unlike every other use of Hash in Rails, is not a HashWithIndifferentAccess. Which means that if you give it a Symbol as a key when setting a value, you must use the same Symbol to get the value back. And if you use a String to set, you must use a String to get.

But that’s okay, right? Since my OpenID URL cookie creating helper looks like this:

def remember_signin_openid_url(url)
  cookies[:signin_openid_url] = { :value => url, :expires => 10.years.from_now }
end

The helper sets the cookie using the Symbol:signin_openid_url, so the other helper should be able to get it using the same Symbol. Right?

Wrong. CookieJar only uses Strings as keys. If you pass it a Symbol, it converts it to the corresponding String, and never looks back. Symbols not welcome here.

Okay, got it. So I rewrote the helper as follows:

def prefer_openid_signin?
  cookies.has_key?("signin_openid_url")
end

Ah. Which totally works.

But that’s annoying. I don’t want to have to remember that dealing with cookies is the one time on Rails when I need to care about whether I’m using a Symbol or a String. (And I’ve been bitten by this same, um, quirk when testing cookies.)

Thank goodness for monkey patching. I wrote the following:

module ActionController
  class CookieJar < Hash
    def has_key?(key)
      super(key.to_s)
    end
    alias :contains? :has_key?
  end
end

And put it in lib/cookie_jar.rb, and required it in the appropriate initializer.

Now I can check for the existence of a cookie by checking for the existence of the corresponding key, or in more elegant fashion by asking cookies.contains?(:signin_openid_url). That’s still one more hoop than I really should have to jump through, but at least it’s only one.

On consumerism, compost, camping, framing, high-density polyethylene, recycling, and doing the right thing.

hypsometry.blog@cboone.fea.st (Chris Boone) — Mon, 11 Feb 2008 10:50:00 GMT

Like most people these days, I order a lot of stuff. I’m big on buying locally, of course, but there are a lot of things that I simply can’t get locally, at least not without significant expenditures of time and energy.

Pretty often that stuff comes shipped in Tyvek envelopes. Tyvek’s great stuff, in a lot of ways: I’ve worn protective suits made of it while mucking out composting toilets at Farm and Wilderness, I’ve used it as an ultralight groundcloth while camping, and I’ve wrapped houses in it during construction.

Even though it’s just a fancy HDPE plastic, envelopes made of Tyvek are not generally recyclable. The same plastic (#2) in bottle form is easy to recycle; some places, like San Francisco, even allow recycling of HDPE tubs; but almost no one will recycle HDPE envelopes.

Turns out, however, that DuPont themselves will recycle your Tyvek envelopes, free of charge. Take one Tyvek envelope, turn it inside out, fill it with other Tyvek envelopes, and address it to:

Tyvek Recycle
Attn. Shirley Cimburke
2400 Elliham Avenue #A
Richmond, VA 23237

I guess that’s not totally free of charge: You have to pay a bit of postage.

And it’s a bit strange shipping stuff back across the country to be recycled. Is it worth the energy use? In other words, is the energy used by the shipping back, and then the recycling itself, less than the energy wasted by simply throwing the envelopes out? Maybe I should write Shirley a note.

On Aquarius, Camino, proper server behavior, searching, and laziness.

hypsometry.blog@cboone.fea.st (Chris Boone) — Fri, 08 Feb 2008 05:17:00 GMT

As I mentioned, I spend a fair amount of time on the Aquarius Records website. They carry stuff that no one else has, and their reviews are fabulous.

(An aside: A few weeks ago, I found myself in Other Music, trying to decide whether to buy a CD. I didn’t quite trust their opinion on the matter, so I busted out my phone, went into Safari, and found a review of the CD on the Aquarius site. That should give you a sense of the situation.)

Their site is plenty functional, though if your eyes are as sensitive as mine, I wouldn’t recommend viewing the source. The main way to interact with it is through the keyword search. However, the muscle behind the search is a CGI script (stored in /bin, of course), to which the search form POSTs.

This is annoying. Because the form POSTs your search, the URL of your search results is always the same, no matter what you searched for: http://aquariusrecords.org/bin/search.cgi. If you reload that page, you’ll get an annoying dialog box from your browser, checking to make sure that really want to do that. If you bookmark that page and return to it later, you’ll get an Internal Server Error message. Ditto for copying and pasting the URL (to email to a friend, for instance).

What the site should be doing, of course, is redirecting your search to a URL that responds to GET requests and that contains the searched for string in the URL itself. (Post, redirect, get, that is.) Then all those little annoyances would go away.

It turns out, however, that Aquarius’s search script doesn’t actually care whether you POST or GET to it. The string to be searched for needs to be passed as the search_string parameter, and that’s enough: http://aquariusrecords.org/bin/search.cgi?search_string=daniel higgs, for example. Which is fully bookmarkable, copy-and-pasteable, reloadable, and error free.

Camino is my main browser these days. One of its many cool features is the ability to create search shortcuts. I’ve got a whole pile of them set up, for all the different searches I perform often: Wikipedia, the weather, Amazon, movies, Yelp, the library, etc.

To create one for Aquarius:

I went to a search URL that I had created, http://aquariusrecords.org/bin/search.cgi?search_string=daniel higgs, and bookmarked it, changing the name to the more general “Aquarius Records Search”.
Then I went to Camino’s bookmarks page and edited the bookmark’s URL to be http://aquariusrecords.org/bin/search.cgi?search_string=%s. That’s the key: Change the search string to %s. Camino will automatically replace %s with your search string.
Last, I assigned the shortcut aq to the bookmark.

Now I can type aq paul metzger into Camino and go directly to the Aquarius search page for Paul Metzger. Simple and easy, and good for your ears.

You can read more complete information on Camino’s search shortcuts on their documentation page. Firefox has the same feature, and I think Saft adds a similar feature to Safari.

On habits, simplicity, obsolescence, and Zachary Schneirov's sense of humor.

hypsometry.blog@cboone.fea.st (Chris Boone) — Thu, 07 Feb 2008 08:33:00 GMT

For a few years now I’ve been using Notational Velocity for, well, for just about everything. As its author, Zachary Schneirov, puts it:

While there are many, many note-taking programs for Mac OS X, Notational Velocity is the only one that actually operates in a useful manner.

It’s as simple as it possibly could be, and all the more powerful for that. All you do is write notes and search for text, and there’s one interface to perform both those functions.

The components are simple: There are notes, and each note consists of a title and some body text. (Completely plain text.) And you can see a list of your notes, in which each entry shows both the title and the beginning of the body text. And there’s a search bar, which is the most powerful part.

For instance, I keep my todo list in a note called “today”. To get to that note, I start typing “today” into the search bar. The search bar autocompletes (in a soft, unobtrusive manner, unlike iTunes, for instance) what I’m typing. At the same time, a list of all notes containing (in either their titles or their bodies) whatever I’ve typed so far. By the time I’ve typed “to”, the note titled “today” has been selected for me. In addition, I can see all the other notes I’ve created that contain “to”, such as a note that contains the address of a friend in Washington, a note that contains my serial number for Toast, a bunch of notes with my full name Christopher, and so on.

So that’s simple enough. I just select the note I want from the list, tab into the main text editing area, and do whatever I need to do.

One entry in my current todo list is “call Fernwood”. If I type “fernwood” into the search bar, the list of notes narrows down to just one: “today”, where I’ve reminded myself to make a camping reservation for a folkYEAH show. But because there’s no note with the title “fernwood”, Notational Velocity only shows me that note in the list; it doesn’t select it. If I tab into the text entry field, then the application will automatically create a new note for me, with the title “fernwood”, where I can enter my reservation information.

In other words, the search bar tries to find what you’re looking for, but if it can’t, it assumes that you’re creating something new. Simple as could be.

Notational Velocity has a bit of a cult following. I think I first read about it on 43 Folders, back in 2004. Unfortunately, Schneirov stopped updating the application as of version 1.1.1, which was sometime back in 2005. Which means that there’s no Intel version available, which means that it’s dying a slow death.

Last summer PJ Hyett created a Rails version of the application for the web, called vJot. (And released it as open source.) vJot’s slick, but a web application doesn’t really fit into the same slot in my workflow as Notational Velocity. So it looks like I’m stuck with it, slowness and proprietary database format and all.

Today I just figured out how to speed it up, in one crucial regard. Notational Velocity allows you to set a hot key that will bring the application to the front. For some reason, this has revealed itself to be one of the application’s worst performance bottlenecks. After a year and a half of being annoyed by the delay of bringing to the front, it finally occurred to me to trigger it using Quicksilver. (Yes, my other favorite application which is essential to my workflow and whose development has also stopped.) Quicksilver, it seems, is much faster at revealing Notational Velocity than Notational Velocity itself.

Simple enough to do: Go into Notational Velocity and set the hot key to some combination that I’ll never press, then go into Quicksilver and create a new trigger that opens Notational Velocity when I press command-option-space.

Oh, and even if you don’t care about anything I’ve said here, go over to the Notational Velocity site anyway, just to check out the brilliant photographs. Please.

On the quiet archivist that lurks inside us all.

hypsometry.blog@cboone.fea.st (Chris Boone) — Tue, 05 Feb 2008 15:02:00 GMT

The New York Times, Design Observer, and the AIGA are collecting and archiving amateur photographs of the American voting process. The Polling Place Photo Project aims to have photographs of every polling place in the country, all of them available under the Creative Commons Attribution No Derivatives license.

Posting photographs is easy: Just choose a file and enter some information about where you voted. You can browse the submitted photographs, and search by various characteristics. The photographs all show roughly the same things, but none of them show exactly the same things.

Little old ladies checking people’s names.

So many signs.

In New York they use levers, in San Francisco they use paper ballots.

Finished voters get stickers.

The American flag is everywhere.

Snowmen like Obama.

And then there’s Flat Stanley.

My contribution is a little out of focus, but it’s been that kind of day.