Adam @ Bitscribe

Catapult is a side project I’ve been working on this past few weekends, with the goal of bringing a command-line style interface to web navigation.

Think about how one normally navigates to the web apps one uses every day. If I want to compose a new post on my blog, for example, I go to the blog homepage (by entering in the complete url, maybe utilizing my browser’s autocompletion), then grab my mouse and click on the admin link, then click on the write link, then switch back to the keyboard to start typing. This is no big deal for just one app, but think of all the actions like this we perform every day. Web searches, Gmail, Yahoo yellow pages, Google Maps, Craigslist, eBay, your bank’s website, and so on. Typically we do all this with bookmarks, urls typed in from memory, and lots of clicking on navigation links. It’s not very efficient.

Catapult lets you create commands that act as shortcuts, in some cases dynamic ones. So for example a Google search would be “g [search terms]”. I can launch Gmail with “gmail”, but I can also jump straight to the compose window with a recipient already entered by typing “gmail someone@somewhere.net”. Searching my inbox is just as easy: “gmail /thing to search for”.

It’s interesting to note that using the Gmail launcher has increased my productivity in an unexpected way. I often need to send an email about something, but opening my inbox and seeing some new messages that have come in distracts me from that task. By jumping straight to the compose window I don’t even get a chance to see the inbox and thus avoid unintended distraction.

Check it out, and post any feedback here; or drop me an email with your comments.

Consider for a moment the html form element for entering multi-line text:

<textarea>...</textarea>

Not much to look at, is it?

Hard to believe, but this little widget is fast supplanting the word processor as the tool with which most of humankind’s writing is done. Just as the word processors supplanted the typewriter, the typewritter the pen, and the pen the quill.

Think of all the places where one writes using textarea. Blogging, Writely and friends, site comments, feedback forms, message forums, GMail, and user profiles on community sites like Tribe, to name a few. Even the internal tool I use at work for creating project designs involves writing in a textarea.
What’s astonishing, then, is just how lame the textarea widget is. I’m pretty sure that Notepad has it beat out for features and usability. Scary, that.

I think the attitude thus far - and my attitude until just recently - was that textarea is just a multi-line version of <input type=text>. If you were trying to use it for any serious writing, you’re doing it wrong.

Sure, you and I know that for any serious writing you should use a real editor, then cut-and-paste the results into a textarea. For example I’m writing this in vim, to later be pasted into the textarea of my blogging software. But this is a haphazard and error-prone approach. One can accidentally cut and pasted too much or too little, for example. And then what if you want to edit it? Back to the original text file, delete the contents of the text area, and then cut and paste again? Or edit in place in the textarea, the very thing we were trying to avoid to begin with?

People not in the know about text editing tools - that is to say, 99% of computer users - just muddle by with textarea. They don’t know any better, but that doesn’t mean they aren’t feeling the hurt. Improving textarea’s capabilities would make everyone’s lives better, not just power users.

The other thing that gets my goat is the quantity of time an energy put into javascript rich text editors. Countless web applications, realizing the importance of decent editing capabilities, have sought to create their own or integrate an open source rich text editor. A few notables including GMail (which includes the very important feature of autosaving drafts) and WordPress. But these tend to be quirky, slow to load, and difficult to make work cross-browser. More significantly though, is that the application developers are spending huge amounts of time developing and maintaining a method for text entry, which seems like massive duplicated (and thus wasted) effort to me.

Everyone needs to have decent editing capabilities whenever they enter text. Why not just build it into the browser?

Partial attempts have been made, so I’ll mention a few of the notables here. One of the first ones that really caught my eye - and got me thinking about this - was automatic spellchecking, introduced into Konqueror a few years back. I was amazed by how much this improved my web writing experiences right away. Prior to having it, I think there was a small part of my brain that was constantly worried about whether I was spelling this or that word wrong and making myself look like an uneducated yokel. But any such thoughts were being squelched by the pragmatic concerns of cutting and pasting the text into Ispell or OpenOffice. So I had this constant little game of stress going on in my head - gone the moment Konqueror started highlighting my misspelled words in red. (I understand that Firefox 2 will be adding this feature as well.)

The honorable mention goes to KVim, which alas appears to be a dead project. This is a KPart (a pluggable component of the KDE architecture) that, when activated, caused most of KDE’s text widgets (including Konqueror’s textarea) to turn into a vim editor. Unfortunately the usefulness of this is limited for obvious reasons, but this is the closest browsers have ever come to having a non-sucky textarea widget.

More on the rich text side than the power-editing side is the clumsily-named Xinha Here Firefox plugin. Regrettably this is not inline; you have to right click and select “Open Xinha Here”, at which point a window pops up to offer an advanced editor. When you save, the results are pasted back into the textarea. More convenient than an external editor, but still far from the seamless solution we need.

So come on folks, let’s collectively come to grips with the fact that textarea is the most important editor of the future. Time to make it, you know, good.

The caps lock key is the dumbest key on the keyboard. I mean, there are other vestigial keys, like Scroll Lock. Scroll Lock crouches off to the side, doing nothing in particular, not getting in your way. It’s a waste of space, but this is a minor transgression compared to the accursed Caps Lock.

Caps Lock is one of the largest keys on the keyboard, and sits right to the left of the home row. Thus it’s very easy to hit, and that would be ok if it did nothing, like our pal Scroll Lock. And maybe it would even be ok if it inserted a character into your typing stream, because you’d spot it immediately and backspace. (Backspace is about 1/3rd the size of the caps lock on my keyboard, and much further from the home row. From this we can glean that backspace is used perhaps 25% as often as caps lock? Ha!)

No, it’s even worse than an extraneous character, because this is a modal key. That’s right, you don’t get any immediate feedback after striking it. Instead, whenever the next alpha keystroke comes - it could be seconds later, or hours, or even days - you are amazed to find yourself typing in all caps.

And even THIS could be forgiven. Maybe, very maybe. But if you’re currently in a program that uses the alpha keys for commands, like Photoshop or - and this one is truly nasty - vim, your next set of keystrokes (which, remember, could be many minutes after the original caps lock change) start having strange and unpredictable effects on your work. Only after a few confused and disorienting seconds do you realize what happened, try to back out what went wrong, and finally turn off the caps lock.

Yes, this horrible, horrible key should be drug out back and shot between the eyes. Thankfully this isn’t hard to do, even without physically mangling your keyboard. Directions follow for switching caps lock to an alternate control (thus making it actually useful) or off (just making it inert, a scroll lock with better real estate).

GNOME (i.e., Ubuntu Linux)

System -> Preferences -> Keyboard
“Layout Options” tab, expand “Control key position”
Select “Make CapsLock an additional Control”

Mac OS X

System Preferences -> Keyboard
Click “Modifier Keys” button
Change “Caps Lock Key” dropdown

---

Update: Looks like I’m not the only one that thinks this. Check out the CAPSoff campaign.

There’s a debate that seems to be emerging among web app developers between three competing types of interfaces. I’ve been pondering this question for years - almost since I first began working in the web realm - but, lacking good terms to describe my vague thoughts on the matter, I was unable to vocalize them. Luckily I stalled long enough that someone else did the hard work of coming up with terms. Here they are:

• REST - Aka “the usual”. This is where all the information for the page’s state is stored in the URL, or in the payload of an HTTP POST. (The latter implies that every piece of data you want to carry onto the next page will appear as a hidden input field in the previous page’s form.)

  REST is easy to use, works perfectly with all browser functionality (back, forward, bookmarks, etc), and requires no server-side storage. It is the default and should be used unless there is a compelling argument to use one of the other two types.

• Continuations - This is where you stuff user state data into a session stored on the server. Aside: the name comes from the continuation feature offered by advanced languages, but the language or framework doesn’t need to support low-level continuations to implement the interface feature. Sessions are a cinch to use with modern languages, in some cases even easier than REST since you can store complete objects and not just easily urlencodable fields like text and numbers. Use of sessions makes a lot of sense for multi-page forms (which closely resemble the “wizard” style of interface in the olden days of local GUI applications). The checkout process on a shopping cart, filing out a long and complex profile on a dating site, or browsing the result set from a complex query on a travel booking site are some good examples of where continuations / sessions are often used.

  The downside to continuations is that they break some browser functionality. This is painfully apparent with tabbed browsing. Want to browse two result sets side-by-side in two tabs or browser windows? Too bad - you can only have one session at a time. I’ve often worked around this by viewing the site with two different browsers at once. The fact that this terrible hack is worth using indicates there is some serious flaws in the continuation model.

• Ajax - Always a crowd-pleaser. Ajax breaks browser functions completely in most cases, so it should be used only when breaking standard navigation can be considered a benefit. One of my favorites is deleting an item out of a list. Back/forward and bookmarks make absolutely no sense for this. Dragging the map around in Google Maps is another good example. (Importantly, you can still get bookmark / email a link to your friend / etc capability via the “Link to this page” link.) And sometimes Ajax can be justified just for speed reasons. GMail breaks some browser functionality in places where it might be preferable to keep it, but the benefit to performance makes this a worthwhile tradeoff.

Personally I really like continuations. They are just so dang intuitive. The user clicks a link or button to start a new session, taking them into a multi-page form where they can move at will between the steps, tinkering with all the data until everything is just right. Then when they are satisfied that everything is perfect, they click “Commit” or “Place Order” or other button at the end of the process, and the session data is finalized and saved into the server’s database.

Continuations can actually get even cooler if they can be used as a work-in-progress which can be returned to at a later time, or even send the link to another person for collaboration. One of our clients has a system which uses this to submit change requests. Certain types of users can start the request, entering in all the relevant data, but they cannot commit it. The change request is saved as a work-in-progress and users from another role are notified. One of those users then loads up the request - effectively taking it over - and can verify and approve all the data they see entered, then run the finalize step at the end to commit the change.

One could actually do this same sort of thing even with a single-page form, but prior to needing this interface feature I never stopped to think about storing data in an incomplete / work-in-progress state. The old web app model was just form post -> store to database, and that was it. Multi-page forms forced me to come up with a good implementation for saving the state of an incomplete data record; but once that capability was available, I discovered there were a lot of other uses for it.

Multiple Continuation Sessions

So what about running two separate continuation sessions in different tabs? There’s a pretty simple technique for dealing with this, although it doesn’t seem like many places use it. The trick is to create a unique key each time a new session is started. For example, a travel booking site might generate a random key whenever you click “Find my flights” or whatever was the initial button or link to launch the search process. This key should go in the URL, so your address bar looks something like:

http://example.com/multipageform.php?sesid=12345

The object storing your continuation data can then be accessed via something like $_SESSION[’multipageform’][$_REQUEST[’sesid’]]. Users can view the same session in multiple tabs by cutting and pasting the URL from their results or by a duplicate tab/window function. Or they can view different sessions by opening a separate tab and starting a new search - or any combination thereof.

One thing to watch out for here is that your session data can get pretty large if you don’t do a little bit of manual garbage collection. I usually just limit the number of sessions which can be open at once, throwing out the oldest one when the limit is reached. For example:

if (count($_SESSION['multipage']) >= 5)
   unset(key($_SESSION['multipage']));
$sesid = sha1(rand());
$_SESSION['multipage'][$sesid] = new MultiPageFormController;