Facebook Group Integration Module

September 24, 2012

By Shaya Pourmirza

This module has been created for communication between a Facebook group and Open Wonderland as part of my masters thesis project at the University of Essex. With this module, users can post comments in a 2D Facebook group and have them dynamically show up within an Open Wonderland world. Additionally, users in the Wonderland world can start new discussions or add comments to existing Facebook discussion threads from in-world.

To support this functionality, each Facebook group integrated with Wonderland has a Facebook Application as an intermediate layer. In this example, I have created a 2D Facebook application (http://shoopi.appspot.com) and deployed it on the Google App Engine. The functionality of this application is described below.

Authentication and Authorization

Before a user can set up a Facebook viewing window in Wonderland, they must use the intermediate Facebook application to generate an Access Token.

Access Token

They can then copy this Access Token from the Facebook application and paste it into a dialog box in the Wonderland world to authorize the Wonderland Facebook code to access Facebook. This step only needs to be done once by an administrator. All other Wonderland users can then see the Facebook discussions in-world.  The 2D Facebook application uses Facebook’s new authentication method which is based on Access Token and OAuth 2.0. (For more information, see Facebook’s Server-Side Authentication documentation.)

Retrieving Data From a Facebook Group

Once the admin user has entered their Access Code in Wonderland, Facebook viewing windows can be opened in-world. These windows can show discussions in private Facebook groups that the authenticated admin user has access to, or they can show discussions in any public Facebook groups.  The Facebook viewing windows are based on the Wonderland HTML Poster module, so all links in these windows are live. There is one Facebook viewing window per Facebook discussion group.

Creating a New Discussion

To open a new Facebook viewing window in Wonderland with an entirely new discussion thread, the user can click on the “Add a New Discussion” link in an existing Facebook viewing window. This launches a New Discussion entry form in an external web browser window.

Create a New Discussion

Once this initial post is created, any in-world or 2D user can add a comment to the discussion.

Adding a New Comment

In-world users add comments to an existing discussion by clicking on the “Click here to add new Comment” link in the appropriate Facebook viewing window. This launches an external browser window. Users are taken to an Authentication Servlet web page. If they have not already logged into Facebook, they will be asked to do so. Once logged in, they are provided with an Access Token.  Users must copy this token and then proceed to the next screen where they can enter their comment and paste in the token. When they click the “New Comment” button to submit their comment, it simultaneously shows up in both the 2D Facebook group and in one of the Facebook viewing windows in the 3D world.

Demo Video

The following video was captured from a user trial session.

It illustrates the procedure of adding two comments from the 3D world into a Facebook group. Since these comments were added at the same time, only one of them will be shown step by step. Finally, participants were asked to fill in a usability questionnaire. The results indicated that users appreciated this new Open Wonderland feature.

Source Code

If you are interested in looking at the code for this module, I have made a zip bundle available on Google Drive:

Facebook Integration Module Source (.zip)

Select “Download” from the File menu to download the complete bundle.

Advertisements

Wonderland Showcase – iED Boston 2012

July 13, 2012

By Nicole Yankelovich

At that Immersive Education conference in Boston last month, eight Open Wonderland community members from 6 different countries joined me remotely to show off their work. Here’s a brief summary of the worlds and features presented during the showcase. In all cases, the presenters have agreed to leave their spaces running on the community server. If you missed the conference, you can explore the spaces on your own. Simply log on to the community server and use the Placemarks menu to navigate to the different spaces.

WonderBuilders Outpatient Clinic

I began the session by showing one of the simulated medical spaces created by my company WonderBuilders.

WonderBuilders Outpatient Clinic

WonderBuilders Outpatient Clinic

This virtual outpatient clinic is designed for communications skills training. Each of our virtual clinical spaces comes with a soundproof observation room with one-way windows so that instructors and others can observe students during role-playing scenarios. This space also features a non-player character that speaks, a poster with links to different portions of the space, an App Frame for organizing documents, and pop-up questions using a modified version of the Sheet Suite developed jointly by WonderBuilders and the University of Missouri.

+Spaces

Michael Gardner from the University of Essex talked about the +Spaces (pronounced “positive spaces”) EU-funded project aimed at engaging citizens in policy-making. Michael showed excerpts from this role-play video:

To learn more about the use of role playing in the +Spaces project, as well as the Wonderland modules developed as part of this project, see these previous WonderBlog articles or search the blog for articles by “Bernard Horan.”

Entrepreneur Space

Johanna Pirker from Graz University in Austria took us on a tour of the space she created for teaching entrepreneurship.

Entrepreneur Space

Entrepreneur Space from Graz University

This space includes an informal area for students to get to know one another, an area for presentations, and a work area where students, mentors, and instructors can collaborate.

WonderSchool

Roland Sassen demonstrated WonderSchool, an on-line school that takes advantage of Wonderland’s ability to run shared applications within the virtual world.

WonderSchool

WonderSchool with the Alice programming environment.

Roland demonstrated how he can teach students to use complex software such as the Alice programming environment from within the virtual world. He also demonstrated other dynamic applications running remotely inside a VNC Viewer window.

Seekers School Maze

Chris Derr, head of the Seekers School, talked about using Wonderland in his innovative curriculum to motivate kids who have had difficulty in other school situations.

Seeker School student activities

Seeker School student activities

The students spent the past semester learning how to build Open Wonderland worlds, including making their own 3D models in SketchUp and creating simple animations using Wonderland’s EZScript capability. Among other things, the students created a fun maze, mountain climbing challenges, and a colorful spinning roof.

iSocial

Ryan Babiuch from the University of Missouri iSocial project showed one of the many learning spaces used as part of their curriculum for remotely teaching social competency skills to students with autism spectrum disorders.

iSocial

iSocial space used in teaching students with autism.

This curriculum was pilot tested this past semester in two schools. While the data has not yet been fully analyzed, the initial results were extremely positive.

ImmerHire

Michel Denis and Gery Winkler from ImmerHire showed the Survival on the Moon space they use to help assess logical thinking skills.

ImmerHire - Assessing Logical Thinking

ImmerHire – Assessing logical thinking in the Survival on the Moon scenario.

The ImmerHire environment is intended to help employers evaluate communication, personal, and social skills of job applicants using a range of virtual role-play activities.

STCC Virtual Campus

Kristy Perry, an English-as-a-second-language (ESL) professor at Springfield Technical Community College, showed one of the spaces she designed on the STCC Virtual Campus.

STCC Virtual Campus - patio

STCC Virtual Campus – patio

This patio space is intended as a venue for small group projects and conversation practice. The STCC Virtual Campus will be deployed for Level 2 ESL students starting in September.

Wonderland Wednesday Projects

Jonathan Kaplan, our Wonderland architect, demonstrated the three Wonderland Wednesday community projects that he has lead. These projects – Telepointers, EZMove, and Subsnapshot Import/Export – were all developed collaboratively on the Open Wonderland community server. In the weekly Wonderland Wednesday meetings, developers worked together using NetBeans and other shared applications.

Telepointer demonstration

Telepointer demonstration

The new Telepointers are considerably more aesthetically appealing than the old telepointers. More importantly, they now work when you have control of a 2D application. For multi-user applications such as the Whiteboard, this is particularly helpful as it allows users to see where everyone else is working.

Be sure to visit the community server to see these spaces and try out the set of Wonderland Wednesday features.


Summary of +Spaces Development in Wonderland

July 10, 2012

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.

Polling Booth

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 BinaryPollQuestion, and FreeTextAnswer.

Figure 1: +Spaces Polling Booth

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 App2DCellClientState, App2DCellServerState and CellMessage. However, server communication with the +Spaces middleware follows the example of the connectionsample module that relies on the use of a subclasses of BaseConnection, Message and ResponseMessage and implementations of ServerPlugin and ClientConnectionHandler.

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 CellMO according 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) CellMessage to its clients, causing the clients to update. Finally, the ClientConnectionHandler returns an instance of (a subclass of) ResponseMessage to 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) ClientConnectionHandler to 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.

Debating Chamber

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.

Figure 2: +Spaces Debating Chamber

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 CellMO as 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 ModelCellMO and 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 ClientConnectionHandler associated 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.

Simulation Agora

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: +Spaces Simulation Agora

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:

  1. Meet Participants—this is the starting stage of the simulation
  2. 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
  3. Ice Breaker Results—the results of the ice breaker vote are presented
  4. Assign Roles—the moderator assigns the participants to the roles described in the template
  5. 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)
  6. Read Statements—the participants read out their statements
  7. Mark & Group Statements—the participants and the moderator collaborate to group their statements and to assign votes to statements
  8. Present Results—the participants discuss the results of marking and grouping the statements
  9. 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
  10. 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)

Summary

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
  • office-converter
  • postercontrol
  • tightvnccontrol
  • twitter
  • webcamcontrol
  • webcaster

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.


Wonderland Webcaster, part two

May 14, 2012

By Bernard Horan

Some time ago, I described work on an Open Wonderland webcaster that had been undertaken by one of our students at the University of Essex. One of the motivations behind the Webcaster was to provide access to those users who merely want to observe (and listen to) the activities in an Open Wonderland (OWL) virtual world instead of actively participating. In particular, we wanted to enable access to a set of users in the +Spaces project, such as policy makers, who wish to watch a session in which a policy is debated or acted out in a role play simulation and not be able to influence the session.

Since the first video-only version of the Webcaster, we’ve experimented with several different approaches to extend the Webcaster to provide audio, one of which is described below. After several unsuccessful attempts, we now have a successful prototype implementation that combines the video broadcast functionality with an existing OWL virtual phone object to provide a unified audio-video webcast.

The video above shows the OWL webcaster being used by two clients.

  • One client is a regular OWL webstart client, into which a Webcaster ‘object’ has been inserted.
  • The other client is a Web Browser that has two standard plugins: Flash and Java. The Browser opens a URL (provided by the Webcaster) hosted on the OWL web server and downloads the HTML content. The content includes a Flash object and a Java applet. (The Java applet is provided by doddlephone–a web-based SIP client.)

The deployment requirements are as follows:

  • The SIP client requires that authentication is enabled on the OWL server
  • The following ports must be open on the server host (and accessible through a firewall): 5080 and 1935.

The Webcaster requires further testing with more concurrent users before release to the OWL module warehouse–we’ll post a message on the forum when it’s ready. However, as ever, the source code is available in the unstable directory of the wonderland-modules SVN repository.

Technical Details

In this section I’ll briefly describe the video-only webcaster, the failed experiment at combining audio and video, and an idea for how the current implementation could be improved.

1. Video-only Webcaster

The video functionality of the webcaster requires a full OWL client to capture the graphics rendered by the in-world webcaster ‘camera’. The captured graphics are transmitted to a Red5 RTMP Server that is likely running on the same host as the OWL server. From there, lightweight clients can connect to receive a Flash ‘stream’ to play in a Flash player (or Web browser plugin). In this case, the firewall has to be configured to enable the OWL client to transmit graphics to the Red5 server, as well as for Flash clients to stream from the Red5 server. This architecture is represented by Figure 1 below.

Architecture for Video-only Webcaster

Figure 1

2. Combining Audio & Video on the OWL Client

The OWL Client receives audio from the voicebridge that it plays through the client’s audio-out drivers, such as its speakers or a headset. The audio it receives is attenuated/spatialised according to the location of the avatar that is associated with the user of the OWL client, but does not include the audio from the microphone connected to the hardware on which the OWL client is running.

Our attempt to combine audio and video on the client first required us to mix the audio from the voicebridge with the audio from the client microphone and then combine that with the captured graphics, before sending it on to the Red5 server. From that point, the Flash clients would be ignorant of the change in architecture and would receive a combined audio/video ‘stream’ to play. This architecture is represented in Figure 2 below.

Figure 2

However, this approach failed due to several problems, including:

  • The audio was received from the perspective of the avatar of the user associated with the client, NOT from the perspective of the webcaster object in the virtual world.
  • The frequency of the received audio could be changed by the user, which made mixing with the audio from the microphone unstable.
  • The extra processing that was required on the OWL client to mix the audio and then combine with the graphics was significant.

Thus, this approach was abandoned as infeasible. An alternative approach: to mix the audio on the voicebridge before sending to the OWL client was also considered. This suffered from the drawback that there was no existing mechanism to send the mixed audio to the OWL client–it would have required an additional connection through a firewall. Again, this was abandoned due the problems of managing ad hoc connections.

3. An Alternative Approach?

The current approach works around the audio problem by using an existing virtual phone object. However, we recognise that it is less than an elegant solution–we would still like to be able to provide a combined audio and video Flash stream to Web Browser clients. Ideally, we’d like the architecture as illustrated in Figure 3. Here the  video is sent from an OWL client to the Red5 server where it is mixed with the spatialised audio that comes from the voicebridge, from the perspective of the webcaster. We have no idea if this would be possible, as it requires expertise in developing Red5 applications. However, if any readers would like to take this on as an experiment, please reply via a comment below. Or, if you have experience of Red5 and think this is a daft idea, let us know via the comments!

Figure 3


Role-play Simulations in Wonderland

May 7, 2012

By Bernard Horan & Michael Gardner

In earlier blog postings about the +Spaces project, Bernard described how we were using Open Wonderland (OWL) to host polls and debates, so that citizens could express their views on potential government policies. In this posting, we will describe another mechanism to encourage citizens to engage in the policy-making process: role-play simulations.

Role-play has been used for many purposes such as predicting outcomes, war-gaming, team building, and training. It has been particularly useful as a teaching tool in the classroom, allowing students to act out and experience some of the dynamics of a particular problem or issue, from different stakeholder perspectives. Aspects of role-play have also been used in online environments such as virtual theatre, gaming, and focused discussion forums. Role-play simulations in virtual worlds have often been labelled as ‘serious games’, often used where it would be too dangerous or too costly to attempt the activity in a real-world setting. Examples include safety training on oil rigs, and educating paramedics.

Many of the examples of role-play simulations are custom-built virtual worlds (such as the examples above). However, one of the requirements of the +Spaces project is to come up with an abstract description of role-play simulations that could be used in multiple policy domains, so that the +Spaces functionality could be used to address policies across a range of domains.

Building on the success of role-playing in the education, we have adapted resources from the Australian Flexible Learning Framework to develop two role-playing templates for use on the +Spaces platform. These are:

  • Galactic wormhole: participants imagine themselves to be five years in the future and reflect on positive and negative outcomes of a particular policy
  • Depolarizer: structured game based on the philosophy that many issues that we treat as problems to be solved are actually polarities to be managed

The idea is that users can consider the consequences of a proposed policy through a role-play simulation. An online moderator facilitates the session, assigning users to roles specific to the role-play. The users are then guided through the stages of the role-play simulation by the moderator. The template can be instantiated with a description of the policy, useful web links, descriptions of roles, and questions to be answered by the participants.

We implemented the two templates in OWL, and the video below shows a much-shortened version of the first trial that took place recently, using an instantiated Depolarizer template. You’ll see that the moderator (Michael) has a control panel from which he can step through the stages in the template, whereas participants (such as Bernard) do not have access to the control panel. The other users in the trial were students from the University of Essex.

(For brevity’s sake, the video focuses on the steps in the template and omits user participation. A fuller version of the trial is provided below.)

The purpose of the trial was twofold:

  • to test the ‘process’–i.e. to ensure that the users felt that they understood how to participate
  • to test the functionality of the modules we had developed for OWL

The results of the trial were broadly positive:

  • The participants felt that the process worked very well. They thought that it was clear what they were meant to be doing at each stage.
  • They particularly liked the icebreaker stage as a way of getting into the subject. The carpet vote also worked well.
  • Some of them preferred the experience of the role-play to their experience of taking part in the previous OWL debate pilot. Because the process was much more structured they felt it was easier to follow than the debate – it was easier for the users to participate in the activities because they had a clear idea of what they should be doing at each stage – they felt that they could participate more easily.
  • Although the Depolarizer is quite a simple role-play compared to the Galactic Wormhole, they all found the optimist/pessimist roles to be very easy to get into.
  • The functionality of the simulation worked well, although there were some issues with the size of the statements on the “statement wall” and the location of some of the elements of the virtual world.

Videos are also available that provide an (edited) full-length version of the trial, as well as a (very short) video of the OWL features that we implemented. We’d be really interested in your responses to this approach to simulation and also other possible applications, such as directed learning.


SIPping Wonderland

April 6, 2012

By Bernard Horan

One of the great features of Open Wonderland is its telephony support. In this blog post, I provide a few examples of standard VOIP clients that use SIP to call into an Open Wonderland server. It may seem odd to use an impoverished audio connection to a rich immersive 3d environment, but there are many occasions when users wish to participate in meetings from locations or using devices that are not able to provide the full Open Wonderland experience.

In the video below, I show some examples of how to use two of the many SIP clients to call into an Open Wonderland server. The first of these, Jitsi, is an open-source Java-based client that can be used on a regular desktop/laptop. The second client, 3CX, is available for iPhone (iOS) and Android platforms. The video provides three examples:

  1. Using Jitsi to connect, registrar-less, to an Open Wonderland server running on a local network
  2. Using Jitsi to connect, authenticated, to an Open Wonderland server running on a host on the public internet
  3. Using 3CX installed on an iPad to connect, authenticated, to the same server as in (2). (The settings for the 3CX client are provided at the end of this post.)

These examples augment the existing video that shows how to use a virtual phone to call out via a PBX. There is nothing special about the Open Wonderland installations that I’m using for the demonstrations. The only requirement before producing the examples was to insert a Virtual Phone into the virtual world using the standard ‘Insert Object…’ dialogue. In detail:

  1. The first example uses a source build (rev 4820) of Open Wonderland, with no authentication enabled, running on my home local network.
  2. The second and third examples both use a binary installation (rev 4816) of Open Wonderland, with authentication enabled. The installation is hosted on a public internet-facing server at the University of Essex that has its firewall configured according the the Open Wonderland firewall instructions.

Many thanks to Morris Ford for his guidance on using SIP.

For information about the settings I used to connect the 3CX client, see the figure below.

3cx-Settings


Debating in Wonderland

March 16, 2012

By Bernard Horan

In an earlier blog posting about the +Spaces project, I described how we were using Wonderland to host polls for users to express their opinions about proposed governmental policies. In the next stage of the project, we have taken a look at another way of engaging citizens: debates. The video below is a very shortened version of a test debate that took place in the middle of February 2012. The participants were students from the University of Essex in the UK, along with project partners from the National Technical University of Athens (NTUA) and the Hellenic Parliament. The debate is fairly formal: it has a fixed time slot, a moderator (in this case a researcher from NTUA) and participants who are asked to comment on a particular topic under discussion, suggested by someone taking the role of a policy maker (a representative of the Hellenic Parliament).

You can see from the video, that we’ve developed a couple of extra modules to enable the debate. These are:

  • a ‘carpet’ in which participants can vote, by pressing a button,
  • a ‘pigeon’ that displays messages arriving from other virtual ‘spaces’ (in our case Facebook and Twitter) that are also hosting the debate,
  • a ‘list of links’ with URLs relevant to the topic under discussion.

The debate uses existing Wonderland modules such as the Sticky Note and the Audio Recorder. (Unfortunately, the audio at the beginning of the video is poor due to a high latency wireless connection, it improves once we were able to patch the recording from the audio recorder into the video.)

The feedback we received from the participants was positive. Generally, they really liked the ‘carpet’, but there was some discussion about whether or not users’ names should be displayed on the poles that represent votes. Some valued anonymity, and others wanted to know who had voted for or against.

In the next stage of the project, we are looking at using Wonderland to host role-play simulations of policies. We hope to complete that by Summer 2012.


%d bloggers like this: