Copyright Chris Johnson, 1998.
This course must NOT be used for any commercial purposes without the express per mission of the author.

Human Computer Interface Design Using Java


Chris Johnson

Buttons and Check Boxes

We have already seen numerous examples of buttons. The main things to note are that you declare a new instance of class button. You set its label to represent the text that you want to display. You then add it to the Component that is to present it. You can either enable() or disable() buttons. However, if you disable a button you must make sure that the user understands the reasons why. It can be extremely frustrating to see something that you want to press but be prevented from doing it by the system. An example and the code for a button Applet were presented earlier. As we have also seen, you will need to write an event handler (listener) to respond to the user selecting a button.

Check boxes are similar to buttons in that they have can be selected by the user. In the case of a button this usually results in an action - delete, cancel etc. In the case of a checkbox, selection is used to indicate the acceptance of a value - either on or off. Here is an Applet that implements a simple set of checkboxes. Notice how you can select an arbitrary number of items. The code for this Applet is here (because the code doesnt include an event handler, it will compile cleanly in both AWT 1.0 and 1.1).

Here are the highlights from this applet:

        Checkbox cb1, cb2, cb3; //independent checkboxes
        //Build first panel, which contains independent checkboxes
        cb1 = new Checkbox();
        cb1.setLabel("Checkbox 1");
        cb2 = new Checkbox("Checkbox 2");
        cb3 = new Checkbox("Checkbox 3");
Notice that the final instruction sets the third check box to be initially selected. This is good practice in instances where a default value can be identified for the users choice.

Radio buttons are a special case of the Checkbox class. Only one box can be selected at any one time. This is supposed to resemble the way in which you select the waveband on a radio - VHF, Short wave, Medium wave or Long wave. The radio can only be set to one of these at a time. In other words, these options are mutually exclusive. Here is an example of some radio buttons that are implemented using a CheckboxGroup object to control the state of its component boxes: The code for this Applet is here (be cause the code doesnt include an event handler, it will compile cleanly in both AWT 1.0 and 1.1).

As before, here are the highlights of this Applet:

        Checkbox cb1, cb2, cb3; //independent checkboxes
        CheckboxGroup cbg;

        //Build panel, which contains a checkbox group
        cbg = new CheckboxGroup();
        cb1 = new Checkbox("Medium Wave", cbg, false);
        cb2 = new Checkbox("VHF", cbg, false);
        cb3 = new Checkbox("Long Wave", cbg, false);
This approach might have been imporved by using a default as shown above.

Choices and Lists

Choices and lists display a list of strings that can be selected. A list supports multiple selection while a choice supports only a single selection. This difference is the same as that between a checkbox that supports multiple selection and radio buttons that only support a single selection. Lists, typically, display all of their items at the same time. Choices may only present the user with their current selection.

The following Applet illustrates the use of the List class. As can be seen, the two lists on the right present users with access to all of their items through two scroll bars. Several items can be selected from the top list but only item can be selected from the bottom list at any one time. Here is the code for this Applet (the AWT 1.0 code is here).

The event handler for this program uses the actionPerformed method. The line:

List list = (List)(e.getSource());
provides an elegant way of avoiding the use of strings to name screen objects. Previously, we have relied upon the textual label on buttons to identofy whoich one the user has selected. This can be error prone if the program is modified to change the label. For example, if a programmer changed the label on a Button from Exit to Quit then the following would no longer work: if(button_name.equals("Exit"))... Notice also the way in which the itemStateChanged method is called when the user changes the selected item in the list.

Lists are constructed as follows:

//Build first list, which allows multiple selections.
                spanish = new List(4, true); //prefer 4 items visible
		/* etc etc */

//Build second list, which allows one selection at a time.
                italian = new List(); //Defaults to none visible, only one selectable
		/* etc etc */

As mentioned, choices are similar to lists except that one one item may be visible and that item represents the users current choice. The choice item can be changed by selecting another of the available options. It is important to note that choices are used most effectively when designers only have limited space available to them. By only showing the currently selected object, you do not have to display the other available options as you would in a choice or check box. The following Applet illustrates the use of the Choice class. Here is the code for this Applet (the AWT 1.0 code is here).

As with lists, the itemStateChanged() method is used to identify the users selection. The code that sets that label value to be the text on the selected choice is as follows:

public void itemStateChanged(ItemEvent e) {
Choices are constructed as follows:
                //...Where instance variables are defined:
                Choice choice; //pop-up list of choices

                //...Where initialization occurs:
                choice = new Choice();

The Font Choice case study

This Applet is based on a program developed by D.M. Geary in Graphic Java 1.1, Sunsoft Press, 1997, p.204.

This example implements three choices. A font choice presents the available fonts to the user, such as Helvetica, Times etc. A size choice presents a range of point sizes from 12 up to 36. The style choice offers users Italic, Bold, Plain and Bold+Italic. The user selects one item from each of these. The corresponding name of the chosen font, its style and size are then displayed below. For example, if the user chose Helvetica, Italic and 14 point it might display the following message:
Helvetica Italic 14

The Applet relies upon the following classes:

The full listing for both of these classes is available here. (Here is the AWT 1.0 code).


AWT 1.0 only supports one type of menu and they must be placed in a menu bar. This restriction is relaxed in AWT 1.1 that also provides a PopupMenu.class. However, further restrictions apply even here because Menus are not part of the Component class. This prevents the programmer from performing many of the manipulations and changes that might be considered for particular applications.

One of the consequences of running menus from menubars is that it makes little sense to exploit them within an Applet. This would lead to a situation in which there were two levels of menus in the same window: those from the browser and those on the Applet's menubar. This would be seriously confusing for most users. However, the following Applet provides a simple illustration of the various types of menu that are available.

The full listing for both of these classes is available here (the AWT 1.0 code is here). When the user clicks on any menu item, the window displays a string indicating which item was clicked and what menu it's in. Menu 1 is a tear-off menu. If the user clicks on the dashed line, they create a new window that contains the menu. This can be moved to an appropriate place on the screen so that it is near the user's work. Warning tear-off menus are implemented only on the Solaris platform, not in Windows 95/NT or MacOS.

Menu 2 simply contains a checkbox. Menu 3 contains a separator between its second and third items. This is useful for the chunking techniques mentioned below. Menu 4 contains a submenu. Menu 5 is right justified on the menu bar as a help facility. Some platforms alter the location of this facility. For instance Motif places Help on the far right of the menu bar. Windows95 places it on the right of the last menu rather than justified against the right most edge of the menubar.

Here are some of the highlights of the previos applet. The menubar is constructed as follows:

	//Build the menu bar.
                    mb = new MenuBar();
The first menu is added to the bar and items are inserted as follows:
        	    //Build first menu in the menu bar.
                    //Specifying the second argument as true
                    //makes this a tear-off menu.
                    m1 = new Menu("Menu 1", true);
                    mi1_1 = new MenuItem("Menu Item 1_1");
                    mi1_2 = new MenuItem("Menu Item 1_2");

The main usability consideration about menus is that they offer users a constrained set of options; this is similar to check boxes; choices and lists but differs from free text forms. This approach offers a number of advantages over text based interfaces. The use of lists reminds users of their options. This can help them to direct their activities. Menus provide prompts that support short and long term memory. Users do not have to search through recollections of previous interaction to recall all possible commands. Once they have remembered a command they do not have to continually remind themselves to ensure that it will not be forgotten again. Rather that trying to remember the command to print a file, users simply go to the file menu and browse its entries.

The design aims for menus are as follows:

The individual items have to be grouped under labels. If there is only one menu then this is a trivial task. In more complex systems, it must be possible for users to infer that a particular item is available from a particular menu. Typically, this is done by placing the operations on an object under a menu that is labelled by the name of that object. For example, most interfaces have options such as Print, Copy, Open under the FILE menu. Alternatively, items may be collected under labels that reflect common operations. Various forms of SEARCH may be found under the same menu.

Just as items may be grouped under common labels, they are also grouped within a menu. For instance, creation operations such as Open and New are placed together in the File menu. Again, this supports users' navigation tasks within the menu structure. Finally, any destructive options, such as Delete should not be placed at the top of a menu. In mouse driven systems it is relatively simple to `drop-off' the label and select this option by mistake.

And now on to part six...