This is what happens when you let programmers design interfaces (PNG)
codeproject.com
codeproject.com
Controversially, despite its ugliness and widget abuse, it does have some things going for it - it's largely self-explanatory and unambiguous and is probably incredibly quick to use due to its general lack of reliance on tabs and submenus.
A better example of a truly bad interface is Lotus Notes 7 - its UI was an utter disaster yet the application remained popular. See http://en.wikipedia.org/wiki/Image:Ln7.jpg - thankfully much, much improved with Lotus Notes 8 (http://en.wikipedia.org/wiki/Image:Lotus_Notes_8_home.png)
Your point is taken about bad UI design, though. There are many exemplary instances. I find that bad UI design can come from any number of functional roles.
Many programmers I know (myself included) have been around good and bad designers for so long, and have used apps similarly, that a sensibility has developed within us. Some of us also know about user experience and usability testing. If you seek elegance in code, you will often want the UI of your product to be similarly elegant.
Getting a simpler UI would take more work, but just because someone is a programmer doesn't mean they can't design a good UI if given proper design requirements, and enough time.
Fixed that for you.
Sure, the interface is pretty sadistic for Yet Another Scheduling Tool, but maybe the original goal wasn't to make another FogBugz -- maybe it started as a prototype to explore different ways of munging data from project schedules. Comparing the original Joel article to the current Evidence-Based Scheduling approach of FogBugz, it's possible that even the HCI wizards at Fog Creek hacked together a few obtuse prototypes before finally settling on the right combination of plumbing and porcelain.
Edit: For comparison, look at these screenshots of FogBugz and Bugzilla
http://www.lazygray.com/blog/wp-content/uploads/2007/04/prev... http://www.mozilla.org/frontpage/productShotBugzilla.jpg
Software needs to be functional before it's beautiful. Ideally, you have both, but sometimes you need to prioritize.
Compare it to trac, an application that has basically the same functionality yet is a joy to use (e.g http://trac.edgewall.org/ticket/6614)
http://www.gisinfo.ru/images/map2005_desk.gif
Count just the flashlight icons, there's 16 of them. And three Help icons next to each other. But the best part is the vertical sequence of icon mutations in the lower left center.
Just thought I'd mention that although I agree with your general point speaking as an engineer that has created some crimes against HID and been saved by a designer.
In I don't think it's fair to say the UI was actually designed at all. This is what's leftover from what committees and executives decided the application needed to do with no thought whatsoever to anyone who would actually be using it. Notice how the most relevant information for the technician is on the fourth tab over, in a tiny unsizeable window next to a massive expanse of empty space. Note that several of the tabs seem to be describing the same thing. Where do you go to find out what you have to do? 'description?' 'instructions?' 'sub-tasks?' 'change details?' Why not 'general?'
And this is just the tip of the iceberg. This thing was an enormous, slow, resource-hogging java applet that required internet explorer. It no offline mode yet booted you off every 15 minutes which sometimes made you close out of IE and clear the cache or else you couldn't log back in. The boot-off process involved the entire application leaping into the foreground interrupting anything else you might have been doing.
This one uses the same colors everywhere, so the user can barely recognize the logical groups on the page! Yikes.
Here's a tip -- the squint test. If when looking at your UI, you can't squint to see logical groupings (regions of activity that are related), then you don't have a good visual hierarchy.
I think that an engineer can learn design, however. Certainly a standard CS education doesn't necessarily teach you those skills, but one can definitely develop them over time. It takes a good design sense and a good engineering capability to build great user experiences. Often you can't get that in one person, but when you can, one can accomplish that much more.
Try to turn things around - there are a lot of designers (and kids and grandpas) that code something up. This usually ends up as a horrible mess, not following any programming paradigms, spaghetti code, non-existing security, etc. We've all seen it happen. But you only see this if you're a professional programmer. Non-professionals don't see the detail, the design decisions, the security measures, the scalability, etc. They just see a slow or buggy site. Or worst-case they see their credit cards exposed.
Design is the same, just to a larger degree - everyone thinks they can do it, because well done design seems so simple. When they try to do their own, however, it is never quite as good and they don't understand why. The reason is the exact same as why novice programmers create crappy programs. To do a great and simple design you need a lot of experience and a lot of knowledge. Certain things need to align, some colors match others don't, certain design elements send certain signals to the user, etc. Have you ever noticed the drop-shadow on the logo on Google's homepage? Chances are you haven't, but it is a core part of their design - you don't notice it, but it holds up the whole page.
As a novice designer you can only get so far until you start running into problems that require expert knowledge and experience. Just like programming.
And when you start talking about usability (which I think the flaws in the linked pic are) things get even worse. Read Jakob Nielsens useit(http://www.useit.com) if you want to learn more about it.
I gotta recommend reading "Don't Make Me Think" by Steve Krug. It is the best beginning user experience design book out there.
Are there more fundamental design principles, or is it more a matter of experimentation and experience?
"Design of Everyday Things" by Don Norman "The Visual Display of Quantitative Information" by Edward Tufte "Don't Make Me Think" by Steve Krug
Tufte will give you the vocabulary around visual concepts. Norman will give you the vocabulary around evaluating basic usability. Krug will apply both to the domain of the web.
Additional recommendations: About Face 3.0 -- written by the head of Cooper Design, it outlines in somewhat dry fashion the frontiers of user experience process. Buy this only if you're desperately interested in becoming an interaction designer, or you want to institute user-centered design in your organization. It's really the UCD bible.
When I work with designers I notice that the finished result is often very far away from the initial idea, and that the intermediate steps are obviously experiments in some direction. It is apparent that a lot of time goes into trying things out that are never seen in the finished product. It's probably a lot like writing essays: write a lot and throw away the 90% you don't really need.
So in short: I think there are no shortcuts, it's about experience and hard work.
The one I made for myself was quite different and far simpler.
There were two listboxes and one text field for entering new items. You could open any item with a keypress and see a text box with more detailed notes. All the data was maintained in human-readable text files.
I've noticed a trend where hackers with good design sensibilities have migrated to working on web earlier than other developers. That might have something to do with it.
Aside from griping with them about the backend machinations/magic required to transform some of their wireframe mock-ups into running code, working with a well-known HCI/Ux firm made our product's UI cohesive, usable, and functional. They also helped us build reusable common UI components. This was a high-profile, multi-million dollar new product launch so the ($$$) money the firm cost was well invested.
Being a UI designer has it's pluses, but while I've on occasion been lectured by a geeky accountant or sales guy on the pros and cons of multicore processing or platform independence or something, I've found that almost everyone in the company has strong opinions on why the UI designer's work sucks. It seems that 95% of the public are really "artists" (not that you could tell from anything other than the passion of the aesthetic opinions) just working to pay the rent.