Supporting the Business Game of a TV Production by LMS – About the Implementation of Highly Configurable Submission Rooms for Various Learning Scenarios Alexander Roth Decision Support & OR Lab University of Paderborn, Warburger Strasse 100, D-33098 Paderborn, Germany E-Mail: roth@upb.de Phone: +49 5251 60 5236
Thorsten Hampel Computer Science University of Paderborn, Fürstenallee 11, D-33102 Paderborn, Germany E-Mail: hampel@upb.de Phone: +49 5251 60 6522
Thomas Strauch Center for Information- & Media Technology University of Paderborn, Warburger Strasse 100, D-33098 Paderborn, Germany E-Mail: thomas.strauch@upb.de Phone: +49 5251 60 2828
Abstract: Today's e-learning systems and system supporting collaborative work need to be adapted to a wide range of contexts of use. Based on the concept of virtual knowledge spaces we developed a conceptual approach of highly adaptable terminology-based components as well as a successful open source infrastructure implementing our concept. Key element for shaping e-learning environments to different use cases are web based adjustable views. Our contribution illustrates adjustable views on collaborative spaces with the help of a flexible submission room for different e-learning scenarios, which also includes a business game of TV-production.
1. Introduction The contexts in which virtual community members learn and work together are influenced by a great variety of factors: Nowadays learning environments often have to consider several didactical concepts and their flexible combinability (blended learning). However, changing requirements for working environments of virtual communities often arise because of an increased grade of socialization and the related demand for better self-administration and –regulation (see Wenger, 1998). Accordingly, the necessity of supporting dynamic contexts is founded on different arguments; however the realization of both system classes brings up the same conceptional challenge: The technological infrastructure must be designed as reactive and adjustable in terms of communication, interaction and cooperation, in order to accommodate for the individual, as well as the collective evolution-dynamic of its users (see Hampel et al., 2005). Educational technology, which is scalable concerning this matter, will be of low-maintenance: The administration of materials and their access rights requires extremely flexible options for alignment and configuration; the same applies for different levels of self-organization of groups In an interdisciplinary cooperation between the two work groups ”cooperative media” and “contextual computing” and the decision support & operations research-lab at the university of Paderborn a modular architecture has been developed, which suits as a basis for the development of such a learning and working environment. Instead of developing a conceptional database-scheme for the special problem area and maintaining it throughout the application’s life-cycle, we aimed at a terminology based development of components: The constant use of Hampel’s conceived metaphor (see Hampel, 2001) of virtual knowledge spaces in specialized components on the one hand makes them independent from one another, but on the other hand also very compatible with each other. Hence, an optimal flexibility and expandability can be achieved, to fulfill the requirements of dynamical and growing platforms. This article will first describe the conceptional and technological basics, then introduce our process model and take the virtual submission room as an example of such a component. By means of a course dealing with a business game of a TV production, we show how these configured rooms can be used in higher education. We conclude with a summary and an outlook on further development.
2. Merging Terminology with Technology 2.1 The Metaphor of Virtual Knowledge Rooms One of the most important fields of intervention of knowledge organizations is the arrangement of areas: The area canalizes communication and permits or limits the structuring, allocation and the medium of information. As a central metaphor, virtual knowledge rooms offer space to work with knowledge objects as well as the space to store them. They can be connected freely and in different ways, e.g. through hallways, doors or with the help of links between materials located in different rooms. Since there is the possibility of advanced structures through folders or sub-rooms within one room, it is also possible to display amounts of objects, persons and structural relationships in a semantic, logic and chronologic way. The concept of the media-functions identifies medial support, which provide technical systems to create, change and arrange knowledge-objects and their structures.
2.2 An Object-Model for the Metaphor of Knowledge Rooms For the architectural-technical realization of the above mentioned basic-metaphors, a class/-or object-model realized in the Paderborn sTeam-System1 emerged. This system basically depends on the idea, to treat collaborative (CSCW-) environments as connected room-structures, where several documents and nested object-structure can be filed and where users are able to stay, move, and be aware (see Hampel, 2001). The basic object-model is characteristic for the structure of the collaboration-server sTeam. It is limited to the attributes object, room, link, document, connection, container, user and group and describes a terminology for learning and working-scenarios (compare to figure 1).
Figure 1: The object-model works as generic kernel (1).Functions for media and communication are built on it, and available through standardized internet protocols (2). This enables integration into heterogeneous infrastructures (3), and adapted views on rooms and knowledge objects. This model represents the metaphor of virtual knowledge spaces by Hampel (see Hampel, 2001).
The central element of the model is the object. Mainly, it has functions to set and select attributes, but also to set and review authorizations. Further classes inherit the basic characteristics of objects. A document adds the feature of administering the content of a document to the object. With the help of links, documents (objects) can be connected arbitrarily. The main function of a container is to encapsulate documents. Therefore, the room is a special feature of the container, where users can stay. Rooms can be connected through gateways, which are a specialization of links. In that way, a corridor develops, where users can move along the set access rights. A user-object inherits all characteristics of the basic type object and of a container, and is therefore (just like a rucksack) able to carry all kinds of objects. It can also be featured with arbitrary attributes and authorities. Groups are directly derived from objects and allow the administration of different participants of one user group. Via access rights, various interactions and contexts of use can be controlled, and users move in virtual rooms and have the right to deal with different objects. Herewith different levels of self-organization of groups and users are realized. 2.3 Integration through Adjusted Views In order that the presented concepts can serve a basis within a heterogeneous environment, the Paderborn collaboration server sTeam obtains the actual communication- and infrastructure protocols from the internet through protocol adaptors on the elements of the knowledge-room metaphor (compare to figure 1, right side). Different clients can therefore produce various, adapted views on the virtual space. Thus, objects of annotations can be retrieved through mail protocols, or documents can be rearranged and edited in collaboration in one room with the help of a shared whiteboard-client. Also PHP programming interface, which is used in the example presented in section 4, produces adapted views on the knowledgeroom metaphor and the objects structures administered in the persistency layer of the collaboration server 2. 1 2
For more informations about the sTeam collaboration server see http://www.open-steam.org. At http://www.phpsteam.org/ we provide the API’s documentation and files, also some code examples.
3. The Development Procedure of Terminology Based CSCL/CSCW-Components The implementation of different learning and working contexts within a system is often connected with high effort and a multitude of differing functionalities that need to be implemented. A component-oriented architecture can reduce the implementation complexity substantially, by combining (or aggregating) different software modules into an applicationscenario. Components have – contrary to normal classes – a well defined interface and have to accord with certain requirements concerning their independence (autonomy), seclusion and openness (see Lieberherr, 2004). To warrant best possible combinability and flexibility, the components must be compatible on a technical and objective level. In this chapter we want to detail our experiences in the terminology based development of a configurable software component on the basis of the collaboration server sTeam. After that, we will show an example of such a component in section 4. 3.1 Organizational and Semantical Specification of the Scenario The first step in the terminology based component development marks the relevant difference to the traditional approach: Instead of designing a new semantical data model of the problem area (supported by the component), then building the basic data structure and comparing it with existing schemas of the CSCL/W platforms that will be extended, the supported scenario will be directly constructed with the terminology described in 2.2. When using a given object model, the assignment of objects and classes, as well as the identification of structures (which would be necessary in the object oriented analysis), are omitted. A simple diagram scheme, which can represent the operational and organizational structure of the problem area by means of the knowledge space metaphor, has proven to be an efficient aid in modeling the construct (compare to figure 2). Since the construct of the component has to be explicitly identified and instantiated during runtime for flow control, a central object is defined in this step. The unique key of these objects is later used as an identifier to access the completed construct. 3.2 Implementation Issues As depicted in figure 1 and detailed in section 2, the instances of objects and functions described in the model are designed to adhere to the COAL internet-protocol. Application programming interfaces (APIs) are built on top of this, thereby enabling the use of the knowledge space metaphor and the respective functionalities. Based on these APIs, the flow control and functionalities for the construct from the first step are programmed in the according language(s). The sTeam-APIs provide base classes in the terminology of the virtual knowledge space. This guarantees that the terminology will also be used in higher architectural levels, which leads to a better compatibility of the components (see Hampel & Roth, 2005). The so-called factory-services (used for creating and loading new component instances) are also defined in this step. To accomplish this, the constructs controlled by the component are read from the persistency layer of the sTeam collaboration server via the unique key of the central object and then provided as instances of the base classes in the runtime environment. 3.3 Functional Extensions of Terminology-based Developed Components In a next step, the component is extended with simple operations like get/set-functions as well as more complex ones, which allow for an objective usage. The combined functions thus build the (main) object interface. Aiming at the highest possible autonomy, the data-types are kept primitive (String, Integer, ‌); instances of persistently saved objects in sTeam are only accepted and returned via the mentioned base classes (see figure 1). Different learning and cooperation scenarios can require the same set of functions, while differing on the level of selforganization. If a component is to be used in several similar scenarios, the construct administered in sTeam has to be extended with attributes to persistently store additional information about states, control options and configurations. In this step, another interface type is implemented, namely the observer-services, which can be started with an event control provided by sTeam. These services can be used to take care of event-driven message communication between the components. The communication in web-based applications is often carried out via the stateless HTTP (Hypertext Transfer) protocol. This means, that in this case an event-driven notification via a browser as client may not be possible, since every connection between browser and web-server states an independent transaction. Communication with clients or applications, based on other protocols, still remains possible in this way.
3.4 Bringing Components together within Scenarios For the realization of freely combinable learning scenarios or working environments that can be adjusted to the requirements of a community, the developed software components are connected via the flow-control. The communication between components is also taken care of by the control, to avoid mutual dependencies among them. A possible persistent storage of connected components is also performed within the given terminology; for this the constructs managed by the component are connected persistently in the virtual knowledge space.
4. The Configurable Submission Room for Material-oriented Scenarios Documents, or media in general, which are brought into learning- or working contexts by users, can play various didactical roles in different scenarios, e.g. presentations, groundwork material, as well as workpieces and results. The requirements for software support of such material-oriented scenarios differ from one another when it comes to the level of interaction, as well as the necessary communication functionality, derived from the scenarios’ sociocultural specificities. In real life, these scenarios are supported by a physical placement area (e.g. a project folder, a pin board, or a mailbox for handing in assignments), and a set of rules, which should coordinate the communication, interaction and cooperation on it. To support several similar scenarios of this kind, a flexible usable, configurable component was developed on top of the introduced terminology of virtual knowledge rooms.
Figure 2: Terminology-based developed components can be managed by their constructs in the persistency layer. In the example given, virtual submission rooms are managed as course room’s subspaces in analogy to lections and appointments.
Expressed in the metaphor of virtual knowledge rooms, physical placement areas and their functionalities can be modeled through rooms. Based on this construct, coordinating rules can be implemented inside the component’s objective methods, in combination with additional attributes of the room, to be able to store different states in the persistence layer. The
metaphor’s annotations support the implementation of various communication functions. Via the graphical user interface, the tutor has options to define the communication methods (i.e. their performance and presentation), as well as the level of interaction possibilities with materials for the user. The options presented in table 1 have been proven as adequate to cover many variations of material-oriented, didactic scenarios. Option Deadline Access Precondition Presentation Annotation Rights
Description Material contribution is subject to a time limitation. Is a deadline defined, the component can be configured differently for the time after. This limits access to materials in the virtual room; students can only enter the room after submitting their own materials. This option controls whether foreign materials in that room are to be presented anonymous or with author/group names, in case students are allowed to see them. Instructions to if and how communication between users can occur regarding the materials. If room access by students is allowed, these rights define, how they can interact with own and foreign submissions: read, write and/or delete.
Table1: Configuration options for virtual submission rooms
To be able to combine virtual submission rooms with other didactic scenarios, a loosely coupling of the congruent components is necessary. To achieve the necessary autonomy, any dependencies of each component to another have to be kept on a very low level. As mentioned above, terminology based developed components can be combined in the persistency layer through the constructs managed there. Thus, the necessity to couple components in the application layer is reduced to the minimum. Figure 2 shows exemplarily a submission room embedded inside a course scenario. Here, submission rooms are created as subspaces of the course room; the central object of that construct, on which the component for course management is based3. All parties do not need any further information from one another, because the primary base classes and their media functions are sufficient to support their cooperation.
5. From Shooting Schedule to Copyright Declaration - An Exemplary Usage Scenario of Submission Rooms To facilitate the transfer of knowledge into practice for media education at the University of Paderborn, the Center of Information- & Media-Technology frequently applies a specific modification of the project method (see Kilpatrick, 1918). In this context, the learning management framework openSMT4, built on top of the steam server, supports different didactic scenarios within a single course, due to its configurable submission rooms (see Roth, Hampel, & Suhl, 2005). The success of the project method results from a seminar’s accomplishment in analogy to a production process in a journalist’s every day work life. Not only that this requires the appliance of available knowledge in defined processes, respectively the internalization of knowledge in the direct context of making a journalistic contribution, but also it gives the opportunity to socialize students in an environment near to work life. The competence to solve problems, which is based on practical experiences, but also activities like becoming a team player and entering into time-limited and social commitments, are encouraged (because demanded), particularly with regard to the production process. The core piece of this method is the production schedule with its conceptual formulation, its definition of available process time, and its intermediate products with their related acceptances. Therefore, the intermediate products are acting as milestones. To proceed with the next step is permitted only after successful acceptance. The introducing part of the course is organized as classical seminar. Missing knowledge, proficiencies and dexterities are arranged through lectures, exercises, and presentations. This phase is very important, because of the heterogeneous previous knowledge of the participating students. Aims of the introduction are: • Instruction for appropriate use of the LMS • To convey knowledge and skills needed for the production process • Agreements regarding aesthetic principles of the designing process
3 4
And, therefore, the flow control during the runtime. Open Framework for Service-oriented Modules for Teachware, see http://www.opensmt.org.
The business game represents the whole process of a TV production. Hereby, openSMT works as an editorial system, which coordinates both, the collaboration of group members, and the collaboration of groups and tutors. In addition, it stimulates discussions. It is crucial, that, in the end of each intermediate step, an intermediate product is submitted by each group of students, which can be discussed and evauluated for acceptance. If standards have not been achieved, subsequent improvements are allowed. A go-ahead takes place if the intermediate product achieved the minimal standard. Here, the tutor plays the roles of the editor and executive producer. Phase & Intermediate Steps
Materials
Types of Media
Creators/Authors
Introduction
Learning materials, examples of TV productions
Tutor
Preparatory (BG)
Shooting Schedules
Text documents, Internet resources and videos on streaming server Text documents, diagrams
Filming (BG) Cutting (BG)
Raw Versions Chunky and precision cuts
Text Editing and Timing (BG) Audio Recording (BG)
Speaker’s manuscript Accompanying commentary
Mixing (BG)
Final Tape
Finishing (BG)
Text for introductory moderation, copyright declaration, voucher copy Examples of the new productions, discussion threads
Reflection
Groups of students
Video files on storage medium Video files on streaming server Text documents, diagrams Audio-Files Video files on streaming server Text documents, video files on DVD Text documents, videos on streaming server, annotations
Students / Tutor
Table 2: The presented business game (BG) is divided into several intermediate steps, in which groups of students have to submit different intermediate products as milestones up to an agreed deadline. Configured submission rooms can support these organizational workflows, but can also stimulate the open discussion in the reflection phase with a less stringent configuration. The introducing part is supported by standard rooms, which can be used as virtual lectures or appointments (rooms interlinked with calendar objects).
Each individual performance is incorporated into an assessment catalogue, which delivers one student’s final score at last. Therefore, the process of assessment becomes clear for students, and eased them from major assessments (e.g. written examinations or reflections). Because the participants are divided into production groups during the business game, the progresses in the learning process (equal to the progress in the production process) can be differentiated properly regarding group-specific objectives, social aptitudes, and compliances with deadlines. In the last part of the course, the final products are presented to the plenum. Here, experiences and problems of the production process are analyzed and discussed. Thereby, subjects regarding content, aesthetics, technology, and organization are particularly focused. During this phase, external audience (customers) can participate. This has two reasons: On the one hand, ingenuous members of the audience were encouraged to introduce further critical points of views (putting trained incapacity up to discussion), on the other hand, the presence of external viewers increased the pressure to succeed, to “go on air” right on time. Moreover, the final products are published online, as far as legally permitted. In this course, different didactic scenarios can be supported by virtual rooms and their corresponding configurations for access rights and communication methods. During the introduction part, the write access of virtual rooms has been limited to the tutor. Here, students have only read access and a few communication options, wherewith they can download course material and annotate it for their own notes. Especially during the business game, the extended functionalities of submission rooms show their advantages: • The distinction of cases between own and foreign materials regarding the access right for student groups provides a better usability for tutors. Herewith, intermediate products from all student groups can be submitted to a single room, without permitting access to other groups’ submissions. For the tutor, this provides a good overlook about the state of progress on the one hand, and on the other hand it facilitates comparisons during assessment. • Applying the deadline concept allows a second room configuration for the time after. Here, students can see and annotate intermediate products of other groups, which they cannot see before. This stimulates constructive feedback. Another advantage is grounded in the support of an organizational aspect: students have general write
•
access on their own submissions before the deadline. After, this right has to be enabled by the tutor for the mentioned subsequent improvements. The option for de-personalization regarding submissions and their annotations/feedback helps to gain a constructive and helpful working environment. If enabled, the tutor can see the names of the authors, the students cannot. Students can learn to deal with critic in an objective manner, without becoming personal.
6. Practical Experiences and Outlook During their lifetime, learning environments and community platforms have to adhere to often changing and even new requirements, or various requirements for similar concepts as exemplarily shown. This leads to problems when using conceptional data schemas in applications. Since these are fully concerned by implementation, maintenance and extension, it would require a very high effort to keep them consistent with the application’s logic. Our experiences with the outlined architecture and the terminology based component development in the area of learning and community platforms have shown, that these disadvantages do not occur with this approach. Not only the productivity can be increased immensely in the terminology based system developments; but also a better ability to react on dynamical processes and arising changing requirements can be achieved, which greatly helps the maintenance of these complex systems. Besides its usage in other big community platforms, the presented architecture will be used in the planned extension of infrastructure of the University of Paderborn. The focus of the Locomotion (low-cost multimedia organisation and production) project, besides module- and exam-management (process) support, lies in the increased use of eLearning, eTeaching and eCollaboration to improve quality and optimize the handling of connected processes.
References Hampel, T. (2002). Virtuelle Wissensräume – Ein Ansatz für die kooperative Wissensorganisation, Dissertation, University of Paderborn Hampel, T., & Roth, A. (2005). Rapid Development of Non-Monolithic CSCL-Applications – About the Benefits of Using a Prescribed Terminology in Web Programming. In: Proceedings of E-Learn 2005, World Conference on E-Learning in Corporate Government, Healthcare, & Higher Education, AACE, Vancouver, BC Canada, pp.2095-2102 Hampel, T., Roth, A., Kahnwald, N., & Köhler, T. (2005). An Adaptable Platform for Evolving Communities of Practice, In: „Design for Large-Scale Digital Communities“, IRSI – International Reports on Socio-Informatics, Bonn, Germany. Kilpatrick, W. H. (1918). The Project Method, In: Teachers College Record Vol. 19, No. 4, pp.319-335 Lieberherr, K.-J. (2004). Controlling the Complexity of Software Designs, in Estublier, J., & Rosenblum, D. (editors): Proceedings of ICSE2004, ACM Press, Edinburgh, Scotland, pp.2-11 Roth, A., Hampel, T., & Suhl, T. (2005). Platform Spanning Cooperative Learning – An Integration of Distributed Environments based on Virtual Knowledge Spaces. In: Proceedings of Ed-Media 2005, World Conference on Educational Multimedia, Hypermedia, & Telecommunications, AACE, Montreal, Canada, pp.1620-1625