Adaptation and Evaluation of a Virtual Classroom for Blind Users

3.1 BigBlueButton

The virtual classroom BigBlueButton has a modular structure and could thus be extended easily. On behalf of an improved accessibility, keyboard support, auditory feedback, activity protocol, alternative descriptions and accessible recordings were added [11], which were not part of the official open source project (see Figure 1).

Figure 2

Tactile user interface of the virtual classroom. The description module is active (cf. [10]).

Depending on the assigned role, a user has access to the following module functionalities of the virtual classroom:

1. Participant’s list: Overview of all participants including their roles and available media.

2. Web cams: Display of all shared video streams.

3. Whiteboard: Display of presentations and creation of drawings and annotations.

4. Chat: Possibility for public and private communication.

5. Descriptions: Descriptions for presentation and whiteboard elements.^[4]

6. Activity protocol: chronologic list of events, which can be refined by a filter.

Further features include the display of the session title, various setup options and recording functionality.

3.2 Alternative User Interface and Interaction Concept

The following alternative user interface concept was developed to facilitate the adaptation of the complex modules of the virtual classroom to the two-dimensional tactile representation of the BrailleDis [12, 14]. Using the implemented prototype, a blind user can perceive the content of the following modules: activity protocol, whiteboard, chat, participant’s list and description module (cf. [10]). The design concept allots one module to be presented in the center of the display at a time, called body region (cf. Figure 2, number (1)). Furthermore, each view displays the title of the virtual classroom and the name of the active module (2), a navigation bar (3), a status bar (4) and a detail region (5). The detail region can be compared to the output on a single-line Braille display, which displays the currently processed content in Braille letters parallel to the audio output.

In the navigation bar, active modules are emphasized by removing the separating vertical line on the right of the tab (see tab “description”). On the other hand, the upper border of the tactons (tactile icons) in the status bar is added in order to indicate an active state.

Figure 3 shows all modules that can be displayed in the body region. It maps the screen content of Figure 1 to a tactile representation on the BrailleDis.

The layouts of the activity protocol (Figure 3a) and the chat (b) are similar. An input field is placed at the bottom. In the chat module, the user can enter text messages. In the input field of the activity module, the user can enter filters and requests similar to a command line. The content of the activity protocol or the chat history is displayed above in Braille. An entry of the activity protocol consists of the name of the source module, a time stamp and respective descriptions or content. A chat entry shows a time stamp, the author and the message itself.

The whiteboard module (c) shows the whiteboard area of the virtual classroom. The whiteboard content is transferred to a bitonal representation displaying black pixels as set pins. The learner can use the zoom function and change the contrast in order to obtain the clearest representation for an optimized tactile perception.

The description module (d) holds descriptions to the whiteboard elements. A list of all slide elements is available on the top left. A minimap (see [18]) on the right displays a minimized representation of the whiteboard. If an alternative description is available, it can be displayed in the field underneath. Additionally, this input field allows the user to add or alter descriptions for whiteboard elements.

Figure 3

Tactile representation of the views in the body region: (a) activity protocol, (b) chat, (c) whiteboard, (d) description module, (e) participant’s list.

The participant’s list (e) is divided into a moderator’s list (top) and a list with participants (bottom). The current status of the microphone, video transmission and presentation rights is displayed next to each participant’s name. To keep this view compact and clear, the status information is abbreviated.

Users can choose between interaction using the hardware keys of the BrailleDis as well as gesture input. Text input is performed using the keyboard. The concept includes a comprehensive keyboard control which is not yet fully implemented.

In order to avoid accidental gesture input during reading (see Midas Touch effect [9]), a hardware key has to be pressed to initiate an exploration (Figure 4 (EG)) or selection gesture (SG) [2, 22]. In addition to these keys, the following commands can be executed via the hardware keys:

1. switch between the modules (1–5),

2. stop the current speech output (F1),

3. turn the microphone on and off (F2),

4. raise or lower the hand (F4),

5. zoom within graphical representations (Z),

6. change the contrast of images (C) and

7. scroll the content using a navigation bar (NB).

Figure 4

Allocation of hardware keys: (1) activity protocol; (2) whiteboard; (3) chat; (4) participants; (5) descriptions; (F1) stop speech output; (F2) microphone on/off; (F4) raise/lower hand; (EG) exploration gesture; (SG) selection gesture; (Z) zoom, (Z – up) enlarge, (Z – down) downsize; (C) contrast, (C – up) increase, (C – down) decrease; (S) slides, (S– left) previous slide, (S – right) next slide; (NB) navigation bar ([10, 14], graphic according to [4]).

All these hardware commands can also be performed using gestures on the touch-sensitive Braille display. This can be achieved by pressing the selection gesture key while performing a one finger tap gesture in the desired area. By this means, a blind user can focus input fields and press buttons. Additionally, zooming using a (half-)circle gesture is more precise when performed via gesture input than using the hardware keys [18].

^[5]

In order to obtain additional information without performing an action, the user presses the exploration key while taping on the desired element. For example, a message in the activity protocol can thus be read aloud by the application. To maintain the orientation of the user, no focus change is performed when using exploration gestures.

Thanks to these interaction modes, the blind learner has access to all basic functionalities and interaction possibilities like a sighted user has in the role of a participant.

3.3 Filtering of the Application Data

Figure 5 shows the architecture of the prototypical adaptation of the virtual classroom BigBlueButton called TactileBBB. It was implemented using C#. TactileBBB uses the Microsoft Accessibility Framework UI Automation^[6] (UIA) to access the application data of the virtual classroom, defines the presentation layout on the BrailleDis and provides the logic for interpreting user interactions. For communication between the application and the BrailleDis, the BrailleIO framework^[7] [3] is used.

Figure 5

Architecture of the prototypical implementation of BigBlueButton [10].

If a user desires to switch the view to the activity protocol, a hardware key on the BrailleDis can be used. The BrailleIO framework recognizes that a key has been pressed and passes the event to the TactileBBB application. TactileBBB receives the event with the request to display the activity protocol view and switches to the module in BigBlueButton. TactileBBB then transfers the data for this view to the BrailleDis using BrailleIO. The user receives auditory feedback that the view has changed. As the filtering process can take some seconds, saved protocol information is displayed in order to support the user in perceiving the changes. Subsequently, the current data of the activity protocol is filtered using UIA and compared with the saved data. In case of changes, the new information is passed to the BrailleDis – and thus to the user – via the BrailleIO framework.

4.1 Sample

The sample consisted of ten blind subjects who were 17 to 53 years old, including four women and six men. Four subjects were experienced in the work with the BrailleDis due to previous evaluations and will thus be referred to as experts. Six subjects from senior classes in secondary school were familiar with tactile representations, but inexperienced with tactile two-dimensional displays and will subsequently be referenced as users. Five of the ten subjects were familiar with e-learning applications (e.g. learning management systems and chat applications), but no subject had used virtual classrooms or conference software before [14].

4.2 Methodology and Procedure

The study was structured as follows: A preliminary questionnaire was sent via e-mail, an introduction to the BrailleDis, the user test itself and a concluding questionnaire directly after the user test. The evaluation was executed with the functionality described above. The qualitative research was conducted with one subject at a time and a test supervisor on-site as well as another test supervisor in a remote location. The second test supervisor at the remote location possessed the double role of an additional participant and of the teacher (see Figure 6).

Figure 6

Experimental setup of the user test [14].

The initial introduction to the basic operation of virtual classrooms, the tactile user interface and interaction techniques was conducted using the evaluation method cognitive walkthrough (cf. [19]) in order to gain an impression how intuitive the user interface was. Due to the prototypical version of the application and the limited recognition of gesture input of the BrailleDis, restrictions concerning the functionality were substituted by interventions by the test supervisor using the wizard-of-oz method^[8] [5]. The evaluation was documented using audio recordings and videos of the subjects’ hands on the BrailleDis, the recording function of the virtual classroom as well as protocols of the test supervisors. In the following the two parts of the user test are described:

4.2.1 Part 1: Comparison of a Textual and Semi-graphical Output

A comparative test simulating similar course scenarios was performed to evidence an accessibility improvement due to the alternative concepts. The display of textual output of the activity protocol on the BrailleDis was compared to the semi-graphical representation of the complete user interface of the TactileBBB application. The main difference of the two representations lay in the removal of the navigation bar, the title area and the status bar for the textual display (see Figure 2). This representation matches almost the customary working techniques of blind users without having to use further assistive devices.

Figure 7

Comparison of the screenshots of textual and semi-graphical representation of the filtered virtual classroom showing activity protocol on the left and TactileBBB application on the right [14].

In the context of a course setting, the teacher explained a topic using speech, drew a hierarchical diagram on the whiteboard and posed questions in the chat. The subject was asked to follow the course as best as he/she could and to answer comprehension questions afterwards. At first, the textual representation of the activity protocol was used (see Figure 7, left), followed by the same course setting with a slightly adapted topic using the semi-graphical application (Figure 7, right).

4.3 Results

The results of both parts of the evaluation showed a high acceptance of the user interface and the proposed interaction concepts. The following sections describe the results in detail.

4.3.2 Results Concerning Interaction

The evaluation of the interaction comprised three use cases:

1. Raise the hand: Selection gesture on the tacton [h] in the status bar (Figure 2) or press of the hardware key [F4] (Figure 4).

2. Post a chat message: Switch to the chat module – selection gesture on the input field – composition of a message using the keyboard – post message using the enter key (Figure 3b).

3. Edit descriptions: Switch to the description module – selection gesture on a whiteboard element in the list – selection gesture on the input field – composition of a description using the keyboard – saving the description using the enter key (Figure 3d).

All three use cases were evaluated by the experts; the users each evaluated some of the use cases depending on the available time.^[10]

The operating steps for the composition of a chat message and for raising a hand were rated positively. The description view is the most complex view of the user interface and was thus judged as hard to use. Nevertheless, the operation steps for adding or editing a description were rated positively. The prototypical implementation of the description view comprised a list of whiteboard objects, a downsized representation of the whiteboard (minimap [18]) and an input field as well as three buttons (Figure 3d). Subjects wished for the highlighting of the selected list elements in the minimap. This linking is conceived in the concept but not yet implemented (cf. [12]). Therefore this concept was affirmed by the subjects.

Figure 8

Weighted representation of preferred views according to their perceived importance (1 most important, 3 rather unimportant) [14].

Figure 9

Responses to the question: “How did you like the control elements?” [14].

4.4 Discussion

Even the reading speed of the experts proved to be slower than the presentation speed. It is to be expected, that an increasing familiarity with the operation of the user interface and the elimination of usability and technical impediments will lead to a nearly synchronous perception of the content.

It was easier for blind users to follow the virtual classroom session when using the semi-graphical than with the textual representation. However, the activity protocol allowed perceiving a higher amount of detail information and chronology than using only the whiteboard view. Therefore, the views are equally important and should be applied alone or in combination according to user preferences and course type. The focus of the evaluation lay in the verification of the virtual classroom’s usability and accessibility; a continuative survey of collaborative activities would complete the findings. Furthermore, it could yet not be shown if the alternative concepts allowed for an improved understanding of semantic coherences between the different functions of the virtual classroom (cf. Table 1, question D). The not yet implemented concept to allow for a linking of related elements could increase this understanding.