Adobe CS4 UI Clusterf**k Cont’d

I’m guessing that Adobe pays more for UI designers working on Photoshop than Pixelmator’s gross revenues — obviously, they’re earning their money. Neven Mrgan posted a very amusing list of different ways Adobe fails to implement slider controls in Adobe Photoshop CS4 (amendment: he missed at least one — the lamentable layer opacity slider), followed by a blog post discussing hilarious attempts to defend this crap. Here’s a link to someone attempting to blame Final Cut Pro for doing the same thing (including an accurate rebuttal).

Right now, Adobe’s CS4 apps look about as amateurish as a typical RealBasic app — this isn’t to denigrate RealBasic — but most RealBasic apps are written by one guy with no designer, QA department, testing, and customers who are grateful if the program does more-or-less what it’s supposed to do and doesn’t format their hard disk.

The truly sad thing about Adobe’s applications is that (a) they’re written for artists and designers, and (b) Adobe doesn’t just toss apps together more-or-less adhering to platform UI standards, it goes out of its way to think about UI design, develops its own internal standards and frameworks — and then produces incredibly clunky interfaces.

Convergent Evolution & OOP

I’ve seen UI nightmares like this before: in Smalltalk. Because Smalltalk has been around so long there are enormously complex class libraries built on top of it, and in many cases these libraries branch out and then overlap — just as mammals, reptiles, and birds all evolved from a common ancestor, but when mammals, birds, and reptiles evolve to occupy a particular ecological niche — e.g. insectivore — you find convergent evolution — e.g. long snouts and sticky tongues, so did Smalltalk’s class libraries grow multiple overlapping instances of similar controls derived from different ancestors. So while an ant may think that nature is being stupidly inconsistent (why don’t all sticky tongues smell the same?), form follows function where it has to, ancestry dictates “cosmetic” differences.

(This turns out to be an argument neither for nor against “intelligent design” since — presumably — Adobe’s software is “intelligently designed”, but it does seem to imply that if God designed the Animal Kingdom, then God is more like a bureaucratic Fortune 500 company than an omniscient super-being.)

By the mid 90’s SmallTalk’s UI class libraries — at least the ones I saw being used in the Finance sector — were pretty appalling. You might find that there were ten different slider controls (clarification: actually slider controls were way beyond Smalltalk’s GUI at this point, so I should use — say — “buttons” as an example) found in ten different branches of your class hierarchy, and three were color, six monochrome, one greyscale, two could have a value field, three might be skinnable (but one could only use 16 color graphics), one was anti-aliased, three could have check marks, four could have keyboard shortcuts, one wasn’t focusable, and so on. Several different versions might — and often with good reason — appear in a single dialog box. Adobe’s apps seem to have exactly the same symptoms.

Ugly but Functional

While nothing can justify ridiculous cosmetic inconsistencies, at their core Adobe’s apps are still incredibly functional, and consistency across versions has ensured that even Adobe’s more peculiar UI design decisions have been so indelibly burned into our muscle memory that it seems perfectly natural that dragging a selection moves the marquee and not the selected pixels by default, or that to quickly set the color of a text layer you click on it and hit option-delete.

Perhaps the problem for Adobe is that — if they were to fix the “obvious” flaws in their UIs, it’s not clear where it would end, and how many more people it would piss off.