tewha.net

Audio MIDI Setup is a pretty moldy corner, really. Click to see it in motion:

Even the question and button names at the end are worded in a way that conflicts with generally accepted Mac standards.

So I’m about five days into my free .Mac trial, and I thought I’d write up some thoughts.

I pay about $60 per year for 500 GB of storage and 5 TB of bandwidth from DreamHost. .Mac costs $100 per year. For that much, it should be really, really special. On a strictly numerical level, DreamHost beats .Mac. Now, it’s true that DreamHost’s reputation for reliability has taken a beating the last year or so, but for $6 per month I can accept a few days per month of down time. And it’s nowhere near that bad; it seems to be less than one evening every month or two.

So that leaves a comparison of features. Now, actually there’s very little overlap between the two. .Mac offers a bare minimum of traditional web hosting features, with low bandwidth and storage, and few of the more dynamic features such as SQL and PHP. DreamHost offers huge bandwidth, huge storage, and lots of dynamic features.

As a traditional webhost, DreamHost wins hands down. But .Mac offers a lot that DreamHost doesn’t.

Apple lists the features of .Mac as Web Gallery, Website Hosting, IMAP email, Back to My Mac, Sync, iDisk, Groups, Backup, and 10 GB storage. There’s also easy publishing with the iApps. The webmail interface shames DreamHost’s webmail, but I download all my email anyway. The most useful-looking features are syncing and Back to My Mac.

Back to My Mac doesn’t work at all for me. There’s no errors, no feedback at all — it just isn’t there where it’s supposed to be. I’ve done a bit of research on this, and I expect it’s because my NAT doesn’t support the features Back to My Mac needs. But this is really just a guess, since there’s no feedback at all.

At first glance, syncing seemed to work for me. But then I ran into an odd problem: The sync created duplicates of a bunch of smart mail boxes. No problem, though: Delete them, reset up to .Mac. It’ll propagate to the other computers, right? Well, it turns out that’s a bad assumption. It worked to a point, but then one of the other computers just adds them again. I’d basically need to delete them from both computers simultaneously in order to get rid of them. No problem, I’ll just use Back to My Mac.

Oh, wait. That’s not going to work.

Well, maybe I’ll check out .Mac in another few years. But for now, I can’t imagine spending $100 on it. I want something that takes the gremlins out of a multi-machine existence, rather than adding bigger, more annoying ones. I feel like I started with a mogwai and .Mac fed it after midnight. Maybe if I was a bigger webmail user or wasn’t comfortable setting up things like WordPress it would be more interesting, but I’m not that guy.

In addition to the Time Machine security issue I reported (radar link)¹, Apple has also fixed Time Machine being almost unusable on my Core Solo Mac mini due to poor graphical performance (radar link). Prior to 10.5.2, the star field animation was too taxing for the little guy. With 10.5.2 and the Leopard Graphics Update, it zips along at a perfectly respectable rate while leaving my Mac responsive enough that I can select files without needing something to keep me busy between clicks.

Unfortunately, Apple has not fixed the problem where the Leopard’s new (and totally awesome) menu search can point to the wrong problem (radar link). Still, at least the arrow is close enough. I love this feature.

Two out of three is pretty good, especially considering the one left unfixed is relatively minor.

The bugs that were flagged as duplicate also seem to be fixed. Sadly, my biggest Finder pet peeve (radar link) is still present (click the image to see it demonstrated in a QuickTime movie):

I’m pretty sure this one predates Leopard.

I’m one of those who thought that 10.5, even with its bugs, was a better OS choice than 10.4. However, with 10.5.2 I can finally recommend 10.5 without even a hint of reservation.

1. You won’t be able to follow this link; it’s in case anyone from Apple stumbles across this post and wants to look up these bugs. See rdar:// urls over at the red shed if you’re interested in this. [↩]

Apple claims to have fixed the issue where applications could run automatically out of a Time Machine backup. Look for CVE-2008-0038 in Apple’s About the security content of Mac OS X 10.5.2 and Security Update 2008-001 .

Thanks to Apple for mentioning me. I certainly would have reported the bug regardless, but it’s a nice bonus.

The only thing I wish had happened differently was an earlier acknowledgement from Apple that they realized what I was describing and agreed it was a security problem. I didn’t find out Apple considered it a problem until January 22nd, when they asked how I’d like to be credited for discovery. Most of that time I wondered if I should file more details in an attempt to convince them it really was a problem.

Note: I’m saying “claims” only because I haven’t installed the update and verified the fix yet. I have no reason to disbelieve Apple.

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. [↩]

I consider Stacks the very worst feature Apple’s ever added to Mac OS X (or Mac OS before it). Even QuickTime auto-play could be turned off! So I was very pleased to see a report that 10.5.2 fixes stacks (in the same way people fix their dogs). Hooray! (via Daring Fireball.)

The Finder is generally pretty good at reformatting the data column to show dates without truncation. Give it enough space, and it will display the date as “Friday, November 23, 2007, 12:52 PM.” A little less and it is supposed to drop the Friday part. A little less and it switches to a numeric format.

Unfortunately, it seems less than perfect. Sometimes it keeps the long format with columns that are too narrow, as seen in the following picture:

Why? I don’t know. It seems they put so much effort into this already, it’s hard to imagine why they didn’t make the final push to make date columns always usable.

Radar #5612934.

This will surprise no one, but Mobile Safari is not exactly like desktop Safari. Most of these differences are limitations, but one stands out in my mind as a feature.

Namely, that’s the ability to zoom out to get the big picture of a web page.

It’s true that this is a lot less necessary on the desktop due to the large screens on many systems, but that doesn’t mean it isn’t necessary at all. On my PowerBook, a lot of things scroll. Even on this iMac I’m using write now, the “New Post” screen scrolls.

A large image is already zoomed out in desktop Safari, so why not a large web page? I should be able to hit, say, F7 and have the page fit my window and click to zoom in on a part of the page.

While Apple is at it, they can add some indication that you’ve been zoomed out to images.

Here’s an example of the current view, using Macworld’s website:

You see a bit of the page, and can scroll for the rest.

But here’s what the zoomed out look would look like:

(In reality, this might be zooming out too much.)

Now imagine that scrubbing with the mouse pointer shows the area in more detail:

We haven’t got an obvious win yet, but we’re well on the way to something useful. I bet Apple’s engineers could make this an obvious win.

Mac OS X Hints describes how to make Leopard’s menu bar opaque. Much easier on the eyes.

This is a mystery to me. Why would a popup menu stop before colliding with the dock? Shouldn’t it layer above the dock?

And if it isn’t going to layer over the dock, shouldn’t the menu at least extend upwards?¹ Why should I need to deal with menu items three at a time on a monitor with a resolution of 1680×1050?

Not sure if this happened in Tiger or not.

1. It usually does. I don’t know what’s different about this situation. [↩]