Friday, August 15th, 2008

Custom events as API end points for key bindings and more

Category: Examples, JavaScript

Inspired by the Gmail team and how they created well known Greasemonkey endpoints and the custom events work that I have been doing, I was lead to play with custom events as a way to tie into key bindings. This lead to the following post on my blog:

On the back of my example enjoying the Observer pattern with custom events I have started to play with a pet project also involving custom events.

I love keyboard shortcuts. I hate the mouse. I wish that Web applications would offer more keyboard shortcuts a la Gmail, and wondered if there could be a generic way to tie keys to actions in an app. There are things such as accessKey, but we need more.

If you start to follow the pattern of creating named events for public integration points, then how about tieing in keys? I implemented this on the quote example, where you can now use up and down arrows, and N and P, to move through the list of names.

To use the system you declare the keys and tie them to events:

javascript

  1. KeyBindings.add({
  2.    eventname: 'action:move-up',
  3.    // keys: KeyBindings.caseInsensitive('p'),
  4.    keys: ['p', Key.ARROW_UP ],
  5.    description: "Move up the stack"
  6. });
  7.  
  8. KeyBindings.add({
  9.    eventname: 'action:move-down',
  10.    keys: ['n', Key.ARROW_DOWN ],
  11.    description: "Move down the stack"
  12. });

This code ties the keys to the actions, and thus fires those actions when pressed. Next, you need to capture those events to do the work when the key is fired:

javascript

  1. document.observe('action:move-up', function(e) {
  2.     Selection.moveUp();
  3. });
  4.  
  5. document.observe('action:move-down', function(e) {
  6.     Selection.moveDown();
  7. });

With a standardized way of annotating events, interesting side effects appear. You can hit the ‘?’ key to bring down a heads up display sharing what keys do. You could imagine a Greasemonkey script, or browser plugin, that loads the keybindings.js code, and looks for the key binding definitions. The declaration could be done in HTML too, which could be found by the plugin and tied into the system. What do you think?

Posted by Dion Almaer at 8:58 am
6 Comments

+++--
3.8 rating from 19 votes

6 Comments »

Comments feed TrackBack URI

hi dion,

“I love keyboard shortcuts. I hate the mouse. I wish that Web applications would offer more keyboard shortcuts a la Gmail,”

Do I love keyboards ? (I use emacs) These days I use the mouse more because the web browser forces me to use the mouse. Keyboard doesn’t give me as much control browsing stuff that mouse does.

I’ve long wanted web apps to provide keyboard users something. Especially those tutorials . they should have a KEY for NEXT page, etc. All the tutorials and articles on the web should have a PREV, NEXT, PAGE UP, PAGE DOWN standardized. What would it take to do that ?

Will try out what you’ve done and see if I can include them in my apps.

thank you,

BR,
~A

Comment by anjanb — August 15, 2008

Anjanb,

Exactly! I love the idea of having actions as you describe (next, prev, etc). It would be very lightweight to start seeing common events that people expose and “standardizing” them so you know that “n” always goes to the next item in a list etc.

Cheers,

Dion

Comment by Dion Almaer — August 15, 2008

I think it’s important to be cautious about a few things with keystrokes on web apps:
.
1. Key combinations should use a modifier key. Without them, you interfere with some configurations of find as you type, which is wrong to do to your users. It also provides cognitive dissonance to users who are accustomed to key commands, and might cause unexpected behaviors to users who aren’t. That is also wrong to do to your users.
.
In some cases exceptions can be made (non-standard use of right/left arrows, pgup/dn, escape and so on), but it’s important for those exceptions to be made for keys which are already commonly used as keystrokes in existing software.
.
2. Respect the OS’s conventions. All of the major browsers allow accurate OS detection, use that. If your user is on OS X, you should bind to metaKey rather than ctrlKey where possible. This isn’t really a hard and fast rule however; for example, if you want to offer a functionality similar to OS X’s Spotlight, it makes sense to use a similar key combination, such as ctrl+space. In fact, I’d recommend always providing commands similar to the established ones where functionality is similar. For example, if your richtext editor has a special copy function, it makes sense to bind it to ctrl (or cmd) shift c.
.
3. Research existing key combinations in the various browsers and OSes, and avoid conflicts with those. Obviously you cannot hijack combinations like ctrl-w, but to varying degrees you can hijack some existing combinations. That is wrong to do to your users.

Comment by eyelidlessness — August 15, 2008

“and might cause unexpected behaviors to users who aren’t”
.
I meant to add that, even as a keyboard junky, I found Gmail’s keyboard commands infuriating for this reason and quickly disabled them. Which reminds me:
.
4. Allow users to turn off this feature. Like it or not, the web is still the web; if users prefer the behavior they’re accustomed to (no key commands), they should have that option available.

Comment by eyelidlessness — August 15, 2008

This is a pretty tough problem.

I find myself more and more confused as I tend to think of the app I’m in rather than the OS. Safari and Firefox looks so much the same to me on Mac and PC that I often find myself doing things like hitting Ctrl-T to open another bvrowser window. I keep trying it because I KNOW it works. Then finally, oh yeah–wrong computer.

Comment by Nosredna — August 15, 2008

Addendum to point #4: Allow users to reassign key commands!

Comment by eyelidlessness — August 16, 2008

Leave a comment

You must be logged in to post a comment.