Is Mousing Faster?

There's been some discussion on the Mac blogosphere this week regarding the relative speed of using the mouse v the keyboard. I obviously have a horse in this race, and that horse is called MercuryMover (a program that lets you move and resize your windows via the keyboard.) Scott Stevenson wrote about how some of the changes in Leopard may seem to negatively impact usability, but in actuality might be a net gain for users due to difficult-to-quantify reasons (this is a poor thumbnail sketch, you should definitely read the original). He cites none other than Bruce Tognazzini: User Interface Superhero. According to this article :

We've done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:

• Test subjects consistently report that keyboarding is faster than mousing.
• The stopwatch consistently proves mousing is faster than keyboarding.

Scott's take home point is that the obvious solution (provide better keyboard navigation since it feels faster) may not actually provide a better experience.

My angle on this is clear: I think that keyboarding is cool. The original article was written 18 years ago, at a time when the average monitor had only a few hundred thousand pixels of real estate. By contrast, my new iMac has well over 2 million. I have a lot more ground to cover with my mouse than Tog did back in the day. My snazzy new keyboard may very well be faster under these circumstances (although my one-man-shop isn't going to spring for the usability study to find out.) Secondly, and this is really Scott's point, i love to use my keyboard. It feels much faster to me and that's why i (no joke) love to use MercuryMover. I wrote this program because i knew it would make me feel just slightly more powerful when i used my Mac; and indeed it does every day.

I (NS)Screen, You (NS)Screen

A problem that has dogged me with MercuryMover since the beginning is getting MercuryMover to recognize where the edges of the screen are when using two displays in a top-to-bottom configuration. (If using your mouse to move and resize windows is dogging you then try MercuryMover!) Having promised a user that this would be fixed in the upcoming v2.0 release, i finally had to sit down and figure it out. The crux of the problem is that while the NSScreen API dutifully returns the dimensions of any screen as an NSRect, and the Accessibility API lets us determine the position and size of any window (by copying the values to an NSRect), these two operations return NSRects in different coordinate systems. The NSScreen API returns a coordinate system where the bottom left corner of the main screen is 0,0 with the y axis going up. Accessibility however treats the top left corner of the main screen as 0,0 with the y axis going down. While the latter seems more sensible to me, i don't claim to be smarter than the engineers at apple (quite the contrary!) so it's not for me to question, but to convert. Fortunately, those same Apple engineers (the royal Apple Engineers, the editorial Apple Engineers) provide us with a mechanism to transform one coordinate system to another. Using NSAffineTransform, we can specify a transformation like so:

	NSAffineTransform* coordinateFlipper = [NSAffineTransform transform];
	[coordinateFlipper translateXBy:0.0 yBy:frameOfMainScreen.size.height];
	[coordinateFlipper scaleXBy:1.0 yBy:-1.0];
	[coordinateFlipper concat];	

There's more than meets the eye here. This transformer will take a point and let us work with it as if its origin were push up the y axis by the an amount equal to the height of the main screen:

 
	[coordinateFlipper translateXBy:0.0 yBy:frameOfMainScreen.size.height];

This accounts for the fact that the two coordinate systems have origins on opposite left hand corners. Secondly, this guy will change the direction that the y axis counts (numbers getting bigger as you move down the screen, instead of up):

 
	[coordinateFlipper scaleXBy:1.0 yBy:-1.0];

Now, i can transform the origin of my key window (the one that MercuryMover is controlling):

	NSRect flippedRectOfKeyWindow = rectOfKeyWindow;
	flippedRectOfKeyWindow.origin = 
		[coordinateFlipper transformPoint:flippedRectOfKeyWindow.origin];

and my coordinate systems line up.

Shortcuts and Setbacks

The problem with creating a task list like the one i have for this week is that software, like so many things in life, doesn't always cooperate (see my 2.5 year old at the dinner table). The technique that i had planned to use to write the shortcut editor was a total bust. I ended up putting out a call for help and moving on. Like i always say, if at first you don't succeed, work on something else until you have a better idea. If no help comes through, then i'll just have to roll up my sleeves and write a lot more code this afternoon.

For those of you keeping score at home, here's where we stand in our run up to the v2.0 beta:

• New pop-in/pop-out animations
• cool display when shortcut is saved
• Add shortcut editor to preference pane
• fix window along the left or bottom edge +/= key unexpected behavior
• change demo so that it is based on a number of uses, not a number of days
• give pref pane a once over
• change "Advanced" tab to "Keys" and list undo, redo, center and maximize
• set the copyright year automatically at build time
• Give EULA a once over
• run through clang

Up today: new demo mode, and the shortcut editor (take 2).

Short(cut) time

Yesterday and the day before i had planned to cross MercuryMover's new shortcut editor off of my todo list. As man plans, software laughs. Fear not loyal reader, for yesterday i solved the major technical problem. Before i give you the slightly technical answer, let me provide an introduction for those of you new to the Helium Foot blog. Here at Helium Foot Software, we're working on v2.0 of our flagship (and for now, only) product called MercuryMover. MercuryMover enables you to move and resize the windows on your Mac from your keyboard.

For the last few years hooking up a user interface to your Mac app's preferences has been pretty trivial thanks to Cocoa Bindings. In short, bindings provide the glue between your interface and your data (whether that data is in some persistent store such as your preferences or is just your applications's model). Unfortunately, my case is not exactly textbook since MercuryMover ships as a Preference Pane that is hosted by System Preferences. Thus, when i try to bind to my preferences, i'm bound to the preferences for System Preferences (would you prefer that i write about something else??). The solution was to create a proxy object that hosts an array of all of the Shortcuts. This array is both backed by MercuryMover's preferences and also bound to the Preference Pane. This lets the Preference Pane display the shortcut information as stored in the preferences file, and also persist changes to the same. Eagle eyed (kv) observers will note that this will keep information in sync only in one direction (from the Preference Pane to the preferences file) but not vice versa. Since the MercuryMover agent that actually moves and resizes the windows can also create shortcuts, i have said agent posting a notification via the NSDistributedNotificationCenter which the Preference Pane listens for and updates itself accordingly.

For those of you keeping score at home, here's where we stand in our run up to the v2.0 beta:

• New pop-in/pop-out animations
• cool display when shortcut is saved
• Add shortcut editor to preference pane
• fix window along the left or bottom edge +/= key unexpected behavior
• change demo so that it is based on a number of uses, not a number of days
• give pref pane a once over
• change "Advanced" tab to "Keys" and list undo, redo, center and maximize
• set the copyright year automatically at build time
• Give EULA a once over
• run through clang

Up today: Finish the shortcut editor and fix the maximize/center bugs.

defaultapp

In this tweet yesterday, John Gruber of Daring Fireball fame asked:

Anyone have a shell or AppleScript command that tells you what the current default web browser is?

I had written code to do this for my upcoming app, so i spent a few minutes packaging it up as a command line tool. I present to you defaultapp. Download it here. The zip file contains the now public domain source (not too pretty) and the "defaultapp" executable. To use it, give it a -n, -b, -p or -a and a document extension. The options (in order) yield the app's name, bundle id, path or all three. Thus:

$ ./defaultapp -n html
Safari.app
$ ./defaultapp -b html
com.apple.Safari
$ ./defaultapp -p html
/Applications/Safari.app
$ ./defaultapp -a html
Safari.app
/Applications/Safari.app
com.apple.Safari

The tool uses LaunchServices to determine url of default app for the given document extension and then LaunchServices again to find the application name. The bundle id is determined via the carbon CFBundleCopyInfoDictionaryInDirectory call. You can probably do this with Cocoa, but i found the carbon call to be more reliable. YMMV.