![]() |
![]() |
|
![]() |
Maintaining Pedagogy while Changing Technology: ICONSnet1Presented at the Regional User Services Conference ICONS (the International Communication and Negotiation Simulations), an educational outreach program of the Department of Government and Politics at the University of Maryland, offers international relations simulations at both the university and high school levels. Students at a participating institution represent the decision makers of a selected country and negotiate solutions to global problems via the Internet with peers around the world. Each year, ICONS runs approximately 7 university-level and 5 high school level simulations, with an average of 15 teams per simulation. Since 1990, 162 universities and 129 secondary schools from 37 countries have participated in ICONS simulations. This paper will deal with the development of ICONS second-generation message exchange software package, ICONSnet, focusing on the reasons why ICONS chose not to rely upon commercial products to meet its needs and the ways in which the new software supports ICONS simulation methodology and pedagogy. In addition, it will explain how the unique features of ICONSnet support asynchronous and real-time message exchange with full archiving, making it useful for other applications, such as distance dialogues and virtual conferences. Background Although computers have been used in social science simulation since the 1960s, ICONS grew out of a type not originally associated with computers. These "all-human" simulations were free form in nature and aimed to capture more of the complexity and subtlety of international political issues through the use of fairly detailed scenarios, which focused on real or plausible policy problems. Unlike simulations that cast the computer in a central role, the decisions made by participants in these simulations were constrained not by the rigid input requirements of a computer model, but rather by judgments about what actions would be considered plausible in the "real world". Until the advent of computer-based communications networks, these simulations could be conducted only at single sites, limiting the number and diversity of the participants. Taking advantage of computer networks to facilitate communication among human participants at distant locations, Robert Noel and his associates at the University of California Santa Barbara developed specialized software to support multi-site interactions and began conducting distributed social science simulations in the early 1970s (the POLIS Foreign Policy Simulation). In these trials, involving schools linked through ARPANET, Noel discovered that the dynamics of the interactions among the participants were not distorted by the distributed nature of the exercise (Wilkenfeld and Kaufman, 1993). In fact, physical distance added a new dimension to traditional simulation exercises by bringing faculty and students from different schools and in different courses together in meaningful intellectual activities. A number of the POLIS system features made it particularly well-suited to support the educational needs of the simulation process: (1) support for simultaneous participation for up to 20 teams at distributed locations, (2) flexibility allowing it to work with a variety of different scenarios, (3) capability to process high volumes of information, allowing for classification, storage, and retrieval, and (4) support for simulation monitoring and control (Wilkenfeld, 1983). The ICONS Project was based upon Noel's POLIS simulations, and was founded in the early 1980s at the University of Maryland by Jonathan Wilkenfeld of the Department of Government and Politics and Richard Brecht of the Department of Germanic and Slavic Languages. The original POLIS software was enhanced and ported to the University of Maryland, where it ran on a PDP-11/44, and later on a Micro VAX II. The software, written in C, was redesigned in the mid-1980s (POLNET II), and was used until 1997. It ran on a DEC-Station 5000 in ULTRIX 4.2, with users maintaining a constant connection to the system through telnet. ICONS participants originally relied upon global commercial networks such as TELENET, and eventually, NSFNET and the Internet. While POLNET II met the needs of simulation participants, it was not user-friendly and required substantial training. By 1995, the World Wide Web and related technologies made it possible for ICONS to provide users with an easy-to-use interface, coupled with accessibility from any computer with an Internet connection and a web browser. After examining and testing some commercial packages, ICONS developed an entirely new software package, ICONSnet, that replicated and enhanced the essential features of POLNET II in a web-based database application. The remainder of this paper will focus upon the ICONSnet development process. Necessary Features Technical Requirements
Pedagogical Requirements
Evaluating Alternatives Since our primary need was for a mechanism to exchange messages among participants, we first considered using an e-mail package, but rejected that notion for a number of reasons. First, it would be impossible to maintain the anonymity of the teams. If an e-mail program were used, participants would have to know other participants' e-mail address or build a mail list to send messages to other teams. Participants represent countries, and as such, all message exchange is between country teams. Having to use a complete e-mail address, rather than communicating within a closed system, would undermine the mystique the negotiations had for the students. Second, because team members read their messages using different machines, the messages must reside on a server with access from a local machine. An e-mail application with preferences set with a POP server downloads all messages to a client machine unless it is specifically set to keep a copy in the server -- with obvious complications for team message management. An alternative would be to keep all messages on the server by using IMAP, but all clients machines would have to be set up to use an IMAP mail server. This would be difficult to assure since our participants log from multiple locations. In any event, search capabilities, which we consider to be an essential feature, were not available. We also considered commercial packages to handle our real-time conferencing requirements. Chat applications were an unacceptable alternative because most chat programs do not support message archiving and do not necessarily keep track of the specific sequence of messages. Furthermore, if a participant were to arrive late, he/she would miss the exchange of messages prior to his arrival and be lost tracking the negotiations. Finally, some participants with slower connections would not be able to send as many messages as participants with better equipment, and participants using English as a second language might find it difficult to keep up with the speed of messages scrolling across the screen. Another alternative for conferencing was a conferencing package. A program like Microsoft NetMeeting would overcome several of the difficulties associated with chat program, and would also enable participants to send both public and private messages, a necessary feature.2 However, we determined that NetMeeting and similar programs would not be a good choice for us because it could not be seamlessly integrated with a message exchange system and would require participants to install and configure an application on their local computers Our most extensive investigation was into the use of groupware. During Summer 1996, we ran a trial simulation using Lotus Notes 4.1, a groupware program that runs on a local area network with available remote access over the Internet, with a group of students participating in the ICONS-sponsored Maryland Summer Center for International Studies. We chose Notes because it would allow users to share a common database of information (while permitting differential access for the different country-teams) and allow connections from different hardware platforms. However, our experiences led us to believe that this particular program would not be a viable solution for us.
Based upon our experiences, we made the determination to develop a customized product because that was the only way that we could guarantee that the application be fully supportive of our pedagogical needs. Further, we decided to make our system web-deliverable because the only software requirement on the user end would be a web browser. In our technology survey in 1995, we had found that 87 percent of our university users and 64 percent of our high school users were currently able to access the WWW. Noting the rapid development of the web at the time, we expected that this number would only grow. ICONSnet Development During the busiest period of a semester there may be as many as 12 separate simulations running concurrently, with 4-8 on-line conferences (150-300 messages per conference) each day and as many as 750 regular mail messages exchanged daily. The software must be able to support multiple on-line conferences as well as regular message exchange. Especially during the real-time conferences, the access time to retrieve and send messages is critical for the negotiation process; this must not be affected by other simulation activities. ICONS chose Oracle because of its reliability in handling large databases, and because at the time we were deciding among alternatives, Oracle was the only company to offer a web server application that connected directly with the database. Since time was of the essence and resources were limited, priority was given to the ability to develop a user interface that ran on the server side without having to build the software to connect from a web application to the database. Oracle Web Application server makes the connection between a web based application and the database transparent. An Oracle cartridge uses the HTTP communication protocol and is a shared library that either implements or accesses application logic stored in an Oracle database. ICONSnet is built upon the PL/SQL and Jweb web cartridges. The application logic is written in Oracles proprietary language PL/SQL, which allows the addition of complexity to standard ANSI SQL statements with the packages stored directly in the database. ICONSnet is written as a series of PL/SQL packages. It was developed during Fall 1996 and Spring 1997, pilot tested in Spring and Summer 1997, and fully implemented in Fall 1997. It underwent a major revision in 1998. (In addition, we make regular modifications to respond to user input and to upgrade to new versions of Oracle tools.) When using the ICONSnet system, participants input data into a series of customized forms which allows them to submit data to the database (e.g., sending messages either asynchronously or in a conference) or request data from the database (e.g., reading new messages, reading conference messages, or accessing the archives). Design Attributes In making design decisions, we were guided by our experience and desire to meet specific pedagogical goals, and incorporated features that we thought were particularly useful within the POLNET II system. Of course, the differences between a file structure program and a web-based database application meant that we had to try to achieve the same outcome using completely different means. The benefit of the latter, though, is that it allowed us to add a number of enhancements to make the system much more intuitive and easy to access. Support for Different Users ICONSnet supports the role of the simulation controller (Simcon), an ICONS staff member who provides administrative and educational oversight and guidance for each simulation. Simcon automatically receives all messages (public and private) and has access to all conferences. In addition, Simcon can utilize administrative functions, allowing her to review passwords, delete messages, add conferences, add participants, and run reports showing the level of participation of each country-team. Simcon can also set up simulation "issues", which are the primary topics for negotiation in a simulation, such as human rights or arms control. Simcon establishes these before the simulation begins to allow for categorization of messages by topic. (Teams are not allowed to add new issues, to keep the list manageable, but they can attach an optional "subject" to each of their messages.) Flexibility was the primary concern in making decisions about support for regular participants, who make up the vast majority of ICONSnet users. In most cases, the login accounts are used by a team of users, such as a group of students at the University of Maryland representing Brazil.4 When reading new messages, participants can choose to read them all, to read specific messages, or to read messages by issue. (See Figure 2.) The latter option is particularly useful for team message management because individual team members can access and respond to messages that correspond to their area of expertise. In addition, users can determine when they wish to leave messages in their new message queue and when they want to archive them. Flexibility was also a consideration in designing the archives, so that participants would be able to quickly and easily access any simulation message according to a number of different criteria. For evaluation purposes, the archives are "opened up"at the end of a simulation, giving regular participants access to all simulation messages. ICONSnet has a special set of functions for translators, in order to facilitate the use of languages other than English during a simulation. If a team does not have foreign language capability "in-house," ICONS staff can set up a translator path between a team which is sending in a foreign language and a team wishing to receive translations. ICONSnet automatically sends the translator team all messages that require translation based on the translator paths. When the translation is to be sent, the translator receives a form that automatically selects the message recipients and issue, and contains a link back to the original message. (ICONSnet can support any number of translation teams during a simulation.) The inclusion of observers in a simulation is useful for giving access to all simulation interactions to parties that are not direct participants. These may be current faculty members, potential future participants, or researchers. Observers can "see all," but they differ from Simcon users in that they do not have access to administrative functions, and remain hidden from regular participants. (For example, observers do not show up as potential message recipients on the "Send Message" screen.) Finally, for pedagogical reasons, we included the capability to utilize control teams in any simulation. Control teams appear to be regular simulation participants, but work closely with Simcon to advance the educational goals of the simulation. For example, in high school simulations, the U.S. is often played by graduate students who aim to provide a model for how to negotiate and "raise the level" of the negotiations. The difference between a control team user and a regular participant is that messages between control teams and Simcon users stay private even when the simulation archives are opened up to general examination at the end of a simulation. Meeting Program Requirements
Conclusion ICONS decision to develop a customized application in Oracle, has also opened the doors to build more tools to support the simulation activity and special projects. ICONS has developed a team research web page, using PL/SQL and Java, for students to include links that they collect as they conduct research on their assigned country. This enhances teamwork during the research preparation phase of the simulation. In addition, the use of the Oracle database has allowed the project to quickly develop on-line evaluation questionnaires and registration forms. While we will continue to evaluate new software, we will add only those features to ICONSnet that enhance the learning experience and the ease of use for participants. A longtime participant in Argentina who registered for the Spring 1999 simulation after a hiatus of several years humorously compared the difference between ICONSnet and our old POLNET II software to seeing "Star Wars" after George Mélièss 1902 "Le voyage dans la lune". While clearly an overstatement, we do believe that we have made a considerable advancement. Our development of the ICONSnet system has allowed us to maintain the essential features of our simulation pedagogy, while using technology advances to make the simulation experience better for our participants. Endnotes 2. Many conferencing applications allow for whiteboarding. We considered this as a program enhancement (for example, to simulate a treaty drafting meeting), but an experiment with TalkShow convinced us that whiteboarding would be unworkable with more than a few participants. 3. Cost was also a consideration. Using Lotus Notes would have required us to purchase a license for each individual team participating in a simulation. 4. Some of our simulation communities do contain individual users. For example, each simulation has a complementary "faculty community" where instructors of the participating student teams can communicate with each other about what is happening during the simulation. 5. This was also important because of concern for accessibility for disabled users. 6. The researchers used ICONSnet to hold meetings between the times when they could meet face-to-face. They report that the most important benefit was that all interactions were archived, which allowed them to avoid arguments over remembering things differently. References Wilkenfeld, Jonathan and Joyce Kaufman. 1993. "Political Science: Network Simulation in International Politics." Social Science Computer Review. 11:4 (Winter). Pp. 464-476. |
|
| About ICONS | Participant
Resources | Current Simulations | ICONS is located at the University of Maryland. For more information, please contact icons@gvpt.umd.edu. Copyright 1999, Project ICONS, University of Maryland |
||