Question Management Software

The Question Management (QM) software is necessary to keep track of the lecturer- audience interaction as the virtual cameraman is able to detect motion in an image but is not able to detect the semantic meaning of this motion.

The software consists of three modules. The abstracted view on the participants of the interaction leads us to the first two modules: the lecturer†s client and the questioner†s client. As we need a central communication base which also keeps track of the active state of the interaction we amend our modules by a communication server which syn- chronizes the lecturer and questioner clients and produces the messages for the virtual director.

This makes the QM software a distributed software suite. As the lecturer already uses a computer to present his or her slides and another computer is used for the virtual director, we decided to use these machines to run the corresponding part of the soft- ware suite on them. In order to equip the potential questioners in the room with elec- tronic devices we use PDAs which we employ anyway for interactive quizzes during the lecture (Scheele et al., 2005) and (Kopf & Effelsberg, 2007). They provide wire- less LAN access, a built-in microphone and a touch screen. These three features are used to implement the questioner†s client.

Tasks to fulfill

The QM software suite has to provide the GUIs for the lecturer and the questioner, it has to implement and supervise the lecturer ‡ questioner interaction as shown in sec- tion 2.2.3, it has to convert the actions of lecturer and questioner into messages for the sensor input of the virtual director, and finally it handles the audio connection of the questioner for the virtual sound engineer. Furthermore, the software may have to man- age more than one hand-raising at the same time, and it additionally has to provide a management interface for the lecturer.

Implementation Details

We now show the important implementation details of the three modules of the Ques- tion Management software suite.

Questioner•s Client

The first purpose of the Questioner†s Client is to request the estimated position from the WLAN indoor positioning system, to provide the GUI to show the estimated posi- tion and let the user confirm his or her seat. Then the client connects to the QM server, transmitting its IP address and the confirmed position.

The second purpose of the questioner†s client is to provide the general GUI for the questioner. In the top portion of the screen, there is a status indicator box. It informs the questioner at any time about the status of the interaction. The status indicator changes according to the interaction from „waiting…, „announced…, over „please ask… to „answering…. Figure 23 shows the standard interface.

Figure 23: Standard interface of the questioners' client.

However, in some cases, there are different messages, e.g., „sorry, not possible… if the question was blocked by the server, „just a minute… if it was deferred by the lecturer who will automatically be reminded after one minute, or „please, do listen… if the lec- turer denies the question.

The third purpose of the client is to capture the student†s audio and transfer it to the server in order to get it processed by the sound engineer. As the PDAs are typically within one†s arm reach, they are in a distance well suited for audio recordings. The audio transmitting instance is created when the questioner announces a question, but

the transfer of the audio data using wireless LAN is not started until the questioner has been given the floor.

Lecturer•s Client

This client runs on the lecturer†s presentation computer. Its central task is to indicate that a student would like to ask a question, and to provide an intuitive user interface to accept or decline such questions. At a certain point in time, a question may disturb the progress of a lecture, or it can be undesirable for other didactic reasons. Therefore, the client also offers the possibility to temporally postpone a question.

While teaching, it is important that the client software of the question manager does not disturb the lecturer too much. He or she should only focus on the QM client in case of a question. Therefore, we have implemented the client in such a way that it is usually running in the background. If a student wants to ask a question the ques- tioner†s client submits this request to the lecturer†s client via the QM server. A fore- ground window pops up at the lecturer†s computer, stopping the current presentation. If more than one student announces a question, the foreground window shows a list of all announced questions. Figure 24 shows the foreground window with one an- nounced question.

Figure 24: Popup on the Lecturer„s computer showing announced questions.

A mouse click on a button of the lecturer†s client is sufficient to give the floor to the student, to ignore the request, or to postpone it. In the last case, the window pops up again after the predefined time of one minute. Depending on the lecturer†s decision how to proceed with the question, the student gets a different status messages on the display of his or her PDA, as mentioned in the section on the QM questioner†s client above.

Figure 25 shows the steps of the basic question ‡ answer interaction, amended with the corresponding client screen shots of the questioner (left) and of the lecturer (right).

Figure 25: Basic question - answer interaction, amended with client screen shots.

After the lecturer has given the floor, the student asks his or her question, and the QM client transports his or her audio to the sound engineer. One click on the button „Now

answering… in the lecturer†s client indicates the beginning of the lecturer†s answer. A

last click by the lecturer on the button „Question Answered… signals the end of this question ‡ answer interaction. The lecturer may allow additional questions, remarks, or discussions, but he or she can also continue with the lecture.

Transporting the questioner†s audio to the sound engineer is necessary for the re- cording of the lecture and for tele-teaching scenarios as the remote audience or view- ers of the resulting video want to hear the questions. In the lecture hall itself the voice of the questioner is normally sufficient for every participant.

Not shown in the basic version of the question ‡ answer interaction above is the pos- sibility for the questioner to ask a further question in the same interaction. The GUI of

the QM questioner†s client has two buttons which are active when the lecturer is an- swering. So, the questioner can either click on the „Answer OK… button which ends the interaction or hit the „Not yet answered… button. In the latter case, the lecturer†s GUI is reset to the state before he or she gave the floor to the student, and there is room for another turn.

A question ‡ answer interaction is active until either the questioner has hit the „An-

swer OK… button or the lecturer has clicked on the „Question Answered… button on

their respective GUI. Of course, the decision of the lecturer overrides the action of the questioner.

Question Management Server

Let us finally look at the QM Server application which represents the central compo- nent of the Question Management software suite. It handles the communication with all the questioner clients concerning all interaction events, of receiving the ques- tioner†s audio when given the floor, of communicating with the lecturer client for the relevant interaction events, sending consolidated events to the virtual director as sen- sor input, and providing a GUI to monitor and control the client events.

During start-up, every QM questioner client automatically registers itself at the QM server by sending its IP address and its position coordinates. The connected QM ques- tioner client is represented by switching the background color of the according field of the server GUI to green.

When a questioner announces a question the server receives the corresponding event message and performs three actions:

1. Create an instance of the audio receiver for the questioner client, 2. Raise an event for the lecturer client, and

3. Raise a sensor input event for the virtual director.

While a window pops up at the lecturer†s client, the virtual director gives the orders to the cameraman showing the audience to aim at the position coordinates of the ques- tioner and to zoom in. When the lecturer gives the floor to the questioner, the server receives the corresponding event from the lecturer†s client. Now, the server sends out the sensor input event „questioner acknowledged… to the director, and as a result the audience camera is switched on air. Meanwhile, the audio stream is sent from the

PDA to the QM server over wireless LAN, and the questioner is requested to ask his or her question.

When getting the signal from the lecturer†s client that the lecturer starts to answer the question, the server stops receiving the questioner†s audio and announces that the an- swer begins to the questioner†s client as well as to the virtual director. At last, when the server gets signaled the end of the answer either from the questioner or from the lecturer, it resets all displays settings and audio components and reports the fact that the system should be switched back to the lecture context by the virtual director.

Furthermore, the server provides some more functionality:

- It blocks any question announcement if the „Block Clients… property is ticked. - By clicking on a number of the lecture hall abstraction shown in the GUI, the

audience camera is aimed at the respective seat.

- Finally, the „Home Position… button resets the camera adjustment to show the entire audience.

Figure 26 shows the GUI of the server. Registered questioner clients are shown in green while the currently speaking questioner is shown in red. On the left side, the queue of announcing students is visible, showing each with the timestamp and the seat of the announcement. On the right side, there is some additional information concern- ing the IP address of the active questioner and the state of each part of the QM soft- ware suite.

Figure 26: GUI of the QM server, client on seat 77 asking.