There are usually two motivations for carrying out an evaluation. The first aims at demonstrating the advantages of a particular concept, idea or artefact and proving that the artefact is an improvement over what was previously available. The second motivation is to bring out the disadvantages of an artefact, with a view of identifying those aspects that require further work.
The example real-time Web conferencing application that has been developed is similar to many Web-based chat applications, although its novelty lies in providing users with a controlled pace of feedthrough. However, the main purpose for implementing the example
application was to demonstrate the practicality of the GtK notification server as an impedance matcher within the GtK framework.
It is often problematic to evaluate a toolkit or a framework embodied in code. If the aim of the evaluation is to show that the toolkit produces good applications, then multiple applications should be built, not once but several times. In addition, third party users should be involved in the process of building those applications. But none of these techniques have been employed here. Indeed, it would have been impractical to cover such an in-depth evaluation within the scope of this research.
The focus of this research lies on gaining a deep understanding of how applications can be built to provide a desirable temporal behaviour within a distributed collaborative setting and hence facilitate user cooperation. In order to meet this goal, the emphasis throughout this work has been on the architectural aspects of application building through a number of analytical studies.
The findings of those studies have enabled the development of the GtK framework that enables impedance matching. The conferencing application described through the rest of this chapter merely acts as an exemplar that demonstrates the feasibility of pace impedance matching in improving the temporal behaviour that user receives at the interface level.
9.2 Interface behaviour
This section describes the behaviour of the example real-time Web conferencing system from the users’ perspective. It provides a system walkthrough that analyses the visible parts of the user interface and shows how users interact with the different functionalities offered by the interface.
The conferencing application allows users to create conferences on several topics and launch discussion sessions with different participants at the same time. The discussion sessions are mainly held in real-time but late joiners can also catch up with any ongoing session. The application offers functionalities that are common to most Web-based chat systems. However, the novel feature of the conferencing application is its ability to enable users to interact with multiple conferences simultaneously while adjusting the pace of feedthrough to match the users’ rate of interests.
9.2.1 Connect to application
Like many Web-based chat applications, the nature of the interaction pushes towards the use of applets for maintaining conversations. Users connect to the conferencing application that runs on a server through an applet interface from any common Web browser.
A user launches a conference client by typing the correct URL on a Web browser. Following this action, a typical applet is downloaded on the user’s screen (figure 9.1).
Figure 9.1 Typical client applet
The Message area displays feedback information in response to users’ actions. For
instance, when a user first connects to the server, a message notifies her if the connection is successful or not.
9.2.2 Register with application
Let us assume that Jane has just launched a client applet on her screen. Jane registers with the conferencing application by first typing in her name in the User name field and then
clicking on the Connect button (figure 9.2).
Figure 9.2 User registration
If Jane is successful in registering with the server, she can proceed to create and join any conference. Note, if other users are already logged on to the system and created some
conferences prior to Jane’s registration, a list of the existing conferences would be displayed under the Conference List at this stage (see figure 9.3).
9.2.3 Create new conference
If Jane wants to create a new conference called JAVA, she simply has to type in the
conference name in the New Conference field and click on the Create button (figure 9.3).
The Conference List is subsequently updated and sent out to all the participants who are
logged on to the system.
Figure 9.3 Create new conference
9.2.4 Join conference
Jane joins a conference by first selecting its name from the Conference List and then
clicking on the Join button (figure 9.4).
A new window labelled with the conference name pops up on Jane’s screen followed by a welcome message “Hello Jane”, which is displayed on the ‘Users contribution’
area (figure 9.5). The lower ‘public chat’ text area accepts users input while the upper
‘Users contribution’ message area displays all the participants’ contributions to that
particular conference.
Figure 9.5 Pop-up conference window
Soon after Jane is active on the JAVA conference, Tom decides to join in. Jane
subsequently receives the message “Tom has just joined” which informs her of Tom’s
presence (figure 9.6).
9.2.5 Add contribution
Users can add their own contributions to a conference by typing in some text and clicking on the Send button. The contributions are then broadcast to all the participants logged on
9.2.6 Interact with multiple conferences
Users can participate in more than one conference simultaneously. For each conference, the user needs to select the conference name from the Conference List and then click
on the Join button (figure 9.4). A separate conference window pops up on the user’s
screen each time. Users may therefore receive several overlapping windows, each representing a particular conference contribution.
Figure 9.7 shows two overlapping conference windows for Tom, one representing the XML
conference and the other showing the JAVA conference. Although it appears that Tom is
active on both conferences, his focus in fact lies on a specific conference at any instance in time.
In any windowing system, the top-most window indicates the user’s focus as it has keyboard control. From this we can deduce that, Tom’s focus is on the XML conference,
given its window position. Hence, any new contributions to the XML conference are likely to
be of more interest to Tom. The JAVA conference window is instead in the background,
which implies that Tom only has a passive interest in the changes to that conference. A similar reasoning was applied when investigating potential scenarios for impedance matching in Chapter 7 (Section 7.5.2).
Figure 9.7 Overlapping conference windows
Tom therefore receives changes to the XML conference immediately after a new contribution
latency. Tom does not necessarily receive new contributions to the JAVA conference as
soon as they are sent out.
However, if Tom decides to shift his focus back to the JAVA conference or wants to catch
up on the thread of conversation going on there he simply has to click on the title bar of the
JAVA conference window at any time, to bring it into focus. This action immediately
increases the pace of feedthrough that Tom was getting for the JAVA conference.
Consequently, any outstanding contributions are displayed straightaway on Tom’s JAVA
conference window. Furthermore, Tom will receive new contributions to the JAVA
conference almost as soon as they are posted but any new contributions to the XML
conference will be communicated to him at a much lower pace. The implementation issues surrounding pace frequency are described in Section 9.4.
9.2.7 Leave conference
A user can leave a conference at any time by clicking on the Leave button on the
conference pop-up window (figure 9.8). After Jane leaves the JAVA conference, the
conference window closes on her screen. Shortly after, Tom and any other partcipants on the JAVA conference receive the message “Jane has just left” on their screen, which
informs them of Jane’s departure (figure 9.9).
Figure 9.8 Leave conference Figure 9.9 Notification of departure
9.2.8 Quit application
Users can quit the conferencing application by simply clicking on the “Quit” button on the
main window of the client applet (figure 9.1). This action closes down the applet window. Moreover, users do not have to explicitly leave the conferences they had joined before quitting the application. For example, if Jane quits the application before leaving the JAVA
conference, Tom and any other partcipants on the JAVA conference would still be informed
This section has demonstrated the behaviour of the example real-time Web conferencing application at run-time. It has also examined the effect of users’ simultaneous participation on multiple conferences and shown how the pace of feedthrough is adjusted to match their focus. The next section will now describe how the underlying GtK framework supports the application’s interface behaviour and assists in implementing its various functionalities.