SCJD: GUI Design Principles

I read a few GUI design articles before starting the design and they suggested mostly the same principles. Here are some of the more important ones that I implemented. You might want to take a quick look at my previous post for screen shots.

Good Decisions: Principles followed

  • GUI widgets should flow from top to bottom, left to right.
  • Windows should be re-sizable.
  • GUI should have a tool bar and menu bar.
  • Similar elements (ex. check boxes, radio buttons, etc) and related logical elements (search criteria, application configuration, etc) should be grouped together.
  • The menu bar should have mnemonics for easier access.
  • There should always be a File menu (with Save (where applicable) and Exit) and a Help menu (with About & Help Topics).
  • There should be keyboard shortcuts for important tasks in the menu.
  • Textfields should have trailing labels (right justified).
  • Properties specified by the user should be persisted and retrieved on the next run of the application.
  • Textfields requesting a file location should be accompanied by a browse button.
  • Potentially dangerous actions (such as exiting the application), should be confirmed by the user before being allowed to continue.
  • Components (buttons, tool bar buttons and menu items) for actions that are not allowed should be disabled when appropriate.

Bad Decisions: Principles not followed

So the GUI section of the assignment is where I lost most of the marks that I lost. Initially I was quite puzzled by this, because I thought it was adequate for the requirements. Then the more I thought about it, the more reasons I saw for possibly losing marks. I encountered all of these problems when thoroughly testing my GUI, but I just wanted to submit the assignment asap; so I definitely cuts some corners and wouldn’t be surprised if I lost marks for these…

Not giving the user feedback during time intensive tasks (ex. a JProgressBar)

My initial thought on this was that it was one of those nice to have, “let’s pretty up the GUI” features. But as it turns out it wasn’t the case. I found this out when I was stress testing my app. I created a database file with thousands of records and then tried to load the network client. So obviously the network client took a LONG time to read all the records (as the server would take much longer to do this), so the app just looked like it was crashing (ex. when you’re redeploying in eclipse and everything freezes and goes white). A JProgessBar would’ve been very handy to let the user know hey, the app’s not really crashing, its just really busy and they could see some progress happening. A JProgressBar is much more than window dressing.

Not allowing modifiable cells in the JTable to be editable

The only field in the JTable that was editable was the customer id field; there was no requirement to edit an entire record, just the customer id field. So modifying the table didn’t seem like a big priority. So I figured, hey why not just use a pop up with a basic JTextField for the customer id, easy enough. To be honest, I did try to implement cell manipulation but I found playing around with TableCellRenderer and dealing with table cell actions and focus issues to be quite a lot of work; and not really worth it when only one cell in the table could be updated. While I still think the pop up was a good compromise, in hindsight I’d implement direct cell manipulation if only for the fact that users would expect such a feature.

No Standard Edit Menu with Cut, Copy & Paste

This was clearly a mistake or just laziness on my part. This is as standard as it gets. In my design choices document I attempted to defend this by stating the JTable wasn’t editable anyway and that most (if not all) settings were persisted and loaded on future runs of the app. I don’t think the accessor bought it and really, the accessor shouldn’t have.

Overall Swing Impressions

Swing is fairly simple to learn and understand. Basically, when building a screen you extend JFrame, assign a layout manager to your frame and just start adding JPanels to the frame as dictated by your chosen layout manager. Then adding widgets (such as JTables, JButtons, JTextfields, etc) to a JPanel is straightforward. Really, building a small screen is quite trivial.

However, once you start to build more than trivial GUI displays (displays that require many differently sized panels and widgets and varied widget alignments) then things get interesting. Let’s just say that without some sort of GUI building tool, using GridBagLayout (one of Swing’s most powerful layout managers) and GridBagContraints to build a GUI can be very, very frustrating. But once you’ve mastered it (which will take time), its not so bad.

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply