Chris Johnson

• Part One: Introduction
• Part Two: AWT Components
• Part Three: Text and Labels
• Part Four: Setting Things Out...
  
  
• Part Five: Selection Components
  
  • Buttons, Check Boxes
  • Choices and Lists
  • Menus
  
  
• Part Six: Graphics...
• Part Seven: Additional information
  
  
  
• Back to Main Index

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");
        cb3.setState(true);

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);

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());

Lists are constructed as follows:

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

//Build second list, which allows one selection at a time.
                italian = new List(); //Defaults to none visible, only one selectable
                italian.addItem("uno");
                italian.addItem("due");
                italian.addItem("tre");
		/* 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) {
        setLabelText(choice.getSelectedIndex(),
                     choice.getSelectedItem());
    }

                //...Where instance variables are defined:
                Choice choice; //pop-up list of choices

                //...Where initialization occurs:
                choice = new Choice();
                choice.addItem("ichi");
                choice.addItem("ni");

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

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();
                    setMenuBar(mb);

        	    //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);
                    mb.add(m1);
                    mi1_1 = new MenuItem("Menu Item 1_1");
                    m1.add(mi1_1);
                    mi1_2 = new MenuItem("Menu Item 1_2");
                    m1.add(mi1_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:

• clear structure. In interfaces of any complexity it may be necessary to place menus within menus. For example, the file menu must be selected to print a file. This may produce another menu to select the destination printer and so on. It is important that users understand the relationship between these different structures.
• clear labelling of categories Menu items are grouped under categories or headings. If users cannot decode these headings then it will be impossible for them to access the appropriate information. The labelling of individual items should be organised according to the guidelines already presented for forms and command line interfaces.
• appropriate breadth and depth. Designers are faced with a trade-off. They can either make all menu options available from a top-level display. This increases the breadth of the structure and forces users to remember the location of each individual item within a category. If they cannot then there may be a significant increase in search times. Alternatively, items may be grouped within sub-menus that are, in turn accessed from the top level display. This increases the depth of the structure. Users can use category information to access these sub-menus and direct their search task. The problem here is that high navigation costs may be incurred if an entry is not found within a particular sub-sub-sub menu.
• simple selection procedure There is a heuristic in HCI that states frequent commands should be easily performed, less frequent commands may be correspondingly harder to perform. It is important that users can easily select the most common options. However, it should also be the case that potentially destructive options, such as delete or re-format, should involve some confirmation. Inadvertent selections are a continual problem in menu-driven interfaces.

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...