Among those common keyboard shortcuts are cmd-arrow to move to the beginning or end of a line, and option-arrow to move between words in a sentence.

Starting in Lion, Apple fine-tuned the behavior by changing the definition of what constitutes a word delimiter for option-arrow navigation. While it used to stop on e.g. period-separated words, now it considers such chains.of.words to be a single “word.”  My friend Mike Ash noticed this and, when he complained about it to me, I set about finding a solution.

It turns out there’s a supported preference setting to alter this behavior. Look in your System Preferences under the Langage & Text pane, and you’ll find a “Word Breaks” setting with various options, including a special one just for nerds:

For most people, the “Standard” setting is probably the right choice. But computer programmers are far more likely to encounter words that are separated by syntactic characters such as periods, colons, etc. For us, it makes more sense to have the system pause at these word breaks than to breeze right by them.

Updates:

1. You should take note that after changing the setting, you won’t notice changes in applications until they have been quit and relaunched again.
2. As noted in the comments, this feature was apparently available in 10.6 as well, and was possible more along the lines of the default in 10.5 and previous. The growing consensus seems to be that it was in the update from 10.6 to 10.7 that a previous selection of this setting was not preserved.

The way I use Twitter is to leave one of these client applications running in the background, with all the notification settings set to off. I still check it quite often, but it’s on my terms. If I get deep into concentration working on some bug, chatting with a friend, or or watching a video, I don’t want Twitter interrupting me.

Twitterrific was the first desktop client I used, and I can’t remember whether it was the default choice or if I picked it, but I got in the habit of using the global keyboard shortcut Cmd-Ctrl-T to toggle the window’s visibility. When I tried other Twitter apps, I made a point of setting the preference in that app to match the same shortcut.

Eventually I tried an app that didn’t support a setting for a global keyboard shortcut, so I had to write a script to do it for me. It occurred to me at some point that I could write a single AppleScript to handle the toggling of visibility regardless of which app I was using.

Download “Toggle Twitter”

The script logic is pretty simple: given a list of common Twitter app-names, is one of them running? If so, toggle it. If not, launch it. If you’re using something else, just add it to the list, and it should work perfectly.

I used FastScripts to hook this up to the global shortcut Cmd-Ctrl-T because it matches my historic muscle memory, and well, T is for Twitter.

Marco provides a handy bookmarklet that you can add to your browser’s button bar, so when you find something cool you just click “Read Later” and it gets added to your Instapaper collection. This is handy, and if you’re using a browser like Safari, these bookmark bar items even get mapped to default keyboard shortcuts based on their position, e.g. Cmd-1, Cmd-2, etc.

My news reader of choice, NetNewsWire, also supports Instapaper, allowing me to easily add any news item’s underlying content to my “Read Later” list. In NetNewsWire, the keyboard shortcut is Ctrl-P (for paper!), and I’ve gotten hard wired to punting stuff to my reading list with a quick flick of the keys.

For months I’ve thought it would be nice if I had the same workflow in Safari and in NetNewsWire: see something, want to read it, don’t have time, press Ctrl-P. I don’t know why I took so long to sit down and spend the 5 minutes it took to write an AppleScript wrapper for Marco’s bookmarklet, and install it in my scripts folder to invoke with FastScripts.

If you want to be cool like me:

1. Download and install FastScripts. Free for up to 10 shortcuts!
2. From the FastScripts menu-bar icon, select FastScripts -> Create Safari Scripts Folder.
3. Download this script, and move it to the Safari-specific scripts folder: [Home] -> Library -> Scripts -> Applications -> Safari
4. Switch to Safari.
5. While holding the Cmd key, select “Read Later” from the FastScripts menu.
6. Assign a keyboard shortcut of your choice. (Ctrl-P for NNW-likeness).

Now whenever you see a cool page in Safari, just press Ctrl-P to instantly tag it for later reading.

Update: David Kendal observes on Twitter that you can assign custom keyboard shortcuts to bookmarks in Safari by simply using the System Preferences Keyboard Shortcuts and assigning to the correctly named bookmark. I was not aware that this would work with bookmarks! Very cool. It diminishes the necessity of the above workflow considerably, though I was pleased to be able to take “Read Later” out of my bookmarks bar. Another downside to the System Preferences route? Apparently the keyboard shortcuts will never take effect until you’ve shown the menu that they appear in at least once per Safari-launch.

Today Joel shared a very short and dangerous pronouncement on the use of hidden and disabled menu items:

A long time ago, it became fashionable, even recommended, to disable menu items when they could not be used.

Don’t do this. Users see the disabled menu item that they want to click on, and are left entirely without a clue of what they are supposed to do to get the menu item to work.

Instead, leave the menu item enabled. If there’s some reason you can’t complete the action, the menu item can display a message telling the user why.

He’s absolutely right about hidden menu items, but on the subject he emphasizes, disabled menu items, he’s absolutely wrong.

Joel argues that instead of disabling a menu item, applications should leave them enabled, and instead display an informative message when the user tries to use them. This solves one problem: that of the user who is perplexed as to why a menu item is disabled. I recognize and applaud the desire to fix this issue. But enabling every menu item creates more usability problems than it solves.

Disabled menu items convey valuable information. Users who are skimming menus in order to figure out what to do are trained by years of experience to skim past disabled items and look for enabled ones instead. The more complex the application is, the more valuable this dichotomy becomes. In essence, disabling menu items gives application designers a means of “funneling” user attention to the actions in an application that will actually work at this moment in time.

Sure, it’s frustrating when you can’t figure out why a menu item is disabled. But what would be unbelievably frustrating is drowning in a sea of enabled menu items, for which the application offers no immediate usability guidance. Instead of skimming past disabled items, a user could be forced to select several, each time receiving a valuable instruction (punishment) as to why it was a worthless move. In time the user would learn to avoid these irritatingly enabled menu items, but they would be offered no future assistance in actually avoiding them.

Joel is right that it’s a bad idea to outright hide menu items. Users become comfortable with an application by learning its topography: where each menu item is in relation to its menu and the other items in that menu. When you go about willy-nilly removing and adding items, it can cause confusion. If you’ve ever visited an old home town after years away, you know this problem. You’re sure your favorite restaurant is around here somewhere, but so many of the shops and landmarks have changed, it’s hard to find it as quickly as you once could.

Joel’s suggestion may increase the learnability of an application in one very specific way, but at the expense of long-term usability. Although it can be argued that an application needs to be learnable in order to attract long-term users, I think user loyalty will be greater when the usability of the application is maximized.

What would be a better solution? The idea is to answer the naive user’s question: why is the menu item disabled? For this purpose I can think of many solutions. The application might show tool tips as the mouse hovers over the disabled menu item. Or if the problem is especially grievous, it could warrant a dedicated reference page in the documentation, where users could easily look up the cause of their frustration. The point is to build a framework for application learnability that does not seriously affect the usability of the application for experienced users.

It’s not often I get to say it, but hear me loud and clear today: don’t listen to what Joel says about menu items!

Consider Google Maps, which won me over instantly when I first tried it, almost entirely because of the innovative (then) “drag to scroll” behavior you can rely on whenever you see a Google map.

They won me over with a usability boon, which means I suffer through the usability gaffes. I often use Google Maps to locate businesses or other points of interest in whatever area I happen to be in. As luck would have it, the nature of businesses is that they cluster in one place. These are what our parents, who actually left the house, called “town centers.” So if I search for restaurants, I’m liable to see results like this:

This particular map was actually sent to me by fellow Boston-area Mac developer, Paul Kafasis. He was pointing out some local restaurants I should try. But this problem is not unique to this map or even rare. In fact, often the pins line up even more perfectly, so that you literally can’t tell there are more than one at the location.

Google has tons of real-estate to work with here, but to find out what’s actually at the cluster point, I have to go back to the ugly list and click items to see where they pop up in the map. With all that space to work with, surely Google could come up with something better.

The peacock approach would work to at least allow several places to show up at one spot, yet still be clickable. The directionality of the pin makes it clear that they’re all referring to the same point.

Of course, it could get complicated if nearby pins overlap with “the peacock.” Perhaps a “drop-down pin point” would be better, clearly identifying a multi-hit location with a different color and interior shape:

Surely with a feature that is so central to the map’s usefulness, Google can come up with something that improves on the current behavior.

With things in flux while I moved bits and pieces of the UI around, I was able to observe a pretty stellar example of how the visual placement of objects within a container can dramatically change the appearance of the container’s size. Consider these snapshots, taken from Mail and this experimental version of MarsEdit. Stare at the buttons on the Mail version (top), then at the buttons on the MarsEdit version. Which section is taller?

Answer? They’re exactly the same height. 23 pixels tall. The crowdedness of the MarsEdit version makes the whole section seem way shorter than it really is, while the Mail version has miles and miles of room to breathe.

It occurs to me that this illusion might not affect everybody the same way. To me the difference is stark, unless I start fixating on the blank part of the bar, when I can more easily accept they are the same size.

But I’d like to offer my revision on a popular joke from academia…

1. Those who can, do
2. Those who can’t do, write ToDo apps.
3. Those who can’t write ToDo apps … eventually figure out how to do.

For the past year or so, I’ve adopted the “save everything” approach, ala gmail, except on my Mac. So I have this huge “Received Mail” archive that actually, for better or for worse, contains every single email that makes it to my inbox, including spam that SpamSieve filters.

I’m not perfect at this, but I like to strive for an empty inbox. This makes me feel less stressed. So I “delete with abandon,” knowing that a copy has been archived for future reference. Unfortunately, when I delete with abandon I sometimes lose references to mail conversations in progress. I want to go back and see exactly what somebody said a few messages back, so I’m forced to go to my mail archive and look it up.

No problem, right? Wrong. My mail archive is huge so Mail stutters and thrashes. This is because even though I only care about the message I just received a few minutes ago, it is preparing to show me the entire history of my email life.

Now for the punch line. Smart folders solves this problem! I added a “Recently Viewed” smart folder to Mail, which simply shows me any message I’ve looked at in the past 2 days. At first I tried “Recently Received” but discovered that it also showed me all of the spam I’d received. “Recently Viewed” is perfect, because it shows me stuff I’ve dredged up out of the past. It’s my Mail message working set!

I was so pleased by this that I also added a “Recently Sent” smart folder to do basically the same thing, but for messages that I’ve recently written to others. My only major complaint is that I can’t order the smart folders above my gigantic IMAP hierarchy. It’s a pain to navigate down the mailbox list to find them.

For some dumb reason, I’ve been living without such conveniences for several years now. I know there are many 3rd party products that add an epic amount of functionality to the standard copy and paste of the system, but I’m not really interested in running a separate application for this purpose.

It occurred to me that this would be a perfect use of Xcode’s Menu Scripts. Xcode not only supports the addition of custom scripts to the menu bar, but supports a unique format by which the scripts can advertise keyboard shortcuts, and integrate seamlessly with Xcode’s text editor. For instance, you can use a script to process the selected text in Xcode and spit back out something else in its place.

Append To Pasteboard is a simple python script that takes advantage of the “pbcopy” and “pbpaste” commands to tack whatever you’ve selected in Xcode on to the end of the existing pasteboard. You stick this within your (horribly located) user scripts folder, where you must name the folders and files with numeric prefixes to inform Xcode where they belong. For example, the script lives in my home directory:

/Users/daniel/Library/Application Support/
	Apple/Developer Tools/Scripts/
	10-User Scripts/1-DCJ/

Unfortunately Xcode doesn’t handle the situation where some scripts come from your home directory, and some come from the /Library installation directory. So I put everything in my home directory. The “10-User Scripts” is how I tell it to name the menu bar item “User Scripts.” The “1-DCJ” folder is the folder with all my custom scripts in it, and since it is “1,” it comes before all of Apple’s standard scripts that I copied in (10-Open, 20-Search, etc). The process of providing scripts to Xcode is ugly but when you finally get it all put together, this is what you end up with:

Now it’s a snap to cruise through a .m and accumulate method declarations, for pasting into a corresponding .h. Note that the script always appends a newline to the existing pasteboard, which could be annoying depending on what you want to use it for. Since I envision myself almost always double-clicking a function or method declaration and appending it to a list, I find this behavior to be most convenient.

Thanks to Jon Wight for helping with Python.

Update: Any productivity gained by using this macro was certainly lost as I tried desperately to debug Xcode’s latest propensity to “beachball” on launch. Finally, I attached with gdb and found a telling backtrace. Hmm? Yep, when I “zipped” the script for upload to the blog, I left a zipped copy in the scripts folder. Next time I launched Xcode, it choked big time on trying to treat that zip file as a script.

The best part of the video? In the midst of all this enlightened modern living, the video shows a man scribbling away on his Newton while talking on the phone. A pay phone! If only they could somehow combine those two devices! I also like the knowing look and raised eyebrows one worker gives to another just before she “beams” him a message. A subtle suggestion that Newton might actually get you laid.

I never used a Newton much, although I occasionally had my hands on one at work for some debugging purpose. Some of the design considerations really pop out, like the fact that the Newton was almost entirely “soft button” based, much like its nascent offspring. The soft QWERTY keyboard is even reminiscent of the iPhone’s, except that with the Newton it was only intended to be used when the handwriting recognition made a mistake.

Which it did. A lot. Many people consider the failure of adequate recognition on the Newton, and the basically functional compromise of Palm’s “Grafitti” to have been the death blow for the gadget. Amid all the happy music and smiling people, you can tell the issue was weighing heavy on Apple’s mind, too. Halfway through the video the topic changes to “handwriting tips” and more or less stays on the subject for the rest of the promo.

If Apple presents iPhone along with a promotional video that is half devoted to teaching users how to workaround the device’s bugs, then we’ll know it’s doomed.