I think this is overly harsh. As far as I can tell, this is a program made by a single person in their spare time and was then open sourced. This is what happens when someone develops an application for themselves based around their own needs and then decided other people might want to use it - I'm sure the developer didn't set out to create a "great user experience".
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.
Agreed. I have used this app off and on for years. A very nice contribution on the part of the developer. I see the UI of this app as being more a symptom of the target audience. It is targeted to other software developers (I assume) since it is a project on Code Project. It is targeted to the power user elite. Every option is no more than a mouse click away and many are a keystroke or two away.
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.
Exactly. This is a ToDo list application. There are dozens of valid approaches to designing one. This looks like an app that could be very fast and effective once you got comfortable with it.
I agree - I think it would be a stretch to say someone 'designed' this UI. This is a small project, with an easy UI.
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.
I bet the data structures for this app look pretty much identical to this interface. It looks like the author read Joel Spolsky's "Painless Project Schedules", wrote a GUI to do that, then exposed all of the plumbing to allow endless tinkering.
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.
It doesn't look too bad. Seems like some sort of bug tracking or issue tracking software. The middle section displays bugs. The top section lets you select what bugs to display. The bottom section displays information about the bug. The bit green "+" is used to add new bugs. It's not beautiful, but it gets the job done.
Edit: For comparison, look at these screenshots of FogBugz and Bugzilla
I think Bugzilla is an example of a web application with an extremely badly designed user interface - I find it very frustrating to use in general with unclear navigation and excessive clutter.
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.
It's really easy to judge but without context it's rather pointless. If that is a consumer app then yes, it's far too complex. If however it's a specialist app to be used by a trained operator then that may well be the perfect, most optimal and efficient display of the information they (the trained operator) want.
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.
Wow, at least the other one had some sense of grouping/visual hierarcdhy.
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.
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.
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.
You're right, the shadow does give a sense of substance to their simple design, and the same idea is used in google maps. I can imagine how amateur the site would look without the shadow.
Are there more fundamental design principles, or is it more a matter of experimentation and experience?
I'm not a designer, so I'm probably not the right one to ask - but for what it's worth I think that it is like everything else in life: a little talent and a lot of work will get you the experience needed to do good design.
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.
"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.
If they had added two additional widgets, that UI wouldn't be that bad. Collapse the top, and collapse the bottom, and it's pretty much exactly what you'd want in a task tracking system.
Are you sure you know what I want in a task tracking system?
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.
It is kind of unfair to say all programmers are bad at designing interfaces. I've never personally met one that was actually bad, and know several that are quite good- to the point where they could be professional UI designers if they wanted.
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.
I don't think it's for want of design ability - as rantfoil said a standard CS education just doesn't educate an engineer about how to design better. I think the lack of UCD emphasis is pretty strange really, it's not like even just considering the user requires graphic design skills or anything...
The lack of emphasis on usability in a CS degree program isn't surprising at all. In a software engineering program, it would be entirely appropriate, but in computer science, the focus is intended to be, well, the science of computer software (and to a lesser degree, hardware), not how to develop real-world software projects effectively.
I completed a computer engineering degree in embedded systems. Everything I have worked on has benefited from the courses I took during my PhD program in user centered and participatory design. How are people going to use their CS skills? I think it's very rare for someone's hacking not to have an effect on someone else even if it's just fellow engineers...
Sometimes the rule is even broader: this is what happens when you let your company design the UI (before bringing in a HCI/Ux (user-experience) consultancy to fix/transform 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.
People who aren't specialists design interfaces they think they'd like. Programmers, therefore, design interfaces for programmers. This is going to suck for consumer apps, of course, because most people aren't programmers - but this is actually a good thing for other programmers. Take a look at Emacs or Vi - is there ANY way they can get more confusing and badly designed from a consumer-app point of view? Yet they're perfect for the programmer.
Indeed, bad design is bad design, but just because the dash and controls of an industrial lift crane are 'more confusing' than a Dodge Neon, doesn't mean the crane's designers sucked.
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.
Its not so much that "programmers design for programmers". When designing a GUI we make assumptions about what the users knows, and how much we think they're comfortable figuring out on their own. Programmers I think, tend to err on people knowing too much, and being able to figure out too much.
I really don't see what the big problem with the interface is. It is not very pretty, but seems very functional, which is the most important thing in an interface.
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)