Does Sun understand GUI design?

When will Sun make the Java GUI fast and consistent?

When Java debuted in 1995, the focus was on applets -- mini-applications, typically with a graphical user interface (GUI), that ran inside Web browsers. Developers who had worked with GUI systems, especially Windows and Macintosh, knew even then that Java's GUI support, the Abstract Windowing Toolkit (AWT), was fairly weak; it didn't support basic features like shortcut/accelerator keys, drag and drop, and more.

Java has since made a lot of progress by way of the Java Foundation Classes (JFC), mainly the Swing APIs. However, while the latest demos of Swing-based applications are impressive, Swing still seems to fall short, considering how far proprietary GUI systems have advanced.

The key problems are:

  • The application takes a long time to load
  • The refresh rate for screen painting is slow
  • The dialog boxes (open, save, etc.) are inconsistent with the operating systems' standard dialog boxes
  • Swing APIs are powerful, but somewhat complex for basic development use
  • Swing-based-application developers don't seem to adhere to a standard look and feel, even though Sun has published the Java Look and Feel Design Guidelines

Where does the problem lie?

While some of the problems with Swing are related to the challenging task of providing a cross-platform GUI, I have always wondered how much of it is related to Sun's roots in Unix.

Most people know that Unix is a command-line-oriented operating system. Unix developers and administrators love the command line! From shell scripting to regular expressions to piping commands, you just can't convince them that the common features of modern GUI systems, such as drag and drop or copy and paste, make a lot of sense. This is probably because most GUI applications on Unix-based systems have not traditionally followed consistent design guidelines. It is a shame that Unix GUIs did not become more prevalent, given the power of systems like X Window and the fact that they had a head start on Microsoft Windows.

I have had the unique pleasure of mastering regular expressions, dozens of Unix utilities, and complex shell scripting using shell and Perl, while doing GUI development on both the X Window System and Microsoft Windows. The one thing I have come to admire about Microsoft Windows is the consistency of most of its applications. Things like cut, copy and paste, standard accelerator keys (e.g. Ctrl-C, Ctrl-V, Ctrl-X), and standard menus are present in most Windows applications. Further, most Windows applications appear to follow a standard look and feel (although I have seen my share of ugly Windows 3.x applications). Unfortunately, I cannot say the same for Java-based applications. Even the Java-based GUI applications developed by Sun and bundled with the Java Developer Kit (JDK) look so horrible that it is a major turnoff when you try to use them. Did Java become so popular on the server because of the command-line nature of server-side applications?

Other questions in my mind are:

  • Will Swing's GUI ever be able to compete head-to-head with proprietary GUI systems?
  • Will history repeat itself on smaller devices (e.g. PDAs, Web phones) as it did with GUI on desktops in the 1990s? That is, will Microsoft's and Apple's user interfaces be much better than Java's?
  • Will Sun continue to focus on powerful GUI APIs (similar to the X Window System) instead of promoting ease of use and consistency?
  • Will Sun solicit input from companies -- such as Sitraka (formerly KL Group) and Infragistics (formerly ProtoView) -- that have done an excellent job with their GUI product offerings?

Discuss your thoughts about this column in the iSavvix Soapbox forum.

Anil Hemrajani is chief technology officer at iSavvix, a technology services firm for full-service Java and Internet technology solutions. He welcomes your comments and questions about this column.

Learn more about this topic

This story, "Does Sun understand GUI design?" was originally published by JavaWorld.

Copyright © 2001 IDG Communications, Inc.