In Episode 4, Manton and I discuss the Apple Design Awards, which were handed out at WWDC. We also go off on a fun tangent about application versioning, and how the traditional “Mac way” of doing it is is frequently overlooked or ignored by new developers to the platform.

Joel Spolsky has a remarkable track record of speaking truth to programmers on his blog: Joel On Software. Occasionally he says something with which I disagree, but usually it’s on a subtle point, or it’s an issue where his passion for doing things one way is motivated by his preferred platforms: Windows and the web.

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!

Code signing is a technology for associating a cryptographically secure signature with your application’s executable code. This signature makes it possible for the operating system or other services to make confident assumptions of authenticity based on the unique signature which you’ve supplied.

Thus, code signing is a technology which is rather useless in itself, but which can be utilized by other services to achieve specific goals. Starting with Mac OS X 10.5, Apple built some features into the operating system which take advantage of code signing, including some features which make accessing secure items from the keychain less of a nuisance.

In particular, consider the scenario in which an application asks permission from the user to access items in the keychain. Once the user gives permission to “always allow,” the application can thereafter obtain a secret value from the keychain without user intervention. This is very handy for internet passwords, etc. But once the application changes, e.g. a new version comes out, the user must be asked again to permit the access. This is to ensure that malicious code hasn’t been snuck into the application.

But with code signing, the users permission can be expanded to cover any release of the application that was signed by the same certificate. The idea is that if users approve one version of an application, then they’ll likely approve the next version, as long as they are guaranteed it came from the same developer.

I have so far not signed any of my publicly released applications. I may do so soon, because these conveniences would remove one more tedious task for users who are updating to the newest versions of my applications.

But the user who has it worst of all is me myself, as I’m constantly revising the application, leading the system to request new approvals every time my changed application accesses the keychain. To get around these constant requests, I finally decided to at take advantage of code signing during the development phase. What does that mean? It means I’m committing to signing my own code for my own internal purposes, but not yet committing to signing publicly shipped products.

From Zero To Code Signed In 300 Seconds

With Xcode 3.0, code signing is easy, but takes a little work to set up. Since I just went through the somewhat tedious task myself, I thought I’d share with you how it’s done easily and predictably:

1. Establish a self-signing certificate. Apple offers simple instructions for how to do this with the Apple-provided Keychain Access utility. When you create the certificate, you’ll be asked to give it a name. Name it whatever you like, for instance “My Cert”. The certificate is stored in your keychain, where it can be easily referenced by name.
2. Add a custom build phase to Xcode. Xcode will not automatically sign your code, but it’s easy enough to add a build phase that does. Select your target in Xcode and choose “Project -> New Build Phase -> New Run Script Build Phase” from the main menu. Paste in the following script:

   if [[ ${CONFIGURATION} == "Debug" ]]
   then
   	# -f means force to re-sign even if already signed
   	codesign -f -s "My Cert" "${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/"
   fi
   

   Observe that the “My Cert” text can obviously be changed to whatever you ended up naming your certificate. Also notice that because of my hesitation to ship a code signed application yet, I am restricting the action to only the Debug build configuration. If you’re ready to go public, just remove the test and the code signing will happen for all build configurations.

3. There’s no step 3! Enjoy.

Constantly approving those keychain approval dialogs is one of the things that I just fell into the habit of tediously doing. Thanks to Apple’s code signing efforts in 10.5, there’s no longer any reason for me to do that. Hopefully if you use the keychain in your own development products, you’ll find this productivity upgrade useful as well.

At this year’s Macworld conference, the guys at Rogue Amoeba decided to do what many trade show exhibitors do: give away a free demo CD to interested attendees. But recognizing the conventional drawback of these demos, that they are obsolete from almost the minute the disc is burned, they invested in developing a clever application that runs from the disc, and conveniently presents the latest copies of all of their software to the user. If what’s on the disc is still fresh, the user runs it. Otherwise, the latest version is downloaded from the web and that’s what the user sees instead.

I spoke to them about their solution at the time, and was impressed by it. It certainly seemed like a good way to avoid turning those thousands of plastic discs into guaranteed landfill fodder. But what’s even cooler is that they’ve now decided to share the technology so that other companies who are interested can pull of the same feat with a minimum of work:

Announcing LiveDiscKit

It’s also worth reading to near the end of the article, where they confess that even with the clever technology in place, the discs did not turn out to be all that effective as marketing tools:

Of the 5,000 discs we gave out, 5.8% were ever used. That may seem a bit low, but it gets quite depressing when converted to an absolute count: 288. Out of 5000 CDs given out, no more than 300 were used – perhaps giving away CDs isn’t the best idea after all

Well, you can’t win them all! On the bright side, I don’t think they would have been able to gather this information without putting in the effort to make the discs smart enough to “check for updates.” It was a valiant effort, and a very cool idea that other companies might still find useful.