|
Home
| pfodApps/pfodDevices
| WebStringTemplates
| Java/J2EE
| Unix
| Torches
| Superannuation
|
| About
Us
|
|
|
Java GUI Programming Tips and Guidelines
|
There are two common situations in which dialog boxes appear
i)
When the user asks the application to perform some task and the
application presents a dialog box to obtain the necessary information
from the user.
ii) When something happens that the application
needs to let the user know about (usually an error)
Examples of the first situation are 'File Open' dialog boxes, 'Colour Choosers' and application 'About' dialog boxes. Examples of the second situation are often error conditions such as, File Not Found, Disk Full, Lost Connection, Out Of Memory or more mundane messages such as Task Completed.
In this article I argue that dialog boxes should never be used to interrupt the user to report errors, etc. After presenting a few examples of inappropriate dialog boxes, I discuss why they should not be used and I suggest an alternative method of presenting the same information to the user using the status bar.
In passing I also mention that some of the dialog boxes used to obtain information from the user should be made unnecessary in modern applications.
Below are a selection of inappropriate dialog boxes. Under each one I have translated what the programmer is really saying to the user.
You
have asked me to do X.
Do you really want to do X?
If you do X,
I will not be held responsible for what happens.
I
am doing what you asked, don't rush me.
Just sit and watch and
wait.
I
finished what you asked me to do so I just thought I would interrupt
you to let you know.
You
have asked me to close the window or shut down the application.
Do
you want to throw away all the work you have done?
I think you
should save this work but I am too lazy to do it for you unless you
ask me to each and every time.
The
operation failed for some reason only I would understand.
Don't
expect any on-line help because the Java JOptionPane does not provide
a build-in help button
and I could not be bothered programming one
just for you.
You
have done something that I allowed you to do
but I never thought
that anyone would do.
How could you be so dumb as to do that.
Everyone (me) knows you never do that.
I
have made a programming mistake, so I will now end the program
and
discard all the work you have done so far.
The main reason you should not use Dialog boxes to send messages to the user is that they are “show stoppers”. When you pop up a dialog box you are saying to the user, “Stop whatever you are doing and handle this.” As such, dialog boxes interrupt the user's train of thought and their use of the application.
Lets look at the alternatives for the previous dialog boxes.
No Responsibility – This dialog box should never appear. The user should be able to do what they like and undo it if they change their mind or don't like the result.
Progress – This dialog box is designed to let the user know the task has not stalled and to give them some idea of its progress. It also provides an option to cancel the task if it is taking too long. The information is good but the dialog box is not clearly attached to the task window. If there are multiple task running at the same time this can get confusing.
Interruption – This dialog box should never appear. When the operation is finished the interface should indicate that the results are available by displaying them, or that it is ready to accept new commands, by a change in background colour / icon / boarder etc., or the appearance of an input prompt or message on the status bar, etc.
Inane Save Question – This dialog should never appear. The user's work should always be saved. (see Why your application should not have a Save function)
Unintelligible Error, Invalid State, Assertion Error – These dialog boxes are collectively saying the application could not complete some task the user has requested. The application should recover from these errors and let the user know it is ready to accept new commands. The application should present a modification of the “operation finished” response but with the addition of an message to let the user know the task was not completed and a link to on-line help.
When dialog boxes are used they are usually modal. That is they block all user input to other windows in the application until they are closed. This is one of the reasons they are so intrusive. They force the user to stop whatever they are doing to deal with the dialog box. Even if a non-model version is used, they still take focus as they are displayed and so interrupt the user's input to what ever window they were working in. If the user happens to be just pressing the “Enter” key as the dialog box is shown, the dialog box will be closed before the user can see what it was all about.
The first four examples don't need any user input, while for the error messages there is usually nothing the user can do. So when you need to inform the users of some problem, a less intrusive approach is more appropriate.
An enhanced status bar provides a more user friendly alternative to using dialog boxes for messages. A well designed status bar provides for the display of the status of the application or its sub-window, an indication of the progress of a task and the presentation of information to the user when things go wrong.
The following screen shots show how the status bar can be used to replace the previous dialog boxes.
This
is a subtle replacement for the Java ProgressMonitor. You could also
change the cursor to an 'hour glass'. Because the status bar does not
have a Cancel button, you need to provide a means of interrupting any
process running in the internalJFrame. Any non-trivial task should be
run on a separate thread. The ThreadReturn
package provides a simple means of passing tasks off to threads. To
interrupt the thread, a STOP button should be added to the
application toolbar. This STOP button interrupts any threads running
in the currently active internalJFrame.
This
is an alternative to the “OK done that” dialog box. Other
things that could be done are, disabling the STOP button, enabling
text entry panes, restoring the cursor from an hour glass to a normal
cursor. All of these visual queues let the user know the task is
finished and they can continue working with this window.
This
is an example of an error message that terminated the requested task.
Note that the message box is tied to the window it is associated
with. The “Continue” button just hides the message box.
The “Help” button is linked to on-line help for this
message (see Unified
Error/Information Messages and Help). Each error message logged.
User messages are not logged (again see Unified
Error/Information Messages and Help)
Dialog boxes should have a “Continue” button instead of an “OK” button. An error is never OK, but once the user has read the message and the application as recovered from the error, the user should be given the option to “Continue” using the application and dismiss this message. There should also be a “Help” button (or some other means of linking to on-line help such as hyperlinked words in the text)
Some Messages are not tied to a particular task window. These are either global application tasks, such as network connections, or top level application errors.
If there are global application tasks, such as connection between this application and some other computer, then this task should be assigned its own window. This window can then be used to display the status of that task and any error messages. One possibility is to make the window a log file of the task's changing status.
For top level application errors, the most straight forward thing to do is to add a status bar to the main application window and display the messages there. Unlike the InternalJFrame statusBar, this statusBar is hidden unless it is showing.
Now that the status and messages have been localized to each
Internal window and there are no longer dialog boxes popping up all
over the application, you need a method of keeping the user informed
as the the status of all the windows they are working with. At its
most basic the user needs to know
i) Is the task still
running?
ii) Has it completed successfully?
iii) Did it stop
due to an error?
iv) Is it waiting for some input from me?
In a multi-windowing system these states can be displayed for each
window using a tabbed pane at the bottom of the application Jframe.
This is the tabbed pane I use in Parallel. Each window has a tooltip which shows its full title.
On the left of each window tab is an icon that shows the window state.
|
|
task completed normally |
|
|
task is running |
|
|
flashing when the window is waiting for user input |
|
|
task ended with an error |
Dialog boxes are not appropriate for presenting messages to the user. They interrupt the user's train of thought and force them to stop what they are doing and deal with the dialog box. Often the only option they are given is to close the dialog box.
I have suggested a more appropriate and less intrusive approach is to use an enhanced status bar in each of the application's windows to display both status messages and error messages. The error messages come with Help and Continue buttons. Errors are never 'OK'. The Continue button invites the user to continue to use the application. It just hides the error message. The application should take steps to recover from the error and allow the user to continue working even if the user leaves the error message displayed. The user should not be forced to deal with the error message display before they do any more work.
In an application with multiple overlapping and hidden windows, a tabbed pane can be used to keep the user informed by using different icons in the tabs to indicate the state of the window.
Source code for the ExampleStatusApplication is available from the Forward Computing and Control Pty. Ltd. The code includes StatusBar, ProgressBar, MsgBox and ApplicationTabs classes as well as a Help class and example help pages and application logging classes.
Contact Forward Computing and Control by
©Copyright 1996-2017 Forward Computing and Control Pty. Ltd.
ACN 003 669 994
