I believe GUI programming is significantly harder than server-side programming. This flies in the face of common industry practice. I believe that programmers with J2EE skills are more marketable than those having GUI development skills. I also believe that server-side programming positions offer more money (and fame) than client-side programming positions.
GUI builders make it easy to think GUI programming is easy. Nearly anybody can whip up a decent-looking GUI in no time at all using a GUI builder. Done.
Server-side programming is different. EBJ can seem extraordinarily complex, particularly when you are just starting. It is much harder to whip up a quick and dirty EJB system, giving the impression that server-side coding is harder to do.
A bad programmer will continue to struggle with EJB. A good programmer will find ways to automate nearly every aspect of EJB, however. That’s the secret of server-side programming: it is very well-defined and repetitive. Thus, it can be automated. Check your favorite Model-Driven-Architecture (MDA) tool. They work best when generating server-side code, things like EJBs, database access code, and web services. They might be able to generate a rudimentary GUI, but a really GREAT GUI cannot be automated.
Good GUI versus Bad GUI
Let me qualify what I said in the first paragraph. Creating a bad GUI is really, really easy. Creating a “good” GUI is really, really hard.
I enjoy GUI development for precisely this reason. I like the challenge. Here are some reasons why it is hard to create a great GUI:
- Everybody wants to contribute. The GUI is immediately visible, and every person on the team wants their particular feature. Server-side developers contend with technical challenges, but client-side developers contend with many more social and political challenges.
- The people “designing” the GUI are not GUI experts. People who are business analysts can dictate the GUI design.
- People are often attached to their legacy GUI design and cannot think in terms of more modern approaches. For instance, a designer might be obsessed with some weird “button bar” concept because their 4GL tool offered the same thing.
- People migrating text-based systems to GUI-based systems often want to cram too much data onto the screen.
- With web apps, people want to force HTML to behave just like a fat client GUI, regardless of how difficult that may be.
And the list goes on…
What Does it Take?
So what does it take to create a good GUI? Having the right people is the most important factor. You have to find a handful of people with some magic blend of technical and design know-how. How do you quantify good GUI design skills? I do not know. A great GUI is a work of art.
Assuming you find a team of really good GUI designers, you must give them power to enforce consistency. Here’s where it often breaks down. At one end of the spectrum, you have too many people designing the GUI so you end up with really complex, cluttered, difficult screens. At the other end of the spectrum, you have a handful of bad designers forcing the programmers to create a really stupid GUI.
A Few More Random Thoughts
This is a really big topic to tackle in a blog entry. I’m sure people will point out all sorts of things I forgot to say. Here are some more things on my mind…
- Skins are evil. Skins look cool, but impede usability. They offer the illusion of a good GUI. Most skinnable apps are bloated, slow, and hard to use.
- People are quick to criticise Swing, but most bad GUIs are bad because of stupid designs. You can create great GUIs in Swing.
- Good keyboard navigation is essential to good GUIs. This is also very hard to get right. IntelliJ IDEA is a perfect example of a great GUI with great keyboard navigation.
- In-place table editing is virtually impossible to get right and companies consistently underestimate how hard it is. For instance, what happens when you hit Enter while editing in a table? Should the default button on the screen be activated? Should the selection move to the next row in the table? Everybody has a different opinion.
- GUI code is notoriously hard to test in an automated fashion.