Grades

Projects

Resources

GUI Design & Implementation:
A Basic Checklist

Below is a bare-bones checklist associated with the design and implementation of a graphical user interface (GUI).

Design

1. As far as possible, design the user interface so that a User Guide is unnecessary.
2. Model user interaction as a state machine.
3. As far as possible, physically group components and actions related to each state.
4. Do not place antogonistic actions adjacent to one another. For example, do not place a save operation next to a delete operation.
5. Establish the layout hierarchically, especially if the user model is a nested state machine.
6. Physically convey the hierarchy (e.g., with borders).
7. Use meaningful names. For example, prefer "Send message" to "Send".
8. Enhance cognitive consonance: Help the user know his/her current state. Physically convey changes in the user's state.
   • Use focus to help the user know what to do next.
   • As the user changes state, enable and disable components to allow valid actions and disallow invalid actions; it is easier to prevent invalid activity than it is to check for it, and send error messages. For example, if logging in enables [disables] a set of components, then logging out should disable [enable] exactly those components.

     Look for such state transition duality. Reflecting duality of user action in your code simplifies it, also making it easier to modify. If an aspect of a state transition duality appears asymmetric (e.g., enabling something is not undone by disabling it), be suspicious of your understanding of the situation. Strive for simplicity.

   • Modify the meaning of components, making bad choices impossible. For example, the name and meaning of a Connect buttom is changed to a Disconnet button when the user is Connected, and back to a Connect button after the user disconnects. Thus, when connected, the choice of disconnecting appears; connecting is no longer an option. This simplifies the code that "listens" to the button.
   • Where appropriate, add/remove GUI components as the user's state changes to reflect what is [im]possible in that state.

Implementation

Make a code design convention for processing actions and events. A good convention is object-oriented: Package each GUI controller declaration with its corresponding view. For example, the Netbeans Swing tool uses a particular convention for declaring each controller where its corresponding view component is added to the layout.

For example, for each action, its associated GUI component declares an ActionListener in the application's constructor on in the Applet's init method. The ActionListener is boiler-plate code that invokes a private controller method whose name corresponds to the component's name.

componentName.addActionListener( new ActionListener ()
	{
		public void actionPerformed( ActionEvent actionEvent )
		{
			componentNameActionPerformed( ActionEvent actionEvent );
		}
	}
);

 . . .
 
 private componentNameActionPerformed( ActionEvent actionEvent )
 {
 	// put controller code here.
 }