Swing GUI Design for the SCJD, or, Honey, I’m Just in the Mood to Use Some Software

This is about designing software user interfaces. I am leading a study group on successfully completing the Sun Certified Java Developer project, and we’re talking about UI design this week. So here are some thoughts.

Abstract the GUI to hide how the system works (user should be spared the details).

Think of successful user interfaces in the real world and what is great about them.

-Steering Wheels. They are amazingly simple, hide complexity and implementation. It is simple because you aren’t tied directly to controlling each individual wheel. It could be a truck with 12 wheels or a 4 wheel drive or a front wheel drive and the interface is identical.
-Telephones. Old telephones used to require you speak into the phone base, and hold the receiver to your ear. Modern phones accomplish the same task but afford greater freedom by combining the two in one handset. The UI is roughly the same whether it is a cell phone or a desktop phone. The newest phones free your hands altogether.

Rule #1: Write Use Case Diagrams before doing your GUI.

Even if you are being "agile".

Dr Horstmann is the author of Core Java, and offers Violet as a free UML editor.
You can use Violet via WebStart at www.horstmann.com/violet

-Keep it abstract and separate from implementation.
-You are required to use a Jtable.
-What components can you use to

Remember that there are three distinct processes to keep in mind—don’t let them spill into one another, though they are obviously complementary:

1. What the system does (what goals can be accomplished with it)
2. How the system does what it does under the hood.
3. What the user has to do to accomplish a goal.

Rule #2: Sketch your GUI on Paper First

After you’ve written use case diagrams, sketch your GUI on paper.
-It is the fastest way possible
-Changes are a breeze.
-You can show colleagues easily
-You can show your mother, or someone who is not a programmer or necessarily interested in your system and use that to help you determine if your UI is easy to use.
-Shoot for 5th grade level. That is, a 12 year old product of standard American public school system education should be able to immediately use your UI without asking any questions, without reading any documentation, and without having been told what the system is even for.

Once you are happy with your GUI layout, make a few Xerox copies of it. Then use a pencil to break up your sketch according to the panels you will need to break it up into. Remember that nesting panels is a good idea. This is like the process of breaking up a Photoshop layout for a web page into HTML tables or divs. Once you are happy with how it is broken up, then the layout managers you need should be clearer. This will also help you work over your GUI design from a different perspective, and maybe notice flaws in it. Only now should you start coding your GUI.

Group your user interface items logically. Duh. Consider the “File” menu that organizes Open, Save, New operations.

Be disciplined about what aspects of your GUI should allow creative flourishes. The order in which your menus appear in your menu bar is NOT one of them. That is, it would be entirely indefensible to organize it like this:

Help Tools File Edit

There is one obvious, conventional way of doing this:

File Edit Tools Help

Which brings us to…

Rule #3: Users do NOT read.
They feel their way across a layout, based on conventions. Users often will click a button without reading the label because they see in their peripheral vision a gray box that they figure is about the size of a button and is located on the UI at the bottom right hand corner of the form, and they guess based on that information that that’s the “Save Changes” button and click it. I am not exaggerating and if you have developed user-facing software for any amount of time you know it’s true.

Rule #4: Software should be so transparent, so invisible, so achingly thin that users forget they are using it.
That’s because users use software to do their real job, accomplish some other goal, which is what they care about. No one in the world cares about software in itself. No one in the world would simply starting using some random piece of software, in order that they might have the pleasure it affords in its own right. No one says to her husband, “Honey, I think I’m going to go use some software now. Any old program will do. I’m just in the mood to use some software”. They say, “I am going to write a letter to the theater downtown in order to voice my objections regarding the lack of Mexican wedding cakes sold at the intermission.” Then they sit down to their laptop and open Word.

Make a Prototype
Once you have your GUI sketched, make a prototype based on it. Stub your data, just print out to the console in your action listener.

Do NOT use editors in Eclipse or Matisse in NetBeans to do your dirty work for you. Not only is this highly questionable and suspect with respect to the rules of the exam, you will rob yourself of the joy of learning GridBadLayout, one of the simple pleasures left in modern life.

If you don’t know any Swing, now is the time to dig in. Do the Sun tutorial and read the code. Read lots of it:

http://java.sun.com/docs/tutorial/uiswing

Rule #5: Don’t forget the keyboard.
Think of how you use software. Do you drag the mouse all the way up to File > Save? No way. You hit Ctrl + S every few seconds as you’re typing. It’s part of the flow that helps you get your work done quickly. Make sure your GUI has all of the keyboard mnemonics that you yourself would expect.

This is not the time to get inventive, either. Do not make Alt + S be the shortcut to Save. Or Ctrl + V. Save is Ctrl + S, forever and always, and if you violate this rule I think that Dante has a special circle of Hell reserved just for people like you.

Rule #6: Use the MVC Pattern or Observer Pattern
If you don’t know the MVC Pattern, now is the time to learn. Once you have your GUI Sketched and prototyped, apply MVC to it.

Check out these resources:

MVC
http://en.wikipedia.org/wiki/Model-view-controller
http://c2.com/cgi/wiki?ModelViewController
http://www.purpletech.com/articles/mvc/refactoring-to-mvc.html

Observer
http://c2.com/cgi/wiki?ObserverPattern
http://www.dofactory.com/Patterns/PatternObserver.aspx

See also java.util.Observer

Rule #7: Combine Layout Managers
Don’t inspect the layout managers and decide that Spring Layout is for you and that’s all you use. They can and should be combined in order to achieve the best control and fluidity and clarity of purpose.

Test your layouts under many conditions: different size screens with different resolutions and on different platforms. Some of the Swing stuff is just not the same on a Mac as on a PC. Aside from the obvious differences, as an example, colored backgrounds on Jtable headers simply did not work in JDK 1.4 on the Mac. Make sure that when you resize your window it fluidly reorganizes all of your components. Users will do this and should be allowed to, and if your UI tumbles apart when its resized, you did it wrong.

Here are a few final points to help you make sure it is production-ready, and encourage you to use finishing touches.

Use keyboard shortcuts, as discussed above. Accelerators give power users keyboard shortcuts to bypass menus, while Mnemonics let you navigate with the keyboard (http://java.sun.com/docs/books/tutorial/uiswing/components/menu.html#mnemonic).
Select icons and use them on your menus and throughout your app. You can use Sun’s icons from here: http://java.sun.com/developer/techDocs/hi/repository/ They aren’t beautiful or even very good. But you should use them because Sun thinks they are good enough, they are complete and clear, and it is a waste of time to create your own for this project.
Set Tool Tips for everything. Consider whether or not you need to use the Accessibility API (http://java.sun.com/docs/books/tutorial/uiswing/misc/access.html). Defend your choice in your choices.txt.
Consider using the Preferences API introduced in JDK 1.4 to have your app remember the previous location of the window the last time it was closed.
Put borders on your panels to logically separate areas of your UI using BorderFactory.
Use JScroll pane. Just because your database only has 25 records doesn’t mean your UI should only handle 25 records.
Consider using a JToolbar in addition to Menus.
Put labels at the top of your pages so your user knows where he is.
If you have a wizard, tell the user what step she is on (“Step 3 of 5”).
Consider your server—do you need a GUI for that?
Use status messages.
Use a Shutdown Hook to clean up any objects and exit safely.
Center your window on the screen.
Build in logging using the Logging API introduced in JDK 1.4 now. Do not wait. Log absolutely EVERYTHING. Then modify your Handler to tune out the noise as necessary—don’t remove logging statements.
Don’t go crazy. You are trying to make the best UI possible. That is assuredly not the UI that shows off how you can cram the greatest number and variety of components into a single panel.
Use confirmation dialogues as apporpriate.
Note that your requirements mean that you need a dialog on start up to allow the user to specify a few options. You have some choices to make here.
Use JFormattedTextField to validate data. Users are guaranteed to type any ridiculous thing, out of negligence, ignorance, and pure spite. Don’t get suckered in.
Use the Ocean Look and Feel. It is nice looking, and it is available on all Platforms. Windows LNF is not. Your grader will almost certainly be using a Solaris OE box.

Rule #8: Use common sense!
I have seen this on real UIs, unbelieveable as it is: a pair of check boxes grouped together—one that says “Yes” and one that says “No”. Know what kinds of situations controls are intended for and use them only as intended.

Rule #9: Make the workflow obvious—don’t confuse choices with options.
Users need to be set on a path where they can’t wander away and lose their place and screw up what they were doing and lose their work. But they need to be allowed to change their minds (Cancel). This is a fine line. Make your UI so they can change their minds without killing themselves, but don’t make them think. You just have to feel your way through that one.

Check out http://www.useit.com/ for more info.