The recently-released OS X 10.4.7 update included a not-announced Dashboard widget update feature which silently checks to make sure that your widgets are valid. I agreed with the need for such a feature, but wrote about how I think Apple could have implemented things a bit better.
After a particularly infuriating search effort for the Curious George soundtrack at the iTunes Music Store, I wrote this editorial about the store's messed up search functions. Oddly enough, the very day we ran the editorial, Apple updated the store's search functions, and the new functionality addressed every single issue I had raised. Talk about bad timing!
Last week, for the first time since installing iLife '06, I had an excuse to use the newest version of iDVD. In general, I love it. But someone at Apple made one seemingly insanely poor decision involving the "burn progress" screen:
That's the screen that appears when you start the encode (if not yet done) and burn of a final DVD. In prior versions of iDVD, this area was a separate tab within the main iDVD interface. Now it's been attached to a drop-down sheet, as seen above. Within that sheet is a progress bar and a ticker that counts off how many items have been processed.
So far so good, though a progress dialog in a sheet is a somewhat unique concept. But the other change that came with this new sheet is incredibly unwelcomed--you can no longer hide iDVD in any traditional manner. If you try Comamnd-H with iDVD in the foreground, it just beeps at you. If you switch it to the background and then do "Hide Others" from some other app, everything except iDVD hides, and you'll hear the beep again. I even tried AppleScripting it, with no success.
OK, fine, I thought, I'll just minimize it to the Dock. Nope. That doesn't work either. Argh!
Since the sheet is dynamic, my screensaver won't kick in if it's visible. So it seems you're just plain stuck with the iDVD box onscreen, which is an amazingly poor decision on Apple's part. I finally managed to at least make it non-visible by using Backdrop, a utility that lets you drop a desktop picture (or solid color) down as a layer. So I ran Backdrop, set it to display a nice picture, then switched Backdrop in front of iDVD. iDVD was now hiding behind Backdrop, and since Backdrop takes up the whole screen, I couldn't accidentally activate iDVD by clicking its window. I could still switch to it with Command-Tab, or by clicking its icon in the Dock, of course. But at least it was out of sight, allowing me to more easily work on other things while it rendered away in the background.
Why oh why can't we just have Command-H work again, as it did before?!
So let's assume you're a big, powerful, corporation, generally viewed as "customer centric" with very cool and useful products. Sometimes, though, you have the occasional 'what we're they thinking?' moment with a product. Let's further assume your name is, oh, I don't know, how about...Apple? Here's yet another of those moments they seem to have with some regularity:
That, in case you're not familiar with it, is the button in iPhoto toolbar that lets you publish a selection of images to your .Mac homepage. Click it, and a wizard comes up that helps you select the theme, layout options, and other features for your photo page. You then click Publish, and presto, your images are published on your .Mac homepage, complete with a very nice slideshow feature. Presto, bango, simple!
So what's the problem? Well, that button (and the wizard it launched) has simply vanished in iPhoto6. There's no discussion about it in the manual, nor in Help, nor in the Read Me, nor in the Knowledge Base. It has simply disappeared into the ether.
Instead of using the handy wizard, you're now supposed to send all your images through iWeb, which will then force you to create an actual site, just to contain what should be a simple slideshow page. Yech. There is a workaround, which I'll write up in detail for macosxhints next week. (Short version: export and resize to 800x600, upload the folder to your iDisk, then use the .Mac homepage to create the photo page.) But the workaround is a far cry from the ease of use of the old wizard.
Now personally, I never used this feature, as I don't use .Mac for my photo pages. However, after recommending the iLife upgrade to my mother, I definitely got an earful about this "new and improved" iPhoto when she found her single most used feature missing in action! Since I feel responsible for the problem she now faces, it's the least I can do to try to help spread the word about this, and hope Apple can see fit to return a basic feature to the application.
I'll probably be writing about why this is a Really Bad Thing on macworld.com next week, but I wanted to get something up about it now, while it was fresh on my mind. Of course, based on Apple's treatment of the discussion I linked to above, I don't have a positive feeling about the chances of this feature's return...
Perhaps, though, if enough people make enough noise about it, they can bring back what was a powerful and easy-to-use feature.
Given my background with it, and its role in leading to an unexpected but welcomed career change, I'm clearly a fan of OS X. But sometimes, I really question the quality assurance (QA) testing that goes into the OS and its associated applications. Consider the following glitch I ran into yesterday with Address Book.
Now granted, I don't run Address Book directly all that often--I usually just use it via Mail and the other programs to which its connected. But yesterday, I was trying to do something with my nearly my full contact list when I ran into a problem (not fatal to the task, but highly annoying). Here's the problem: Address Book fails to save the scroll thumb location when unselecting entries from the Names list--but only when you're unselecting entries from anywhere other than the first or last screenful of the list.
That actually sounds quite confusing, so I thought I'd demonstrate with a short movie. Click the image at left for a small version (182x174, 188KB) of the problem demonstration, or you can view the full-size version (364x548, 976KB) if you prefer. The clip first shows how unselects should work, by positioning the thumb at the top and the bottom of the list of names. It then shows what happens when the thumb is elsewhere.
To recreate the problem on your Mac, just follow these simple steps:
- Launch Address Book, click on any entry in the Names column, then hit Command-A to select all the names.
- Move the scroll thumb somewhere towards the middle of the list.
- Hold down Command and click any one name. Watch the scroll thumb leap back to the top of the list.
- Repeat ad infinitum.
As I noted, this isn't a fatal bug--it just makes it much tougher to deselect a number of names after selecting all. The bug also doesn't occur if you're simply selecting names from the middle of the list; it's only when you're deselecting (though it doesn't have to be from a Select All).
The bigger question is why do we see these types of glitches in many OS X programs? I probably launch Address Book about once a month, and yet it took only one relatively simple task to reveal a fairly obvious problem--how come a QA team didn't spot it long before the program ever left the development lab?
Tonight, while doing some testing for the ever-growing discussion about my Macworld Spotlight writeup, I stumbled across yet another ‘feature’ of Spotlight that I just don’t get. I’m think I remember reading this somewhere in the hazy past, but it slipped my mind when I wrote the long article for Macworld. But after playing around some more, this new ‘feature’ has jumped well up on my list of Spotlight annoyances.
So just what is this ‘feature’ that bothers me so? It’s this:
Spotlight will, by design, not find exactly what you asked it to find.
At this point, you might be saying ‘huh?,’ but let me explain by way of a simple demo.
I know that not everyone that visits here reads my stuff over on Macworld's site, so I thought I'd put a quick note here, too. Over on Macworld today, you can read my latest opinion piece, A Dim View of Spotlight.
This piece is a follow-up to my original Shining the spotlight on Spotlight article, which (confusingly enough) appeared here on robservatory in May (I wrote it prior to the Macworld changeover). If you read the original, you can skip the whole "what I said back then" section in the new article, and just read through my latest thoughts on why Spotlight still isn't quite everything it could be.
Executive Summary: I don't like the way Spotlight works at all, but I still think it has great potential. Read the story for the specifics on why I feel that way!
One of the things I like the most about OS X 10.4 is Automator, Apple’s new tool to help automate routine tasks. There’s an amazing amount of power hiding beneath a relatively simple user interface. The fact that users can create their own Automator actions (not workflows, but the actual actions that show up in the Action column), as described in this hint published today, means that Automator can be easily extended by those with a bit of programming experience.
Considering both Actions and Workflows, there are already over 100 entries on Apple’s Automator Actions download page, which is quite cool. (This does, however, pale in comparison to the 1,289 Dashboard widgets currently available for download.) In any event, Automator is a good tool to have around, and I’ve already put it to use on a number of occasions.
If you scan the list of Actions, you’ll find that they’re not in alphabetical order. Well, they’re sort of alphabetized. Look a bit closer, and you’ll see that the list is actually sorted by the relevance indicator, just like the search results in Mac Help. While this makes sense in Mac Help, as you’re searching for something that’s not definite, it makes no sense at all in this context. What is this list relevant to? The Finder Library entry? If that’s the case, then how come “Get Selected Finder Items” sits at the top of the list with 100% while “Filter Finder Items” (which sounds very similar) scores 0% and is sitting down near the bottom?
Within the relevance sort, the sort is then alphabetic, so with some practice, you can eventually find what you’re looking for. But Apple’s use of the seemingly-undefined relevance criteria makes the task much more difficult than it should be. Consider the iTunes Library entry; it has four levels of relevance, which means the alpha sort restarts four times—and one of those times is for one lousy item! It takes way too long to find a given entry in a list ordered in this manner, and there’s no reason for it at all that I can see.
You might think that using the Applications Library entry (the first one in the list) would solve the problem, since it selects all actions and displays them at once. But no, even in this situation, the relevance sort order is maintained! As a result, I never use this entry, as it’s really, really hard to find anything.
The solution seems simple to me: Apple, please sort the Automator actions by alpha, not relevance. If you’re going to insist on a sort by relevance, then at least give us the option to sort by alpha instead…
A quick entry tonight, just because the subject came up recently in this hint regarding iSync. In particular, the hint (and comments) note that iSync will fail if the application is moved into a directory whose name contains spaces. I had added an editor's aside about moving apps in OS X, and my personal belief that it's a Bad Thing to do. As noted in the second comment, it's not necessarily an issue with using applications -- they'll (more than likely) run fine from most any location. Instead, it's an issue with Apple's updaters failing if the application they update isn't in the usual spot.
Although it's my philosophy not to move Apple's applications around in OS X, that doesn't mean I'm happy about it. I have multiple partitions on my drive (partition vs. don't partition; that's a subject for another day!), and have one set up particularly for all my applications and utilities (called Apps). I put everything on that partition -- it makes it easier, for instance, to erase and install OS X if I have the need. As of result, the only things you'll find in my boot drive's Applications and Utilities folders are Apple's programs, along with anything that just won't run if it's located elsewhere (Tony Hawk Pro Skater 4, for instance, fails if it's not in /Applications). Everything else lives on my Apps partition. As much as I'd love to move Apple's stuff out of there, after reading about the issues people have had with upgraded applications not working, I've decided to just let sleeping Mail applications lie.
Given my background with macosxhints.com, it's quite clear I'm an OS X fan. But that doesn't mean I think it's perfect. While there are many, many things it does quite well, there are also areas that bother me, and make using OS X tougher than it should be.
One such area is the consistency of applications' interfaces. Long a hallmark of the Mac experience, major pieces of that consistency have been falling away slowly but surely as OS X and its applications evolve. With the recent release of OS X 10.4, I thought I'd take a look at the state of application consistency in OS X. Generally speaking (Java applications excepted), menus remain a high point of consistency. File and Edit are always there, with there generally familiar choices. After that, of course, the menu structure is up to the program designer. But overall, I have no complaints with menu consistency in OS X. It's the actual application interfaces that are bugging me.