Well, old habits die hard. Despite the increased reliability of text-based programs, auto-saving and operating system stability, I still hammer out Command-S periodically to "protect" my work.

But what happens when I try this in a browser-based application like WordPress? It is a common scenario for me: I'm typing out a draft of my post and reach the end of a complete thought; subconsciously, my fingers press Command-S. Then, I encounter a problem: the browser isn't aware that I'm trying to save my work; it thinks that I'm trying to execute a "Save Page As..." command, and I see this:

To make matters even worse, I involuntarily hit the Return key and save a copy of the page to my local drive. Double doh!

Now, imagine that you're the developer or customer support rep who receives this bug report. A common response is to think, "it's the user's fault!" Clearly, the designers had a blogger's best interest in mind when they implemented auto-save and provided a Save Draft button. How could they have anticipated this problem? It seems unreasonable that developers should have to program for every use case...

True. I don't disagree with that statement: programmers cannot foresee every way in which their application will be used. But, this is what separates good UX design from great: an extraordinary attention to detail when accounting for human error.

For example, Google recognized this type of habituation when they created their programs, Google Docs and Gmail. In both applications, if you are drafting content and press Command-S/Control-S, the program will intercept the Save event and execute an auto-save command instead. It anticipates that your intention to save content, not a web page, and creates a forgiving interaction.

And, it makes sense, right? Google is trying to convince users to abandon the traditional desktop programs — Microsoft Office and Outlook — where users have become habituated to Command-S functionality. The designers had the foresight to understand users would try and use the browser much in the same way they had used their desktop app, and accounted for any "errors" they might make. Great design!

Demo

Rather than have you visit Gmail or Docs, I've setup a small example here. To see it in action, start typing in either text area, then press your keyboard save command (Command-S for Mac, Control-S for Windows and Linux) :

The Code

Intercepting key events is easy. If you have jQuery installed, you can use the keydown function:

$("#element-id").keydown( function(e) {
    if(e.which == 83 && e.metaKey) // Do Something
});

Note: The example above listens for keydown events tied to the "element-id" object, and responds to Command-S/Control-S keycodes. Other keycodes can be found here.

Discuss and Contribute

I'd love to hear of other examples that you consider good design, those that embody small, humane attentions to detail.

As for me, drawing on inspiration from John Resig's wonderful article on a Web Developer's Responsibility, I am going to submit "Command-S/Control-S event capture" as a feature request to the WordPress bug tracking system (along with a patch). WordPress is a phenomenal product — one that I use every day — and I have been remiss to get involved sooner.

Nowadays, it might be accurate to say that screen real estate is worth more than actual real estate.

As web developers, we spend precious time laying out our pages, using every UI concept in the book to conserve space, while trying to maintain a user's focus on the task at hand. There are many techniques to use — Lightbox, Carousel and Tabs to name a few — and today I hope to offer up another: jQuery PageSlide.

jQuery PageSlide was inspired by the UI work of Aza Raskin. In his recent posts regarding concepts for Firefox Mobile and a mouse-based Ubiquity, Aza introduced the idea of sliding (or "throwing") content aside to reveal a secondary content pane.

This plugin allows any developer to recreate a similar interaction on their own website using a few simple lines of Javascript. By attaching the method to an anchor tag, PageSlide adds the ability to move your page and display a secondary interaction pane. The slide is animated whenever the click event is invoked.

<script type="text/javascript">
    $(document).ready(function() {
        $('a').pageslide();
    });
</script>

Similar to Lightbox, PageSlide has two major advantages:

1. The primary window is reserved for content; secondary interactions do not require additional space on the page — the area they need is created and removed on demand.
2. Because the user can see the original window, they have a greater likelihood of retaining focus, and can easily return to the previous task.

Can I See It In Action?

Of course, you can! Click for a PageSlide demo.

Where Do I Get It?

I've setup a GitHub project for jquery-pageslide.

When we first encounter Javascript programming, the quintessential function that enamors us all is alert(). Plunk that baby down into a page and, bam (or more accurately…thwunk!), a magical dialog box appears, grabbing the viewer’s attention and providing useful/useless information:

But is this the best way to convey important information? Probably not. For one, the alert box is modal; a user cannot continue with their task until they’ve clicked OK — their train of thought is broken.

One solution to this problem is to use transparent messaging. Rather than doing a disservice by re-explaining, I’ll refer you to read Aza Raskin’s article on Monolog Boxes and Transparent Messages. Or, if you’d like to see them in the wild, check out Songza: we utilize transparent messages to convey the state of media player (play a song, then press the space bar to Pause.)

Now, that’s all well and good, you might say, but what about sites that I don’t have programmatic control over? As a user, I’m at the mercy of whatever features the site programmer chooses to implement. Not true. Enter Ubiquity.

Ubiquity and pageLoad_

One of the goals of Ubiquity is to extend functionality across websites, regardless of whether or not the original programmer had coded that type of interaction (i.e. language translation, map insertion, word definition, etc). As such, Mozilla Labs has given programmers a bevy of authoring tools, including the pageLoad_ prefix. If, in your command file, you create a function that starts with pageLoad_, Ubiquity will execute this code whenever a new page is loaded into the browser window. It is this functionality that allows users to override native Javascript functions, such as alert().

 function pageLoad_overrideNativeFunction() {
     CmdUtils.getWindowInsecure().nativeFunction = function(args) {
          // Your code here
     };
};

By using this pattern, the native function is auto-magically replaced with your customized code each time a new page is loaded. In my case, I’ve chosen to override alert() with a call to create and show a Transparent Message (Note: I’ve used a Singleton with lazy instantiation to converse resources on pages that won’t call the command):

function pageLoad_overrideAlert() {
     CmdUtils.getWindowInsecure().alert = function(str) {
          TransparentMessage.getInstance().show(str);
     };
};

To see a working example, simply install the Ubiquity extension for Firefox and subscribe to the transparent-message command. From there, you can create a test message by issuing the “transparent-message” command, or see how it overrides alert() by revisiting this page and clicking the demo button located at the top of this article.

Note: Many thanks to Micheal Heilemann for authoring the jQuery Humanized Messages plugin. It’s what we use on Songza, and was used as a reference to create the transparent-message command.