First, as someone else noted, systems programming is just as much concerned with ‘usability’ as user-facing programming; only the criteria for ‘usability’ changes. You may be dealing with APIs, calling parameters and returns instead of menus, entry fields and dialogs, but the first design priority is still ‘how is this code going to be used‘ – not ‘how will this code work.’ If it’s not, you’re setting yourself up for trouble down the road when it comes time for integration…

Second, your CUPS example is still guilty of cart-before-the-horse mentality. It’s just as likely – in fact, from what I know of Apple, more likely – that instead of picking CUPS and thinking ‘how do we make it usable,’ the OS X design team thought ‘how do we want OS X printing to work’… and then looked at code to implement it, and picked CUPS.

I found this last bit amusing

Yeah, that part didn’t hold up so well. But who could have imagined that the reception for Vista would be as poor as it was?

If the component you are bolting on to is bad, then scrap it and get a new one. Or write your own! My point is that this consideration should often be based on an ENGINEERING evaluation, not primarily one of usability.

Let’s agree that every component (consumer-facing or not) should be brilliantly designed and usable.

Generally speaking, websites and web applications tend to do best when they’re designed with the needs of real users in mind. That means coming up with features people need (not just building stuff because it’s cool); implementing those features in ways that don’t require a huge learning curve on the user’s part; making features easily discoverable; and creating language, design, and architecture that help the right user find the feature or content she’s looking for. Gruber uses “usability” to mean all that; it’s a driving force behind good design, whether of websites or software.

This doesn’t mean, though, that the underlying programming is unimportant. It’s vital — I agree with you. Build a great website on a bad platform and you guarantee failure. I can see how a developer might take umbrage at Gruber’s suggestion that the part that touches the consumer is more important than the part she doesn’t see. Gruber was of course reacting to Raymond’s naive and disingenuous “discovery” that the front end matters — and Gruber’s dismissive tone toward programming versus usability probably comes from Raymond’s dismissive tone toward design/usability, which Raymond mistakenly thinks of as the easy part.

None of it is easy — we can all agree on that. And all of it is important. As a designer, I wouldn’t have spent eight years pushing web standards if I didn’t respect the technological underpinnings of our digital world.

I’m not sure that that’s what I said, AJ. I said that usability should come SECOND when you are relying on the efforts of some (mostly anonymous) developer to make the underlying technology work in the first place. The example cited was that of CUPS, which was savaged in Gruber’s post for being unusable. However, when Apple’s engineers had to come up with a printing system for OS X, they used CUPS and BOLTED ON A USER INTERFACE to fix the usability issues. Now OS X has one of the nicest printing systems around.

Gruber himself had to tackle this criticism of his message in the follow up to his article, where he is forced to clarify:

“Yes, Mac OS X is built with lots of open source software under the hood. But point #1 doesn’t imply that the entire implementation needs to be written from scratch. Yes, Mac OS X contains a lot of open source software under the hood — but these components are used to implement Apple’s designs, not the other way around.”

But, of course, this is somehow different from BOLT ON usability.

So to your point, AJ, if the raw bytecode on the Broadcom chip inside the phone WORKS WELL and provides a stabile platform for me to build my phone application, then you won’t find me disparaging the chip designer for issues of mere usability – my end users would never SEE their usability issues because I would develop an interface to hide them. The chip designer has done their job, and now its time for me, as the integrator, to do mine.

Look, Zeldman intended this thread to hold a spotlight up to the ongoing usability issues he sees in the industry (and perhaps in the WORLD in general). I’m cool with that. Let’s make things usable. Why not? My only point is that bolt on usability is not always a sin, and it strikes my as somewhat shrill to consider it such.

If the component you are bolting on to is a GOOD component, then it is fine to add usability after the fact. If the component you are bolting on to is bad, then scrap it and get a new one. Or write your own! My point is that this consideration should often be based on an ENGINEERING evaluation, not primarily one of usability.

It’s easy to ridicule the estimated 2006-or-2007 ship date for Longhorn, the next major release of Windows. But do you doubt for a moment that Longhorn will provide more improvements from Windows XP than desktop Linux will gain during the same period?

I haven’t personally used Vista or Ubuntu, and I don’t doubt that Vista is easier to use. But which one has made more gains? Based on what I’ve heard, anyway, it’s Ubuntu.

If you’re implying that the open source community by nature doesn’t care about usability, then I’d say that you’re wrong. The open source community works on the principle that each developer does what he or she thinks is necessary to make the product worth using. If the product is not usable to a certain class of people – say, everyone who is not a unix hacker, for example – it’s because the developers of the product either have no idea that these users cannot use it (no feedback?), or lack the skills to make it usable to them (quite common), but also because all the people who really do have the skills and who know the problems have chosen not to contribute.

If open source software fails usability tests, its because usability experts are not interested in improving open source software.

Oh, and this wordpress blog’s usability is broken. It won’t accept my email address because it’s on a .info TLD, and the validation regex looks for 2 or 3 character TLDs. That regex will probably fail most RFC2822 valid addresses.

APIs are user interfaces. In order for something like Twitter or RSS or GSM or any of the other myriad technical conveniences we take for granted to work, a hell of a lot of back-end work has to be done, starting with thinking about how the user is going to do things.

When you consider how incredibly limited cellphone interfaces are (usually just a few lines of text, and a number pad), it’s a miracle we can make calls at all. If Jeff P had his way we’d be exposed to the raw bytecode running on the Broadcom chip inside the phone, because the developers did a lovely job on that so we can send everyone else home early, ok?

I really despise this attitude that the code is all that matters. _Good_ code matters, and good code that is _easy to use_ matters more than code that is closed, or hard to grok, or poorly conceived, or once built, cannot have a good UI attached except by Herculean efforts.

I don’t know, they could also be personal preferences, but these are not important in usability. Nielsen says “don’t listen to what they say, look at what they do”. And that’s because they may like the button on the other side, but since the most logical place is on this side, they will look there first, making the task easier.

The best you can do is make an educated guess at the average.

I think I know what you are saying, but I think your wrong. While it is difficult to guess each user’s own likes and dislikes, using usability testing methods can teach a great deal about norms in usability–aim small miss small. You will have the occasional “where is this located” but thinking about usability will ensure that the masses can use your stuff better.

Why was windows created in the first place? To make the computer more usable. Did everyone get on board right away? Maybe not, but the masses found clicking an icon was much more usable and forthright than typing in dos commands.

You also stated:

I’ve redesigned a couple of our intranet sites, and I still get the occasional email saying they liked the old one better.

What I believe your users are really saying is really not about visual aesthetics, they don’t like it because it is wildly different from what they are used to. Which brings up another point about usability, you can follow design norms, but there is still a learning curve with any UI.

Some of the users of my web apps say they want the submit button on the right. If I move it to the right, then I get to hear from another group of people wishing it were to the left. Same story for font size, font face, color combos, and pretty much anything that can be designed and re-structured to enhance the experience. I’m reminded of the CICS terminal emulators that display no graphics, but the user can control which monospaced font to use and whatever color combos they like. You wouldn’t believe the color combos I’ve seen. But the bottom line is that they have a limited amount of preferences, just enough to suffice their wants. I’d like to bring this concept to the web, but the most difficult part is choosing the limit.

I’ve redesigned a couple of our intranet sites, and I still get the occasional email saying they liked the old one better. The old one was a complete nightmare with no organization what so ever, an eyesoreful jumble of colors that should never be displayed together, and an abundance of confusing instructions with poor grammar. So I’ve pretty much come to the conclusion that functionality comes first. Then I worry about design, then usability/information architecture.

I could be way off, considernig my experience is somewhat limited. But this has proven to be a successful formula for me (so far). It’s definitely worth noting that these are internal business applications, nothing that is meant for the public eye. Anyways…

The part about wowwing users with the skills is great, I’ve felt the same way for quite a while. Good zinger, Zeldman!

Also accessibility is an unknown up here. e.g.: The local technical college teaches web design courses and they teach students to do layouts with tables.

*sigh*

I’m certainly glad I had attended the AEA in Boston, it certainly opened my eyes a bit wider to usability.