Hypsometry. Modal Synthesis.

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.

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