- Which would you prefer, given the choice. A good body or a big dick?
- Good body, definitely. I’d look weird with a big dick.
It’s always a little embarrassing when you are moved to write a piece because something in particular was bugging you, only to get so caught up in the moment that you forget to mention said thing.
Well this is it.
Take a look at iPhoto’s source list compared to, say, that of iTunes. Really look. They aren’t that different. For those in the audience lacking familiarity with either of them: iPhoto is in the left column, iTunes in the right. The bright blue highlight indicates that the selected item has keyboard focus —move up and down with your arrow keys as you will— while the more muted blue-gray highlight indicates that while that album is still selected, the keyboard focus is elsewhere. Probably amongst the photos of that album.
For now, disregard the slightly lighter blue gradient of iPhoto’s selected album. Disregard the column header being just slightly taller. Even disregard the bank of pixels around the column resize handle being slightly darker than the column header it’s sitting on (and that’s asking something). What’s different?
First and foremost, iTunes’ currently-selected item’s label is bold. This isn’t an emphasis thing, this is a readability thing. Because a dark background imposes itself upon white text much more than the other way ‘round, it appears slighter and is more difficult to read. Bolding the text is just another tool in the fight against said imposition, and iPhoto fails to make use of such a cheap and effective tool. That’s just the way it is. But there’s something else.
Eighteen months ago I wrote about Safari’s then-new CSS
text-shadow support and the abuse thereof at the hands of goofball designers. Actually, the post was in praise of its use in situations where it served a real purpose; that is to say I praised its use where it served design, not decoration. The thing that makes the drop-shadow a great design element is that it can increase text-to-background contrast and make text more readable. This is especially the case where the background color is mutable and text is not. If you don’t know what I’m talking about, take a look at the white text and drop shadows in the opening credits of Lost next time you see it.
So by now you know what I’m really trying to point out in iPhoto’s source list. The currently-selected album doesn’t have a drop shadow, while iTunes’ playlists do. Now I have young eyes, and unlike every other member of my family I’m blessed with 20/20 vision, but it’s actually difficult to read the word ‘Library’ there in the bottom-left quadrant. Light background, white text… low readability! Who’d’ve thunk?
I know I’m flying off the handle here, the eloquent readership of this most prestigious of blogs is more than vocal enough on the topic. But like most of the complaints I’ve aired about Apple’s UI design of late, this isn’t a deal breaker. It’s just evidence that the attention to detail is gone, and that’s fucking sad.
Ignoring that profoundly stupid word for a moment (and it is a real word, it means academics, surprise surprise) and inspecting the article it was lifted from: New Grant System Excludes Mac Users, I think we’re in need of a corollary to Hanlon’s Razor…
Never attribute to stupidity that which can be adequately explained by laziness.
Every generation of human beings, every generation without exception, has bemoaned the fouling of their precious language by the younger generation. My parents do it, their parents do it, their parents did it, and you can bet your ass their parents did it. I would do it too, but I’ve become immune. Immune not because I’m too young/hip/jacked-in/manly for these things to bother me, but because I’m not ignorant enough to believe that change is something language suffers from.
Oops! I just ended a sentence with a preposition. Shoot me.
The language Tony holds so dear is a terrible, horrible bastardization of what earlier generations held dear, and admired writers the likes of Shakespeare and Joyce and Austen (and Swift, as Tim mentions) would turn in their graves to see his work. To be reviled in the eyes of your heroes; is there anything more tragic? Well, it already happens in music, sculpture, photography, and every other artistic human pursuit… why would writing be any different?
That Long would label me an apologist is telling of his naïveté. Here’s a heads-up: linguists are people who study language and language change, they are not “apologists” for “bad writing”. What a fucking jackass.
While the laundry list of mumbles and grumbles I’m yet to cover in this iPhoto 6 blogathon is long, from elements of the new full-screen editing interface to the entirety of the ancient Photo Info panel, I’m finding I don’t have the stamina for long-term grouchiness. Being ornery all the time is bad for you. It angries up the blood.
I really couldn’t let this series end without picking on what is to my mind iPhoto’s biggest problem, a problem that has no workaround and affects users of all orientations, it’s the toolbar.
Watching my parents play with iPhoto is frustrating. They’re fantastic subjects for usability tests, incidentally, they make exactly the kind of mistakes quote-unquote “power users” are blind to, and to watch them repeatedly hit a button labeled Slideshow expecting a quick photo presentation (instead to be given a new, empty slideshow) brings tears to my eyes. Their source list is full of poor blank slideshows named ‘Library slideshow’; it’s quite sad. But it’s not their fault.
The toolbar icon, foolishly, says ‘Slideshow’ rather than ‘New Slideshow’ or ‘Create Slideshow’, trading comprehensibility for a few ems of space and failing on the way. That the button exists at all (and this goes for cards, calendars, and books too) is overkill; the File menu and the ‘+’ button below the source list already offer the full range of “new things” to create, though inclusion is understandable from a marketing and discoverability perspective.
Now believe it or not, iPhoto has sixteen icons in its toolbar. Sixteen. Big ones, too, and that’s not counting those in any of the editing windows. Working on a 12" PowerBook most days I’m somewhat limited in my screen dimensions, so I’d like to remove those tools I have no need for. I’d also like to remove that pesky Slideshow button on my parents’ computer, so they have no option but to hit Play when they want to give me a quick photo tour of Karratha.
Toying with the View → Show in Toolbar menu you can uncheck anything you don’t want to appear in the toolbar, which is handy for people in situations like my own. Except that you can’t uncheck Slideshows. Or cards. Or calendars. Nor books, the rotate tool, the edit button, the play button, or the search field. If you’d thought unchecking every item in a menu titled ‘Show in Toolbar’ would leave you with nothing showing, you’d be dead wrong; you’re definitely left with something. Eight somethings.
Since I can’t rid myself of the half-dozen icons I’d rather weren’t there, I guess I’d like to fit as many of the tools I do want to keep on the screen as possible without having to see the “it just won’t fit, man” chevron. Years of valuable experience with toolbars tells me I should just check the ‘Use Small Size’ option for smaller icons, and maybe disable the text labels since I already know what all the icons mean. No such luck. While iPhoto’s toolbar may looks like a toolbar and, yes, even act like a toolbar to a point, it ain’t the NSToolbar we Mac users have come to expect when we see a toolbar. Not by a long way.
NSToolbars are the standard interface elements you see in most of your everyday apps that sport a toolbar. Mail, Automator, NetNewsWire, SubEthaEdit… they’re so prevalent because they’re so easy. Easy because they’re simpler to implement from a programmer’s perspective than to build their own from scratch, and easy because the interaction model is steady and familiar to any that have used OS X for more than a week. If you have a toolbar, you’d be daft to avoid NSToolbar (cf. Address Book).
All NSToolbars share similar properties. Items in an NSToolbar can be drag-rearranged when you hold down Command, or removed altogether if you hold down Command and drag them out of the toolbar. Toolbars can be hidden or shown; have large icons, small icons, or no icons at all; with text labels or without; and can be customized through a nifty “drag whatever you like into the toolbar” sheet that drops down when you select ‘Customize’. Yes, they’re dandy. But iPhoto doesn’t use NSToolbar, so it misses out on all that — particularly the part about removing whichever items you please.
The first —and reasoned— objection to using NSToolbar in iPhoto is that iPhoto’s toolbar is at the bottom of the window, making it a much more involved procedure than calling the standard APIs for top-of-window toolbars, and making the Customize sheet a problem for users. You don’t want a sheet dropping below the bottom edge of your screen, and you don’t want to have to move or resize iPhoto (or have a ridiculously large monitor) just to get at it. They’re good points, but they’re not without their workarounds; namely subclassing the NSToolbar class.
Subclassing is programmer jargon for ‘specializing’. You take something (X) that does mostly what you want (F) and you extend its capabilities… building a kind of second-generation thing (X') to do exactly what you want (F'). It’s like breeding greyhounds. As technical analogies go that’s a pretty weak one, but it works for lay purposes, and it’s exactly what iPhoto needs. A ‘special’ class of toolbar that does everything NSToolbar can do, but can be placed arbitrarily at the bottom of the window (though I never really understood why iPhoto did that). Every other problem, particularly the dumb oversights caused by overworked and under-deadline engineers —like being incapable of disabling eight arbitrary tools— disappears in a poof.