Archive for January, 2007

Protect Users From Themselves

Often, when designing a system for users, we look at what they could do wrong and either try and prevent it or tell them what’s going wrong. I prefer to take as much of a proactive approach as I can by having the system fix the problem and not even bother the user with an error message if it’s not absolutely necessary.

This same mentality holds true for the way users expect a system to work. I found an example from bloglines today, which is a great service that I use every day.

Bloglines has the nice feature of letting you use keyboard shortcuts to navigate around your feeds and the posts within them. It’s a tremendous time saver not having to scroll all the time. However, this morning, I discovered an oversight that is easy to fix: if I have caps lock enabled, the navigation doesn’t work. It is something that only comes up in a blue moon, but it took me a minute to figure out what was going on today to correct the problem.

The problem is with the javascript that bloglines uses to capture the key events and perform an action. Here’s a (snipped) example.

1
2
3
4
5
6
7
8
9
var g_hotkey_scrolldown = 106; // j
 
else if( whichCode == g_hotkey_scrolldown ) {
    // j - scroll down pane
    cancelEvent(e);
    if(main.basefrm && main.basefrm.gotoNextItem) main.basefrm.gotoNextItem(nav4);
    else if(main.gotoNextItem) {
        main.gotoNextItem(nav4);
    }

This only captures the lowercase j, but if you wanted to capture the uppercase J (because someone might have the caps lock enabled by accident), then it would be simple to change the whichCode line to add in the case for uppercase J.

1
2
3
4
5
6
7
8
9
10
var g_hotkey_scrolldown = 106; // j
var g_hotkey_scrolldown_upper = 74; // J (uppercase)
 
else if( whichCode == g_hotkey_scrolldown || whichCode == g_hotkey_scrolldown_upper) {
    // j (upper and lower) - scroll down pane
    cancelEvent(e);
    if(main.basefrm && main.basefrm.gotoNextItem) main.basefrm.gotoNextItem(nav4);
    else if(main.gotoNextItem) {
        main.gotoNextItem(nav4);
    }

A simple one line change for this example, but it prevents users from getting behavior in the system that they don’t expect.

Update: I had sent this issue directly to Bloglines before making this post with essentially the same information. I received a reply from them saying that they would forward on the report to the appropriate department. Hopefully, they will fix this issue and get back to me. A commenter noted this issue happens with similar sites that use access keys in this way. My lazyweb question then: is this not technically possible? I didn’t actually run the code I wrote, but I could if I really wanted to test it out since I believe Firebug will allow me to do that. It just wasn’t that pressing.

Update: I still haven’t seen this work and have moved on to another blog reader. I just couldn’t deal with the lack of progress and missing out on better options. So long Bloglines, you’ll be missed. I’m happy to be lured back someday.

Make A Name Map

This is an article that I have seen go past in my RSS reader a few times lately: Meeting Tip: Learning Names. It is something that I have used for years, but this is a great writeup of what to do. Simply stated, make a little “map” of the meeting table you are at and write everyone’s name along with any other information you might need next to them.

I’ve taken it further a few times and actually written notes under each person’s name so that I knew who came up with the idea. It was a common practice for me at NeoTactix where we would meet a ton of new companies all the time and I could _never_ keep their names straight in my head. I find it equally important in my consulting life at ThoughtWorks, but rely on it less when I see the people that I meet every day and their name eventually starts to stick in my head.