tewha.net

As you’ve heard by now unless you don’t follow anything iPod-related, Apple put out an application update for the iPod touch. It costs $20 and adds a bunch of useful new applications. Generally accepted reasoning is that the Sarbanes-Oxley Act is to blame for Apple charging for it. A great recap on that argument is here.

Which begs the question that if the 802.11n enabler was $2, why was the application update $20? Why not $2? The generally accepted reason is Apple are charging what people will pay¹.

I’d like to float a different theory. This is a complete wild guess, mind you, but since I’m currently watching progress bars in another window I have very little else to do but type crazy theories.

I think Apple is charging $20 so they can realize the revenue using a subscription model without it looking ridiculous on paper. Why might they want to do this? Because then they can add additional features to anyone who’s paid the $20 without accounting problems.

This would have been stupid for the 802.11n enabler. There are quite simply no more magic hardware features to pull out of the hat. Any new features, then, will be unarguably software, and will probably come in the form of a for-fee 10.6 “Lion”².

I guess we’ll know when Apple adds features that aren’t simply updates and fixes to the shipped applications. My theory is that it’ll be free for anyone who purchased the application upgrade, and not available to those who haven’t.

What does it matter? Well, you need to look at what major feature is on the horizon for the iPod touch.

Third party applications.

Yeah, it’s hard to argue that supporting third party applications isn’t a major new feature.

So my prediction, and I’ve been wrong many times before, is simple: Installing a third party application will require that you have installed the “application update” and paid the $20 fee.

Because here at tewha.net, we’re not afraid to make wild-assed guesses based on no facts at all.

1. Which is sort of a nice way of saying Apple is a bunch of greedy jerks in this case, given that we paid a pretty large price for the iPod touch not too long ago [↩]
2. Name pulled out of the air. [↩]

Coding Horror’s plea to programmers: Don’t pollute user space. I totally agree with this one. Microsoft and Palm, in particular, need to get their ugly mitts off my Documents folder!

TextWrangler got update to 2.3. I haven’t been using it for long, but I did notice an icon change.

When TextWrangler first shipped for Mac OS X, it looked pretty good. It wasn’t bad compared to most applications, but looked ugly compared to Apple’s recent icons.

There’s a few things I don’t like about this icon, but they’re mostly related to it looking out of focus and drab. I’ve often wondered if it started out at 32×32 and was scaled up and had a quick fix applied to it rather than a redesign.

TextWrangler’s icon has been looking increasingly out of date for the last few years. The new icon doesn’t look so different that it can’t be recognized, but it brings the icon up-to-date:

I’m not overly fond of the jaunty angle it’s set at, but that seems pretty common these days. However, the drabness and bluriness is gone, replaced with vivid (but not distracting) colours. The rope in particular… well, in previous versions I wasn’t completely sure it was a rope. Sometimes I wondered if it was actually mango liquorice¹.

1. Good stuff, that. In fact, I think I’ll pick up a bag later. [↩]

I’m seeing over and over in blogs and “news sites” how Apple’s new Xserve is the most powerful Xserve ever.

Consider:

• Hardware usually gets faster or cheaper. Sometimes both.
• The Xserve price hasn’t dropped like a stone.
• It’s been 4-5 months since the last Xserve was last updated.

Put it another way: Unless it was radically cheaper wouldn’t Apple have just left the old one on the market if the new one wasn’t faster?

I have my problems with MacWorld¹, and I think they’ve fallen some from their glory days, but incidents like this just show how far they’d need to fall to catch up with everyone else. In this case, MacWorld at least used one of Apple’s claims to quantify the increase in their headline, and even attributed it to Apple (Apple: New Xserve twice as fast as predecessor). Not so with hundreds of other news sites.

1. Chief among them their horrible new software, which in addition to being ugly ate my login to the point that I can’t create a new one. [↩]

Just a quick plug for a coworker’s incredibly nerdy, usually profane math comics. Let the advanced nerdery commence! Huzzah!

In Where Keyboard Shortcuts Win, Gruber talks about Tog’s findings on mouse vs. keyboard. In a footnote, he adds:

Especially with most Cocoa apps, where the Find commands are in a sub-menu, and thus take even longer to target using the mouse.

To me, this is a real problem on Mac OS. It is not one that Apple has not only completely failed to address, but has actually made worse in Mac OS X. For technical users, items in hierarchical menus are slightly more difficult to activate. But for non-technical users, items in hierarchical menus are not just a little more difficult to activate, but awesomely so. And in Mac OS X, Apple has introduced more of them!

Hierarchical menus have become a little better now that you don’t have to hold down the mouse button¹, but watching a neophyte or novice try to access them is a real eye-opener. I’d really suggest to any developer thinking of using one that they ask a non-technical person to select one. Using the mouse at all is the first major task. Using the mouse to select menu items is almost as difficult. And using the mouse to select menu items in hierarchal menus will often be more difficult than the previous two combined. It’s not only conceptually screwy, but physically difficult.

After doing so with a product used by teachers (including the almost-ready-to-retire), I removed every hierarchical menu from our application. There weren’t many anyway. But one of the most difficult things for me when moving from Mac OS Classic to Mac OS X was how obvious it was that Apple hadn’t tested this.

Now I’m not altogether opposed to hierarchical menus. I think they’re a perfectly valid solution for Services, Open With and maybe even Arrange By². All of these options can be accessed some other way, except for Services which are rarely used by novices or neophytes. I also think they’re fine for contextual menus, since contextual menus only offer choices that are available elsewhere.³ But having Find commands in a hierarchical menu? That’s completely completely insane. Find is something users need to be able to access.

Apple even admits this problem in Apple Human Interface Guidelines:

Because submenus add complexity to the interface and are physically more difficult to use, you should use them only when you have more menus than fit in the menu bar…

So far, so good. But they go on:

…or for closely related commands.

This simply does not follow! Making something physically more difficult to use just because it’s closely related to something else is stupid. A good design puts commands in recognizable locations, and puts commands users need to access in locations that are easy to physically access. Closely related is not an excuse for a hierarchical menu. Closely related and infrequently used⁴ is a good reason, though. But what genius decided that spell checking and find qualified? If find qualifies as infrequently used, it’s almost certainly because it’s such as a pain in the ass to select!

I do think this is less of a problem now that the menu search has been added to the Help menu. I find myself using this frequently in applications with many infrequently-used menu entries.⁵

1. And, in fact, this suggests a simple fix Apple could do: Clicking an item with a hierarchical menu should lock that hierarchical menu open so the user can take as long as they want and use whatever motion they want to get into the hierarchical menu. [↩]
2. Arrange By is a valid place to use them only because novices and neophytes are probably looking to arrange by name most often, and that’s easily achieved by switching to list view. [↩]
3. Ahem. Or should. See Apple’s Human Interface Guidelines on Contextual Menus. [↩]
4. Or an option with an easier access method. [↩]
5. Another symptom of lack of zen in application design. A few unused commands are normal but when a menu bar consists almost entirely of unused commands there’s a problem. [↩]

From an RSS feed:
“Here at Xyz we are striving to be the #1 blahblah company and are well on our way. ”

Great. So who is #1? I should really be dealing with them, shouldn’t I?