Apple’s new MobileMe service is due out before too long, and I’m pretty excited about it. In particular, I’m looking forward to what I hope will be a wholesale remedying of the many irritating shortcomings of its predecessor, the useful but error-prone .Mac service.
I know that I’ve said it before, but I’m really inclined to repeat it until a solution for its many problems is actually in place (and not just marketed) — .Mac is a very poor service. In my estimation, it falls far short of the high bar for excellence that Apple has consistently set for itself and met over the past decade.
If you don’t believe me, then have a look at this little collection of .Mac frustrations that I’ve been collecting. Think of it as a gallery of failure.
Here’s my number one peeve. Each time I go home from the office and synch for the first time, or when I go back to the office the next day and synch again for the first time that day, I’m confronted with this particular conflict resolution dialog.
Ninety-nine percent of the time, the resolutions to these conflicts are immaterial; as far as I can tell, they’re only conflicts insofar as a contact’s icon has been changed. My guess is that when a users sign onto iChat or another instant messenger client from work, that client software uses a different picture from the client software they’ve used at home. (Mac OS X applies those icons from I.M. programs to the system’s contacts database, and then synchronizes them.)
Often, the result is that I’ll see a ‘conflict’ that, to human eyes, isn’t much of a conflict at all. Like this one.
I might be able to excuse this system error, because it’s somewhat difficult for a machine to draw the distinction between two different image files even if they look exactly the same to the naked eye. (With an emphasis on “somewhat.”) However, I find this similar error more or less inexcusable:
Substantively, this is the exact same error as above, but there’s a crucial difference. The image is supplied by Apple — it’s one of the stock images you can pick from when setting up a new account — which makes it reason that Apple should know when a user has chosen the same image from two different locations. I just don’t think there’s any excuse for continually confronting a user with this ‘conflict’ just because Apple has failed to account for it.
Those errors, at least, are somewhat benign, even if they’re annoying. Here’s one that’s somewhat more alarming.
I have no idea what this means. Thankfully, when confronted with this error I can almost always initiate another .Mac synch successfully.
Along those lines, here’s another somewhat inscrutable message that I get with some frequency when synchronizing my iCal data.
In both cases, I can usually dismiss the errors and initiate a new .Mac synchronization right away, and almost always successfully. Which is good. But the ease with which those warnings can be disregarded leads me to think that these messages, while having the appearance of being quite dire, are actually rather trivial. A simple message that said, “Sorry, had a little trouble synching that time — please try again,” would have made a world of difference.
You might argue “no harm, no foul” when the ultimate outcome is that I’m able to synch properly. But to me there are few worse user experience gaffes I can think of than alerting a user to a seemingly disastrous problem when none exists. That’s just irresponsible.
Finally, there’s this bizarre error that I get every time I try to synchronize .Mac on my home computer.
Not only is its consistent and inexplicable appearance an irritation, but it also halts all synchronizing activity until I actually enter in the password that it asks for. I have no idea what causes it, and an hour or two spent online with a .Mac technician produced mostly uninformed and utterly unhelpful answers.
As you can see, while I find .Mac useful, there’s no love lost in my regard for its reliability. Mostly, I find these errors, though relatively innocuous, to be examples of just sloppy craftsmanship. No two ways about it: .Mac is a slovenly written. I hope MobileMe rectifies the situation.