It’s always interesting to watch what the guys over at 37signals are up to. They’re on the verge of releasing their new Backpack application, and one of their previews explores a set of ideas that I’ve also been finding myself increasingly intrigued by.
The specific feature that I’ve been thinking about, and that Backpack seems to leverage nicely, is the use of email as an input method. This seems like an odd idea: isn’t it a lot clunkier to send an email to an application, even a web application, than to use some custom form within the application itself? And yet, even without something like Backpack available, I find myself using email as a quasi-database all the time: to make lists, send myself reminders, record important snippets of information, even log hours spent on a project. Why? First of all, because the email client is the one window that I will always have open and easily accessible, whatever else I might be doing. Second, email is a great redundant data source: as well as going to whoever (or whatever) I send it to, a copy of the message ends up on my local machine, another on my servers, maybe yet another on Google’s servers, and so on. If I need to, chances are I can find it later from pretty much anywhere. But probably most importantly, email is, for many of us, the main personal input stream: if some new piece of information comes up that I have to record or take action on, chances are pretty good it came to me through email. So what more natural way to respond than right from the email client?
Because of all of this, it’s become somewhat common for blogs and wikis to accept emails as unstructured data. What Backpack does that’s interesting is accept them as structured data. Given enough context - from the subject line, say - and a few simple conventions, it’s possible to extract pretty reasonable structure from the text of an email message. Backpack scans (much as Word does, actually) for text that looks like a list of items and makes it into a structured to-do list. A contact manager might use something like SBook5’s parsing to build a structured address book record. A generic database application could look for one of its field names at the start of a line and take the rest of the line as the value. It’s crucial that the application also provides more direct ways to do the same thing, but there’s something immensely satisfying about firing off a quick email and having it show up as “real” data rather than just text.
The more general idea here is the use of freeform text as a way to reduce the complexity but increase the power of a user interface. With a good parser, for example, a freeform date input can be much nicer to use than any calendar widget. Or look at Google. A single text input lets you put in not just search keywords, but also stock ticker symbols, unit conversions, tracking numbers, and no doubt all kinds of other things that I don’t know about. The key here, as always, is incrementality. As a new user to Google, I can just type some keywords into the search field and get back reasonable results. Only when my needs get more sophisticated do I have to even be aware of the wealth of other features available. Hiding these options in a textual syntax, rather than building complex forms specifically for them, may seem like a regression to the command line, but it’s also a great way to reduce clutter and let your user experience scale smoothly.
And since this blog is somewhat spreadsheet-obsessed, it’s worth pointing out that Excel does the same thing. There’s no special mode or dialog you have to access when you progress from entering data into cells to creating formulas, you just have to figure out to use the “=” sign at the start. The moment where a spreadsheet user first learns to do this is a critical and somewhat magical one; what other equals-sign moments can we build into our software?