By Bernard Horan
One of the goals of the +Spaces project is to prototype three applications in Open Wonderland (OWL) by which citizens can be engaged in policy discussion: polls, debates and role-play simulations. In the earlier blog posts, I focused on the way in which the applications appeared to users and the interaction features they provided. In this blog post, I provide a brief description of the other less visible features of the applications and the way in which, from an architectural standpoint, the applications are implemented in Open Wonderland.
The additional invisible responsibilities of each application are:
- to receive updates from the +Spaces middleware
- to communicate user actions to the +Spaces middleware
Each application is implemented as an OWL ‘cell’, packaged in an OWL module. However, there are some additional supporting modules that provide cells and other functionality used by the three applications. I’ll go through each application, beginning with the Polling Booth, and then briefly describe the other functionality before summarising our work.
The Polling Booth is the simplest of the applications and is implemented as a 2D cell. The client implementation is a 2D Swing application that displays the current users of the Polling Booth, along with metadata describing the poll, and a button by which the user may take the poll. The user interaction of voting in a poll is implemented as a heads-up-display (HUD) component—this is because the activity is private to the user (see Figure 1, below). The description of the poll, such as its title and sequence of questions, is represented as an instance of a Java class that takes the role of a data model, with no behaviour. The Java
Poll class is dependent on some other data-model-like classes such as
The server implementation of the Polling Booth cell acts as a gateway between the client implementation and the +Spaces middleware; thus it has two responsibilities: communication with the client and communication with the +Spaces middleware. The server communication with the client follows the regular OWL architecture, relying on subclasses of
CellMessage. However, server communication with the +Spaces middleware follows the example of the connectionsample module that relies on the use of a subclasses of
ResponseMessage and implementations of
The communication flow is as follows (and is common to all three +Spaces OWL applications):
- The +Spaces middleware creates a connection to the OWL server, and calls a method on the connection to set the data model of a cell (identified by its cell id) to be an instance of class
Poll. The connection sends a message (an instance of a subclass of
Message) to the OWL server and waits for a response.
- On the OWL server, the instance of (an implementation of
ClientConnectionHandler) receives the message. It then looks up the instance of
CellMOaccording to the cell id (via the method
CellManagerMO.getCell()), casts it to be of the correct class and calls a method to set its poll data model. The CellMO instance, in turn, sends an instance of (a subclass of)
CellMessageto its clients, causing the clients to update. Finally, the ClientConnectionHandler returns an instance of (a subclass of)
ResponseMessageto indicate if the operation to set the poll was a success.
- From the client, when the user interacts with the Polling Booth, the answers (and other actions) are sent from the Cell to the CellMO on the server via an instance of (a subclass of)
CellMessage. The Polling Booth CellMO then calls a method on the instance of (an implementation of)
ClientConnectionHandlerto send the user’s actions to the instance of (a subclass of)
BaseConnection, where it is received and passed on to the +Spaces middleware via a listener pattern.
The Debating Chamber application is also implemented as a cell, taking on two roles: it acts as a container for other elements of the chamber; and it presents a ‘carpet’ to the user on which he or she may express a vote.
When the CellMO that represents the Debating Chamber is inserted into the world, instances of other subclasses of
CellMO are added as its children, as shown above in Figure 2. These are:
- Two instances of
StickyNoteCellMO—these post-its are used to display the ‘statement’ and ‘description’ of the debate.
- An instance of
ModelCellMO—this is used to hold the 3D model of the chamber (the OWL auditorium model).
- An instance of
AudioRecorderCellMO—this is used to produce an audio recording of the debate (it adds the instance of the Debating Chamber
CellMOas a listener to be informed when a user terminates a recording).
- An instance of
SharedActionCellMO—this is used to render messages received from other virtual spaces such as Twitter and Facebook (this is based on the twitter viewer module that is in the OWL modules source code repository and rendered as a pigeon on the client).
- An instance of
LinkListCellMO—this is used to render the list of URLs that users may double-click on to open a browser. This cell is part of a new module that is based on the Sticky Note cell: it is rendered similarly, with a list replacing the text area.
The CellMO that represents the Debating Chamber maintains managed references to each of these children (except for the instances of
AudioRecorderCellMO). For example the Debating Chamber CellMO has a field labelled ‘debateDescriptionCellRef’ which is an instance of
ManagedReference<StickyNoteCellMO>. The references are used as follows:
- When the
setDebate()method is called on the Debating Chamber CellMO, it calls the method
setText()on each instance of StickyNoteCellMO, with the parameter representing the description or statement, appropriately. It also calls the method
setLinks()on the the instance of
LinkListCellMO, with a list of links (URL-displayname pairs). The result of these method calls is to update the display of the contents of the cells on the clients.
- From the client, when the user interacts with the Debating Chamber, the user votes are sent from the Cell to the CellMO on the server via an instance of (a subclass of)
CellMessage. From then on, the mechanism follows the same pattern as the Polling Booth.
- When the +Spaces middleware reports a comment from Twitter or Facebook, it is received as a Message by the implementation of
ClientConnectionHandlerassociated with the Debating Chamber CellMO. This, in turn, calls the method
notifySharedMessage()on the Debating Chamber CellMO, which then calls the method
addRecord()on the instance of
SharedActionCellMO, eventually causing the clients to display the contents of the comment.
In terms of its communication with the +Spaces middleware, the implementation of the Debating Chamber application follows the pattern set by the Polling Booth. That is, it reports user actions and receives comments from other virtual spaces via the OWL server.
The ‘Simulation Agora‘ is the name we give to the virtual space that hosts the role-playing simulation. It is the most complex of the applications and is also implemented as a cell, somewhat similar to the Debating Chamber. However, unlike the Debating Chamber it does not provide any direct user interaction features for 3D objects, and instead represents the floor of the agora (rendered as an EU flag) and provides a HUD control panel to a privileged user role by which the stages of the simulation can be managed.
Figure 3 illustrates some of the elements of the Simulation Agora and the HUD control panel that is accessible to the moderator (or any member of the admin user group).
The HUD control panel is implemented as a Swing tabbed pane. One of the tabs provides the moderator with the means to step forwards and backwards through the stages of a ‘template’ that describes activities of a role-play simulation (more information about the use of role-play templates is provided in an earlier blog posting). Each of the two templates is implemented in Java in the form of a (pseudo) state machine: as the moderator progresses the template from one stage to the next, the state machine calls methods on the CellMO that represents the Simulation Agora to insert and remove child cells and to update the state of those child cells. Without going into too much detail, the sequence of stages of the state machine are as follows:
- Meet Participants—this is the starting stage of the simulation
- Ice Breaker Vote—this is an optional stage, specified by the policy maker, in which participants may vote on a question related to the policy
- Ice Breaker Results—the results of the ice breaker vote are presented
- Assign Roles—the moderator assigns the participants to the roles described in the template
- Prepare Statements—the participants create a number of statements according to the description of their role (the number of statements is specified by the template)
- Read Statements—the participants read out their statements
- Mark & Group Statements—the participants and the moderator collaborate to group their statements and to assign votes to statements
- Present Results—the participants discuss the results of marking and grouping the statements
- Final Vote—if there was an ice-breaker vote, then the participants are given the opportunity to vote again to determine if their views on the policy have changed
- End Simulation—the results of the final vote are presented
The children of the cell that represents the Simulation Agora are:
- An instance of
PosterCellMO—this shows the current stage of the simulation by rendering an appropriate image. This cell remains visible at all times.
- An instance of a simulation carpet cell—this in turn has a child Poster cell that displays the question that the carpet is to be used to answer. The simulation carpet is used to capture the participants’ vote on the ice breaker vote and the final vote. It is added and removed as necessary by the state machine, in response to the moderator’s interaction with the HUD control panel.
- Two instances of
PosterCellMO—to present the results of the ice-breaker vote and final vote. The state machine adds these cells when appropriate and sets their contents to present the results of the preceding votes.
- A cell that is used by participants to add ‘statements’—this is a cell developed specifically for the project. It is a 2D cell, in which the client implementation is provided by a 2D Swing application that uses an instance of JDesktopPane. The cell is added as a child when the state machine is at the ‘Prepare Statements’ stage.
- Pairs of cells to represent each user role. Each role is associated with a poster cell describing the role, and next to it a ‘podium’ cell that acts as a place mark. The placemarks are used to enable the participants to jump to a description of their roles. These pairs are added at the ‘Assign Roles’ stage by the state machine.
- A cell to represent a countdown timer. This is added and removed when necessary by the state machine.
- A shared action cell, as described in the Debating Chamber application.
The CellMO that represents the Simulation Agora maintains references to the CellIDs of each of these children. For example the Simulation Agora CellMO has a field labelled ‘simulationDescriptionCellID’ which is a reference to the CellID of the instance of
PosterCellMO that displays the description of the simulation. The fields are used as follows:
- When the
setSimulation()method is called on the Simulation Agora CellMO, it follows more or less the same pattern as the Debating Chamber, except that it also retrieves the template identifier from the simulation and creates a new instance of the state machine that represents that template.
- When the moderator steps through the stages of the template, the CellIDs are used to identify the appropriate cells to delete or update, as described in the stages above.
- From the client, when the user interacts with the Simulation Agora, the user votes and statements are sent from the Cell to the CellMO on the server via an instance of (a subclass of)
CellMessage. From then on, the mechanism follows the same pattern as the Polling Booth and Debating Chamber.
- When the +Spaces middleware reports a comment from Twitter or Facebook, it follows the same pattern as the Debating Chamber.
The other two tabs on the HUD control panel enable the moderator to inform the server when ‘something interesting happens.’ That is, something worth noting by the data analysis service; for example, when a video recording of the session is replayed, viewers are able to jump to appropriate timestamps to view the users’ activities (and listen to their comments). This is implemented using the regular OWL architecture—a message from the Simulation Agora cell to the OWL server which is then forwarded to the +Spaces middleware. All other communication between the +Spaces middleware, the OWL server and the OWL clients is as described in the two applications above.
Other +Spaces Functionality
In addition to the cells that provide the functionality for the Polling Booth, Debating Chamber and Simulation Agora, we also implemented a module with some extra features:
- A means of reporting user activity to the +Spaces middleware:
- two users come in range of each other (implemented using a client plugin)
- a user ‘chats’ (using the text chat)
- a user is forcibly disconnected
- a user is forcibly muted
- a user logs in or logs out
- a user begins speaking
- a servlet which provides a means of capturing profile information about a user (which is then forwarded to the +Spaces middleware)
In summary, we have developed 19 OWL modules for the +Spaces project, the following of which have been (or will be) donated to the OWL source code repository:
- countdown timer
However, we could not have completed any of the Wonderland aspects of the +Spaces project without the use of many of the existing modules and the wonderful support of the OWL community. So, on behalf of the project, I’d like to express my thanks to all the member of the community.