One of the many little things that annoys me about Windows is the inconsistency of where items are placed in contextual menus. Case in point: the menu that pops up when you right click on a taskbar item or window. I haven’t done a scientific study, but I’m going to guess that 80% of the time or more the last item in this particular contextual menu is the option to close the window that is being right clicked on. This is what the majority of the contextual menus look like:

Having it as the last item makes sense. It’s probably the most commonly used menu item and it’s an easy target when it’s the last item in the list. The problem is: because that item is listed as the last item over 80% of the time, I start to expect that it’s always going to be the last item in the list. Unfortunately, that’s not always the case.

For whatever reason, some applications list other options below the Close option. Here’s an example of the right click menu for a cmd.exe window:

When I want to close that window, I right click on the cmd.exe item in the taskbar and choose the last item that pops up. But it’s not going to close the window. Instead it’s going to bring up the properties dialog for the cmd.exe window. Now, not only do I need to close 2 windows instead of 1, I also need to always remember that cmd.exe breaks the convention and lists Close as the 4th item up from the bottom of the menu.

Here’s another example:

That’s the right click menu for SQL Server Enterprise Manager. It’s outdated now, but it used to be the main tool for dealing with SQL Server databases. Like cmd.exe, this application also lists an item below Close in the contextual menu. What’s even more annoying in this case is that the item listed below Close is Help Topics. It’s another option that I will accidentally click on instead of the option I wanted, but, this time, choosing the wrong item will start up another application. And, no matter what computer I’m working on, the help application always seems to take a painfully long amount of time to open up.

Now, I would be able to excuse all of this if it was just 3rd party developers who weren’t following the conventions set up by other Windows applications. The problem is: cmd.exe is a integral part of Windows and Enterprise Manager was Microsoft’s official application for SQL Server Databases. So it’s Microsoft that’s disregarding an informal convention and randomly placing items below the Close option. I can only hope that Microsoft plans on dealing with this problem with Windows 7.

A while ago, I was thinking about software programs like Camtasia that allow you capture a user’s activity as they work on a computer. Screen capturing programs are useful for usability studies because they allow you play back a user’s activity later on when you are evaluating their performance on a set of tasks. I started to wonder if their were any options for capturing a user’s activity remotely through the browser. When I didn’t find anything I thought was compelling, I decided to try writing my own.

What I came up with was a JavaScript class I called MouseMovie that could be used to record the mouse movements a user made while on a page. The first draft is pretty rough, but it will allow you to create a new mouse tracker, start tracking the mouse movements a user makes on a page and then stop the tracker. Once data has been captured by the tacker, you can use the mouse timeline to replay the user’s movements or trace the path of the user’s movements.

/* Create a new tracker, 
start it and stop it and then use 
the timeline to animate 
and trace the mouse path. */
var MyTracker = new MouseMovie.Tracker(); 
MyTracker.start(); 
MyTracker.stop(); 
MouseMovie.Animate({TimeLine : MyTracker.TimeLine});
MouseMovie.Trace(MyTracker.TimeLine);

Currently, there is no way to persist the user’s movements to a file or database, but I’d like to make it possible to store the movements and play them back at another time. A simple demo of the mouse tracker can be found here