Archive for October 23, 2006

Monday, October 23, 2006 [Tweets] [Favorites]


Ned Batchelder:

Pygments is a new pure-Python package for syntax highlighting source code. It seems very well done, and quite full-featured. Not only does it lex and color a bunch of languages, but it handles embeddings too, like Django templates in HTML. I use SilverCity on this blog, but have never liked that it calls into Scintilla DLLs to do the hard work, and isn't up to the task of two languages shuffled together. Pygments seems like a good alternative.

Python Paste 1.0

Paste “brings consistency to Python web development and web application installation, providing tools for both developers and system administrators” (via Ian Bicking).

Build Your Own Damn HIG

Daniel Jalkut responding to John Gruber at C4:

Is the HIG dead? I don’t know. But Gruber’s talk was thought-provoking, and I’m feeling pretty convinced right now, high on sleep deprivation and freshly returned from the fray. At the very least I think it’s time for us crotchety old engineers indoctrinated by System 7 or earlier values to mellow out a bit. I got so used to defending the party line for so many years, that I stopped questioning whether it was worth defending. Taking a step back now, I have to wonder why none of us, noticing that Apple was “constantly violating its own HIG,” stopped to consider whether we were the suckers for being so hung up about these problems on their behalf.

Violations in appearance are the easiest to see and get the most play. They bother me because I like looking at a consistent interface and because I think many of the custom controls are ugly. But it’s not that big a deal because, as the Web has shown, people know how to recognize weird-looking buttons. More important, I think, are higher level design and behavior. These were never as codified as the appearance guidelines, they’re more subtle and so are harder to build into an implicit HIG, and yet they determine what it’s like to use Mac software. This is where the real shift has happened in the second Jobs era.

I’m thinking of the card interface in Address Book; the decision that (until recently) iMovie would take over the screen and not allow more than one open document; the increased use of icons for verbs; the increased use of modes; the use of large multi-paned windows and tabbed inspectors over larger numbers of smaller windows, i.e. extreme reduction of window clutter even when this makes the interface constricting; the behavior of selected objects and panes; and the trend towards tabbed windows with a very small number of controls on each tab.

Apple has, deliberately or not, been doing a lot of things differently. There have been both good and bad ideas, with little guidance about which ones should be adopted, and in which circumstances. New ideas are rapidly adopted throughout Apple’s apps, but are slow to make their way into the frameworks. The problem is not that Apple has been breaking its own rules or writing new ones. It’s that—as the brushed metal saga has shown—Apple’s choices seem more driven by fashion than considered design. It’s leaving a leadership vacuum.

Update: Scott Stevenson writes:

Some Mac users are concerned that the lack of guidelines means things could spin completely out of control. Here’s what I’ve learned: Mac users, on the whole, have a sense of taste. If an app’s experience isn’t right, they simply won’t use or buy it. The Mac user base is its own filter. It’s not just theory, we’ve seen it happen.

Which is true to an extent. However, in some ways things already have spun out of control, and there aren’t enough apps for us to have the luxury of choosing a product that has the right functionality and good taste (though, fortunately, these sometimes coincide). Scott says “Can you imagine Front Row with NSTableViews,” but that’s a false dichotomy because Front Row is a full-screen app that will be controlled from across the room; it’s obviously an exception. I can imagine Mail with a normal outline view, and it works just fine. Also, I don’t buy the idea that there can’t be consistency or guidelines or framework support because the new stuff is still in flux. Gear buttons have been around for at least three years. They should be relatively easy to standardize. Yet they still look and behave differently in each app and they have no support in either Carbon or Cocoa. They are mentioned in Apple’s publication style guide, which calls them action pop-up menus—rather unfortunately, because “action button” has a completely different meaning in the interface guidelines and because historically pop-up menus (with up- and down-pointing triangles) have been for showing states. The gear button more closely resembles the pop-down menu, which has a larger down-pointing triangle and typically contains commands rather than states.