ICONS logo pix10.gif (815 bytes) International Communication and Negotiation Simulations

University of Maryland logo

ICONS Image Map (Alternative links at end of document)

Maintaining Pedagogy while Changing Technology: ICONSnet1

Presented at the Regional User Services Conference
April 16, 1999
University of Maryland University College
College Park, Maryland

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
Simulation refers to the process of developing models of a real world environment, allowing participants to make decisions within the constraints of those models and to see what the results of their actions are. In effect, simulations in the social sciences function much as laboratories do in the natural sciences. As such, simulations of international relations can be conducted either as an experimental tool to help scholars develop theories of decision-making or as an educational tool to help participants learn how to apply decision-making theory. Although ICONS owes much to the former tradition, it is essentially an educational program. The increasing popularity of ICONS simulations stems from a number of trends in both secondary and higher education: (1) providing for more interdisciplinary approaches to education, (2) "internationalizing" the curriculum, (3) providing active learning exercises to supplement traditional lectures, and (4) allowing students to work collaboratively and take some responsibility for their own learning (Wilkenfeld and Kaufman, 1993). A significant benefit of using simulations in education is the high level of enthusiasm on the part of the participating students.

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
ICONS’ experience with POLNET II helped to frame expectations about the features necessary for any follow-on product. The requirements were driven by both technical and pedagogical considerations. (Although our pedagogical considerations centered around the use of the system specifically for foreign policy negotiation simulations, many of the features are useful for broader applications.)

Technical Requirements

  • Ease of access: Any application had to be accessible from any computer with Internet access, with minimal additional software requirements. A given simulation may contain as many as 20 teams, with as many as 30 students on each team. Because many ICONS participants are likely to have access to multiple computers (e.g., in classrooms, in computers labs, at home), it was important that participants be able to easily access a system without worrying about complicated configurations, or differences in platform
  • Design for "lowest common denominator": Many participating schools are located outside the U.S., in countries where Internet connections are slow and equipment is outdated. Old computers are also a fact of life in many American secondary schools. The lack of the latest technology should not prevent a school from participating, although we realized that there would have to be a "floor".
  • Minimal training time: Given the number and diversity of participants, as well as the fact that we could not personally train all participating classes, we needed an application interface that was easy to understand and use without extensive training time. Ideally, the technology would become transparent and students would focus on the substance of their interactions with their peers.
  • Integration: POLNET II supported all simulation functions within one package. We wanted to offer our participants the same convenience with any new application.

Pedagogical Requirements

  • Team anonymity (i.e., no identification by address): Participants in ICONS simulations are identified only by the country the team represents, and their actual identities are not revealed until the end of the simulation to enhance the realism of the simulation. As a result, the students are able to focus on their negotiating partners as diplomats, rather than fellow students, and can make judgments about the others based solely upon the quality of the negotiation.
  • Team message management: Because ICONS is a team activity, team members are not individually identified. For this reason, a team, composed of as many as 30 students, logs in to the system using just one account. (Teams are generally divided into subgroups to handle different issues under negotiation, but can only send messages as the country they represent.) The new system had to ensure that teams would be able to manage their messages (i.e., read and respond to them) without letting any fall through the cracks, even if team members were working from different workstations.
  • Dual modes of communication: Although most of the simulation is conducted through asynchronous message exchange (which simulates day-to-day diplomatic exchanges), real-time conferencing is a crucial part of the process. Conferencing simulates summit meetings among heads-of state, and is an important motivational activity because students find it to be stimulating and exciting to be in real-time contact with peers around the world.
  • Archiving: An application had to support easy search and retrieval of both messages exchanged and real-time conference transcripts. This is necessary for team message management, as well as review of the interactions both during and after the simulation by students, instructors, and researchers who wish to evaluate performance.
  • Support for foreign language translations: The use of foreign language in international negotiations has been an important component of the ICONS’ simulations since their inception because it allows for even more realism in the simulation foreign policy environment. An application had to facilitate the work of translator teams (usually composed of foreign language students), who would provide translation services for teams that did not have capability for foreign languages being used during the simulation.

Evaluating Alternatives
In 1995, when ICONS began to evaluate possible strategies for replacing the POLNET II system, we conducted a technology survey of our current participants to assess their current capabilities and preferences for a new system. The primary concern expressed by our users was that changes should not be made just to "jazz" things up, but should directly support the educational mission of the program. Although we did discuss the inclusion of sound and video at some time in the future, we had ruled out including either of these as part of our central activities. A trial with CU-SeeMe in 1994 had convinced us that video actually detracted from the educational value of the simulation by allowing students to see each other as students rather than diplomats, and by reducing the emphasis on crafting clear, well-written statements of policy. We determined that sound and video would be most appropriate for delivering supplemental educational materials and for conducting group debriefing sessions, where students focus on the lessons learned during the simulation. In this process, we considered other commercial alternatives, specifically e-mail, chat, conferencing, and groupware applications, which are reviewed below.

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.

  • Security difficulties: Notes’ security features required that each team use only one computer to access the database. This was logistically impossible, especially since we wanted to make availability as broad as possible. Providing a login for each individual student was not feasible because it would have detracted from the idea of team products and would have been an administrative nightmare for ICONS staff.
  • Design limitations: Lotus Notes was designed for use by individuals, not teams. It was based upon message threading and did not allow for message numbers. Our trial showed that individual students were unable to coordinate who had read which messages with their team members, and that messages fell through the cracks because student were not able to use the response feature correctly without significant training time. (For example, a message on nuclear proliferation could easily get buried in a message thread on debt issues, making it unlikely the topic specialists on the other teams would ever see the message.) We feared that even with extensive training, there were no guarantees that students would use the system correctly.
  • System requirements: Lotus Notes had specific requirements for the minimally acceptable computer configuration. Our trial was conducted using computers from the lower end of this scale, and the response times were unacceptably slow, even though all participants were in the same location. From our technology survey, we knew that slow connections might be a problem given the distributed nature of the exercise and that many of our participating schools would still be using older computers. A further significant complication was that using Lotus Notes would require that we ship software for installation on local computer to each participant.3
  • Integration problems: Message threading and other considerations did not allow us to integrate asynchronous message exchange and real-time conferencing in the same application.

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
POLNET II was written in C using a file structure to store data. Each simulation "community" had a separate set of files to store messages and participant information. Today, most online transactions processing systems are based on a relational database application. Although ICONS is an educational program, its technical requirements for data storage are similar than those of a commercial user.

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 Oracle’s 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
Most of the pages the participants access contain dynamic data, except for the login page. Each button calls a PL/SQL procedure that customizes the information shown on the screen. (See Figure 1.) For example, in an international simulation, Canada and Mexico may see different information on the screen. Messages that are sent to all participants will be seen by both, but Mexico will not be able to access messages sent only to Canada.

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
There are five different classes of users within the ICONSnet system: Simcon users, regular participants, translators, observers, and control teams.

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
ICONSnet was designed to meet the pedagogical and technical requirements that we outlined earlier in the paper:

  • Ease of access: Since the program is web-based, participants need only a web browser and a connection to the Internet. In addition, unlike POLNET II, ICONSnet does not place any limits upon how many users from any given team may be "logged in" at any one time.
  • Design for "lowest common denominator": Although performance is enhanced with fast Internet connections and newer computers, older computers are not precluded. In fact, ICONSnet was designed to also work with text-based browsers, such as Lynx.5
  • Minimal training time: The point and click interface makes all the applications functions obvious and easy to access. Faculty members report that they often do not even need to conduct formal training sessions with their students.
  • Integration/Dual modes of communication: ICONSnet does support both asynchronous message exchange and real-time conferencing within the same application, allowing for "one-stop" convenience. Conferences function in much the same way as the message exchange, but the interface includes features and functions which facilitate the real-time exchanges.
  • Team anonymity: When participants send messages, they are presented with a check list of community members so that they can specify to whom they wish their messages to be sent. There is no other identification.
  • Team message management: Participants can access new messages according to issue, which facilitates work by subgroups within country teams. With each individual message read, they can also choose whether to keep the message in the new message queue for easy access by another team member or send it to the archive.
  • Archiving: ICONSnet provides an easy-to-use interface, which works the same for both messages and conference transcripts. At the end of the simulation, participants are allowed to access all messages, even those which they did not originally receive, so that they can get a better picture of the full negotiation process.
  • Support for foreign language translation: ICONSnet allows translator teams to easily provide translations for certain messages for the participating teams that need their services.

Conclusion
Since our adoption of ICONSnet, we have seen a number of positive developments. First, faculty report that the technology has become practically invisible to the students, allowing them to give their full attention to the substance of their interactions with their peers. Second, we have attracted new participants, who might have been discouraged by the more difficult POLNET II system. Third, we have had the opportunity to use our system to support non-simulation activities, such as a series of dialogues on issues related to democracy linking high school students in the U.S. and Europe, as well as virtual meetings of researchers from 6 countries working on a joint project.6

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ès’s 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
1.  This paper was written by Beth Blake, ICONS Simulation Director, and Rosie Morales, ICONS Computer Associate. ICONSnet was originally designed and developed by the former ICONS Computer Associate, Kim Holley.

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. 1983. "Computer-Assisted International Relations." Teaching Political Science. 10:4 (Summer). Pp. 171-176.

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 |
Future Simulations | Research Library | Site Map

ICONS is located at the University of Maryland.   For more information, please contact icons@gvpt.umd.edu.   Copyright 1999, Project ICONS, University of Maryland