Generating Footnotes With MarsEdit

July 14th, 2008

One of the aspects of MarsEdit which appeals to me is the way it hides much of its power and versatility beneath a relatively simple interface. Shimone Samuel recognized the power of MarsEdit’s scriptability and powerful markup macros, and came up with a pretty cool solution for automating footnote generation.

Nice work, Shimone! It’s great to see examples like this. As I said, I think it’s nice the way MarsEdit hides much of its functionality away, but the flip side of that is of course that it can be difficult to realize its full potential. Blog posts such as Shimone’s do a good job of showing off its hidden strengths.

Core Intuition: The Design Awards

July 1st, 2008

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.

Disabled Menus Are Usable

July 1st, 2008

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!

Development Phase Code Signing

June 29th, 2008

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.