bradchoate.com

Unicons is a little project I put together today, making it easier to insert some of those little Unicode symbols (like ☃ or ☺ or ✌) into web text fields. You know, the text fields you see on comment forms or Twitter.

The project is hosted at Github and feedback is welcome!

Posted at 8:40 PM | Permalink | Comments (4) | TrackBacks (0)

via apple.com

Belorussian translation provided by PC

I picked up an Apple Magic Mouse at the local Apple store Thursday night. It’s pretty nice! It’s amazing to me how Apple brought the mouse to the mass market (well, Dvorak didn’t like it) but have done a poor job in the design, until now.

What I like:

• the slim design
• even with batteries, this thing is light, but not too light
• fewer moving parts, and no scroll wheel to keep clean
• most of the top surface area is touch-sensitive
• no more red light for the optical sensor!

What I don’t like:

• it was a little pricey, but I remember paying $100 for the first Microsoft optic mouse

My other area of complaint can’t be summed up in a bullet. Basically, it’s the gestures. Apple has brought three slightly different sets of multi-touch gestures to the market in three different products: iPhone, the multi-touch trackpad and now the Magic Mouse. I’m going to look at five of these gestures in particular:

1. clicking (or tapping for iPhone)
2. content scrolling
3. content magnification
4. content rotation
5. content navigation

iPhone (and iPod touch of course) multi-touch gestures are really, really natural to me, but maybe because I’ve been using them longer than these other devices. Gestures on iPhone for these five interactions are:

1. clicking: single finger tap
2. content scrolling: single OR two-finger slide up/down
3. content magnification: two-finger pinch/spread
4. content rotation: two-finger rotate
5. content navigation: single finger slide left/right (as used for photo navigation)

It is interesting that iPhone recognizes both single and two-finger slides for content scrolling. I believe this is done with an eye towards what I am looking for and will elaborate on — a universal set of gestures.

Apple added multi-touch to their trackpads and some gestures to go with them. They differ from those on iPhone, namely because you aren’t interacting directly with a screen, but with an area that is controlling an on-screen cursor. This is a very different model from a multi-touch display which has no cursor to speak of. So, the multi-touch trackpad gestures are:

1. clicking: single finger click and/or tap (MacBook trackpads can be configured to accept a tap as a click action but they are no configured this way as a factory default)
2. content scrolling: two-finger slide; omnidirectional
3. content magnification: two-finger pinch/spread
4. content rotation: two-finger rotate
5. content navigation: three-finger swipe left/right (as used to navigate backward/forward in a browser or navigating a photo album in iPhoto)

Now those are mostly the same, with the exception of the content navigation gesture.

So how about this Magic Mouse? Gestures are:

1. clicking: single finger click (a tap on the surface does nothing)
2. content scrolling: single OR two-finger slide; omnidirectional
3. content magnification: none
4. content rotation: none
5. content navigation: two-finger swipe left/right (as used to navigate backward/forward in a browser or navigating a photo album in iPhoto)

The Magic Mouse may not support tap-to-click because it has a serviceable button, and having two ways to click would be kind of weird. But the multi-touch trackpads that also have a tactile click for the trackpad itself (including all the new MacBooks, save the MacBook Air which still has a separate button) and can be configured to support a tap to click as well. I personally prefer this configuration since there is less effort to do something that you do all the time.

As for gesture two… well, obviously, a single finger slide on the trackpad is the mouse equivalent of moving the mouse around. So we can’t expect Apple to change the trackpad’s single finger slide gesture to scroll content (unless they add an optical sensor to bottom of their laptops, but who wants to move their laptop around to move the cursor?). The other option is to use two-finger sliding to scroll on the Magic Mouse. Well… actually, that works too — you can use either a one or two-finger slide for scrolling.

What about the gestures for content magnification and rotation? The Magic Mouse is missing these for some reason unknown to me. The hardware should be capable of recognizing such gestures as recognized on iPhone/iPod touch and trackpads.

Content navigation gestures differ in number of fingers across all three: iPhone only needs one finger (granted, the use there is for full-screen pages, like on the Springboard and photo albums; this same gesture can’t be used for navigating forward and backward in Mobile Safari), the Magic Mouse uses two fingers and the trackpad uses three! The trackpad cannot use two fingers because two finger scrolling can scroll horizontally as well as vertically. And while you could conceivably use three fingers on the Magic Mouse (there may be a hardware limitation, but I doubt it), it’s kind of awkward to do so.

All in all, it’s a mixed bag. I can understand the decisions made around making these gestures differ from one context to another, but at the same time, it’s frustrating that they are different. This feels like an area where a real standard should emerge, one that can be used across these devices so consumers don’t have to re-train themselves when they shift from one device to another.

If I had my druthers, I would recommend the following as universal gestures:

1. clicking: single finger tap and (Mac only) right-click: two-finger tap
2. content scrolling: two-finger slide (single finger use for iPhone/Magic Mouse)
3. content magnification: two-finger pinch/spread
4. content rotation: two-finger rotate
5. content navigation: three-finger slides

This affects all three multi-touch devices in subtle ways: for the Magic Mouse, Apple would have to support tapping the surface to behave as a click and support both two and three-finger slides for content navigation. They would also have to implement gestures for content magnification and rotation (I suspect they plan to eventually). For iPhone, recognizing three finger slides to navigate content in Safari would be great, as it doesn’t support any gesture for that interaction today. A three-finger slide could also be treated as page turns for other contexts where a single finger slide work now. For multi-touch trackpads, Apple would need to make tap to click a default configuration, so this behavior is supported without having to reconfigure your trackpad to use it.

With these minor adjustments, a single set of gestures can work across all these devices. Optimized versions of these gestures can still be supported — you should still be able to scroll on iPhone and the Magic Mouse with one finger, but the universal gesture would be two fingers.

It’s kind of strange to me that Apple has shifted from a position where they insisted on grounds of usability that a single-button mouse was “The Way” for so long to where we are today: a variety of input devices with rich and complex interaction features that also have varying control schemes. Hopefully some standard will emerge… I’m sure someone at Apple is thinking about this too.

Having said all that, I really do recommend the Magic Mouse, particularly for desktops and for the Mac mini which is where I use mine.

Finally, one last wish of mine: I’d love to see an alternate Magic Mouse driver written that makes this device function just like a multi-touch trackpad. I’d like to just leave this mouse stationary and simply use my finger on the surface as I would a trackpad. So single finger sliding would move the cursor, instead of moving the mouse itself. And if that were possible, I’d also prefer to use the mouse in a sideways orientation, since screens are generally wider than tall. Apple could do this as an alternate configuration for their mouse, but this feels like a third-party thing and one I would gladly pay for.

Posted at 1:47 PM | Permalink | Comments (8) | TrackBacks (0)

Did you know you can assign a keyboard shortcut that invokes any browser bookmark you’ve created? For example, I have a bookmarklet for sharing a link on FriendFeed.com. I’d like to run that bookmarklet on the active page using Ctrl+Cmd+F. To do this, I can create a keyboard menu shortcut for OS X:

Creating the shortcut is easy: open your System Preferences and go to the “Keyboard & Mouse” preferences, then click on the “Keyboard Shortcuts” tab. Click the “+” button below the shortcut listing. Set the shortcut to apply to “Safari” (or “Firefox”) in the Application list, then type in the name of your bookmark (exactly as it is labelled in your bookmarks), and set a keyboard shortcut.

After you do this, you may have to restart your browser to try it out. I’ve also noticed that these shortcuts are not always recognized right away, due to the way the menu options for bookmarks are lazily loading until it is needed (Safari and Firefox both behave this way). Just click on the “Bookmarks” menu option if your shortcut isn’t already working; you only need to do that once after the browser has loaded.

I love this tip because it makes bookmarklets so much easier to invoke, and it doesn’t involve using any weird third-party software hacks to do it.

Posted at 10:20 AM | Permalink | Comments (5) | TrackBacks (0)

This may be the last week I have to use this clunky 1st generation iPhone. I’ve been anticipating the 2nd gen model since June 30, and the original doesn’t hold a candle to my expectations for iPhone 2.

Posted at 9:04 AM | Permalink | Comments (0) | TrackBacks (0)

Lets talk about a variety of Mac OS X software called Input Managers.

In brief, an Input Manager is software that can affect other running applications. The original intent of Input Managers was to provide a means for customizing the operation of the keyboard and/or mouse to support things like locale-specific input behavior (treating keyboard input differently for different languages or regions) and software that aids handicapped individuals. The name “Input Manager” is thus appropriate for these intended uses. (Read more about Text Input Management.)

However, it wasn’t long before Mac developers found this to be a useful way to graft additional functionality into other applications. There are several OS X software products out there that are input managers which have little to do with input management (Inquisitor, 1Password, Chax are three that I use today). These products are typically unstable in nature, since they often times rely on undocumented aspects of the “host” application. But when they work, they can add real useful functionality to other programs.

The downside to Input Managers is that it is a tempting means for rogue software to exploit. One such example is the “Oompa-Loompa” trojan which surfaced about two years ago. This was a download that supposedly contained pre-release screen shots of OS X 10.5. It masqueraded the installation program as an image file, and when the unsuspecting user tries to view the file, it installs itself into the user’s “Input Managers” folder. It then can access any application that is run and affects iChat in particular, so that it tries to spread to others in your iChat contact list.

One of the changes in Mac OS X 10.5 (Leopard) was in how OS X dealt with Input Managers. The early rumors were that Leopard wouldn’t permit them to run at all. But after release, Leopard did run Input Managers, but only those that are installed in the system-wide “/Library/InputManagers” folder.

The distinction is this: before Leopard, if a user runs software that tries to install an Input Manager, there is nothing to stop it from installing one that is local to that user’s account (installing it to the “/Users/username/Library/InputManagers” folder). With Leopard, installation of an Input Manager requires system-administration rights (so the user is prompted to authenticate to permit the installation), and the Input Manager is installed to the “/Library/InputManagers” folder.

The authentication requirement is the key and is a welcome change. There should be some kind of barrier to install software of this nature. BUT, it is wrong for Input Managers to only be installable in a system-wide fashion.

Before Leopard, I always— always— installed Input Managers for my own account only. By doing so, I could always login as another user to disable them. Remember— by their nature, they are less stable, and can cause applications to crash. A common request of developers when reporting bugs in their programs is to disable any third-party Input Manager software to see if it resolves the problem at hand. I could do that by logging in under a different account before Leopard, but now I cannot.

Personally, I would have preferred that user-specific Input Managers were still supported, but also require an administrator’s password to install. So, you would have a path, perhaps like “/Library/InputManagers/Users/username”, which may even be symlinked to “/Users/username/Library/InputManagers”. I think this is a better option, than requiring Input Managers to be activated for all users of that machine.

Hopefully a later update or release of OS X will address this and restore the option of user-level Input Managers.

Posted at 10:44 PM | Permalink | Comments (2) | TrackBacks (0)

Netflix.com has this option to watch a selection of their movies through your browser. Assuming your browser is running on Windows, as they require Windows Media DRM to play it.

But their promotional graphic (pictured here) shows it running on a black MacBook (Update: apparently, I’m jumping to conclusions — see comments below).

They doctored the thing of course, placing a still frame over the display, covering the portion that has the built-in camera and all evidence of the ‘MacBook’ imprinted at the bottom of the display. But you can make out the key layout, the size of the trackpad, and even the infrared receiver on the front-right side. It’s definitely a MacBook.

Now, it’s not impossible to get those videos on a MacBook. You can do it if you’re running Windows under Parallels or VM Fusion. Performance is fine, even at full resolution. But I seriously doubt they expect their average customer to do that!

Posted at 7:11 PM | Permalink | Comments (3) | TrackBacks (0)

The new empty trash confirmation dialog in Leopard.

But… I’m using Time Machine. There is an undo! This seems contradictory.

Also, the window grab action includes the huge drop shadow Leopard puts on focused windows. Is that necessary?

Posted at 3:35 PM | Permalink | Comments (6) | TrackBacks (0)

Just wondering how long it will take for someone to restore the rounded edges that have always been on the Mac menu bar.

From Tiger:

From Leopard:

Update: Not long.

Posted at 11:54 AM | Permalink | Comments (3) | TrackBacks (0)

I suspect Vonage doesn’t want Mint.com to recommend existing customers to switch to a cheaper plan, but hey, you save $117 a year if you do!

Posted at 5:11 PM | Permalink | Comments (3) | TrackBacks (0)

I guess if you’re a domain name registrar, you use entire domains for even trivial things like, say, your e-mail help manual. ‘emailuserguide.com’ is a domain for hosting the Network Solutions email user guide. Apparently, the whole thing is meant to be in a pop-up help window.

But wait, it gets better. The bulk of the guide is actually in a PDF file. So the domain, as best I can tell, hosts about 19 pages altogether (mostly FAQ material), with links to other places or files that have actual useful information.

Oh, and if you’re managing your account, you’ll want to use accountmanageruserguide.com.

Posted at 10:16 AM | Permalink | Comments (1) | TrackBacks (0)