CS102 Lab 2:
Graphical User Interfaces

Assigned: Tuesday, February 2
Design (5 points) due in lab section: Monday, February 8
Demonstration (5 points) in lab section: Monday, February 15
Hard copy of code (10 points) due to the CS102 mailboxes: Tuesday, February 16

Goals:

By the end of this lab, you should...

have experience designing a simple graphical user interface,
learn how to implement an interactive user interface using a variety of components from the java.awt,
understand the Java event model, and be able to create listeners, register them with event sources, and react to events,
appreciate what it means to separate the user interface from the underlying application, and
be familiar with the idea of "wrappers" and "factories" in object-oriented design.

Motivation and Overview:

In Lab 1, you created a package that programmers can use to create surveys. There, you concentrated on the API, the Application Programmer Interface, which defined how the programmer using your package would create and interact with the objects defined by your package. In this lab, you will expand your package, concentrating on the HCI, the Human-Computer Interface, which defines how the end-user will interact with the objects in your package. Since graphical user interfaces (GUIs) are the most dominant form of HCI today, you will create a new package called survey.gui that will provide graphics for allowing an end-user to fill out a survey that was created using the survey package you defined in Lab 1.

Keep in mind that GUI design is an art. In general, a good interface is:

attractive (uncluttered and generally appealing to the eye),
clear (it should be obvious to the user what they can do and how to do it),
efficient (simple things should require a minimum of keystrokes or mouse clicks),
responsive (so that users see the results of their actions interactively), and
fool proof (it should prevent user actions that could result in an error in the underlying application -- for example, when pressing a button at a certain time would cause an error, the button either shouldn't be visible or it should be disabled).

Before starting:

Be sure that your Lab 1 project works, and that your test program is written as described in the Lab 1 assignment.
Become familiar with the packages java.awt and java.awt.event by reviewing your lecture notes and looking at the documentation provided in the textbooks or on the web. This will help you get a sense of what is available for you to construct your user interface. Pay particular attention to the following classes and interfaces:
- Component,
- Frame and Panel,
- TextArea, TextField, Button, Checkbox and CheckboxGroup,
- BorderLayout, GridBagLayout, and CardLayout,
- ActionEvent and ActionListener,
- ItemEvent and ItemListener, and
- TextEvent and TextListener.

Overview:

In the package survey.gui, you'll need to provide a class SurveyDisplay that extends Frame and whose constructor takes one parameter, a Survey object that contains the survey to be presented to the end-user. Your SurveyDisplay class will be responsible for displaying the survey, one question at a time.

You should think of a SurveyDisplay object as a "wrapper" around the Survey that you pass to it in the constructor. It is a wrapper in the sense that it surrounds the Survey object, putting something of a "shell" around it. The end-user interacts with the SurveyDisplay object through the graphics it displays, and the SurveyDisplay, in turn, interacts with the Survey object. It's like a layer between the user and the Survey object itself.

In order to do its job, the SurveyDisplay object will create a number of QuestionDisplay objects, one for each question in the survey. The SurveyDisplay object will choose, at any given moment, which question should be displayed, making use of the advance method provided by the Survey. So, at any given moment, the end-user will see and interact with the graphics shown by only one QuestionDisplay object.

The QuestionDisplay constructor will take a Question object as a parameter, and the resulting QuestionDisplay object can also be thought of as a wrapper around the Question object. The user interacts with the QuestionDisplay object, which in turn interacts with the Question. For example, it decides what to display by calling the accessors of the Question object.

Similarly, each QuestionDisplay object will contain a number of OptionDisplay objects, one for each option of its Question. Again, these will be wrappers. For example, the OptionDisplay will call an accessor on its Option object to determine what text to display, and when the user clicks on a checkbox in an OptionDisplay, the OptionDisplay will ensure that the appropriate method (i.e., setSelected) is called on the Option object to update the data in that option.

Specification:

The specification is simple. Your SurveyDisplay class should take a Survey object into its constructor and display a user interface that allows an end-user to take a survey, answering questions in the order intended by the programmer who created the Survey object. The user should be able to select options and fill in text, and have those results saved inside the Survey object. The user should also be able to navigate through the survey by clicking a button to advance to the next question. When the user advances past the last question, the SurveyDisplay should take itself off the screen and should print out the completed survey by calling the Survey's toString method.

Design:

Think carefully about what components you'll need to display your survey. Then design classes whose instances will serve as wrappers around the survey, questions, and options. In working with wrappers for your questions and options, you may find it helpful to define one or more methods (or entire classes) that serve as a "factories" by taking in a Question or Option object and returning a wrapper containing that object. The particular wrapper would be chosen by the factory based on the type of the object provided (using instanceof). For example, the factory might choose a different wrapper for a CheckoffOption than it would for a CombinedOption.

Create a one-page design (front and back) with the following information.

GUI illustration:

On the front side of the page, draw a picture of what you want the graphical user interface (GUI) to look like on the screen when the end-user takes the survey. On your diagram, label each of the components with their functionality and explain how the end-user will interact with them. You may need more than one picture, to show different question types.

Class hierarchy:

On the back of the page, draw a diagram of the class hierarchy for your survey.gui package. Briefly explain the purpose of each class and summarize the methods it provides by its name in the hierarchy, and say what java.awt components each of them will use and/or extend.

At the bottom of the page, briefly describe the internal representation you will use in the various classes. and how you'll deal with end-user events.

Bring your design to your lab section on February 8. At that time, you should go over the design with a TA and ask the TA to sign and date the design. Note: By signing the design, the TA only signifies that he/she has discussed it with you and tried to give you useful feedback. The signature is not a guarantee that it is a good design, or even that it will work at all. Therefore, if things aren't working out when you do the implementation, you may want to reconsider the design. If you need to, you can change your design after February 8. There is no penalty for changing your design, but be sure to turn in both the original signed design and the new design with your completed lab.

Implementation:

Implement the classes of the survey.gui package according to your design. Carefully choose the appropriate protection modifiers for each class, method, and instance variable according to the guidelines described in class.

Testing:

Modify your test program from Lab 1 to create a SurveyDisplay object for the survey you already created in that program. To test the end-user interaction, complete the survey several times, answering the questions in various ways. Make sure advanceQuestion works as intended, skipping questions correctly according to the user's answers. After the survey is completed, your test program should print out the survey to the terminal by calling the survey's toString method, and you should check that the printed results correspond to the answers you gave in filling out the survey.

Demonstration:

In your lab section on February 15, you will demonstrate your complete working lab. The TA may ask you to add new questions or options to your survey, and to demonstrate your user interface.

Bring your signed design with you to the demo, and have a completed CS102 cover sheet ready for the TA to record your demo grade and demo comments (what worked and didn't work).

Hard Copy:

After your demo, take some time to clean up your code, add documentation, and generally make it beautiful. If there was a problem during the demo, you should mark on your code where you think the problem is. If you have time, you can try fixing it, and you should describe how you fixed it and whether or not you were able to get it to work. However, you will not be able to replace your demo grade by doing another demo unless you use a late coupon or a rewrite coupon.

What to turn in:

By 5:00pm on February 16, you should turn in the following items to the CS102 mailbox:

Your cover sheet (with the demo grade recorded on it).
Your design, signed and dated by a TA.
Your final design (if different from the signed one).
A printed copy of all the code in your survey and survey.gui packages.
A printed copy of your test program.

Kenneth J. Goldman (kjg@cs.wustl.edu)

CS102 Lab 2: Graphical User Interfaces