Sci-Fi Hi-Fi

Slava, ever the agent-provocateur of the Mac developer community, sparked a fair amount of heated discussion the other day by posting an article to his weblog entitled “Shareware is Dead.” His argument is that the term shareware is outmoded—it made sense in the days when small developers distributed applications by word of mouth (sometimes with a little help from computer bulletin boards or computer magazines), but it doesn’t really fit the current, reigning model of Internet distribution.

In responding to Slava, meanwhile, both Erik Barzeski and Steven Frank (both developers of Mac software) point out what is, to me, a much more problematic aspect of the “shareware” label—it tends to connote a certain level of quality that is far below what people expect from “real” commercial software. This is, of course, unfair to applications like MailDrop and Transmit which may have been developed by small companies but still exhibit a level of quality equal to or greater than that of the larger software houses. The question, then, is what should small developers like Erik, Steven, and me call our software?

As the author of an application that traditionally would fall under the “shareware” heading, and as a developer with aspirations to someday having the level of success of Erik or Steven, I have personally thought about the problems with the “shareware” designation for awhile now, and I’ve come to one conclusion: that the term I prefer is independent software.

The model I have in mind here is, of course, independent records labels, and I think the comparison works well in a number of ways. Like an independent record label, an independent software company is differentiated from its “big league” competitors mainly by:

1. A much smaller number of employees.
2. A preference for direct distribution channels.
3. An ability to serve niches that aren’t economically viable for the larger players.
4. Less sensitivity to, shall we say, industry political correctness (here I’m thinking particularly of the coming era of “digital rights management,” which I think will be a huge boon to small developers with good hacking skills and a willingness to strike a blow for fair use).
5. Greater agility and far more sensitivity to emerging trends.

Most importantly, “indie” record labels don’t bear the stigma of low quality just because of their small size—far from it! Some of the greatest music in the last twenty years has originated from independent labels—for example, Factory Records in the late 1970s and 1980s and Creation Records in the 1990s. In the same way, I believe that much of the most innovative software in recent years (at least on the Mac platform) has been created by independent developers, and that this trend will only continue. Just as Factory and Creation were both there at the birth of new movements that later swept through their industry, I believe that “mainstream” software developers will increasingly find themselves taking cues from their “indie” counterparts.

Shareware may be dead, but who cares: indieware is alive and kicking!

Last night, around midnight, a very sudden snow storm descended on Denver. I thought it was worth capturing because:

1. We have gotten so little snow in Colorado this year.
2. It was a weird storm—the snow was descending in little “pellets.” Apparently this is what’s called an ice storm—I’ve never seen one before.
3. I happened to be out and about, and I need practice with my new digicam in anticipation of my upcoming UK/Ireland trip (I’m particularly interested in testing its low light capabilities).

So, for your viewing pleasure, some images of last night’s snow storm…

I’ve often mused that anyone who complains about Apple’s recent user interface work should take a quick look at the front page of VersionTracker any day of the week. The atrocities that amateur developers (usually drunk on the newfound power bequeathed to them by their copy of RealBasic) unleash upon the world through that venue make Apple’s UI transgressions look downright venial!

Serious Mac developers, many of whom also depend on VersionTracker as a major source of exposure, have long bemoaned the extent to which deserving apps get lost in the sea of crap on the site. As the author of an application with a great many competitors (many of which are very, very poorly done), I have certainly been among the complainers.

Fortunately, someone has decided to do something to hopefully reduce
the problem—by shaming the worst offenders! In the spirit of such “meta”
sites as Who Would Buy
That?, the folks at href="http://perversiontracker.com/">PerversionTracker scan
VersionTracker every
day for the worst the Mac software community has to offer—from a timer that measures a minute as 100 seconds, to a simple calculator program that offers no improvement over the one included with OS X (348Kb) but weighs in at a stunning 5.7Mb!

Here’s hoping that PerversionTracker becomes a very well-known site—and a major force in reducing the amount of crap that the Mac platform’s many talented, independent developers are forced to compete with for attention!

As I mentioned in my previous post, I purchased a new digicam from the Aspen Grove Apple Store last night. Being, as I am, an owner and devotee of the Leica M6, I had originally planned on purchasing a Leica Digilux 1. After reading a review from Photo.net, however, I became concerned about the excessive amounts of noise (on ISOs higher than 100) and weird “pointilist” effect that people have reported when using that camera. At the same time, reading Derrick Story’s excellent article about covering MacWorld using a Canon S200 “Digital Elph” convinced me that I might prefer a compact form factor to the decidedly chunkier Leica. Combine all of that with a much lower price, and the fact that it can use the compact flash media I already own (as opposed to the SD memory used by the Leica), and Canon S230 started looking very attractive.

Unfortunately, the first S230 I got from the Apple Store had a dreaded
stuck pixel—actually a cluster of about 4-6 near the middle of the image,
all stuck on red. So, I had to take it back and endure the predictable
lectures about manufacturing “tolerances” and how if Canon had to ensure
that if every one of their CCDs was perfect, my camera would cost $10,000.
Whatever. Fortunately, after taking some test shots to prove my case, the photo geek Apple Store employees were persuaded to take my camera back, and I now seem to have a perfectly functioning version.

In the best Dean Allen tradition, my first subject was, of course, Wilco.

Derrick Story, the managing editor of the O’Reilly Network (and the man whose stunning MacWorld photo reportage convinced me to purchase a Canon PowerShot S230 last night), has announced that O’Reilly will be sponsoring a competition for independent Mac OS X developers. You can rest assured that, rules allowing, PodWorks will be a contender!

In addition to being a top-notch photographer, Derrick is also a true “Mac guy” who understands that a community of excellent, independent developers is one of the best assets Apple has (and I’m not just saying that because he’s said nice things about PodWorks!). I think this contest will be a wonderful way to encourage even more grass roots innovation from OS X developers everywhere!

Well, there’s nothing like a gentle, well-reasoned rebuttal to make one
reconsider his href="http://www.scifihifi.com/index.cgi/mac/UILand.html">bold public
statements. To be honest, I didn’t expect anyone to take much notice
of my little essay on the issue of Apple user interface consistency, and I
was both surprised and gratified to see href="http://nslog.com/archives/2003/02/14/apple_ui_experimentation.php">Erik,
href="http://www.vinayvenkatesh.com/blog/archives/000186.php">Vinay, Matt and John Gruber all acknowledge my entry into the debate.

John and Matt in particular made me think twice about my post—Matt because he seems like such an all around nice guy and yet I was, by implication, comparing him to (cringe!) Jakob Nielsen; John because he seems to present such a well-developed philosophy of what the essential qualities of “Macintoshness” are.

One of John’s statements in particular hit me right where it hurts:

It’s not pedantry that inspires Mac afficionados to gripe about Apple’s violations of the Macintosh Human Interface Guidelines. It’s not that the HIG is simply a list of rules to which a bunch of us nerdy Mac experts demand blind adherence only for the sake of following rules. It’s that the guidelines outlined in the HIG form a cohesive whole describing a philosophy of design.

This is absolutely true, and I, a self-professed admirer of rigorous, Bauhaus-style design, should certainly admit it.

While I don’t exactly back down from my statement that “Consistency is
valuable, but only as long as it doesn’t stifle innovation,” John’s well-reasoned response compels me to add a proviso: the case where innovation trumps consistency is exceptional. I still feel justified in expanding the debate by defending Apple’s right to depart from their own HIG, but I must also add that this is a right which, like the right to amend the US Constitution, must not be taken lightly. Unfortunately, as Erik, Vinay, and John have been pointing out, Apple hasn’t exactly been conservative in its approach to UI development lately, and a lot of its recent design work has absolutely screamed “design for design’s sake.” All of this is, of course, very “un-Bauhaus” and, all things considered, very “un-Apple.”

There has been a lot of talk in the Mac community lately about a
perceived decline in Apple’s user interface standards. John Gruber has href="http://daringfireball.net/2003/02/when_in_rome.html">savaged
Safari over at Daring Fireball, while one of Safari’s developers, href="http://www.mozillazine.org/weblogs/hyatt/">David Hyatt, has
suffered the consequences of soliciting UI feedback via his own weblog.
href="http://nslog.com/archives/2003/02/12/mac_ui_roundup_osnews.php">Erik,
href="http://www.scotlandsoftware.com/blog/index.php?p=83078088&more=1">Matt, and Vinay have also weighed in with thorough critiques of the custom UI widgets used in Apple’s iApps. And don’t even think about mentioning textured (i.e. metal) windows on Apple’s cocoa-dev email list unless you want to provoke a tedious, two day debate about Apple’s human interface guidelines (a debate which, by the way, is recapitulated every time a new iApp is released).

I usually try to steer clear of such discussions, because, for me, they only bring back unpleasant memories of joyless usability “gurus” like Jakob Nielsen (not to mention certain ex-Apple employees who simply can’t abide any departure from the classic Mac OS). I’m going to add a few comments to this particular discussion, however— both because I think in this case the nay-sayers have some valid points, and because I would like to offer some dissenting food for thought.

Let’s start by stating the complaint simply. It seems clear from the
applications Apple has released in the last few years that a certain amount of, shall we say, experimentation has been encouraged in the UI department. Rather than adhering to a standard set of interface widgets—the same NSTextFields, NSToolbars, and NSButtons available to all Mac developers—Apple has seen fit to concoct a variety of novel UI elements for each new iApp. To critics, this is sacrilege since it flies in the face of one of the cherished cornerstones of Mac usability: consistency. If developers always use the same widgets and adhere to a set of well-defined rules in designing their interfaces, people, it is reasoned, will be better able to understand new applications and become less initimated by their computers.

What if I was to suggest, however, that consistency is no longer as important a value in UI design as it was in 1984? What if I was to propose, in fact, that, within reason, the evolution of new GUI widgets is not only proper, it is essential (to paraphrase Dr. Strangelove)? And what if I was to tell you that one of today’s smartest interface thinkers agrees with me?

No, I’m not referring to the aforementioned Nielsen or Tognazzini, or even that celebrated information visualizer Edward Tufte. Rather, I’m speaking of Steven Johnson, whose blindingly brilliant book Interface Culture provides an insightful, 21st century alternative to the crusty “Don’t Make Me Think” school of interface thought.

Johnson recently published an excellent opinion piece on (of all places) Slate, in which he argues that Microsoft and Apple are moving in two completely different directions with their interface design. While Microsoft, ironically, is now chasing the holy grail of complete consistency with their “Longhorn” project—one interface to access all of your email, photos, music and video—Apple has adopted what Johnson calls a “Swiss Army knife” approach, in recognition of the fact that different types of media call for different organizational and navigational metaphors. Thus the profusion of new widgets in the iApps.

This is not to deny, of course, that some of Apple’s recent UI designs have been ill-considered. The combination text field/status bar in Safari stands out as a particularly problematic example, and I couldn’t agree more with John Gruber’s criticism of the grayed-out menu items used as headings. Though it never bothered me particularly, I can also recall a number of friends and relatives who have been confused by the “airlock” style “Burn” button in iTunes. All of these things should be fixed, but not merely because they are inconsistent with the canonical OS X widget set—they should be fixed because they either fail to serve their intended purpose or are unnecessarily obscure.

The desktop metaphor has informed the way people have used computers
for almost 20 years now, and I think it’s safe to say that they have it down pat. While users of the Macintosh in 1984 may have prized it for its consistency when compared with older command line apps, users of the Macintosh in 2003 are not likely to be quite so concerned. What’s more, users of Macintosh 2003 (a.k.a. the “digital hub”) are certain to have far more varied uses for their machines than their 1984 counterparts—uses which demand more sophisticated interfaces than the traditional toolkit provides. Obviously there are limits to how far Apple should go: I’m not arguing for complete UI anarchy here. I’m just proposing that Apple is not necessarily out of line when they invent a component like Matt’s “NSSchizophrenicTextField” to solve a problem unique to a certain application. Consistency is valuable, but only as long as it doesn’t stifle innovation.

I finished the latest update to PodWorks (1.3) over the weekend and released it this morning. Aside from the usual, humdrum bug fixes and tweaks, this version introduces two interesting features: French language support and a “Play Count” column.

The French translation was especially interesting to me, since PodWorks represents my first serious attempt at software localization. I had three years of French in high school and I’ve actually visited France twice, so in many ways French was a natural first choice to begin expanding PodWorks’s linguistic repertoire. Still, the further I got into the process, the more I realized how utterly lost I would have been without the help of PodWorks’s volunteer translator, Axel Chaminade.

In all of my schooling, for example, I had never been alerted to the typographic niceties of French punctuation, which dictate that many punctuation marks are to be prefixed with spaces. Colons, it turns out, should always have a space prepended (e.g. “a: b” in English versus “a : b” in French), as should exclamation marks. Without Axel’s guidance, I would have been similarly befuddled by certain idiomatic technical translations, such as the rendering of songs as “morceaux” (“pieces”) instead of the more literal “chansons.”

Localizing PodWorks also gave me a fresh appreciation for the elegance of Cocoa’s approach to software development. The fact that a Cocoa application’s GUI is stored as serialized objects in a Nib file (in contrast to the mass of generated code found in a Visual C++ or Java GUI) makes it easy to add localized variants that adjust for the varying lengths of strings in different supported languages. Where languages like Java stop at the use of properties files containing localized strings, Cocoa goes one step further by allowing for the easy creation of completely different GUIs on a language-by-language basis! Que élégant!

For anyone who is interested in the subject of localization in Cocoa, I highly recommend Andrew Stone’s excellent tutorial. His discussion of what he calls “end user localization” is particularly valuable (it would have saved me a lot of time if I have read it before I began).