Some background information about the Breakout Groups application

Our assignment was to write a Connect pod that implemented the concept of breakout groups. Currently, everyone in one Acrobat Connect Meeting sees the same thing. This is fine for most situations, but it's natively impossible to split participants into subgroups for discussions or brainstorming.

We were asked to implement a workflow with three phases:

• Phase 1: Participants are trickling into the meeting. The host is able to assign them to subgroups, although the participants aren't actually moved into them just yet. Our client already had predefined groups on the Acrobat Connect server, so we were asked specifically to make the pod access these groups and automatically assign participants as they entered, depending on their group memberships. The host must also specify how long the next phase will be. Once everyone is ready for the next phase...
• Phase 2: Participants are sent into their breakout groups. Each group, or "room," contains a rich text editor. One user in each group can take control of the room by clicking a button, cleverly labeled "Get Control"; the controlling user is able to make changes to the text document. Control can be released either by the controlling user or the host. No participant in one breakout group can see the activity in any other breakout group. When the time runs out, everyone proceeds to...
• Phase 3: In this last phase, all participants return to a home room, where there's a non-editable text editor. The host can choose which group's document to show, one at a time, and all participants in the meeting see the same document at once. If necessary, the host can send everyone back to the second phase for further brainstorming.

Overall design of the application

We decided from the start to implement the Model-View-Controller (MVC) architectural pattern. By dividing the application into several pieces with clearly delineated functional boundaries, it's easier to fix and improve individual pieces without destroying the others, and it's easier to work together as a team without stepping on one another's toes. MVC is pretty common in application development, so you might already know what it is, but here's a quick overview of what it can do and how we used it.

Model

We started by planning the model. In MVC, the model represents the application state data. For example, in an MVC implementation of a clock application, the model would store the current time. For us, this is what our model had to store:

• Each breakout group: its name, its members, the contents of the document being modified in its editor, and the participant in control
• The current phase of the application
• The discussion topic

View

Next, the views. The view is just the user interface. Views know what to display because they have a reference to the model. ActionScript lends itself particularly well to this, with its elaborate and flexible event-dispatching model. The view accepts user input, but doesn't really do anything with it. Instead, it leaves the decision-making and state operations up to the controller, which it alerts when some user action is performed. We wrote four view classes: one overall view class that contained a subview, and three subviews—only one of which could be displayed at once. Each subview corresponded to one of the three phases.

Controller

At long last, the almighty controller. The controller is responsible for deciding when and how to change the model. It can decide to do this for internal reasons—a clock's state might need to be changed every second—or for external ones, like user input—if the time is inaccurate and needs to be set manually, for example.

In our case, the controller was responsible for the following:

• Which subview to show to a user
• What to do when a user enters or leaves the application
• Automatically and manually assigning and reassigning users to specific groups
• Adding and removing groups
• Changing the amount of time remaining in the discussion
• Starting the discussion, ending the discussion—manually or when time runs out on its own
• Sending update messages to other instances of the application
• All messages incoming from all other instances of the application and what to do with the data

The controller is serious business.

Basu describes our implementations of the model and views in the next few pages; Raphael writes about the controller afterward.

Page 2 of 9

Previous Page

Next Page