|Home » Learning Curve » Developers Workshop
Apple's UI Hall of Shame
Five choice gumdrops to start you off.
Apple are often considered the ultimate authority on computer usability. But are they really? They often seem to have a lot going for them, simplicity often being a noticeable - and envy inspiring - hallmark. But corporations aren't monolithic - they're people. And people sometimes make mistakes.
Here are five in no particular order.
1. Mail Preferences
An all time classic. This used to be so good. Thanks to the advanced controls available with Cocoa - the 'sheet' being the number one example - this looked really good and worked even better.
But all good things must change for the worse. And this changed for the worse back in October 2003 and it hasn't changed back for the better since.
What they were up to is anyone's guess but with this admirable system there's no way to 'save' changes and they don't occur as you type and click either. To save changes you have to pretend to 'go somewhere else' and then the program stops you in your tracks to ask you.
It can't more bass-ackwards than that.
Not that the program itself is any better: it used to be flaw free. But again with Panther - and like so many other Apple programs for OS X - it took a nosedive and still hasn't recovered. And by all accounts it's only got worse.
Xcode is the successor to the NeXT Project Builder (PBX). PBX was a really elegant tool. Simplicity and elegance were its hallmarks. It was a classic.
Xcode is not Project Builder. Not in any sense of the word. And Xcode on Leopard now ties API searches to the suspect Spotlight technology. Which shockingly some people for some unknown reason don't appreciate all that much.
Worse still Xcode commits the ultimate gaffe of insisting on putting a dotted directory in user root. For what? For source code control is what. What happens if the developer wants neither source code control or this particular brand of SCC? Forget it.
Try to protect a home directory and this is the result.
Clicking either button results in the same thing: the app's going down.
Interface Builder was a brilliant program. More than any other it marked the distance between the NeXT development system and that used by any other software company. It helped put NeXTSTEP twenty five years ahead of the pack.
Interface Builder is the work of Jean-Marie Hullot. Hullot originally wrote a program for the Mac called SOS Interface. Steve Jobs saw the program, met Hullot, and hired him on. The rest is real history.
IB stayed fairly stable throughout Jaguar, Panther, and Tiger. Panther introduced Cocoa bindings and so IB invented a new file type: keyedobjects.nib. Unfortunately this file format is grossly inefficient and enhancements to IB and Cocoa were put in the 'keyedobjects.nib' part of the program.
Developers also discovered when upgrading to Tiger that Apple's IB was corrupting a lot of NIBs. Earlier versions didn't notice this but Tiger's IB did. Oops. The NIBs still worked but they were nevertheless corrupted.
NIBs prior to Tiger could end up at practically any size at all. Click ⌘S once and the file size suddenly goes up 4 KB; click it again and it drops down 6 KB. And that's never a good feeling.
Starting with Leopard and IB3 things are really out of control. There are suddenly two huge panels that take half the screen; when your windows come up in IB the intelligent designers see fit to move your window out from under the overbearing panels; but this automatically changes their screen coordinates. Thus your file is dirty and you still haven't done a thing.
And there are other instances where nothing's ever changed but the program still nags to save changes.
And some of the changes don't stick even if you do save. Several inspector panels for several controls don't seem to have been connected properly prior to release. Tick a few options on and off, save, exit, and reopen, and the old settings are still there.
The original Interface Builder was a work of staggering insight; the current version feels like it's been put together by preschoolers.
The 'designable.nib' scandal makes matters even worse. This 'scratchpad file' can grow to incredibly gargantuan proportions for nothing at all. One has to wonder what people were thinking. Suddenly fanboys are aghast 10.5.4 left 8 MB of these useless files in a download image to be transferred onto millions of hard drives.
But this is hardly the first time. Over the years it's gone up and down: the files classes.nib, info.nib, and data.dependency are also worthless scratchpad files. Yet they were often shipped too. And some developers in Cupertino aren't aware even today what these files do and don't do.
4. Table Views
It's incredible Apple could screw up this bad; GUI controls no longer exhibit consistent behaviour. Text views still work properly under Leopard (albeit noticeably sluggishly); browsers work fine; but suddenly table views are totally 'FUBAR'.
Selections - selections of anything - follow a precise and comfortable logic. This logic is found on all GUIs today on all platforms. It's consistent across platform boundaries.
The logic works like this: shift 'paints' selection between point A and point B.
That works for text views, browsers, and table views. It works on all platforms. It's consistent. It's good. It's marvelous.
Take a text file. Put your caret at the beginning of any line. Hold down shift and click on the end of the line. Whoa.
Now try this.
Put your caret on the second line of a text file. Hold down shift and click on the end of the line. Now keep holding down shift and click into the middle of the third line. Now keep holding down shift and click in the middle of the first line. Marvelous, isn't it?
And you can do that with browsers too. [See above.] But starting with Leopard you can no longer do that with table views. No one really knows what Apple are up to and many suspect they don't know either.
For the misery doesn't stop there. For starting with Leopard Apple have put a timer in their table views. The timer's about one second; to change certain selections in a table view there's a one second delay. Click something - then wait an entire second to see the results? Who's kidding whom?
And what about double clicks? That's right! They don't work either anymore!
And this inexcusable gaffe has followed through five successive releases of OS X 10.5 Leopard. Five. Count 'em.
In fact this gaffe is all by itself so horrendous as to make the platform Leopard practically unusable. No software company's ever screwed up this bad before - not even Microsoft. And because Apple are so busy with their iPhone and their Automator actions they'll never get around to looking at this. And given how badly the code is screwed up people wonder if Apple have the cerebral wherewithal to understand what's wrong and the engineering skills to fix it.
For many writing to this site say outright they've simply given up hope. Apple can't program their way out of a paper bag.
5. Window Shadow
Oh it's so cool you can put shadow around windows! Just like it was so cool you can make round corners! But seriously: do any of you know how shadow works? What happens if you open a number of Icon Composer windows all at once? You blokes never looked?
And this is especially - painfully - noticeable with Leopard's Icon Composer. The windows are so bloody big they can't cascade. They have to come up in the same location all the time.
And for that matter: why - with a platform excelling with scaleable vector graphics - design an icon format using raster graphics? That yields single icon files of up to half a megabyte or more?