In response to the updated iTunes 9.0 from Apple, fellow developer Todd Ditchendorf complained on Twitter that the application still lacks a convenient shortcut for “jumping back to the music.”

I use iTunes all the time, but it hadn’t occurred to me how annoying this is. You’ve been fishing around in the iTunes store, or the Podcasts source, or Audiobooks, or any of the numerous other zones of the application. Then, you get the crazy notion to actually use iTunes to listen to music, so you jump to the search box and start searching. Bah! It’s not searching my music, it’s searching the App Store, or whatever. Now you have to go click the “Music” icon, and start your search again.

So yes, it would be handy to have a convenient shortcut to switch back to the Music source, and that is where my scripting utility FastScripts is particularly potent. It was a little tricky to deduce which magic scripting command would achieve the goal, but I think I figured it out:

tell application "iTunes"
	set view of (browser window 1) to user playlist 1
end tell

Save this as a script file in your home directory:

[Home] -> Library -> Scripts -> Applications -> iTunes

This is an “Application-specific” scripts folder for iTunes, meaning it will only show up when the iTunes application is actually active and frontmost. Now you can open up FastScripts (free for up to 10 shortcuts) and use it to assign a keyboard shortcut:

Now when I’m browsing iTunes, I just press cmd-option-M and it jumps instantly to my music!

I have a bunch of iTunes scripts that I find useful. Over the next few days I’ll be highlighting other convenient tricks I use to make iTunes a more useful application through its scriptability.

I’ve been running Snow Leopard (Mac OS X 10.6) developer releases full-time on my main Mac for the past 3 months. I do this with all major new releases so I can iron out bugs and really get to know the system before it goes public. For 10.6, the public release is this Friday, August 28.

All Red Sweater applications are Snow Leopard 10.6 compatible.

The only serious compatibility issue I ran into during testing was a crashing bug in MarsEdit. Today I released MarsEdit 2.3.3, which addresses that problem. In addition, it includes a few other fixes for pesky bugs that might have affected you even on Mac OS X 10.5.

If you run into any issues using my products under Snow Leopard, please get in touch. It will be my highest priority to resolve compatibility issues, should they arise.

Wil Shipley writes about the compromised perfection we must strive for in order to provide users an experience that meets their human expectations:

“Classic computer programming has largely failed, because it failed to copy nature. Nothing in nature works 100% of the time, but it sure works well MOST of the time – and when it fails, well, you die and get replaced. A human being, for instance, is an absolutely amazing machine, and is provably NOT provably correct.”

I particularly like the example in the second half, having to do with smartly interpreting a typed ISBN numbers for product search. How do you strip the meaningless dashes from a search term, except when they’re utterly meaningful? This kind of thinking is important to fine-tuning an application. Nobody will appreciate the hours you spent laboring over the question, but for some reason they’ll just think your product is particularly awesome.

It’s interesting that the pursuit of perfection in an application has to involve the pursuit of compromise. By solving a problem in a way that degrades gracefully to unsolvable, you offer a happy, possibly even surprise solution to many people who would not otherwise expect one.

The latest ridiculous App Store power-play to make it into the public limelight is Apple’s alleged censoring of Ninjawords, an iPhone interface to a community-edited dictionary called Wiktionary. Before being approved, even as a 17+ rated title, the app’s developers were asked to remove specific words from the dictionary’s index.

(Edit 8/6/2009: Since I wrote this article, John Gruber received a response from Apple’s Phil Schiller. He paints a slightly different picture of the alleged censoring, and defends Apple’s intentions as being noble. I still maintain my theory below helps explains the capriciousness of AppStore review policies.)

John Gruber excoriates Apple for censoring a reference book. Gruber also discovered through an interview with a Ninjawords developer that Apple must have gone out of its way to locate words they could find fault with. Apparently the developers had been careful to prevent casual users from stumbling upon an offensive word, by preventing auto-completion for common vulgarities:

“In other words, the App Store reviewer(s) explicitly searched for curse words they already knew, and found them.”

I’ve been thinking about the capriciousness of the App Store review process. It’s ridiculous the kinds of rejections and hoop-jumping we’ve observed in the past year, and one has to assume that the issues making their way into the public eye are only the tip of the iceberg.

Then I remembered something from my own experience that might shed light on the situation. I started as a Quality Assurance tester back in 1995, in a small engineering group. Our group was diligent in the pursuit of finding issues that would embarrass the company or hurt customers. But we worked with larger groups whose motives seemed more oriented to the systematic evaluation they were receiving from their bosses.

These testers didn’t care how good their bug reports were. It didn’t matter if the software gaffe they discovered would save the company a million dollars, or a metric shit-ton of public grief. All that mattered was that the bug was “valid” and that the reporter was “first.”

I learned about the subtleties of this system through the ways that those testers interacted with me. Sometimes a bug that I submitted was determined to be a duplicate of an earlier report one of these testers submitted. If mine had more detailed information, it might be marked as the “original” bug, while the less informative bug was designated a duplicate. This worked great for those of us trying to ship a great product, but not so good for people who were fighting for their reputations in the metric-oriented testing groups.

Because our group was committed to shipping a great product, we were always convinced that bug reports with more information were superior. But the testers who were under the gun to produce new, unique issues, wanted credit for having uncovered these issues first.

As you can imagine, the “thirst for first” led to a significant number of ridiculous bug reports. If a tester could reasonably defend a bug report as valid, then it counted in their statistics, and made them look like a useful member of their team. My impression was that promotions and raises were directly linked to these statistics.

Many of the mercenary testers I encountered were motivated to scrape the system for bugs, as ridiculous as they may be. They logged them into the bug system and then defended them at all costs, as if their lives depended on it. And it turned out, they did. At least, their paychecks did.

I would not be surprised to learn that App Store reviewers are working under a similar structure. A system that rewards “unique, valid rejections” would certainly explain the behavior we have seen coming to light in the past year.

Why would somebody waste time typing profane words into a dictionary, gathering screen captures, and sending them to developers, except to defend their prize “catch”? If perfecting the product was the goal, we’d see a lot more nuance and thoughtfulness. But excellence is one goal, and collecting proof of “doing one’s job” is quite another. I think I know what many App Store reviewers aspire to.

Afterhought: It occurred to me shortly after publishing the above that App Store reviewers can’t be working purely under a “catch all violations” directive, because if they were, there would be numerous rejections based on UI guideline violations, and we’re not seeing as many of those (or are we?). I’m sticking to my thesis, but I suspect that the number of rejections we’re seeing on contrived issues like “you can find ‘cock’ in the dictionary” is because these are the easiest for reviewers to defend with Apple’s published guidelines. Whether a text field is aligned properly is a lot harder to challenge than whether “cock” can be interpreted as profanity.