A pattern-based design process for the creation - Departament de ...

dtic.upf.edu

A pattern-based design process for the creation - Departament de ...

UNIVERSIDAD DE VALLADOLID

Dpto. de Teoría de la Señal, Comunicaciones e Ingeniería Telemática

Escuela Técnica Superior de Ingenieros de Telecomunicación

Tesis Doctoral

A pattern-based design process for the

creation of CSCL macro-scripts

computationally represented with IMS LD

AUTORA

Davinia Hernández Leo

Ingeniera de Telecomunicación

DIRECTORES

Juan I. Asensio Pérez

Dr. Ingeniero de Telecomunicación

Ioannis Dimitriadis Damoulis

Dr. Ingeniero de Telecomunicación

Abril de 2007


European Ph.D. Dissertation

Defense: June 25th , 2007

Advisors:

Dr. Juan I. Asensio Pérez & Dr. Ioannis Dimitriadis, University of Valladolid, Spain

Three-month research visit in another European country, advisors:

Dr. Colin Tattersall & Dr. Daniel Burgos, Open University of the Netherlands, The Netherlands

Reviewers:

Dr. Hans Hummel, Open University of the Netherlands, The Netherlands

Dr. Jan-Willem Strijbos, Leiden University, The Netherlands

Committee:

Prof. Dr. Carlos Delgado Kloos, University Carlos III of Madrid, Spain

Prof. Dr. Rob Koper, Open University of the Netherlands, The Netherlands

Prof. Dr. Josep Blat, Pompeu Fabra University, Spain

Dr. Andreas Harrer, University of Duisburg-Essen, Germany

Dr. Eduardo Gómez Sánchez, University of Valladolid, Spain

i


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

ii


ACKNOWLEDGMENTS

It is not possible to separate this Ph.D. Thesis from its social context. My work originated as an

external form of activity before definitively turning to what you can read in this manuscript.

Recalling Vygotsky’s words, I like to think that my contributions are the products of a process of

integration in a knowledge community. The community includes numerous researchers who have

inspired my work. I would like to express my gratitude to all the authors mentioned in the reference

list provided at the end of the thesis. It is also now my great pleasure to take this opportunity to

thank the many people that have personally supported this work one way or another.

I wish to gratefully acknowledge the enthusiastic supervision of Yannis Dimitriadis and Juan I.

Asensio. I cannot thank Yannis enough for offering me an opportunity for initiating research work

in the field of CSCL when I was still an undergraduate student. His guidance on the research topic

and research in general have offered me five years of really gratifying work and have lead me to

become an ardent supporter of CSCL as a means of ultimately achieving a more humanizing society.

I am also deeply indebted to Asen for his attention, immeasurable help, endless discussions, and

keen support. Not only has he extremely influenced the results of this thesis but he has also shown

me the value of the educational experience during the three years that I serve as a teacher at the

School of Telecommunications of the University of Valladolid.

I would like to thank the rest of the members of the multidisciplinary GSIC/EMIC group who

have accompanied and supported me during these years. I have been privileged to conduct my

thesis in such an outstanding social context. I am grateful to Bart, Inés and especially Iván for their

important indications while discussing my work. Their contributions to the design of Collage and

their help in the evaluation phase of the thesis have been significantly useful in shaping this thesis

into completion. The work of Miguel on the Gridcole system has also been very important to

complement and evaluate my contributions. I have been also fortunate to supervise a diploma thesis

of a brilliant student. I sincerely thank Eloy for playing a key role in the development of Collage and

I wish him all the best for the future. Four students are currently making real the future work of this

thesis, extending Collage or developing new related tools. Thanks to Julio, David, Susana and

Vanesa for their enthusiasm carrying out this work. Sincere thanks as well to Alejandra, Eduardo,

Rocío, Guillermo, Miguel Ángel, José Antonio, Guillermo Y., Sara, Sara 2, Sergio, Luis, Momo, Fede,

Óscar, Mendi and Luismi. I would also like to thank Rodri for their help with the University

procedures during the last weeks of finishing this thesis.

A Research Fellowship Program of the University of Valladolid facilitated me a visiting Research

Fellow at the Educational Technology Expertise Centre of the Open University of the Netherlands

(OUNL), where I collaborated with Daniel Burgos, Colin Tattersall and Rob Koper. I wish to express

my sincere thanks and appreciation to them. The three months in Heerlen offered me a great

opportunity for finalizing this work and for meeting extraordinary people. I had insightful

discussions with Hans Hummel, Hubert Vogten and Paul Kirschner, and many informal

conversations with a new circle of friends: Gemma, Ellen, Malik, Jose, Christian, Francis, Youngwu,

Hendrik, Tim, Marco, Liesbeth, Tamara, Bas… I do not want to forget the invaluable help of the

secretaries; thanks to Mieke and Audry. I have been especially fortunate to share my months in the

Netherlands with Juanma Dodero. He has helped me immensely by giving me encouragement and

friendship. He has also collaborated in the ideas, reflected in this thesis, around the integration of

learning design solutions formalized with different languages.

iii


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

There are three special projects which have enormously influenced my work. I am grateful to the

communities of UNFOLD. From the many participants in the UNFOLD events that have supported

me, I would like to specially stress the role of Dai Griffiths, Josep Blat, Rocío García, Ana Dias, Bill

Oliver, Chris Crew, Griff Richards, Daniel Burgos, and Rob Koper. Participating in the VDS

workshops organized by the CoSSICLE ERT of Kaleidoscope has been also extraordinarily useful for

achieving the results of the thesis. Sincere thanks to all the members of the ERT and especially to

Andreas Harrer, who has provided me feedback at different stages of the thesis and kindly accepted

to collaborate with me in shaping the create-by-reuse framework included in this manuscript.

Moreover, the work accomplished under TELL project has offered me valuable insight around

design patterns. Particularly, the constructive comments of Simos Retalis have greatly improved

this work. I would like also to thank the (co-)recognition of the “2006-2007 European CSCL Award

for Excellence in the Field of CSCL Technology” and the “ICALT 2004 best paper award”

committees; both awards have greatly stimulated me.

This research would have not been possible without the participants in the experiences studied

for the evaluation of the thesis. Special words of thanks to the students of TTG and CTM2 as well as

to the teachers of the University of Valladolid and the University of Cádiz who participated in

Collage workshops. Sincere thanks to Gregorio Rodriguez for showing interest and contacting me to

experience the ideas reflected in Collage. The workshop and panel organized by the laboratories

Syscom (Université de Savoie, France) and CLIPS-IMAG (Grenoble, France) within the ICALT 2006

conference also represent an important element of the evaluation accomplished in this work. I

would like to especially thank Laurence Vignollet and Jean-Pierre David for sending me the video

recorded during the panel.

I am grateful to all my friends from University, Cristina, Noemí, Rocío, Susana, Laura, Bea, Crix;

and from Plasencia, Rita Mª, Virginia, Laura, Araceli and Cristina for their understanding and

friendship during all these years. I wish special success with their thesis to Noemí and Rocío. I am

sure they will accomplish an excellent research. I am also indebted to the rest of the members of the

management team of the University Student Residence “Colegio Mayor María de Molina”. I have

been fortunate to collaborate with Mariví, Ana, Ana Mª, Avelina, Fely and Angelines, who have been

my surrogate family during the last two years and have allowed me to enjoy an enriching experience

beyond my duties at the University. I especially thank their care and attention.

I remain indebted to my parents and my bother for their understanding and patience when it

was most required as well as for their enormous effort to ensure that I had an excellent education. I

would also like to thank the rest of my family in which I include David’s family, who has shown a

continuous interest in my evolution throughout the thesis. More than ever, I would like to give my

heartfelt thanks to David, for his endless love and encouragement. He has been the most important

support to complete this work.

iv

Davinia Hernández-Leo

April 2007


v

To my parents,

the best collaboration practice that I know of

To my brother

To David


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

vi


Abstract

Information and Communication Technologies (ICT) in Computer-Supported Collaborative Learning

(CSCL) are mainly used for mediating social interactions as key activators of learning. One of the major

concerns of CSCL is however that free collaboration does not necessarily produce learning and that in several

circumstances collaboration should be scaffolded so that the probability of reaching successful outcomes

increases. CSCL scripts embedded in ICT systems aim at shaping the way learners interact with each other in

order to elicit fruitful interactions. The specific focus of this Ph.D. Thesis is on CSCL macro-scripts which

describe pedagogical methods defining flows of coarse-grained activities. This document identifies and faces

up to three challenges around the problem of facilitating teachers the design of those ICT-embedded CSCL

macro-scripts.

The first challenge refers to the design of the potentially fruitful scripts. This work proposes the use of

patterns to capture good practices in structuring CSCL situations for the purpose of reusing them in the design

of new scripts. In this sense, we present a conceptual model for CSCL scripting pattern languages and a

specific pattern language that is compliant with the model. The model defines the different types of patterns

and relationships among them so that it is possible to specify numerous meaningful sequences of patterns that

shape the design of specific scripts.

The second challenge deals with the implementation of the scripts in ICT systems. With the aim that the

scripts can be automatically interpreted without the need of developing new systems, we propose the use of

IMS Learning Design (LD) specification to computationally represent the macro-scripts. This approach

fosters interoperability and enables teachers participate in the design of the behaviour and functionality of the

systems by providing a script adapted according to their particular situations. This work analyzes the support

of this educational modelling language for expressing CSCL scripts considering the possibilities of the LD

notation but also the use of related specifications and tooling.

The combination of the previous proposals enables us to propose a pattern-based design process for the

creation of CSCL macro-scripts computationally represented with LD. The specific patterns considered in the

approach are the so-called Collaborative Learning Flow Patterns (CLFPs), a particular type of CSCL

scripting patterns that suggest generalized structures of macro-scripts. The main goal of the design process is

twofold. On the one hand, it aims at enabling the conceptualization of the expected interaction focusing on

CSCL critical elements through the refinement of CLFP-based templates. And on the other hand, it intends

facilitating the teacher-friendly creation of LD-represented scripts by hiding LD details; thus facing up to the

third challenge related to the fact that computational representations are not familiar to the majority of the

teachers. The design process is implemented in an authoring tool (named Collage) which proves its feasibility

and enables its proper evaluation.

Overall, the applied research methodology is characterized by the multidisciplinary problem domain

within which the dissertation is framed. Particularly, the evaluation phase is accomplished by means of a

multicase study that comprises three case studies, which aim at assessing the same contributions but from

different perspectives. The cases involve workshops with the target audience (teachers interested in applying

CSCL) and experiences with students in authentic situations; but they also involve experts in the collaborative

learning or LD fields and researchers proposing related approaches. The results of the evaluation not only

show that the objectives of the dissertation have been achieved but they also offer relevant clues for future

research directions.

vii


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

viii


Resumen

Las Tecnologías de la Información y las Comunicaciones (TIC) se utilizan principalmente en el campo

del Aprendizaje Colaborativo Apoyado por Ordenador (Computer-Supported Collaborative Learning, CSCL)

para mediar interacciones sociales como activadores significativos del aprendizaje. Sin embargo, un problema

importante en el CSCL es que la colaboración libre no produce necesariamente aprendizajes. En determinadas

circunstancias la colaboración debe ser guiada de manera que aumente la probabilidad de alcanzar beneficios

educativos. Precisamente, los guiones de CSCL integrados en sistemas TIC tienen como objetivo indicar

cómo los alumnos deben interactuar entre ellos para que tengan lugar interacciones fructíferas. El ámbito de

investigación específico de esta Tesis Doctoral recae sobre los denominados macro-guiones de CSCL, que

describen métodos pedagógicos formulados como flujos de actividades. Este documento identifica y hace

frente a tres retos relacionados con el problema de facilitar a los profesores el diseño de estos macro-guiones

integrados en las TIC.

El primer reto hace referencia al diseño de los guiones de manera que éstos sean potencialmente

productivos. Este trabajo propone utilizar patrones para capturar buenas prácticas en cuanto a la

estructuración de situaciones de CSCL. El objetivo es que los patrones puedan ser reutilizados en la creación

de nuevos guiones. Para ello, presentamos un modelo conceptual de lenguajes de patrones para guiones de

CSCL, así como un lenguaje de patrones concreto que es conforme con el modelo. Dicho modelo define los

diferentes tipos de patrones y relaciones entre patrones de manera que es posible definir numerosas

posibilidades de secuencias de patrones que dan forma al diseño de guiones específicos.

El segundo reto tiene que ver con la implementación de los guiones en sistemas TIC. Con el propósito de

que los guiones puedan ser interpretados automáticamente sin necesidad de desarrollar nuevos sistemas,

proponemos representarlos computacionalmente utilizando la especificación IMS Learning Design (LD). Esta

aproximación fomenta la interoperabilidad a la vez que hace posible la participación de los profesores en el

diseño del comportamiento y la funcionalidad de los sistemas. Para ello, basta con que los profesores creen

los guiones de acuerdo con las condiciones particulares de su situación de enseñanza-aprendizaje. Este trabajo

analiza las posibilidades del lenguaje de modelado educativo LD para expresar los guiones considerando la

propia notación pero también el uso de otras especificaciones y herramientas relacionas.

La combinación de las propuestas anteriores nos permite proponer un proceso de diseño basado en

patrones para la creación de macro-guiones de CSCL representados computacionalmente con LD. Los

patrones concretos que se han considerado son los llamados Patrones de Flujo de Aprendizaje Colaborativo

(Collaborative Learning Flow Patterns, CLFPs). El objetivo principal del proceso de diseño es doble. Por una

parte, pretende posibilitar la conceptualización de las interacciones esperadas de manera que los elementos

críticos del CSCL son considerados al refinar plantillas LD basadas en los patrones. Por otra parte, persigue

facilitar la creación amigable de guiones LD escondiendo los detalles de la especificación. De este modo,

proponemos una solución para el tercer reto que se refiere al hecho de que las representaciones

computacionales no les son familiares para la mayoría de los profesores. El proceso de diseño ha sido

implementado en una herramienta de autoría (denominada Collage) que demuestra la viabilidad de la

propuesta y permite su conveniente evaluación.

En conjunto, la metodología de investigación aplicada se caracteriza por el ámbito multidisciplinar en el

que se enmarca la tesis. Particularmente, la fase de evaluación se ha llevado a cabo mediante un estudio

múltiple de (tres) casos. Los tres pretenden evaluar las mismas contribuciones pero desde diferentes

perspectivas. Incluyen talleres destinados a la audiencia potencial de nuestra propuesta principal (profesores

con interés en aplicar CSCL) y experiencias con alumnos en situaciones reales. Los casos también involucran

a expertos tanto en aprendizaje colaborativo como en LD e investigadores que proponen aproximaciones

relacionadas. Los resultados de la evaluación no sólo muestran que los objetivos de la tesis se han conseguido

sino que también ofrecen indicaciones relevantes de trabajo futuro.

ix


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

x


CONTENTS

CHAPTER ONE: INTRODUCTION

1.1 Introduction ........................................................................................................................... 1

1.2 Objectives of the dissertation................................................................................................. 4

1.3 Research methodology .......................................................................................................... 9

1.4 Structure of the dissertation................................................................................................... 12

CHAPTER TWO: DESIGN OF CSCL SITUATIONS

2.1 Introduction ........................................................................................................................... 15

2.2 From TEL to CSCL situations: design challenges................................................................. 17

2.2.1 CSCL as a research field within Technology-Enhanced Learning....................... 17

2.2.2 Instructional Design and CSCL............................................................................ 19

2.2.3 Scripting CSCL .................................................................................................... 20

2.2.4 Participatory Design and CSCL ........................................................................... 22

2.2.5 Discussion: research focus and derived challenges.............................................. 23

2.3 Design Patterns...................................................................................................................... 25

2.3.1 Patterns in Architecture........................................................................................ 25

2.3.2 Patterns in Software Engineering ......................................................................... 27

2.3.3 Patterns in TEL and CSCL................................................................................... 30

2.3.4 Discussion: the generative problem and the generation of potentially effective

scripts ............................................................................................................................ 32

2.4 Educational Modelling Languages ........................................................................................ 34

2.4.1 IMS Learning Design ........................................................................................... 34

2.4.2 Other approaches.................................................................................................. 37

2.4.3 Discussion: IMS LD as a candidate to computationally represent CSCL

scripts ............................................................................................................................ 38

2.5 Conclusion............................................................................................................................. 39

CHAPTER THREE: CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

3.1 Introduction ........................................................................................................................... 41

3.2 Methodology applied for proposing the model and the pattern language.............................. 43

3.2.1 Capturing the experience reported in the literature .............................................. 44

3.2.2 Using case studies as a starting point ................................................................... 45

3.3 CSCL scripting pattern languages model .............................................................................. 46

3.3.1 Aggregation model and types of connecting rules ............................................... 47

3.3.2 An illustrating CSCL scripting pattern language: hierarchical structure.............. 50

3.3.3 General guidelines for applying the PL described with the conceptual model..... 53

3.3.4 Discussion: other categorizations of patterns ....................................................... 54

3.3.5 Discussion: other sample patterns that fit in with the proposed conceptual

model............................................................................................................................. 56

3.4 Examples of applying the CSCL scripting patterns............................................................... 57

3.4.1 Computer Architecture (CA) course .................................................................... 57

3.4.2 The use of ICT resources in Education (NNTT) course....................................... 59

3.4.3 Computer Networks Protocols (TTG) course....................................................... 61

3.4.4 Discussion: moral preoccupation, coherence, generativeness and creativity ....... 70

3.5 Potential computer-supported applicability ........................................................................... 72

3.6 Conclusion............................................................................................................................. 73

CHAPTER FOUR: IMS LD SUPPORT FOR COMPUTATIONALLY REPRESENTING CSCL MACRO-SCRIPTS

4.1 Introduction ........................................................................................................................... 77

4.2 Methodology applied in the analysis ..................................................................................... 79

4.3 Requirements of CSCL macro-scripts ................................................................................... 80

4.3.1 Group composition............................................................................................... 80

4.3.2 Role/resource distribution .................................................................................... 82

4.3.3 Coordination......................................................................................................... 83

xi


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

4.3.4 Flexibility .............................................................................................................85

4.4 Expressing the requirements using IMS LD notation ............................................................87

4.4.1 Group composition ...............................................................................................88

4.4.2 Role/resource distribution.....................................................................................90

4.4.3 Coordination.........................................................................................................92

4.4.4 Flexibility .............................................................................................................96

4.4.5 Discussion and revision of the limitations regarding LD notation .......................96

4.5 Supporting the requirements using related tools or specifications.........................................98

4.5.1 Addressing the limitations using complementary specifications and tooling.......99

4.5.2 Discussion: general specification of group-services.............................................101

4.5.3 Discussion: embedded in tools vs. computer-interpretable micro-scripts.............102

4.6 Conclusion .............................................................................................................................103

CHAPTER FIVE: DESIGN PROCESS FOR THE GENERATION OF IMS LD SCRIPTS REUSING CLFPS

5.1 Introduction............................................................................................................................107

5.2 The “create-by-reuse” conceptual framework .......................................................................109

5.2.1 Reuse of learning design solutions .......................................................................110

5.2.2 Design processes for creating units of learning ....................................................112

5.2.3 Discussion: other potential dimensions ................................................................114

5.3 The role of CSCL scripting patterns in design processes.......................................................115

5.3.1 Assistant vs. templates..........................................................................................116

5.3.2 Implementing CLFPs as refinable LD templates..................................................118

5.4 A CLFP-based design process for the generation of LD scripts ............................................122

5.4.1 Scope: support the creation of LDs ......................................................................123

5.4.2 Combinations and concatenations of CLFP-based templates...............................124

5.4.3 The design process in the create-by-reuse framework..........................................125

5.4.4 Focus on CSCL critical elements: selecting the templates and authoring the

scripts ............................................................................................................................126

5.4.5 Collage authoring tool: implementing the proposed design process ....................131

5.5 Creating LD scripts using Collage.........................................................................................140

5.5.1 CTM2 (Network Management) ............................................................................141

5.5.2 NNTT ...................................................................................................................144

5.5.3 Pyramid-based paper discussion...........................................................................145

5.5.4 Job interview simulation.......................................................................................146

5.5.5 STA (Advanced Telematics Systems) ..................................................................146

5.6 Discussion: towards more general approaches ......................................................................147

5.6.1 Using more general visual representations ...........................................................147

5.6.2 Assembling learning design solutions formalized with different languages.........147

5.7 Conclusion .............................................................................................................................149

CHAPTER SIX: EVALUATING THE DESIGN PROCESS WITH A MULTICASE STUDY

6.1 Introduction............................................................................................................................153

6.2 Formulation of the multicase study........................................................................................155

6.2.1 The quintain..........................................................................................................155

6.2.2 Overview of the cases forming the multicase study .............................................156

6.2.3 Mixed method.......................................................................................................161

6.3 Case study A: Collage workshops .........................................................................................162

6.3.1 Description of the case study................................................................................162

6.3.2 Conceptual structure.............................................................................................167

6.3.3 Case findings ........................................................................................................168

6.4 Case study B: Planet game.....................................................................................................179

6.4.1 Description of the case study................................................................................179

6.4.2 Conceptual structure.............................................................................................181

6.4.3 Case findings ........................................................................................................182

6.5 Case study C: Network Management.....................................................................................195

6.5.1 Description of the case study................................................................................196

6.5.2 Conceptual structure.............................................................................................202

6.5.3 Case findings ........................................................................................................203

6.6 Cross-case analysis ................................................................................................................209

xii


6.6.1 Assertion I ............................................................................................................ 212

6.6.2 Assertion II........................................................................................................... 214

6.6.3 Assertion III ......................................................................................................... 214

6.7 Discussion ............................................................................................................................. 216

CHAPTER SEVEN: CONCLUSIONS AND FUTURE WORK

7.1 Conclusions and main contributions...................................................................................... 219

7.2 Future research directions...................................................................................................... 224

APPENDIX A: A CSCL SCRIPTING PATTERN LANGUAGE

A.1 Collaborative learning flow level ......................................................................................... 230

A.2 Activity level ........................................................................................................................ 237

A.3 Resource level....................................................................................................................... 242

A.4 Roles and common collaborative mechanisms level ............................................................ 245

APPENDIX B: WELL-KNOWN CSCL SCRIPTS:

RUNNING UNIVESANTÉ AND ARGUEGRAPH WITH AN LD ENGINE

B.1 Well-known CSCL scripts .................................................................................................... 250

B.2 Universanté Unit of Learning ............................................................................................... 253

B.3 ArgueGraph Unit of Learning............................................................................................... 260

APPENDIX C: SUPPORT EVALUATION DATA OF THE COLLAGE WORKSHOPS CASE STUDY

C.1 Pattern-based design process ................................................................................................ 266

C.2 Focus on CSCL critical elements.......................................................................................... 271

C.3 Use of Collage ...................................................................................................................... 274

C.4 Potential audience characteristics ......................................................................................... 279

APPENDIX D: SUPPORT EVALUATION DATA OF THE NETWORK MANAGEMENT CASE STUDY

D.1 Meaningfulness of the CSCL script created with Collage.................................................... 286

D.2 Enactment of the CSCL script using Gridcole...................................................................... 291

D.3 Educational innovation with respect to previous students’ experiences ............................... 293

xiii


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

xiv


LIST OF FIGURES

Figure 1.1 General schema of the dissertation including its context, the aimed objectives, the original

contributions as well as the accomplished evaluation ............................................................................... 6

Figure 2.1 Scheme of ideas developed in this chapter ...................................................................................... 17

Figure 2.2 Taxonomy of PD practices .............................................................................................................. 23

Figure 2.3 Relations between some proposals regarding patterns in TEL........................................................ 31

Figure 2.4 The conceptual model of IMS LD................................................................................................... 35

Figure 3.1 CSCL scripting pattern language conceptual model package and relationships with other models 47

Figure 3.2 Aggregation model of CSCL scripting Pattern Languages.............................................................. 48

Figure 3.3 Hierarchical structure of the CSCL scripting PL showing how the PL fits in with the conceptual

model. The numbers on each node reference the patterns as listed in Appendix A. Because of

representational limitations not all the possible relationships are drawn ................................................ 51

Figure 3.4 “Life cycle” of CSCL scripts and related tools................................................................................ 72

Figure 4.1 LD representation of the groups involved in the PYRAMID structure (a) and an example of the

assignment of roles to users in a particular PYRAMID -based UoL (b)................................................... 88

Figure 4.2 Excerpt of a TAPPS-based LD (arrows point referenced element definitions) ............................... 91

Figure 4.3 Expressing the JIGSAW learning flow with the LD method............................................................ 93

Figure 5.1 Dimensions of the create-by-reuse framework: reusable learning design solutions at different level

of granularity and completeness............................................................................................................ 111

Figure 5.2 Design processes for creating UoLs by assembling and refining learning design solutions ......... 113

Figure 5.3 From a CLFP to a UoL: scheme of the process for obtaining CLFP-based UoLs......................... 119

Figure 5.4 General modules of a system implementing LD ........................................................................... 123

Figure 5.5 CLFPs hierarchies ......................................................................................................................... 125

Figure 5.6 CLFP-based design process for the creation of LD scripts within the create-by-reuse framework:

refinement process................................................................................................................................. 125

Figure 5.7 CLFP-based design process for the creation of LD scripts within the create-by-reuse framework126

Figure 5.8 CLFP-based design process for the creation of LD scripts: selecting the templates and authoring

the scripts .............................................................................................................................................. 128

Figure 5.9 Two dimensions of LD tool design ............................................................................................... 132

Figure 5.10 Plug-in framework for an LD editor............................................................................................ 133

Figure 5.11 Collage selection interface .......................................................................................................... 134

Figure 5.12 Help information about the JIGSAW CLFP................................................................................. 135

Figure 5.13 Collage authoring interface ......................................................................................................... 136

Figure 5.14 Configuring the flow of the PYRAMID-based template in Collage ............................................. 137

Figure 5.15 Configuring the flow of the SIMULATION-based template in Collage ....................................... 138

Figure 5.16 Configuring the flow of the TAPPS-based template in Collage.................................................. 138

Figure 5.17 Planning the learning flow........................................................................................................... 142

Figure 5.18 Graphical refinement of the template resulting of the combination of CLFPs using Collage (I) 143

Figure 5.19 Graphical refinement of the template resulting of the combination of CLFPs (II)...................... 143

Figure 5.20 Authoring the NNTT script with Collage.................................................................................... 145

Figure 5.21 Example design process in which various learning design solutions are integrated into refinement,

assembly and mixed processes, according to the create-by-reuse framework....................................... 148

Figure 5.22 Snapshot of the example design process that integrates assembly, refinement processes and mixed

processes, in accordance with the create-by-reuse framework.............................................................. 149

Figure 6.1 Graphic representation of the multicase study............................................................................... 157

Figure 6.2 Authoring the script with Collage ................................................................................................. 183

Figure 6.3 Refining the JIGSAW-based template with the description of the activities and the collaborative

tool supporting the activities ................................................................................................................. 184

Figure 6.4 Enacting the Planet game script created with Collage using Gridcole integrating a shared

repository: clue distribution................................................................................................................... 186

Figure 6.5 Enacting the Planet game script created with Collage using Gridcole integrating a discussion forum

and a chat: cooperative phase................................................................................................................ 186

Figure 6.6 Enacting the Planet game script created with Collage using Gridcole integrating a questionnaire

tool: proposing the solution................................................................................................................... 187

Figure 6.7 Hierarchy of group types as created by Collage according to the combined template.................. 198

Figure 6.8 Lab distribution according to the different groups ........................................................................ 199

Figure 6.9 Extract of the document provided to the students.......................................................................... 199

xv


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

Figure 6.10 Global view of different moments of the experience, in which the students used the different

integrated tools ......................................................................................................................................200

Figure 6.11 A student in the Expert group phase............................................................................................200

Figure 6.12 Applied mixed evaluation method...............................................................................................202

Figure B.1 UML activity diagram of Universanté script ................................................................................254

Figure B.2 UML activity diagram of ArgueGraph script................................................................................261

xvi


LIST OF TABLES

Table 2.1 Comparison between Alexander’s and Gamma’s patterns ............................................................... 29

Table 3.1 Types of connecting rules (relationships) between patterns at the same and different levels of

aggregation.............................................................................................................................................. 49

Table 3.2 TCP mechanisms to be studied in the course and the related scenarios of traffic interchange to be

analyzed and/or designed ........................................................................................................................ 64

Table 3.3 Sequence of lab sessions and the corresponding individual and collaborative learning activities.... 65

Table 3.4 Main expected competencies and skills ............................................................................................ 67

Table 3.5 Labels used in the text to quote the data sources of the “Network management” experience .......... 68

Table 3.6 Relevant evaluation conclusions and associated evidence................................................................ 69

Table 4.1 Computationally representing the group composition requirements of Universanté script .............. 89

Table 4.2 Computationally representing the group composition requirements of ArgueGraph script.............. 90

Table 4.3 Computationally representing the role/resource distribution requirements of Universanté script .... 91

Table 4.4 Computationally representing the role/resource distribution requirements of ArgueGraph script ... 92

Table 4.5 Computationally representing the coordination requirements of Universanté script ........................ 94

Table 4.6 Computationally representing the coordination requirements of ArgueGraph script ....................... 95

Table 4.7 Computationally representing the flexibility requirements of Universanté script ............................ 96

Table 4.8 Computationally representing the flexibility requirements of ArgueGraph script............................ 96

Table 5.1 Excerpt showing the process for obtaining the JIGSAW-based UoL............................................... 121

Table 5.2 Refining the template resulting of the combination of CLFPs towards the ready-to-run script

(students’ activities) .............................................................................................................................. 141

Table 5.3 Refining the template based on a combination of a JIGSAW and a PYRAMID towards the ready-torun

script................................................................................................................................................ 145

Table 5.4 Refining the template based on the PYRAMID towards the ready-to-run UoL............................... 146

Table 6.1 Summary of the experiences involved in the multicase study ........................................................ 158

Table 6.2 Labels used in the text to quote the data sources of the “Collage workshops case study” ............. 169

Table 6.3 Narrative of the Planet Game scenario proposed to the participants of the workshop.................... 180

Table 6.4 Participants in the panel and the workshop under analysis in the “Planet game case study”.......... 181

Table 6.5 Labels used in the text to quote the data sources of the “Planet game case study”......................... 182

Table 6.6 Summary of the UoL (based on JIGSAW CLFP) created using Collage ........................................ 184

Table 6.7 Labels used in the text to quote the data sources of the “Network management case study”......... 204

Table 6.8 Partial matrix for generating theme-based assertions from case findings, case A. ......................... 210

Table 6.9 Partial matrix for generating theme-based assertions from case findings, case B. ......................... 211

Table 6.10 Partial matrix for generating theme-based assertions from case findings, case C ........................ 212

Table B.1 Universanté script........................................................................................................................... 250

Table B.2 ArgueGraph script.......................................................................................................................... 251

Table B.3 ConceptGrid script ......................................................................................................................... 252

Table B.4 Narrative use case description of Universanté ............................................................................... 253

Table B.5 Users and their associations to roles (groups): “country group” .................................................... 254

Table B.6 Users and their associations to roles (groups): “thematic group” and “case group” ...................... 255

Table B.7 Screenshots of CopperCore running the LD-represented Universanté script................................. 255

Table B.8 Narrative use case description of the ArgueGraph script...............................................................260

Table B.9 Screenshots of CopperCore running the LD-represented ArgueGraph script ................................ 261

Table C.1 Partial results and support data concerning the information question “is the selection of the CLFPbased

LD templates and their representation useful and satisfactory?” ................................................ 266

Table C.2 Partial results and support data concerning the information question “does it achieve a satisfactory

trade-off between reuse of CLFPs and the creation of scripts contextualized according to the situational

needs?” .................................................................................................................................................. 268

Table C.3 Partial results and support data concerning the information question “does the design process

implemented in Collage help to determine the learning objectives, task-type and expected interaction

that will be develop?”............................................................................................................................ 271

Table C.4 Partial results and support data concerning the information question “does the design process

implemented in Collage help to understand and determine the structure regarding the flow of activities

and the hierarchy of groups?” ............................................................................................................... 272

Table C.5 Partial results and support data concerning the information question “does the design process

support also the definition of group-size, resource distribution, computer support and the structure

within activities?”.................................................................................................................................. 273

xvii


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

Table C.6 Partial results and support data concerning the information question “can the teachers use

successfully Collage?” ..........................................................................................................................274

Table C.7 Partial results and support data concerning the information question “how can Collage be

improved?” ............................................................................................................................................277

Table C.8 Partial results and support data concerning the information question “which are the characteristics

and motivations of the potential audience of Collage?”........................................................................279

Table D.1 Partial results and support data concerning the information question “is the CSCL script

contextualized to the actual learning situation?” ...................................................................................286

Table D.2 Partial results and support data concerning the information question “does the CSCL script guide

the learning process coordinating the students at the activity level according to the CLFPs on which is

based?” ..................................................................................................................................................287

Table D.3 Partial results and support data concerning the information question “does the CSCL script foster

the desired objectives related to collaborative learning?” .....................................................................290

Table D.4 Partial results and support data concerning the information question “can the students follow

successfully the CSCL script using the Gridcole system?” ...................................................................291

Table D.5 Partial results and support data concerning the information question “how can the enactment of the

CSCL script be improved?”...................................................................................................................292

Table D.6 Partial results and support data concerning the information question “does the enactment of the

CSCL script enhance students’ previous experience in terms of structuring collaboration and use of

supporting technology?”........................................................................................................................293

xviii


CHAPTER ONE

INTRODUCTION

This chapter introduces the main problems in the Computer-Supported Collaborative

Learning field of research that motivate the dissertation. The chapter formulates the

objectives, the expected contributions and the applied research methodology as well as

the structure of the dissertation.

1.1 Introduction

Computer-Supported Collaborative Learning (CSCL) represents a rather new multidisciplinary

paradigm within the field of Technology-Enhanced Learning (TEL), in which Information and

Communication Technologies (ICT) are employed in order to improve various educational aspects

(Koschmann, 1996; Stahl, Koschmann, & Suthers, 2006). The main characteristics of CSCL include

highlighting the importance of social interactions as an essential element of learning (Dillenbourg,

1999a), as well as the need of participatory modes of designing new technological environments

(Häkkinen, 2002). CSCL solutions (developed by technologists) should offer the functionality

desired by the set of potential actors that participate in collaborative learning situations (mainly

teachers and students).

One of the main concerns in CSCL is that the expected interactions that would lead to learning

outcomes do not necessarily occur when the students are asked to collaborate freely (Dillenbourg,

2002). Among many different approaches that share the goal of enhancing effective collaboration

we can mention two important ones. The first approach is to monitor the collaboration and intervene

as necessary in order to redirect the group work in a more productive direction (Soller, Martínez-

Monés, Jermann, & Muehlenbrock, 2005). The other solution refers to an increase of the probability

of reaching successful CSCL situations by providing students with a set of instructions that guide

potentially fruitful collaboration (Dillenbourg, 1999b). When the instructions are technologymediated,

they form what is called a computer-supported collaboration script (CSCL script or

simply script).


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

The goal of the guidance provided by the scripts refers to cognitive or educational objectives.

This difference is characteristically related to the granularity of the scripts (Fischer, Kollar, Haake,

& Mandl, 2007). Micro-scripts are intended for facilitating that students internalize them from a

cognitive psychologist perspective (e.g. learning how to argument by following a script that

scaffolds argumentation). They typically provide support for specific activities by describing the

fine-grained actions (e.g. sentence starters) that each participant should accomplish (Weinberger,

Fischer, & Stegmann, 2005). On the contrary, macro-scripts denote pedagogical methods defining

flows of coarse-grained activities (Dillenbourg & Jermann, 2007). They aim at organizing situations

that elicit desired interactions potentially leading to learning outcomes from the educational point of

view (e.g. understanding the key ideas of a topic by following a script that distributes the

knowledge and promotes mutual explanation).

Unfortunately, up to now the scripts are “hardwired” in specifically devoted learning

environments (Jermann, Soller, & Lesgold, 2004; Häkkinen & Mäkitalo-Siegl, 2007). This fact

limits their reusability in a different situation and imposes significant time and cost efforts when a

new script needs to be implemented. Moreover, developing a new scripting environment is not

trivial. This is mainly due to the inherent characteristic of multidisciplinarity in CSCL, which

implies a need for mutual understanding among the involved stakeholders (mainly experts in

education and in ICT) (Stahl et al., 2006). This need demands active participation of all these

stakeholders during the whole development cycle of CSCL solutions. Participatory Design (PD)

approaches (Muller & Kuhn, 1993) propose a diversity of practices with the goal of working

directly with users and other stakeholders in the design of social software systems.

In CSCL, it has been shown that there is a significant efficiency problem in performing

identification and analysis of requirements for the development of CSCL solutions that support

effective ways of learning (Dimitriadis, Asensio-Pérez, Martínez-Monés, & Osuna-Gómez, 2003).

Collaborative learning practitioners also become active players in the process of customizing

technological solutions to their particular needs in every teaching-learning situation. PD poses a

new requirement that CSCL technologists should tackle: how to obtain technological solutions for

collaborative learning capable of being particularized/customized by teachers that usually do not

have technological skills. The domain problem undertaken in this dissertation is related to

facilitating teachers play the role of designers of those technological solutions. Specifically, the

problem to be solved consists in how PD can be enabled by providing authoring tools for creating

macro-scripts which can be automatically interpreted and executed by learning environments such

as Learning Management Systems (LMSs). This type of systems makes possible the delivery of

learning activities and digital content to students (E-LANE, 2004; Bote-Lorenzo, 2005; Burgos,

Tattersall, Dougiamas, Vogten, & Koper, 2006).

2


INTRODUCTION

One of the problems associated to this research focus refers to the fact that scripts need to be

computationally represented (formalized) in order to enable their automatic interpretation.

Educational Modelling Languages (EMLs), in contrast to metadata specifications (e.g. Learning

Object Metadata, LOM) for describing reusable chunks of learning content (so-called Learning

Objects or LO) (Hodgings, 2000; Duval, 2001), are focused on specifying teaching-learning

processes (Rawlings, van Rosmalen, Koper, Rodríguez-Artacho, & Lefrere, 2002). IMS Learning

Design specification (IMS LD or simply LD) is currently accepted as the de facto standard EML and

the amount of developments around LD is significant (IMS, 2003b; Koper & Tattersall, 2005;

Burgos & Griffiths, 2005).

The aim of LD is to enable the creation of complete, abstract and portable descriptions of any

pedagogical approach taken in a course (or part of a course), which can be realized by a compliant

system. The key idea is that it represents the learning activities (performed by learners) and the

support activities (performed by teachers), including those comprising multi-role teaching-learning

processes and personalized learning routes (Koper & Olivier, 2004). Motivated by the

interoperability prospects and the specification declaration of intent, we consider LD as an

interesting candidate to computationally represent CSCL scripts.

However, the LD support for formalizing collaborative learning processes is not clear (Caeiro-

Rodríguez, Anido-Rifón, & Llamas-Nistal, 2003). This concern is motivated by the fact that the

specification is still very recent and it has not been widely adopted in real practice yet (Burgos &

Griffiths, 2005). Besides, there is a lack of significant examples and efforts showing the

possibilities of LD for CSCL (e.g. description of group hierarchies). Although partial work has been

already accomplished (Gorissen & Tattersall, 2005; Koper & Burgos, 2005), a more complete and

systematic analysis is needed.

On the other hand, the current LD compliant editors require a high level of expertise on LD and

therefore they are not indented for teachers but for expert instructional designers or educational

technologists (Milligan, Beauvoir, & Sharples, 2005; van der Vegt, 2005; Miao, 2005; de la Teja,

Lundgren-Cayro, & Paquette, 2005; Sampson, Karampiperis, & Zervas, 2005). With the aim of

enabling teachers to play the role of script designers, CSCL specific LD-based authoring tools

should incorporate (visual) design techniques (Botturi & Stubbs, in press) that hide the details of

LD (Griffiths & Blat, 2005) as well as the inherent difficulties involved in modelling scripts. These

difficulties are caused by the complex mechanisms and components that comprise the definition of

scripts (Kollar, Fischer, & Hesse, 2003), such as the interrelations of groups or the synchronization

of collaborative activity sequences.

Furthermore, these authoring tools should implement design processes that guide teachers in the

design of potentially effective scripts. This is especially important if the teachers (and students) are

3


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

novice in collaborative learning, since putting into practice collaborative learning experiences is not

trivial (Johnson & Johnson, 1999) and because of the risks of over-scripting the situations and thus

coercing relevant natural interaction (Dillenbourg, 2002). It is important to consider that traditional

Instructional Design (ID) approaches (devoted to individual instructional sequences) based on

general theories (Reigeluth, 1999) are too rigid and underestimate the complexity of CSCL

(Goodyear et al., 2004; Kenny, Zhang, Scwier, & Campbell, 2005). In this sense, CSCL requires

more pragmatic design processes grounded in practice (Karagiorgi & Symeou, 2005) which make

the critical elements for eliciting productive interaction explicit (Strijbos, Martens, & Jochems,

2004).

We argue that a promising solution to approach this problem is to propose a design process that

facilitates the reuse of generalizations of successful collaboration scripts (best/good practices)

formulated as design patterns. This would also avoid the costly efforts related to re-inventing script

strategies. Despite the fact that the word “pattern” has been used for centuries with slightly different

meanings, its use is more known in the fields of Architecture (Alexander et al., 1977) and Software

Engineering (Gamma, Helm, Johnson, & Vlissides, 1995). A pattern provides a means of

organizing information regarding a contextualized common problem and the essence of its broadly

accepted solution, so that it can be repetitively applied. A collection of interconnected (related)

patterns which enable the generation of a coherent whole (e.g. a town) is called a Pattern Language

(PL). Recently other domain specific patterns have been proposed, including TEL and CSCL

(Goodyear, 2005; Derntl & Botturi, 2006; Retalis, Georgiakakis, & Dimitriadis, 2006). However,

the existing pattern approaches in TEL, which vary in scope and purpose (e.g. patterns for designing

LMSs (Avgeriou, Papasalouros, Retalis, & Skordalakis, 2003) vs. patterns for mathematical games

(Learning Patterns, 2005)), do not include any specific proposal devoted to designing scripts.

Therefore, the general problem undertaken in this dissertation refers to the definition of a design

process that takes advantage of insights offered by best/good scripting practices (formulated as

patterns) for the creation of particularized educationally-sound LD-represented macro-scripts as a

means of providing PD approaches which enables teachers to influence in the behaviour and

functionality of CSCL scripting environments. In this way, section 1.2 introduces the objectives of

this dissertation. The research methodology followed to tackle them is presented in section 1.3.

Finally, section 1.4 concludes this introductory chapter.

1.2 Objectives of the dissertation

According to the research problems described in the previous section, the global aim of this

dissertation is:

4


INTRODUCTION

To propose and evaluate a design process based on patterns for facilitating the creation of

potentially effective CSCL macro-scripts computationally represented with IMS Learning Design so

that they can be interpreted by learning environments such as Learning Management Systems.

This global aim can be divided into the following more specific objectives. These derived

objectives and the original contributions of this dissertation are schematically represented in Figure

1.1 and described as follows:

• To identify the types of patterns and relations between patterns that can be used for

generating CSCL scripts.

In order to tackle this objective, it will be necessary to have a unifying view of several

different representative pattern-based approaches in TEL. That will allow us to situate

and describe the scope and audience of what we will define as CSCL scripting patterns.

An iterative process will be followed. It will include case studies, the experience of the

GSIC/EMIC (Intelligent & Cooperative Systems Group / Education, Media, Informatics

and Culture) research group (GSIC/EMIC, 1994), the results of TELL (Towards

Effective network supported coLLaborative learning activities) project (TELL, 2005b)

and a review of the literature with regard to design and, particularly, scripting in CSCL.

Once the types of patterns and the relations between them are identified, a method for

applying the patterns will be discussed. Furthermore, a CSCL scripting PL (with own

and adopted patterns) as well as three CL situations generated using the PL will be

provided to illustrate how the patterns can be applied.

Regarding this objective, the main contributions of this dissertation are the proposal of a

conceptual model for describing CSCL scripting Pattern Languages and an actual CSCL

scripting PL. Both contributions will be useful within this dissertation to situate the other

contributions. They also provide to the scientific community a starting point towards an

agreed high-level structure for the production of CSCL scripting patterns and PLs.

Part of these contributions have been published in (Hernández-Leo, Villasclaras-

Fernández, Asensio-Pérez, Dimitriadis, & Retalis, 2006d), which introduces the

hierarchical structure for CSCL scripting patterns characterized by the conceptual model,

and (Hernández-Leo, Asensio-Pérez, & Dimitriadis, 2006), which presents a real

experience that applies a script generated with the proposed pattern language

5


CONTEXT

A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

Instructional Design

- CSCL requires more pragmatic design

processes, grounded in practice, than

traditional ID approaches

- Focus on CSCL critical elements

Patterns

- Contextualized common problem

and the essence of its reusable

broadly accepted solution

- Patterns in Architecture, Software

Engineering and also in TEL

OBJECTIVES

CONTRIBUTIONS

1.Conceptual model for CSCL

scripting pattern languages. A

CSCL scripting pattern

language

EVALUATION

Design of Computer-Supported Collaborative Learning situations

To propose a design process that facilitates

the reuse of Collaborative Learning Flow

Patterns in the creation of CSCL macroscripts

(computationally represented with

IMS LD) in a way that allows teachers to

particularize the patterns according to the

needs of their educational situation,

making explicit the CSCL critical

elements

3. Design process for the generation of

CSCL scripts reusing CLFPs as LD

templates. Authoring tool implementing

the design process (Collage)

A multicase study

6

Educational Modeling

Languages

- Computer-interpretable notations

to represent units of learning

- Interoperability, IMS Learning

Design as the de facto standard

GLOBAL OBJECTIVE: To propose and evaluate a design process based on patterns

for facilitating the creation of potentially effective CSCL macro-scripts computationally represented with IMS Learning Design

so that they can be interpreted by learning environments such as Learning Management Systems

To identify the types of

patterns and relations between

patterns that can be used for

generating CSCL scripts

Three CL situations

generated using a

CSCL pattern

language situated in

the proposed

conceptual model

Scripting CSCL

- Planning CSCL scenarios so that they

elicit expected fruitful interaction

among the participants

- Micro-scripts (instructions within

activities) vs. macro-scripts (flows of

activities)

- It is not trivial to design scripts: risk

of coercion, lack of experience

practicing collaborative learning

- Scripts hardwired in specific learning

environments prevent reusability

Participatory Design

- CSCL is a multidisciplinar field

- Specific needs of each situation

- Most teachers do not have advanced

technological skills

To analyze the

suitability of IMS LD

for computationally

representing CSCL

macro-scripts

2. Analysis of the

possibilities and

limitations of LD for

computationally

representing the CSCL

characteristics

comprised in macroscripts

A. Four workshops in which slightly different audiences (mostly target users:

teachers) create CSCL scripts based on CLFPs using Collage

B. Participation in a workshop of the ICALT 2006 conference in which we create a

scenario proposed by a third-party using Collage. The results are compared to other

approaches

C. Putting into practice an authentic blended learning scenario (in engineering

education) that uses a CSCL script created with Collage

Figure 1.1 General schema of the dissertation including its context, the aimed objectives, the original

contributions as well as the accomplished evaluation


INTRODUCTION

• To analyze the suitability of IMS LD for computationally representing CSCL

macro-scripts.

The first step so as to fulfil this objective will be to identify common CSCL

characteristics in CSCL macro-scripts. The importance of these characteristics will be

justified according to the literature and related work such as the CoSSICLE project

(CoSSICLE, 2005) as well as the experience based on real context of the GSIC/EMIC

research group (GSIC/EMIC, 1994). After that, LD-represented scripts including the

identified characteristics will be developed. That will allow us to clarify the possibilities

of LD for computationally representing CSCL macro-scripts, differentiating the LD

notation itself from related specifications and supporting tools.

On this topic, the contribution of this dissertation is the analysis of the possibilities and

limitations of LD for computationally representing the CSCL characteristics comprised

in CSCL macro-scripts. The global conclusions have been submitted for publication

(Hernández-Leo, Burgos, Tattersall, & Koper, submitted) and are currently under

review. However, significative partial results have been already published in

(Hernández-Leo, Asensio-Pérez, & Dimitriadis, 2005), extended version of (Hernández-

Leo, Asensio-Pérez, & Dimitriadis, 2004) which received a “Best Paper Award” in the

conference where it was presented, and (Hernández-Leo et al., 2005a), extended version

of (Hernández-Leo et al., 2005b).

• To propose a design process that facilitates the reuse of CLFPs (Collaborative

Learning Flow Patterns, a particular type of CSCL scripting patterns) in the

creation of CSCL macro-scripts (computationally represented with IMS LD) in a

way that allows teachers to particularize the patterns according to the needs of

their educational situation, making explicit CSCL critical elements.

Having the aforementioned proposals as a starting point, we will describe an approach

facilitating the reuse of CLFPs for the generation of CSCL scripts computationally

represented with LD. The design process will meet the following requirements. Firstly, it

will achieve a satisfactory trade-off between particularizations of CLFPs so that the

resulting LDs are contextualized according to particular CL situations and the loss of the

meaningfulness captured in CLFPs. Secondly, it will allow teachers to focus on CSCL

critical features (e.g. learning objectives, task type, level of pre-structuring, group size).

Finally, it will not require high technical knowledge, particularly of LD. An important

element, in this sense, will be the implementation of the design process in an authoring

tool (Collage) in order to prove its feasibility and to enable its proper evaluation.

7


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

The design process for the generation of CSCL scripts reusing CLFPs is the central

contribution of this dissertation since it links several of the previous specific objectives.

The design process together with its implementation in Collage has been published in

(Hernández-Leo et al., 2005; Hernández-Leo, Villasclaras-Fernández, Asensio-Pérez, &

Dimitriadis, in press; Hernández-Leo et al., 2006e) and has been also co-honoured with

the 2006-2007 European Award for Excellence in the Field of CSCL Technology. The

“create-by-reuse” framework in which the process is situated has also been published in

(Hernández-Leo, Harrer, Dodero, Asensio-Pérez, & Burgos, 2006a).

• To evaluate the proposed pattern-based design process for CSCL macro-scripts

computationally represented with IMS LD.

In order to evaluate the design process, we will carry out three different case studies:

A. The first case study will comprise four workshops in which participants (mainly

potential users: teachers) will create LD-represented CSCL scripts based on CLFPs

following the proposed design process integrated in Collage. These experiences will allow

us to value to which extent the design process implemented in Collage facilitates the reuse

of CLFPs in the creation of particularized LD-represented scripts, in a way that allows

teachers to focus on CSCL critical elements.

B. The second case study will involve the participation in a workshop where several

researchers proposing related approaches design a scenario proposed by the workshop

organizers. Therefore, this experience will provide indications regarding whether our

proposal can be used for creating a script representing a scenario proposed by a third party.

Moreover, the workshop will represent a good opportunity to compare our contributions

with related work. Partial conclusions of the this case study are published in (Hernández-

Leo et al., 2006b)

C. The third case study will deal with a real situation in engineering education where

students will experience a CSCL script created according to the design process. This case

study will allow us to show that the scripts are meaningful and can be applied in authentic

educational situations. The results of this case study have been accepted for publication

(Hernández-Leo et al., in press).

Furthermore, this evaluation will allow us to extract conclusions that will be useful for

future research.

8


1.3 Research methodology

INTRODUCTION

The objectives of this dissertation are framed within a multidisciplinary problem domain. This

fact demands a hybrid methodology that includes elements of diverse research approaches (Adrion,

1993) and highlights the need to consider the social context (Stahl et al., 2006). Multiple domain

knowledge, combining theory and praxis, is the key factor of the methodology, which focuses on

real practitioners’ needs.

Therefore, research and practice evolve together in the applied research approach. It uses four

phases: informational, propositional, analytical and evaluation (Glass, 1995). Several iterations, in

which the findings of each phase (essentially the analytical and evaluation phases) feed earlier

phases, are accomplished until “satisficing” results are achieved. (Satisficing is a concept coined by

Herbert Simon which identifies the decision making process whereby one chooses an option that is,

while perhaps not the best, good enough (Simon, 1982).) That expresses the significance of the

evaluation phase, which is also critical for validating the proposals.

Within each phase of the research approach, the applied research methods are described as

follows (Glass, Vessey, & Ramesh, 2002; Zelkowitz & Wallace, 1998):

• Informational phase

The aim of this phase is to gather information in order to, on the one hand, identify and

clearly formulate the research questions and, on the other hand, have an outline of the

current knowledge involved in the problem domain.

The main methods involved in this phase include tasks belonging to both the scientific

(observing the world) and the engineering (observing existing solutions) approaches:

- The search, review and analysis of literature regarding the topics of the problem domain:

CSCL with emphasis in design and scripting problems, pattern-based approaches in TEL

and EMLs.

- The participation in the GSIC/EMIC multidisciplinary research team (GSIC/EMIC,

1994) whose field of expertise (including research and practice) is collaborative learning

and its computer support. Particularly, the experience and findings of two case studies

investigated by the group constitute an important legacy for this research work

(Martínez-Monés et al., 2005; Ruiz-Requies, Anguita-Martínez, & Jorrín-Abellán,

2006).

- The participation in several conferences and projects whose topics include the keywords

related to this research work. The projects are TELL e-Learning project

EAC/61/03/GR009, Kaleidoscope Network of Excellence FP6-2002-IST-507838,

Spanish Ministry of Education and Science projects TIC-2002-04258-C03-02 and

9


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

TSI2005-08225-C07-04 and Autonomous Government of Castilla and León, Spain,

projects VA009A05, UV46/04 and UV31/04. Particularly, the outcomes of TELL

project (TELL, 2005a; TELL, 2005a) represent a significant input to this dissertation.

This phase has been also largely benefited by the informal but active involvement in the

UNFOLD (Understanding New Frameworks Of Learning Design) project (UNFOLD,

2004; Burgos & Griffiths, 2005) (related to IMS LD specification) as well as the

participation in two workshops offered by the Kaleidoscope Virtual Doctoral School and

organized by the multidisciplinary European Research Team CoSSICLE (CoSSICLE,

2005).

• Propositional phase

In this phase we propose and formulate the solutions to the identified research questions

using the information aggregated in the previous phase.

- The core of the first and the third contributions of this dissertation (as numbered in

Figure 1.1) are sketched in this phase, namely the conceptual model for CSCL scripting

patterns languages and the design process for creating CSCL scripts based on CLFPs.

Regarding the formulation of the patterns included in the example of the CSCL scripting

PL, two kinds of pattern mining methodologies are employed (Baggetun, Rusman, &

Poggi, 2004; Retalis et al., 2006): deductive or top-down (using best or good practices in

structuring collaborative learning) and inductive or bottom-up (using the conclusions of

case studies).

- The proposal of computationally representing the CSCL macro-scripts and CLFPs using

IMS LD is also a result of this phase.

• Analytical phase

The purpose of this phase is to analyze and explore the proposals which may lead to a

demonstration or formulation of principles.

- A concept implementation (proof of concept) is performed in order to analyze the

proposal related to the first contribution. It consists in providing a feasible CSCL

scripting pattern language, which can be described with the proposed conceptual model,

and in theoretically generating CSCL scripts that illustrate how the patterns might fit

together. The concept implementation is complemented with examples of how the

patterns can be applied. Whilst these tasks are realized, several iterations proceed back to

the propositional phase as far as the first contribution is concerned.

- The analysis of the possibilities and limitations of IMS LD for computationally

representing significant CSCL scripting characteristics that appear in CSCL scripts is

10


INTRODUCTION

also accomplished in this phase. The applied method consists mainly in trying to develop

LD-represented scripts that code these CSCL characteristics. Part of this work is realized

at OTEC (Educational Technology Expertise Centre) in the OUNL (Open University of

the Netherlands) during a three-month research stay (OTEC, 2006).

• Evaluation phase

This phase is devoted to evaluating the proposals and the analytic findings by means of

several case studies (Zelkowitz et al., 1998; Lundgren-Cayrol, Marino, Paquette, Léonard, &

de la Teja, 2006; Jorrín-Abellán, Dimitriadis, Rubia-Avi, Anguita-Martínez, & Ruíz-

Requies, 2006) organized as a multicase study (Stake, 2005). The case studies aim at

assessing the same contributions but from a different perspective:

- A case study comprising four workshops in which different audiences create CSCL

scripts using the proposed design process. The audience is mainly the target users, i.e.

teachers of two different universities (University of Cádiz and University of Valladolid,

both in Spain) with interest in applying CL and ICT in their practice, but also experts in

the field of research: educational technologists (UNFOLD members) and CSCL

practitioners and researches (members of the GSIC/EMIC group). Some of the CSCL

scripts that they create in the workshops are designed beforehand in laboratory

experiments, in which the corresponding UoLs are created and validated using the

reference LD engine, CopperCore (Martens & Vogten, 2005).

- A case study in which we design a scenario proposed by a third-party using our

approach. It involves the participation in an ICALT 2006 (6th IEEE International

Conference on Advanced Learning Technologies) conference workshop (Vignollet,

David, Ferraris, Martel, & Lejeune, 2006). We create a script reflecting the scenario

using Collage and further execute it using Gridcole (Bote-Lorenzo, 2005).

- A case study in which a real-world educational situation uses a CSCL script created

according to the proposals of this dissertation. The experience is part of an eligible

course on Network Management within Telecommunication Engineering studies at the

University of Valladolid.

In the case studies, a mixed method combining quantitative and qualitative data collection

techniques is employed (Goubil-Gambrel, 1992; Jorrín-Abellán, Rubia-Avi, Anguita-Martínez,

Gómez-Sánchez, & Martínez-Monés, in press; Martínez-Monés, Dimitriadis, Rubia-Avi, Gómez-

Sánchez, & de la Fuente-Redondo, 2003). The emphasis is more on qualitative than on quantitative

research, which is only considered useful for showing trends and indicating probabilities. In

contrast, qualitative research is used to identifying salient features or variables in particular

representative settings according to which the results can be interpreted (Denzin & Lincoln, 2005).

11


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

1.4 Structure of the dissertation

The rest of this dissertation is structured as follows:

- After this introduction, Chapter Two focuses on the domain problem related to the design of

CSCL situations. With this purpose, it reviews CSCL as a multidisciplinary field of research

within TEL and analyzes important design approaches in TEL and CSCL. In this sense, the

chapter describes the role of Instructional Design (ID) in CSCL, focuses on the scripting

CSCL approach and discusses the importance of Participatory Design (PD) in the design of

this type of ICT applications. The analysis leads us to formulate three challenges around the

problem of enabling participatory modes of design in which teachers create their own CSCL

macro-scripts embedded in software environments. Besides, Chapter Two also explores

research directions that envisage solutions to tackle the identified challenges. These

directions include the use of design patterns and Educational Modelling Languages (EMLs)

as well as their combined application through design processes integrated in authoring tools

for the creation of computer-interpretable scripts.

- Chapter Three is devoted to the research direction referred to the use of design patterns. Its

main function is to identify the types of patterns and the relationships between them that can

be jointly applied in the design of CSCL scripts. In this sense, it presents a model for CSCL

scripting pattern languages and discusses a specific pattern language (PL) which is

compliant with the model. To illustrate that the PL enables the generation of many scripts,

the chapter also includes three authentic situations that apply a sequence of interconnected

patterns selected from the PL.

- Chapter Four in turn analyzes the suitability of IMS Learning Design (LD) specification, the

most significant EML at the moment, for computationally representing CSCL macro-scripts.

In this sense, it points out important requirements of the scripts and studies the possibilities

and limitations of the specification to support them. In the analysis, which is illustrated by

means of relevant cases, the scope of the LD notation is confronted to the role of related

tooling facilities and eventually complementary specifications.

- Chapter Five proposes a design process that combines the contributions of the previous

chapters. In particular, the design process facilitates the reuse of CLFPs (Collaborative

Learning Flow Patterns, a particular type of CSCL scripting patterns) in the creation of

CSCL macro-scripts represented with LD. The proposed design process is situated and

compared to related work by means of a framework that conceptualizes different (existing

and yet-to-come) approaches that drive the creation of full-fledged LD Units of Learning

(UoL) by reusing different types of design solutions. Our proposal, targeting teachers

without high (LD) technical knowledge, aims at achieving a satisfactory trade-off between

particularizations of CLFP-based templates according to specific CL situations and the loss

12


INTRODUCTION

of the solutions captured in CLFPs. Besides, the design process allows teachers to focus on

CSCL critical features that are involved in the elicitation of expected interaction processes.

The chapter also presents Collage, an authoring tool that implements the design process

proving its feasibility and enabling its proper evaluation. Moreover, the creation of LD

scripts using this authoring tool is illustrated with several examples.

- In Chapter Six the evaluation of the proposed design process is accomplished by means of a

multicase study. The multicase study comprises three cases which aim at assessing the same

contributions but from different perspectives. The first case is devoted to workshops where

the target audience use the design process implemented in Collage. The second case implies

the design of a scenario proposed by a third-party using our approach and its comparison

with related approaches. The last case analyzes an authentic educational situation where

students follow a script created according to the design process. The chapter finishes with a

cross-case analysis which emphasizes the combined results of the studied cases as the global

assumption of the evaluation.

- Chapter Seven draws together the main conclusions of the dissertation listing its main

contributions and pointing out future research directions.

- Appendix A contains the CSCL scripting pattern language cited in Chapter Three.

- Appendix B includes three well-known CSCL scripts, two of which (Universanté and

ArgueGraph) are also formulated as narrative use case descriptions and UML activity

diagrams since they are used to illustrate the analysis of Chapter Four. The appendix also

shows screenshots of their LD representations (UoLs) running with an LD engine. The

ready-to-run UoLs are available in a CD-ROM attached at the end of the dissertation.

- The remaining appendixes (C and D) collect support data employed in the multicase study

presented in Chapter Six. The raw data is also available in the attached CD-ROM.

13


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

14


CHAPTER TWO

DESIGN OF CSCL SITUATIONS

The aim of this chapter is to present the domain problem of the dissertation, putting into

focus the specific challenges that it undertakes. It starts by introducing CSCL as a

multidisciplinary research field within TEL, which emphasizes the social interactions as

activators of learning in the accomplishment of joint activities that are supported by

technology. The zoom is applied to the design issues around CSCL, considering the role

of the teachers in the design of CSCL situations embedded in learning environments

(scripts). Within the scripting CSCL approach, participatory design requirements

together with the lessons learned from Instructional Design lead us to identify three

challenges as well as the directions that envisage solutions to tackle them: in order to

design the scripts capable of eliciting fruitful interactions, we explore the design patterns

approach; besides, to computationally represent the scripts so that they can be

interpreted by the environments without the need of developing new systems, we seek

for the use of an Educational Modelling Language; the combination of both approaches

through a design process to be implemented in high level authoring tools for creating

scripts would allow teachers to influence in the behaviour and functionality of the

learning environments that supports CSCL situations.

2.1 Introduction

How can technology facilitate and improve the teaching and learning experience? The

introduction of TEL is significantly more complex than a mere addition of technology to the

existing educational practices (Rogers, 2002). Reaching the ultimate goal of the TEL domain

requires a fundamental redesign of the educational systems (Jochems, van Merriënboer, & Koper

R., 2004) as well as important research efforts related to the design of meaningful technical

solutions and authentic usage situations (also called scenarios or settings) (Herrington & Oliver,

2000; Häkkinen, 2002; Dimitracopoulou & Petrou, in press). The emphasis is clearly on learning

with technology and not on learning from technology. We use the term TEL instead of e-Learning,

because the latter is often associated only to distance learning (Littlejohn, 2005). However,

technology-mediated learning can also benefit face-to-face classrooms or blended situations, which

combine non-technology and technology mediated face-to-face and/or distance education (Bonk,


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

Graham, Cross, & Moore, 2006). Dillenbourg et al. (2007) refer to these situations as “integrated

learning”, stressing this broad perspective that may also consider different pedagogical approaches.

Though we acknowledge the importance of other interrelated research dimensions such as

“evaluation” (Martínez-Monés, 2003; Soller et al., 2005), this dissertation relies on the crucial role

that “design” plays in the particular field within TEL (concerted with collaborative learning) termed

CSCL (Koschmann, 1996; Dillenbourg, 1999a; Stahl et al., 2006). Specifically, the dissertation

focuses on the ICT challenges that emerge from the role of teachers as the ultimate stakeholders in

charge of designing potentially effective CSCL situations that make use of learning environments

(or systems) (Häkkinen, 2002). The significance of this research focus within CSCL is motivated,

among other aspects detailed along the chapter, by the fact that most teachers are not technologist

and do not have always the support of technical experts when they need to arrange or modify the

functionality of the learning systems, so that it satisfies the requirements of their concrete

educational situations (Williams, Coles, Wilson, Richardson, & Tuson, 2000; Griffiths et al., 2005).

Before elaborating on this focus and its derived challenges, this chapter introduces the specific

characteristics of CSCL that differentiate it from related fields within TEL. Then, as schematized in

Figure 2.1, we analyze two important TEL design approaches, namely “Instructional Design” (ID)

(Reigeluth, 1999; Merril, 2002) and “Participatory Design” (PD) (Muller et al., 1993; Muller,

Wildman, & White, 1993), highlighting their implications for CSCL. Moreover, the distinguishing

facets of CSCL demand the study of a particular research line within CSCL, known as “Scripting

CSCL”, which proposes to structure the CSCL situations by means of scripts that guide

collaboration (O'Donnel & Dansereau, 1992; Dillenbourg, 2002; Kirschner, 2002; Fischer, Kollar,

Mandl, & Haake, 2007). Furthermore, in order to tackle the identified challenges we propose to

combine the approaches of two other parallel design-oriented research lines: Design Patterns (or

simply patterns) (Alexander et al., 1977; Gamma et al., 1995; Derntl et al., 2006) and EMLs

(Rawlings et al., 2002; Koper et al., 2004).

Therefore, the structure of the chapter is as follows. Section 2.2 introduces CSCL as a research

field within TEL. It describes the role of ID in CSCL, focuses on the scripting CSCL approach and

discusses the importance of PD in the design of this type of ICT applications. This analysis leads us

to identify a set of challenges for technically supporting the design of CSCL situations, which we

point out at the end of the section. Section 2.3 and section 2.4 are devoted to patterns and EMLs,

respectively, since we utilize them to propose a solution overcoming the challenges. A conclusion

envisaging how we generally approach this proposal, gradually developed in the following chapters,

is included in section 2.5.

16


DESIGN OF CSCL SITUATIONS

Technology-Enhanced Learning

Computer-Supported Collaborative Learning

Instructional Design Participatory Design

Design Patterns

Focus: Teachers as the designers

of CSCL situations in learning environments

Scripting CSCL

Challenges

Figure 2.1 Scheme of ideas developed in this chapter

2.2 From TEL to CSCL situations: design challenges

17

Educational Modelling

Languages

In principle, TEL includes different forms of technology: from the classical audio- and videotapes

(Avery, Avery, & Pace, 1998) to the new interactive furniture for classrooms (such as

electronic boards or interactive tables) (Mäkitalo-Siegl, Kaplan, Zottmann, Dillenbourg, & Fischer,

2007). However, it is the use of computers, and mainly computer networks, what has strongly

influenced the progress of the TEL domain (Koschmann, 1996). Our scope in this dissertation

focuses, accordingly, on the application of ICT to enhance education, particularly when

emphasising the role of collaboration as an important element of learning (Dillenbourg, 1999a).

2.2.1 CSCL as a research field within Technology-Enhanced Learning

More than a decade ago Timothy Koschmann, in (Koschmann, 1996), presents CSCL as a

emerging field of research in TEL (or Instructional Technology, as he refers to the broad domain of

using technology for instructional purposes). The historical evolution of CSCL is reviewed in detail

in a recent essay by Stahl et al. (2006). This review depicts how a global CSCL community has

developed from a series of biennially devoted conferences to the new international journal specific

to CSCL (namely ijCSCL).


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

In his highly referenced book chapter (Koschmann, 1996), Koschmann describes previously

existing TEL fields, namely CAI (Computer-Assisted Instruction), ITSs (Intelligent Tutoring

Systems) and the Logo-as-Latin paradigm, and points out the different assumptions that

characterize CSCL. The key difference relies on its perspective concerning the implications of the

social issues in the teaching and learning processes (Roschelle & Teasley, 1995). That is, CSCL

specifically approaches the support of social interactions among the students themselves, with a

teacher playing a mediator or facilitator role (Stahl, 2006).

In this sense, the theories underlying the “collaborative learning” model of education (Johnson

& Johnson, 1999) are socially oriented: Social Constructivism Approaches, Soviet Sociocultural

Theories, Theories of Situated Cognition, etc (Koschmann, 1996; Martínez-Monés, 2003).

Moreover, the CSCL research field is characterized as multidisciplinary (or inter-disciplinar) by

definition. It involves educational, computer and social sciences. As Koschmann states, CSCL is

“built upon the research traditions of those disciplines –anthropology, sociology, linguistics,

communication science- that are devoted to understanding language, culture and other aspects of

the social setting (Koschmann, 1996, pp. 11).”

The assumption that computers can support the collaboration process is also considered by the

CSCW (Computer-Supported Cooperative Work) field (Ellis, Gibbs, & Rein, 1991; Grundin, 1992;

Ellis & Wainer, 1994), which in this perspective is very close to CSCL. However, in contrast to

CSCL, which aims at promoting effective learning outcomes, CSCW points towards increasing

productivity in industrial and business settings. Undeniably, the different words of “learning” vs.

“work” that appears in both acronyms imply different fundamental objectives and, thus, different

approaches and methods to reach them. This discussion may lead the reader to wonder whether

there is also a difference between “collaboration” and “cooperation”, since they are also

distinguished in the acronyms. Though there are some authors that do not make distinctions in this

respect, Pierre Dillenbourg discriminates thoroughly cooperative and collaborative learning in

(Dillenbourg, 1999b): while in collaboration the students accomplish the activities “together”,

cooperation refers to a mere assemblage of partial results corresponding to a divided task. In other

words, genuine collaboration requires systematic efforts to work and learn together, the interaction

of participants should not be competitive or accidental (Stahl, 2006). In CSCL there are two main

(complementary) ways to facilitate these systematic efforts:

- monitoring the collaboration so that the teacher intervenes when necessary in order to

regulates the group so that it proceeds more fruitfully (Soller et al., 2005), and

- providing (beforehand) a set of instructions that scaffolds collaboration in such a way that

the probability of reaching successful CL situations increases (Dillenbourg, 1999b).

Concluding, CSCL is a multidisciplinary research field that seeks to enhance learning by

providing (networked) computer (or technology) support for collaborative learning, where “the

18


DESIGN OF CSCL SITUATIONS

words ‘collaborative learning’ describe a situation in which particular forms of interaction among

people are expected to occur, which would trigger learning mechanisms, but there is not guarantee

that the expected interactions will actually occur (Dillenbourg, 1999b, pp.5).” For the purposes of

this chapter, focused on the design of CSCL situations, the target is, therefore, to explore the

challenges and potential solutions that provide a satisfactory way to design CSCL situations which

promote the elicitation of productive interactions in terms of learning objectives (related to the

acquisition of knowledge, skills and competences or attitudes). Hence, next subsection discusses the

connections between CSCL and the ID approach largely used in other fields of TEL.

2.2.2 Instructional Design and CSCL

During decades ID methods have been applied to the development of instructional sequences

for individual learning. They offer explicit guidance on how to better help students learn and

develop (Reigeluth, 1999). That is to say, instruction is about designing in advance assignments

intended to promote learning (Kirschner, Carr, van Merriënboer, & Sloep, 2002). The traditional

methodology of ID encompasses the analysis, design, development, implementation, and evaluation

of instructional processes. In this way, ID researchers are proposing the use of notation systems to

record precise and minute details of designs in order to ensure correct duplication, execution and

communication, as other mature fields of study such as chemistry or musicology (Waters &

Gibbons, 2004).

Merril (2002) examines representative ID theories and concludes that, although they use

different terms and emphasize different perspectives, they share fundamental principles. These

principles are related to the idea that learning is promoted when knowledge is activated as a

foundation for new knowledge and it is applied by the student to solve real-world problems

(Herrington et al., 2000). Regardless, in practice designers do not make use of ID models, according

to the evidences discussed in (Kenny et al., 2005). Though these models represent helpful

conceptual frameworks, they are too rigid in that they are excessively linear, systematic and

prescriptive. Besides, it is still not clear whether the utility and adaptability of these models are

aligned along with the practitioners needs. This is probably due to that ID adopts general theories

and their models are not actually grounded in practice. This statement is also supported by

(Karagiorgi et al., 2005), who proposes the use of more pragmatic approaches to ID that could

facilitate the design of more situated, experiential, meaningful and cost-effective TEL situations.

On the other hand, several authors critic the value of the methods and tools derived from ID to

be used in CSCL. This is mainly caused by the design tensions that characterized this educational

field (Tatar, in press). Dillenbourg points out the risks of over-prescribing collaboration in

(Dillenbourg, 2002) and the needs of flexibility (Dillenbourg & Tchounikine, 2007). Goodyear et

al. criticize the teacher-centred behavioural approach of ID methods that underestimate the

19


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

complexity of learning processes (Goodyear et al., 2004), specially when they are collaborative

(implying flexibility, context dependency and social variables). Undoubtedly, CSCL situations

demand more flexibility than traditional rigid instructional sequences. Nevertheless, it is also true,

as the previous subsection hints, that planning successful CSCL situations entails well-targeted

effort at design time (Santoro, Borges, & Santos, 2004; Strijbos et al., 2004; Goodyear, 2005).

Consequently, some of the ideas coming from ID could be adapted to propose design approaches

for CSCL. In this case the focus is on designing for interaction, which should stress the promotion

of leaning experiences that benefit the students beyond the mere satisfaction of pedagogical or

technological needs of the instructional objectives (Kirschner, Strijbos, Kreijns, & Beers, 2004).

All these ideas are considered in (Strijbos et al., 2004). Strijbos et al. discuss that considering

the multitude of individual and group level variables that may affect collaborative processes, a less

rigid view of ID is necessary in CSCL. In this sense, designers should focus on methods that

support the learning (and interaction) processes, and not so much on the attainment of pre-defined

goals (since this attainment cannot be guaranteed for all participants). Thus, they propose a processoriented

methodology for the design of CSCL situations. The methodology ensures that student

participation is likely to lead to skill acquisition, by focusing on the elicitation of expected

interaction processes. In this sense, they identify five critical elements that affect the interaction:

learning objectives, task type, level of pre-structuring, group size and technology.

The “level of pre-structuring” element refers to shaping the way students interact with each

other. This scaffolding approach to facilitate social and cognitive processes in collaborative learning

environments is currently known as “scripting CSCL”.

2.2.3 Scripting CSCL

Scripting is a research topic within CSCL studied from cognitive (psychological) (Kollar,

Fischer, & Slotta, 2005), educational (Mäkitalo, Weinberger, Häkkinen, Järvelä, & Fischer, 2005)

and technological (Harrer, Hernández-Leo, & Dimitriadis, 2005; Miao, Hoeksema, Hoppe, &

Harrer, 2005) perspectives (Fischer et al., 2007). As the CoSSICLE European Research Team

describes, “computer-supported scripts (CSCL scripts or simply scripts hereafter) aim at facilitating

social and cognitive processes of collaborative learning by shaping the way learners interact with

each other. Being embedded in the learning environment, computer-supported scripts can optimally

structure interaction as well as support the learners with the very activity they are engaged in

(CoSSICLE, 2005).”

The purpose behind scripting can be of two types (Fischer et al., 2007). The first type refers to

external processes that should be internalized by the learners or influence the already internalized

script (Häkkinen et al., 2007). They provide support for specific activities by describing the finegrained

actions (e.g. question prompts, sentence starters, or descriptions) that each participant

20


DESIGN OF CSCL SITUATIONS

should accomplish (within such activities). This is the reason why they are called micro-scripts.

Weinberger et al. (2005) present two examples of micro-scripts that guide argumentation processes.

The goal of micro-script is that students learn the script; i.e., in the previous examples, how to

argument in order to construct knowledge together. In contrast, macro-scripts aim at organizing

situations that encourage targeted interactions potentially leading to learning outcomes, which are

not necessarily related to the internalization of the script (e.g. the script arranges fruitful discussions

by grouping students with different results in previous activities). Though the granularity distinction

is not purely binary, macro-scripts characteristically denote pedagogical methods defining flows of

coarse-grained activities (Dillenbourg et al., 2007). It is noteworthy that there exists a parallelism of

these ideas with some CSCW notions: (collaborative) learning flow or learnflow are terms used in a

similar way to the CSCW workflow or activity-level coordination, while the specific support within

activities implies relations with the action-level coordination as defined by Ellis et al. (1994).

This dissertation addresses macro-scripts (to facilitate the readability of the dissertation we refer

to macro-scripts as simply scripts hereafter), which mainly describe how groups (and individual

roles) should perform a set of interrelated activities. A framework for the description of scripts is

proposed in (Kobbe et al., submitted). It states that scripts can be specified with a small number of

components: the participants, the activities that they engage in, the roles they assume, the resources

used in each activity and the groups they form. In addition, mechanisms describe the distributed

nature of scripts: how participants are distributed over groups (group formation), how components

are distributed over participants (component distribution) and how both components and groups are

distributed over time (sequencing).

According to (Jermann et al., 2004), there are three different types of environments that can be

used to script collaboration. The first type takes advantage of natural (communication) tool

affordances (Kirschner, 2002; Brecht et al., 2006). In this approach, the teacher is in charge of

scripting the collaboration by socially scaffolding the students while working with the tools.

However, a more explicit technology-mediated coordination may be useful depending on the

characteristics of the educational situation (Dimitriadis et al., 2007). Another type of scripting

environment includes tools deliberately designed to structure collaboration. Some examples are

structured dialogue interfaces (Weinberger et al., 2005) or devoted tools for particular situational

subject areas (Dillenbourg, 2002). The third type refers to configuring existing LMSs (Muñoz-

Merino, Delgado-Kloos, Seepold, & Crespo-García, 2006) so that the scripts are organized through

navigation functionalities.

On the other hand, a crucial aspect regarding scripting CSCL is that scripts need to be carefully

designed. Incorporating collaboration approaches into educational situations involve risks,

especially when teachers and students are new to collaborative learning (Johnson & Johnson, 1999).

Moreover, over-scripting the situations may be counterproductive. Dillenbourg (2002) states that

21


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

while a certain degree of coercion is required for efficiency reasons (increasing the probability of

fruitful interaction), excessively constraining collaboration may disturb natural interaction

mechanisms. This fact together with the unexpected circumstances that can appear in CSCL

situations lead to a set of flexibility requirements pointed out by Dillenbourg et al. (2007).

Furthermore, (Häkkinen et al., 2007) points out the concern that the adoption of scripting

environments may not fit the specific situational needs and even create a conflict regarding the role

of the teacher. This definitely depends on who designs the functionality of the learning

environments that support scripting situations. Next section subsection explores PD as a promising

approach to deal with this concern.

2.2.4 Participatory Design and CSCL

As we advance in subsection 2.2.1, CSCL is a field soundly multidisciplinary. Therefore, it is

characterized by the coexistence of a priori very different expectations, requirements, knowledge

and interests posed by both teachers (collaborative learning practitioners) and technologists (ICT

experts), among other stakeholders such as institutions and students (Kirschner et al., 2002). This

fact implies a demanding requisite related to need of communication and mutual understanding

between all these actors (Dimitriadis et al., 2003). This would facilitate explicit thinking about the

border between the technical solutions and their context of use (Häkkinen, 2002). Along these lines,

the PD field appears as an interesting approach to consider when designing CSCL situations.

PD proposes a diversity of theories, practices, etc. with the goal of working directly with users

and other stakeholders in the design of social ICT systems (Muller et al., 1993). That is, PD

methodologies define processes where users and developers work together during a long period of

time, while they interchange values and identify the real requirements of the application. Muller et

al. (1993) include a brief guide to PD practices intuitively situated in a taxonomic space that is

summarized in Figure 2.2. The horizontal axis of the figure indicates the phase within the

development life cycle at which each practice may be useful. The vertical axis illustrates whether

the software professionals participate in the users’ world or it is the other way round. Of course,

both types of collaboration are valuable as well as the mixtures between them.

We argue that, in the CSCL case, PD is not only necessary when performing the identification

and analysis of requirements for the development of the CSCL solutions. On the contrary, we

recognize the importance of participatory modes of designing that go beyond plain communication:

the implied stakeholders should actively participate in the design of the learning environment

functionality according to the necessities of each particular educational situation. In this sense, we

underline the role of the teacher as the actual connoisseur of the concrete situation requirements.

That is, the design of CSCL situations requires of PD approaches where the users (in this case the

22


DESIGN OF CSCL SITUATIONS

teacher) participates in the technologist world along the whole development cycle, but with special

emphasis in the late tuning.

Figure 2.2 Taxonomy of PD practices (from (Muller et al., 1993)) Superscripted letters in the figure denote

appropriate group size for the practice: T (tiny, 2-4 participants), S (small, 6-8 participants), M (moderate, up

to 40 participants), and B (big, up to 200 participants)

2.2.5 Discussion: research focus and derived challenges

Recapitulating what the introduction of this chapter anticipates, this dissertation focuses on the

design of CSCL situations supported by ICT-based learning environments. Along this section we

have analyzed the requirements imposed by the characteristics of CSCL as well as their

implications regarding the ID and PD fields to the design of such technology-embedded educational

situations.

Thus, a critical concern in CSCL is to promote the elicitation of productive interactions as the

core learning mechanisms to reach educational objectives. From the design perspective it concerns

planning a set of instructions that scaffold the collaborative situation. When these sets of

scaffolding instructions are embedded in learning environments, they are called scripts. Our focus is

specifically on the scripts reflecting pedagogical methods that structure CSCL situations at the

macro-level, i.e. scripts that basically specify flows of activities and the groups (and roles) that

perform these activities.

23


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

The multidisciplinarity characteristic of CSCL entails the need of participatory modes of

designing. In the case of the scripting environments we put the accent on the role of the teacher,

who is the main stakeholder (and not the technologist) that should decide on the behaviour of the

scripting environment according to the particular requirements of the educational situations. This

PD requirement implies an important concern related to time and cost efforts in the development of

tools devoted to specific scripts (until now a new CSCL application should be developed to

implement each script).

Therefore, the challenges derived from this research focus are formulated as follows:

Challenge 1. It is not trivial to design scripts that potentially elicit the desired interactions.

There are many risks that can appear when putting scripts into practice. They are mainly

related to the lack of experience regarding CSCL (of some teachers and students), the

excessive coercion associated to over-scripting and how the teachers’ conceptions of

learning and the characteristics of the educational situation are consistent with what is

specified in the scripts.

Challenge 2. A modelling language should be used to formalize the scripts so that they are

computer-interpretable. To overcome the problem related to the PD requirement, a

promising approach is to use a computational notation system (e.g. an extensible markup

language (XML) “dialect” (W3C, 1996)) to represent the scripts so that they are

automatically interpreted by software engines integrated in learning environments such as

LMSs. This would allow the design of a computer-interpretable script for each situation

considering its concrete requisites without the need of developing a new scripting

environment.

Challenge 3. Computational representations are not familiar to most of the teachers. The

majority of the teachers do not have advanced technological skills, nor do they always have

the support of technical experts to create or adapt the computationally represented scripts.

The intricate mechanisms and components that comprise the descriptions of scripts

(interrelations of groups, synchronization of collaborative activity sequences, etc.) make these

challenges even more demanding. Concerning Challenge 3, a hopeful solution relies on providing

teachers with graphical authoring tools that generate computationally-represented scripts. These

graphical-based editors should use visualizations, concepts and representations familiar to the

teachers (Griffiths, Blat, García, Vogten, & Kwong, 2005; Griffiths et al., 2005; Harrer & Malzah,

2006; Botturi & Stubbs, in press). However, this solution should be combined with crucial

ingredients that undertake the other two challenges. Challenge 2, on the one hand, demands the

study of the existing EMLs in order to select or propose a computational notation suitable to

represent scripts characterized by complexity.

24


DESIGN OF CSCL SITUATIONS

Additionally, with regard to Challenge 1, the direction identified in the previous subsections

refers to the use of design process-oriented methodologies more pragmatic and less rigid than

traditional ID approaches. In this sense, the design processes should be grounded in practice instead

of in general theories (Dimitriadis et al., 2003; Karagiorgi et al., 2005; Kenny et al., 2005). Hence,

the processes should convey a design foundation that provides teachers with well-known

pedagogical strategies that encourage students to interact meaningfully while, at the same time,

these processes should enable the adaptation of the strategies according to specific context,

objectives and peculiarities of the target audience. A key point on the whole is to make the

pedagogical rationale of the critical elements behind the scripts explicit (Strijbos et al., 2004;

Häkkinen et al., 2007; Dillenbourg et al., 2007). Interestingly, very much in line with this

inquietude, design patterns are used in TEL and other disciplines such as Architecture and Software

Engineering as formulations of well-known solutions that can be applied and creatively adapted to

many different situations. Thus, this dissertation investigates the use of patterns to tackle Challenge

1. Next section is devoted to their exploration.

2.3 Design Patterns

Despite the fact that the word “pattern” has been used for centuries with slightly different

meanings (e.g. patterns for dressmaking (Holkeboer, 1987)), their use is more known in the fields of

Architecture (Alexander et al., 1977) and Software Engineering (Gamma et al., 1995). A pattern

provides a means of organizing information regarding a contextualized common problem and the

essence of its broadly accepted solution, so that it can be repetitively applied. A collection of

interconnected (related) patterns which enables the generation of a coherent whole (e.g. a town) is

called a Pattern Language (PL) (Alexander et al., 1977). Recently other domain specific patterns

have been proposed, including TEL and CSCL (Goodyear, 2005; Retalis et al., 2006; Derntl et al.,

2006). However, not all the TEL patterns follow the same approach, nor have the same purpose.

Before providing a unifying view of several approaches with different scopes regarding the use of

patterns in TEL, we introduce the traditional notion of patterns in Architecture and Software

Engineering.

2.3.1 Patterns in Architecture

The first PL was called “A Pattern Language: Towns, Buildings, Constructions” and was

published in 1977 by the architect Christopher Alexander (Alexander et al., 1977). In this book

Alexander defines a pattern as follows. “Each pattern describes a problem that occurs over and

over again in our environment, and then describes the core of the solution to that problem, in such

a way that you can use this solution a million times over, without ever doing it the same way twice.”

Patterns provide a structure for integrating the analysis and solution that can be found to a problem,

25


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

in a way that is sensitive to context. They suggest or offer guidance but require embellishment (E-

LEN, 2004a).

Alexander, driven by the moral preoccupation regarding the need for a good environment and

for the living structure of built environment (Alexander, 1999), introduces 253 patterns in the

architecture domain. He presents patterns for everything from designing independent regions, to

cities, buildings and even single rooms. By connecting these patterns with common forces and other

relations he transforms this collection of patterns into a PL. The interrelated patterns can be applied

sequentially so that the PL provides a consistent way of creating a comfortable environment for

people to live in.

Alexander aims that all design and construction would be guided by a collection of communally

adopted planning principles: patterns. He differentiates the terms design patterns and construction

patterns. While design patterns refer to understanding the geometry of a building and the

relationships between parts, construction patterns examine the materials and processes needed in

order to put the designs into practice. On page 207 of (Alexander, 1979), Alexander defines a PL as

“really nothing more than a precise way of describing someone’s experience of building”. Different

designers would select diverse subsets of patterns on different occasions and therefore use a

different PL for a building or part of it.

Apart from a vehicle of communication in which structured ideas can be discussed, shared and

modified, Alexander points out three essential features of a pattern language (Alexander, 1999):

- Moral preoccupation; something important and vital that goes, ultimately, to the nature of

human life. In architecture this preoccupation refers to the need for a good environment, and

for the living structure of built environment.

- Aim of creating coherence (morphologically coherent in the things which are made with it).

- Generativeness; create coherence of the created whole, with the power to generate such

whole in a million forms, with infinite variety in the details but with a guarantee of wellformed

results (Alexander et al., 1977).

On page 74 of (Alexander, 1999) two interesting comments are included regarding the

generative approach of patterns: “… one of the characteristics of any good environment is that

every part of it is extremely highly adapted to its particularities. That local adaptation can happen

successfully only if people (who are locally knowledgeable) do it for themselves.” “In our own time,

the production of environment has gone out of the hands of people who use the environment. So,

one of the efforts of the pattern language was not merely to try and identify structural features

which would make the environment positive or nurturing, but also to do it in a fashion which could

be in everybody’s hands, so that the whole thing would effectively then generate itself.” It is

26


DESIGN OF CSCL SITUATIONS

noteworthy how related are these ideas to the challenges that this dissertation faces (cf. subsection

2.2.5).

In Alexander’s latest 4 books of the series “The Nature of Order” (Alexander, 2003a;

Alexander, 2003b; Alexander, 2004a; Alexander, 2004b), he deepens in the “search for beauty” and

defends the existence of criteria and methods to determine if something is objectively beautiful and

what degree of live has. The core of the new theory presented in those books is the theory of

structure preserving transformations, which provide means for any step-by-step process to reach

configurations that are most capable of supporting life. A structure-preserving transformation is one

which preserves, extends, and enhances the wholeness of a system (Alexander, 2003b). This theory

relies on the idea of “centers” (Alexander, 2003a). A center is a kind of psychological whole entity

that is felt as a center in the visual field. Each living center is always created by configuration of

other centers (Alexander, 1999). During more than 20 years, Alexander examined objects for life

and wholeness. He identified 15 structural features which appear again and again in things which

have life: levels of scale, strong centers, boundaries, repetition, positive space, good shape, local

symmetries, deep interlock and ambiguity, contrast, gradients, roughness, echoes, the void,

simplicity and inner calm and not-separateness.

Example of Alexandrian patterns can be found mainly in (Alexander et al., 1977). For clarity

purposes and in order to present each pattern connected to other patterns, Alexander uses the same

format for each pattern (Alexander et al., 1977; E-LEN, 2004a). The relations with other patterns

are indicated in the introductory paragraph, setting the context of the pattern, and the final

paragraph, explaining how it can be embellished or completed. The essence of the problem and the

solution are highlighted in bold type. The solution is also shown in form of a diagram, with labels to

indicate its main components. This diagram is a key element to promote a good understanding of

the solution. Moreover, the patterns are marked with zero, one or two asterisks (*), which show how

“alive” we believe the pattern is. Two asterisks denote patterns that state invariants, i.e., these

patterns are essential and that the associated problem cannot be solved in a significantly different

way. One asterisk means that they are on the right track, but they can be improved. For patterns

with no asterisk, perhaps there are better ways of solving the problem, but they have not been found

yet.

2.3.2 Patterns in Software Engineering

At the beginning of the nineties the software community started using Alexander’s technique to

capture and communicate expertise in software design in general and object-oriented design in

particular. Although the movement started in universities and conferences such as OOPSLA

(Object-Oriented Programs, Systems, Languages, and Applications), the first book that was publicly

available was “Design Patterns” by Gamma, Helm, Johnson, and Vlissades called the Gang of Four

27


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

(GoF) (Gamma et al., 1995). It was published in 1995, and the authors presented a catalogue of 23

patterns that are a prescription of how to solve particular problems that come up in software

development.

Patterns in Software Engineering provide a common vocabulary, a common base of

understanding regarding what is important in software (vs. Architecture) and a large corpus of

solutions that makes developers more effective, i.e., they represent best practice, proven solutions,

and lessons learned, which aid in evolving software engineering into a mature engineering

discipline (Tesanovic, 2001). They name, abstract, and identify the key aspects of a common design

structure that make it useful for creating a reusable object-oriented design. Thus, patterns in

software identify the participating classes and instances, their roles and collaborations, and the

distribution of responsibilities. Each pattern focuses on a particular object-oriented design problem

or issue. It describes when it applies, whether it can be applied in view of other design constraints,

and the consequences and trade-offs of its use. On page 3 (Gamma et al., 1995) defines patterns as

descriptions of communicating objects and classes that are customized to solve a general problem

in a particular context”.

Among other aspects, Alexander’s and Gammas’ patterns diverge in their formats and tackle

different types of problems. Table 2.1 collects their similarities and differences (Gamma et al.,

1995; Alexander, 1999). The table does not intent to be complete but to comparatively summarize

their main characteristics.

Although Gamma’s patterns are the most popular among the software community, there are

now many other types of software patterns proposed in the literature (Buschmann, Meunier,

Rohnert, Sommerlad, & Stal, 1996; Riehle, 1996; Tesanovic, 2001). These patterns includes

architectural patterns (high-level strategies concerned with large-scale components as well as global

properties and mechanisms of a system), design patterns (micro-architectures of subsystems and

components), idioms (low level, paradigm-specific or language-specific programming techniques

that fill in low-level internal or external details of a component’s structure or behaviour). In

addition, there are approaches around domain-specific patterns and organizational patterns that

describe software process design (Coplien & Harrison, 2005).

Now that the main ideas regarding patterns in Architecture and Software Engineering are

reviewed, next subsection explores some important initiatives that aim at applying the pattern

approach to the educational domain, and especially to TEL and CSCL.

28


Definition

DESIGN OF CSCL SITUATIONS

Table 2.1 Comparison between Alexander’s and Gamma’s patterns

Alexander’s patterns Gamma’s patterns

Both adopt similar definitions of pattern: at the core of both kind of patterns is a solution to

a problem in a context

Patterns in buildings and towns:

solutions in terms of walls and doors

29

Object-oriented design: solutions in terms of

objects and interfaces

Emphasize the problems they address Describe the solutions in more detail

The solutions do not describe a particular final design, they are general principles or

templates that can be used in different situations

Vehicles of communication

Both are based on observing existing systems and looking for patterns in them

Identification There are many classic examples of

Few software systems can be considered classic

buildings

Structure /

format

Natural

language

Moral

preoccupation

Generativeness

Processes

Both use structures or formats for describing patterns

Fields of the format: a picture showing

an archetypal example of the pattern,

name of the pattern, an introductory

paragraph setting the context for the

pattern (explaining how it helps to

complete some larger patterns), ‘***’ to

mark the beginning of the problem, a

headline in bold type to give the essence

of the problem in one or two sentences,

the body of the problem (the forces) – its

background, evidence for its validity,

examples of different ways the pattern

can be manifested, the solution in bold

type (this is the heart of the pattern,

stated as an instruction, so that you know

what to do to build the pattern), a

diagrammatic representation of the

solution, ‘***’ to show the main body of

the pattern is finished, and a paragraph

tying the pattern to the smaller patterns

that are needed to complement and

embellish it.

Fields of the format: name and classification

(creational, structural or behavioural), intent

(problem that the pattern addresses), also known

as (other well-known names of the pattern)

motivation (a scenario illustrating a design

problem), applicability (situations where the

pattern can be applied), structure (a graphical

representation of classes in the pattern),

participants (classes and objects and their

relationships), collaboration (participants

collaborating to carry out responsibilities),

consequences (trade-offs and results of using a

pattern), implementation (things to be aware of

when implementing a pattern), sample code

(code fragment illustrating one implementation),

known uses (example of patterns found in real

systems), related patterns (other closely related

patterns).

Both rely on natural language and many examples to describe patterns rather than formal

languages (although Gamma et al. discuss about defining a formal representation of

patterns to make automating patterns possible as they state in (Gamma et al., 1995).

Under what circumstances is the Not clear whether there is or not a moral

environment good?

preoccupation (Alexander, 1999)

Generate complete buildings (pattern

language)

There is an order in which the patterns

should be used

Do not generate complete programs (catalogue

of related patterns) (Currently there are

proposals of generative PLs, which are designed

to shape system architecture and can generate

systems or parts of systems (Tesanovic, 2001))

There is no order suggested to apply the patterns

(Currently there are proposals that indicate

processes to apply patterns (Coplien &

Harrison, 2005))


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

2.3.3 Patterns in TEL and CSCL

A rather new and promising approach in TEL is to identify and collect best practices and

formulate them as design patterns that are gathered in repositories which will be eventually enlarged

with the addition of new patterns. Some projects which follow this objective are (PoInter, 2001; E-

LEN, 2004b; PPP, 2005; TELL, 2005b). In this context, patterns reflect the knowledge of experts in

a particular educational domain (e.g. CSCL) and they capture common solutions to recurrent

problems in an educational scenario. Since designing effective TEL scenarios is a complex

problem, design patterns based on sound research can help to guide the design process. Five main

advantages for adopting a patterns approach in e-learning design are pointed out in (E-LEN, 2004a)

and briefly reproduced below:

- Patterns are both empirical and normative, but not prescriptive. Capture expert practice in

specific context.

- Patterns have an internal structure that is good for action-oriented evidence-based advice.

Capture the most important aspects of a problem and a solution in a standard format with a

formalism, which documents and justifies the rationale.

- There is expressive and normative power in the relation between patterns.

- The pattern-based approach is inherently democratic and inclusive.

- Patterns can help to enrich the language of educationalists and to provide a common

nomenclature for designers. They can facilitate communication within interdisciplinary and

multi-perspective teams.

Patterns can be identified and constructed using mainly two methodologies: inductive pattern

mining (from specifics to generalizations), by analyzing common solutions in a set of educational

situations, or deductive pattern mining (from generalizations to specifics), by capturing the essence

of generic models for solutions to recurrent problems that experienced learning designers identify

(Baggetun et al., 2004; Retalis et al., 2006).

2.3.3.1 Different interconnected scopes of TEL patterns and related fields: focus on CSCL

Figure 2.3 aims at relating existing pattern proposals that refer to different scopes of the TEL

field. In general two main types of patterns can be distinguished depending on their use. Firstly,

patterns for analysis” deal with analyzing the usage of TEL systems in training or academic

contexts, in order to help the implied stakeholders continually improve them (PoInter, 2001). The

PoInter project is concerned with investigating the appropriateness of patterns as a means of

communicating information about how people interact with each other through technology (PoInter,

2001). This type of patterns may be also classified as patterns of interaction or patterns of behaviour

(Rada & Hu, 2002).

30


Analysis

Analysis of

interactions/

behaviour

DESIGN OF CSCL SITUATIONS

Patterns for TEL

CSCW

Design

Pedagogical

(CS)CL

31

(Technological)

LMS

Learning

objects

Figure 2.3 Relations between some proposals regarding patterns in TEL

Secondly, “patterns for design” are devoted to the design of TEL environments. This is the wide

scope of E-LEN project (E-LEN, 2004a; E-LEN, 2004a), which proposes patterns for implementing

an institutional e-Learning centre. Of a more specific scale are patterns devoted to particular

didactic areas, for example (Learning Patterns, 2005) is a project investigating patterns for the

design, development and deployment of games for mathematical learning.

Within this “patterns for design” scope, patterns for designing learning scenarios (pedagogical

patterns) and patterns for designing technological solutions that supports these scenarios

(technological patterns) can be differentiated. On the one hand, pedagogical patterns try to capture

expert knowledge of the teaching/learning practice in different educational situations, including

blended learning (Derntl & Motschning-Pitrik, 2004). This type of patterns propose solutions for

problems such as motivating students, choosing and sequencing materials, or evaluating students

(PPP, 2005). Some patterns for (CS)CL can be classified as a type of pedagogical patterns. It is

remarkable that a number of patterns developed within the E-LEN project are related to CSCL (E-

LEN, 2004b). However, the project devoted specifically to the development of patterns for CSCL is

the EU-funded e-Learning TELL project (TELL, 2005b), in which the GSIC/EMIC group has

participated. A deliverable of this project is a book with a collection of patterns representing key

aspects of CSCL (TELL, 2005a).

Some of the outcomes of E-LEN are presented in (Baggetun et al., 2004; Ronteltap, Goodyear,

& Bartoluzzi, 2004) and mainly in (Goodyear et al., 2004). This latter work suggests that design

patterns offer a useful method for sharing design ideas in participatory educational design work and

includes a pattern for “Discussion Group”. (Goodyear, 2005) deepens in these issues and illustrates

a pattern language for “Debate”. In these papers Goodyear conceptualises the problem space of

educational design differentiating the learning task, the organisational form and the space of tools


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

and artefacts. Once these three dimensions are well designed, students will configure their own

personal space, play an activity and construct a learning community, which are not (totally)

prescribed or determined (and thus cannot be predicted) by the educational designer.

On the other hand, technological patterns proposed in (Avgeriou et al., 2003) record design

experience with regard to the construction of LMSs (some of these patterns consider CSCL

requirements, e.g. those related to communication facilities). Similarly, patterns for ITS

architectures are collected in (Devedzic & Harrer, 2005). Focusing on learning objects reusability,

Jones (2004) proposes the use of patterns to produce reusable designs for creating learning

resources that are adaptable.

Patterns from other disciplines or fields can also be useful in the design of TEL. For example,

CSCL can be greatly benefited of knowledge in “groupware” or CSCW (cf. subsection 2.2.1). An

example of patterns for groupware is GAMA, a PL that provides patterns for supporting dynamic

teams using computer technology (Schümmer, 2003; Schümmer & Lukosch, in press). Patterns in

collaborative system design, development and use are also proposed in (Guy, 2003) and (David,

Delotte, Chalon, Tarpin-Bernard, & Saikali, 2003). For instance, one of the examples included in

(David et al., 2003) is about the management of a dialog among many participants. The pattern

reflects a generic process regarding floor control (give hand, ask hand, free hand) that can be

particularized into different processes that share the same principle of execution, i.e., use this kind

of floor control (e.g. a process for managing shared resources).

It is necessary to remark that there are not clear boundaries among the different approaches.

Patterns that result from interaction analysis are related (or can belong) to the domain of CSCL and

CSCW. Patterns for designing ANSCL (Asynchronous Network Supported Collaborative Learning)

systems (Georgiakakis & Retalis, 2006) can be considered both patterns for CSCL and patterns for

LMSs.

Having in mind important initiatives around TEL patterns, this dissertation aims at identifying

the types of patterns and the types of connections that link them with the objective of enabling the

generation of potentially effective scripts as an approach to solve the Challenge 1 (cf. subsection

2.2.5).

2.3.4 Discussion: the generative problem and the generation of potentially effective scripts

Baggetun et al. (2004) point out that TEL patterns are closer to Alexander’s notion of design

patterns than to Gamma’s view. There is a moral preoccupation around these patterns: under what

circumstances is TEL more efficient and effective? We agree with this statement but we also assert

that the generative power of TEL patterns is closer to Software Engineering patterns in the sense

that what TELL patterns describe should be actually supported by software.

32


DESIGN OF CSCL SITUATIONS

Alexander discusses the “generative problem and the generation of a living world” (relating this

problem to software) on page 79 of his keynote address in a conference on Object-Oriented

technologies (Alexander, 1999):

“I have, for many years, thought that this could only be solved by a genetic approach – an

approach where deep structure, spread through society, creates and generates the right sort of

structure, very much as genetic code creates and generates organisms and ecological systems –

indirectly by letting loose life-creating process.

That is what I still believe. But, today, I am convinced that the equivalent of the genes that act

in organisms will have to be – or at least can be – software packages acting in society. If these

software packages are life creating, and accepted, and widely enough spread throughout the world,

there is a chance we might get a grip on this problem: provided that the software is freeing,

liberating, allows each person individual control and decision making power to do the right

thing…”

In the case of TEL patterns, and particularly patterns for CSCL scripts, the generative problem

should go beyond the dissemination of these patterns in repositories, what is done until now (PPP,

2005; E-LEN, 2004b; TELL, 2005b). In contrast, it should be faced by means of providing users

(teachers, learning designers) with authoring tools that incorporate such patterns. According to

Alexander’s metaphor, the genes would be the functionalities of the tools that facilitate the creation

and generation of the right sort of collaboration scripts. If the functionalities of the tools, based on

the patterns, promote effective collaborative learning and are accepted and widely enough spread

through the educational institutions, there is a chance we might enhance learning effectiveness:

provided that the authoring tool allows users control and decision making power to design the right

script for their particular leaning situation.

This approach would provide a design solution grounded in scripting good practices that can be

particularized according to the concrete characteristics of an actual situation, where the “centers”

that appear again and again in the (potentially effective) scripts are the critical elements that likely

elicit the desired interactions. Moreover, not only would this solution overcome Challenge 1, but

the orientation inspired by Alexander also covers Challenge 3. The teachers should be the target

audience of the pattern-based authoring tools and, therefore, the technical details of the script

computational representation need to be hidden. Approaching Challenge 2, the following section is

devoted to review EMLs, as notation candidates to formalize the scripts.

33


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

2.4 Educational Modelling Languages

Learning Technology standards and specifications are growingly supporting the professional

activity of instructional designers (Rodríguez-Estévez, Caeiro-Rodríguez, & Santos-Gago, 2003).

The most widespread approach refers to metadata specifications (e.g. LOM) to describe reusable

chunks of learning content (so-called Learning Objects or LO) that can be used and referenced in

TEL environments (Hodgings, 2000). Recently, the standardization efforts are moving from content

delivery resources to EMLs, which are focused on specifying teaching-learning processes that stress

the importance of the activities. The definition of an EML is pointed out on page 8 of a survey of

EMLs (Rawlings et al., 2002):

“An EML is a semantic information model and binding, describing the content and process

within a ‘unit of learning’ from a pedagogical perspective in order to support reuse and

interoperability.”

This survey analyzes whether potential (non-proprietary) EMLs comply with the stated

definition. In the analysis it is underlined the concept of ‘unit of learning’ (also called ‘unit of

study’ or ‘unit of instruction’), which describes the learning design, the resources and the services

needed in order to achieve one or more interrelated learning objectives. A unit of learning

commonly refers to a course, module, lesson or curriculum. The conclusions of the survey

(accomplished in 2002) are that only OUNL-EML (Hermans, Manderveld, & Vogten, 2004) and

PALO (Rodríguez-Artacho & Verdejo-Maíllo, 2004) languages actually match up the definition of

an EML, with the nuance that OUNL-EML exceeds the expressive possibilities of PALO.

According to the survey, among other features, PALO is limited to the specification of individual

tasks.

OUNL-EML is the base of the IMS LD specification (IMS, 2003b), which is currently accepted

as a de facto standard for formalizing teaching-learning processes (Koper et al., 2004). On the other

hand, other approaches to ID languages involving similarities to EMLs are presently being proposed

as competing or complementary approaches to IMS LD. We present them in this section after

introducing the main issues around IMS LD.

2.4.1 IMS Learning Design

IMS LD Learning Design (IMS, 2003b) realised by the IMS Global Consortium (one of the

major bodies developing interoperability specifications for TEL) in 2003 (IMS, 2001), is the most

established EML at present (Koper & Tattersall, 2005; Burgos & Griffiths, 2005). The aim of IMS

LD is to enable the creation of complete, abstract and portable description of the pedagogical

approach taken in a course (or part of a course), which can be realized by a conforming systems.

The key idea is that it represents the learning activities (performed by learners) and the support

34


DESIGN OF CSCL SITUATIONS

activities (performed by teachers), including those comprising multi-role teaching-learning

processes and personalized learning routes (Koper et al., 2004).

2.4.1.1 Elements, features and organization of the specification

The conceptual model of IMS LD is shown in Figure 2.4. A Learning Design (an LD) is a

description of a method enabling learners to attain particular objectives by performing (learning and

support) activities in a certain order in the context of a learning environment. The environment

consists of the appropriate learning objects (e.g. pictures, books, software simulation) and services

(e.g. forums, chats) to be used during the performance of the activities. A method contains the play,

which is modelled according to the metaphor of a “theatrical play” with consecutive acts and roleparts,

which indicate the activities performed by each role participating in an act. IMS LD

integrates other specifications, such as IMS QTI (IMS, 2006) and IMS Meta-data (IMS, 2002), to

support the portable representation of units of learning (when they IMS LD compliant they are

usually written with capital letters). A Unit of Learning (UoL) is a content package (IMS, 2004a)

including an LD and a set of physical resources or their location. Further detailed information of

IMS LD elements can be found mainly in the specification (IMS, 2003b) and in a handbook

devoted to it (Koper & Tattersall, 2005).

Figure 2.4 The conceptual model of IMS LD (extracted from (IMS, 2003b))

35


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

As other specification and standards, IMS LD promotes the reuse and interoperability of LDs in

different TEL environments (Koper et al., 2004). This is facilitated thanks to the fact that IMS LD is

a generic language for formally expressing (computationally representing) educational situations

making use of a wide range of pedagogies, in such a way that it enables repeated execution in

different settings and with different participants (Tattersall et al., 2005). Therefore, the specification

includes an Information Model (complete description of the elements of the conceptual model), its

XML Binding (the binding of the information model conforming to the XML 1.0 Specification of

the W3C (W3C, 1996)) and a Best Practices and Information Guide (with examples as use cases).

Additionally, it considers three levels of implementation and compliance (IMS, 2003b; Koper et al.,

2005):

- Level A contains all the core aforementioned vocabulary needed to support pedagogical

diversity.

- Level B adds properties and conditions to level A, which enable personalization and more

elaborate structures. By also using global elements and monitoring services, it enables to

direct the learning activities as well as record personal, group or collective outcomes.

- Level C adds notifications to level B, which, also enables to control the flow of activities or

to send alerting e-mails.

Although LD does not prescribe any methodology for the creation of UoLs, Designer’s Guide,

included in (IMS, 2003b), proposes general stages for creating a UoL. (Sloep, Hummel, &

Manderveld, 2005) details these stages according mainly to three phases. The first phase involves

the analysis of a specific educational problem, whose result is a narrative description of the

educational situation. Then, the narrative is translated into a UML (Unified Modelling Language)

activity diagram (Arlow & Neustadt, 2001) in the design phase. The diagram is the basis for the

XML instance IMS LD compliant document. In the fourth phase the resources are developed (if

necessary) and added to the design. Thus, a UoL is created.

2.4.1.2 Interoperable IMS LD compliant tools

The abovementioned basic design procedures are useful if the users that create the UoL are IMS

LD experts. However, other types of users require more abstract procedures that facilitate the design

of UoLs. This is to a large extent related to the type of authoring tool that may implement those

procedures (Griffiths et al., 2005). Griffiths et al. (2005) classify the tools according to two

dimensions according to their type of user (technical expert, instructional designer, teacher) and

their degree of pedagogical specialization:

- Higher vs. lower level tools (or distant from specification vs. close to specification). This

dimension is related to the level of expertise on IMS LD required by the user of the tool.

36


DESIGN OF CSCL SITUATIONS

That is, how much the tool interface is influenced by IMS LD or how many IMS LD details

it hides.

- General purpose vs. specific purpose tools. This dimension deals with the pedagogical scope

of the tools. Teachers using a clearly defined pedagogic approach would not need all the

capabilities of the IMS LD specification. This implies that authoring tools more tightly

focused on that particular pedagogical approach might present to their users only the needed

functionality, reducing significantly the complexity of authoring.

Among the IMS LD compliant editors, RELOAD (Davis, 2002), CopperAuthor (van der Vegt,

2005) and CoSMoS (Miao, 2005) are examples of general purpose editors that are close to the

specification. Their users are IMS LD experts that are not focused on a particular pedagogy.

Similarly, MOT+ editor (de la Teja et al., 2005) and ASK-LDT (Sampson et al., 2005) are intended

also for expert learning designers rather than teachers, although they provide graphical

representations that facilitates to a certain extent the authoring task. On the other hand, LAMS

(LAMS, 2006) is a specialized editor because it offers a set of predefined learning activities, shown

in a comprehensible way for teachers, that can be graphically drag and drop in order to establish a

sequence of activities. Nevertheless, although LAMS is inspired by the same LD philosophy, it is

not LD compliant at the present time.

On the other hand, there are several IMS LD compliant players or LMSs available or under

development at present. Some of them are based on CopperCore engine (Martens et al., 2005), such

as RELOAD LD player or Gridcole (Bote-Lorenzo, 2005), and others include their own IMS LD

engine, such as .LRN (E-LANE, 2004).

Though the amount of developments around IMS LD is significant, its adoption in real practice

is however in its infancy (Burgos & Griffiths, 2005). This is not strange since the specification has

been released recently, as well as the corresponding tools. However, this fact makes unclear the

possibilities and limitations of IMS LD for representing specific requirements of educational

scenarios, including CSCL situations (Caeiro-Rodríguez et al., 2003). This open up the path to other

proposals of related EMLs approaches.

2.4.2 Other approaches

In addition to IMS consortium, ISO/IEC JTC1/SC36 develops standards in the domain of TEL.

Particularly, WG2 is devoted to collaborative technology (ISO/IET, 2002). WG2’s efforts are

focused on standardizing the Collaborative Workplace (data collection and reuse for collaborative

environments), Learner to Learner Interaction Scheme (peer-to-peer and group), and Agent/Agent

Communication (agent-based interfaces in collaborative environments). However, its progress in

the last four years has been limited and no official outcome has yet become available. In fact, its

37


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

proposal regarding Learner to Learning Interaction Scheme has similarities to IMS LD and the WG

has recently agreed to re-name this project to “Data Model for Text-based Communication by the

Study Group”.

Besides, other ID languages are emerging as complementary approaches (e.g. providing visual

representations) or alternatives to IMS LD (Vignollet et al., 2006; Botturi & Stubbs, in press). A

selection of them are comparatively categorized in (Botturi, Derntl, Boot, & Figl, 2006) according

to a classification framework that defines IMS LD as a notation system that is formal, textual, and

of a single perspective. We would classify almost similarly the newly proposed Learning Design

Language (LDL) to model collaborative activities (Martel, Vignollet, Ferraris, David, & Lejeune,

2006b), which also includes a graphical representation associated to each concept.

On the contrary, some available notations do not provide a stringent set of rules for describing

designs but more open, typically visual (in contrast to textual), ways of informally describing

educational situations, such as E 2 ML (Educational Environment Modelling Language) (Botturi,

2006) or the proposal of an AUTC (Australian Universities Teaching Committee) project (Oliver,

Harper, Hedberg, Wills, & Agostinho, 2002; Bennett & Lockyer, 2004). E 2 ML, in a similar spirit to

UML, is a multiple-perspective language. It makes use of different diagrams to provide different

views of the same designs (e.g. chronological vs. structural perspectives). In the same way, the

ongoing PoEML (Perspective-oriented EML) proposal tackles the design of educational units from

different perspectives aiming, at the same time, at achieving precision regarding the implementation

details (Caeiro-Rodríguez, Llamas-Nistal, & Anido-Rifon, 2006a; Caeiro-Rodríguez, Llamas-

Nistal, & Anido-Rifon, 2006b).

2.4.3 Discussion: IMS LD as a candidate to computationally represent CSCL scripts

The competing approaches to IMS LD have been proposed during the realisation of this

dissertation. That is the reason why we initially select IMS LD as a potential candidate to

computationally represent the CSCL scripts, so that it represents a solution to Challenge 2 (cf.

subsection 2.2.5). (We use simply LD instead of IMS LD henceforth in order to achieve a more

readable text, when the context does not lead to misunderstandings with related approaches.) The

scripts describe collaborative learning situations that, according to the definition of the

specification, LD supports. Moreover, LD is an open specification agreed upon by domain and

industry experts (members of the IMS consortium), what envisages promising interoperability

prospects. If the scripts are formalized using LD they could be executed in any LD compliant

environment, with the associated benefits in terms of costs (reusability, adapted reproducibility,

etc.) that it provides.

38


DESIGN OF CSCL SITUATIONS

However, as we have previously advanced, the LD support for realizing scripts is not clear. This

is partially motivated by a lack of significant examples and efforts that show the possibilities of LD

for CSCL. Although partial work has been already accomplished (Gorissen et al., 2005; Koper et

al., 2005), a more complete and systematic analysis is needed. On the other hand, the audience on

which we focus the problem of designing computer-interpretable scripts are teachers that are not

necessarily technologists, nor LD experts. In this sense, if the LD notation is selected as appropriate

to express scripts, the mentioned LD compliant authoring tools would not be suitable to cover

Challenge 3.

2.5 Conclusion

In CSCL one way to use the technology (in this case ICT) so that it facilitates and improves the

teaching and learning experience is by means of (macro-)scripts supported by learning

environments. However, the design of such CSCL situations is not trivial and involves three main

challenges that are identified along the chapter. The conclusions about the challenges and the

envisaged potential solutions are developed next.

Challenge 1 is around the demanding aspects implicated in the design of potentially effective

scripts. On the one hand, the scripts should structure the organization of activities and groups so that

the situation promotes the elicitation of fruitful interactions that lead to learning outcomes. On the

other hand, the risk of excessive coercion and collaboration in general (especially when proposed

by novice CSCL practitioners) should be strongly considered. The same complexity that demands

flexibility claims a meticulous previous design of the CSCL situations.

Therefore, re-inventing and designing scripts for a particular educational situation is costly and

risky. In this sense, a solution would be unravelling content, tools, specific learning tasks, etc. from

the structure of the script (it may represent the essence of the collaborative learning design) so that

the structure (or the different script components and mechanisms reflecting designs solutions) can

be applied and reused in different learning situations and contexts. The effort involved in

developing separated generic reusable elements of scripts is justified if they have been extensively

tested and applied in a broad range of different settings. In this way, scripts based on these

commonly used elements (good or best practices) represent potentially effective scripts. These good

practices can be formulated as patterns so that they are written in structured formats that make

easier their understanding, (re)use, classification and relation among them.

Not only are the time and cost demands imposed by the design of the situations but also for their

implementation in the learning environments (e.g. LMSs). Challenge 2 proposes to use a

computational notation system to formalize the scripts so that they are interpreted by the

environments (without the need of software development efforts). The complex mechanisms and

39


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

components that comprise the descriptions of scripts impose difficult requirements to a candidate

notation. Among the EML proposals, the declaration of intent and interoperability prospective of

LD specification lead us to select it as the most interesting aspirant.

Altogether foresees a promising approach that enables participatory modes of designing in

which the teacher is the main stakeholder deciding on the behaviour and functionality of the

scripting environment according to the particular requirements of the educational situations. The

incorporation of patterns (for scripting CSCL) in design processes would provide more pragmatic

methodologies, grounded in practice, than traditional ID approaches. These design processes would

provide teachers with customizable well-known pedagogical methods according to CSCL critical

elements. Furthermore, the patterns would embody representations and abstractions that are easier

to understand by teachers (interested in CSCL) than the details of some IMS LD elements. If the

pattern-based design processes are graphically integrated into (high-level) authoring tools, teachers

without advanced LD knowledge would be able to create their own scripts, thus overcoming

Challenge 3.

40


CHAPTER THREE

CONCEPTUAL MODEL FOR CSCL

SCRIPTING PATTERN LANGUAGES

This chapter tackles the objective of identifying the types of patterns and relationships

between patterns that can be used in the design of CSCL scripts. Its contribution consists

in a conceptual model for CSCL scripting pattern languages and a specific pattern

language that is compliant with the model. This contribution aims at providing to the

community a starting point towards an agreed structure for the production of patterns for

CSCL scripting. In this dissertation it specifically serves to situate the rest of its

contributions. In order to validate the feasibility of the model, the chapter also discusses

three authentic situations that apply a sequence of interconnected patterns selected from

the proposed pattern language.

The hierarchical structure for CSCL scripting patterns characterized by the conceptual

model is introduced in (Hernández-Leo et al., 2006d), while (Hernández-Leo et al.,

2006) presents a real experience that applies a script generated with the proposed pattern

language.

3.1 Introduction

How can design processes grounded in practice for creating CSCL scripts be provided? The

previous chapter identifies patterns as a promising way of formulating and sharing experience

regarding the design of potentially effective scripted collaborative learning situations.

Design patterns capture reusable knowledge about a problem and its associated broadly

accepted solution. They are useful to understand the critical elements that should be considered

within a design process. Patterns are decoupled when they are applied. However, they work

together with other interconnected patterns to generate emergent contextualized wholes. A Pattern

Language (PL) embraces a set of patterns relevant to a specific design space and the rules that put

together the patterns in meaningful ways so that they provide guidance when building a spacerelated

whole.


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

The previous chapter reviews the pattern-based approaches adopted in Architecture, Software

Engineering and, also, in TEL. Besides, it provides a unifying view that link several representative

proposals with regard to patterns in TEL and related fields differing in scope and perspective. This

chapter is devoted to the identification of the types of patterns and connections between patterns

that can be used for generating CSCL scripts. These types of patterns and relationships are

formulated as a conceptual model (or meta-language) for describing CSCL scripting PLs. That is to

say, CSCL scripting is the design space of the patterns and rules that can be situated in the proposed

conceptual model. This conceptual model aims at providing to the scientific community an

important starting point towards an agreed high-level structure for the production of patterns and

PLs that enable the generation of CSCL scripts. Each institution or community of practice may have

its own patterns of effective scripted CL situations (which somehow typify the community). The

sharing and communication of these good practices within and between communities can be

fostered if they are framed within the same conceptual model.

To illustrate the feasibility of this proposal, Appendix A includes a CSCL scripting PL (with

own and adopted patterns) that can be described with the conceptual model. The PL comprises 18

patterns. Each pattern documents the relationships to other patterns. The map of relationships

sketches many ways in which the patterns may be put together when creating different CSCL

scripts. Depending on the context derived from a particular educational situation, different patterns

and connections of patterns may or may not apply. Nevertheless, it is important to point out that the

PL is not complete as a set in the sense that their patterns cannot be used to generate any CSCL

script. Each community can augment the PL with its patterns or propose a different one (that might

borrow some of the considered patterns).

Furthermore, the chapter exposes three different scripted CL situations that can be generated

using the proposed PL. These situations express and illustrate the relationships between the patterns

and exemplify how the diverse types of CSCL scripting patterns can be applied.

Therefore, this chapter is structured as follows. Section 1.2 introduces the methodology applied

to propose the model and the illustrating PL. The conceptual model for CSCL scripting PL is

presented in section 3.3. It is presented in form of an aggregation model (according to the

granularity and scope of the types of CSCL scripting patterns) and description of types of pattern

connecting rules. A hierarchical structure depicting how the PL included in Appendix A fits in with

the conceptual model is also introduced in this section. In addition, it contains a discussion of how

this model is linked to other potential models of related PLs and points out some general guidelines

for applying the PLs that can be described with the conceptual model. Section 3.4 is devoted to

exposing the three situations based on interrelated patterns embraced in the PL. One of them is

explained in more detail since it is designed from scratch using the PL (the other two are used as

case studies to identify some of the proposed patterns). Section 3.5 discusses the potential

42


CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

computer-supported applicability of CSCL scripting patterns. Finally, the conclusions of this

chapter are presented in section 3.6.

3.2 Methodology applied for proposing the model and the pattern language

Chapter One describes the research methodology adopted in this dissertation in detail. The

phases involved in this chapter are: the informational, the propositional and the analytical phase.

Some of the conclusions resulting from the informational phase are reported in Chapter 2,

which includes a review of important pattern-based approaches in TEL. These conclusions together

with the significant influence related to the participation in the GSIC/EMIC multidisciplinary

research team (GSIC/EMIC, 1994) and the TELL project (TELL, 2005b) are considered in the

propositional phase. In this phase the conceptual model for CSCL scripting PLs and the patterns

included in the illustrating PL are proposed. The analytical phase includes a concept

implementation regarding the description of the PL with the proposed conceptual model. It also

analyzes the generative characteristic of the PL by providing educational situations drawn from real

practice which apply a set of interrelated patterns (belonging to the proposed PL).

Nevertheless, the tasks included in the different phases are actually realized in several iterations.

Before proposing the final version of the conceptual model, most of the patterns in Appendix A are

formulated by us or adopted from other authors. Some of these patterns are identified using the

information provided in the literature, following a deductive or top-down approach (Baggetun et al.,

2004) but others are discovered in case studies, using a more inductive or bottom-up approach

(Brouns et al., 2005). These case studies are two of the three educational situations that we provide

to illustrate how the CSCL scripting patterns can be applied. This approach is commonly used to

show the feasibility of a PL (Coplien & Harrison, 2005; Lukosch & Schümmer, 2006). The third

situation is strictly generated using the PL from the scratch. Describing the pattern-based generation

of the situations is also helpful to reflect and illustrate the types of relationships between the

patterns that form meaningful sequences.

Next subsections look at the techniques we use to formulate the patterns, that is: the problem,

forces and solution for each pattern. We capture the patterns in a pattern form similar to the

Alexandrian format, as it is approached in the TELL project and in other proposals such as (Coplien

& Harrison, 2005; Goodyear, 2005). The pattern format organizes the important components of a

pattern. The body of each pattern starts with an introductory paragraph setting the context in which

that pattern applies. This paragraph explains how the pattern is related to other larger patterns. A

problem may arise in that context; therefore, the essence of the problem comes next in bold type.

After that, the pattern elaborates on the background of the problem, the evidence for its validity and

a description of the forces that define the problem and conduct to the solution. Then, the pattern

43


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

presents a proven solution, also in bold type, which solves the stated problem in the stated context.

A diagrammatic representation of the solution is often enclosed, which makes easier its

understanding. Finally, the pattern concludes with a paragraph relating the pattern to the smaller

patterns which are needed to embellish it.

We also use asterisks to show how mature the patterns are. Two asterisks denote that they

benefit from many years of experience and research and we are sure of their maturity and value.

One asterisk means that they are on the right track, but they can be probably improved. Patterns

without asterisks indicate that more research should be accomplished to state that the proposed

solution reflects the “best” way of solving the problem.

3.2.1 Capturing the experience reported in the literature

Some of the patterns collected in Appendix A have been identified and constructed according to

the experience broadly reported in the literature. In other words, the resulting patterns represent

best/good practices (when scripting CL situations) that have been extensively tested and applied in a

broad range of different situations (including different content and disciplines) and on which there

are many publications on research or practical results. Therefore, the resulting patterns actually

derive from practice (didacticism used in the practice) rather than from general learning theories

(Johnson & Johnson, 1999; King, 2007; NISE, 1997).

One very well-known example in this sense is the “Jigsaw” strategy, which is introduced by

Aronson & Thibodeau (1992) and Aronson & Patnoe (1997) but also applied by other authors such

as Clarke (1994) or DiGiano et al. (2003), among many others. A generalization of the strategy is

formulated as the JIGSAW pattern in Appendix A (Pattern 1.1). Briefly, it proposes that in order to

solve a complex problem that can be easily divided into independent sub-problems, each participant

in a (small) group (“Jigsaw Group”) studies or work around a particular sub-problem. The

participants of different groups that study the same problem meet in an “Expert Group” for

exchanging ideas. These temporary groups become experts in the subproblem given to them. At

last, participants of each “Jigsaw group” meet to contribute with its “expertise” in order to solve the

whole problem. Some of the educational objectives this strategy favours are: to promote the feeling

that team members need each other to succeed (positive interdependence), to foster discussion in

order to construct students’ knowledge and to ensure that students must contribute their fare share

(individual accountability).

Other patterns included in Appendix A that are formulated following this approach are:

PYRAMID (Pattern 1.2) or SNOWBALL (Davis, 2002; Gibbs, 1995), THINK-PAIR-SHARE or TPS

(Pattern 1.3) (NISE, 1997; Millis & Cottell, 1998), BRAINSTORMING (Pattern 1.4) (NISE, 1997;

Millis & Cottell, 1998), SIMULATION (Pattern 1.5) (Paulsen, 1995; Fablusi, 2000) or THINKING

44


CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

ALOUD PAIR PROBLEM SOLVING (Pattern 1.6) (NISE, 1997; Millis & Cottell, 1998; Slavin,

1995).

We argue that this mining method is not purely top-down nor bottom-up. It is however an

intermediate approach in which the patterns are discovered after numerous implementations of

learning scenarios in different settings, and whose benefits are reported in the literature. A similar

approach is exposed in (Retalis et al., 2006), where they follow a reverse-engineering process for

identifying embedded good design practices in e-learning systems and, at the same time, analyze the

way users employ those systems in authentic scenarios. The resulting patterns for CSCL systems

can be found in (TELL, 2005a; Avgeriou et al., 2003). One of them, MANAGEMENT OF ON-LINE

QUESTIONNAIRES (cf. Pattern 3.2 of Appendix A), has been adopted for our CSCL scripting

pattern language.

3.2.2 Using case studies as a starting point

Other patterns presented in Appendix A are distilled using case studies related to scripted CL

situations as a starting point. Some of them are a result of the TELL project (TELL, 2005b; TELL,

2005a) and, therefore, the process we follow is based on the procedure employed in the project.

A case study serves as a starting point for the initial selection of titles and topics for potential

patterns. Additionally, this first case study analysis and our previous experience capturing patterns

in the literature lead us to reflect in the different types of patterns and relationships between them.

The case study we use in this sense analyzes an experience that takes place within a course on “the

use of ICT resources in education” (NNTT, its acronym in Spanish) at the Faculty of Education,

University of Valladolid, Spain (Ruiz-Requies et al., 2006). However, the design of this experience

also benefits from a previous case study also carried out by the members of the GSIC/EMIC group

(GSIC/EMIC, 1994). This earlier case study concerns a course on “Computer Architecture” (CA) at

the School of Telecommunications Engineering, University of Valladolid, Spain (Martínez-Monés

et al., 2005). It is noteworthy that though the content and discipline of the case studies are different,

NNTT reuses several design issues applied and deeply evaluated in CA.

During the enactment of the NNTT case study, we iteratively write and evaluate the patterns.

Several meetings involving the different stakeholders related to the case study are carried out to

discuss the content of the patterns. Therefore, the teachers involved in the case study and the

researchers monitoring its results largely influence the formulation of the patterns. Literature on the

topic of the problems tackled by the patterns is also consulted with the aim of complementing the

analysis of their forces and the associated solutions. In this phase, we continue looking for links

between the patterns so that together form meaningful designs. This process also enables to detect

connections between patterns written and not written yet (Goodyear et al., 2004).

45


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

Thus, the identification and construction of the patterns is basically accomplished by: a careful

questioning of an expert designer about why he designs in a certain way and by distilling them from

our observations about specific instances of good design (E-LEN, 2004a).

Furthermore, a workshop for reviewing the patterns is carried out as part of a meeting of the

TELL project. Feedback from the patterns is received in this meeting and in following

asynchronous messages. Each pattern receives two reviews from two different participants in the

project.

Using the NNTT case study as a starting point, the following patterns included in Appendix A

are proposed: ENRICHING THE LEARNING PROCESS (Pattern 1.7), INTRODUCTORY

ACTIVITY: LEARNING DESIGN AWARENESS (Pattern 2.1), PREPARING FRUITFUL

DISCUSSIONS USING SURVEYS (Pattern 2.3), ENRICHING DISCUSSIONS BY

GENERATING COGNITIVE CONFLICTS (Pattern 2.4), GUIDING QUESTIONS (Pattern 3.3)

and FACILITATOR (Pattern 4.1). As mentioned in previous subsection, JIGSAW (Pattern 1.1) and

PYRAMID (Pattern 1.2) are formulated using the information provided by the literature, but they

are also applied in this experience. Since NNTT benefits from the practice of the CA case study,

CA also exhibits some of these patterns. Section 3.4 details how these patterns are applied in the

pedagogical designs of both cases studies.

Other patterns considered in the CSCL scripting pattern language are proposed by other authors

within the TELL project and, thus, also formulated using this procedure. They are THE

ASSESSMENT TASK AS A VEHICLE FOR LEARNING (Pattern 2.5) and STRUCTURED

SPACE FOR GROUP TASKS (Pattern 3.1).

As aforementioned, all these patterns can be related forming a PL that outlines many different

possibilities of designing a script. The methodology presented in this section lead us to identify the

different types of patterns and relationships between them that can appear in potential CSCL

scripting PLs. Next section introduces a conceptual model for PLs covering the CSCL scripting

design space, and discusses how the considered type of patterns and relationships actually appear in

the illustrating PL.

3.3 CSCL scripting pattern languages model

It is clear that CSCL scripting is not an isolated design space. In contrast, it is highly

interrelated with other spaces involved in educational design. Figure 3.1 shows how the package

concerning the patterns for designing CSCL scripts is related with other types of patterns considered

in at least other two packages. Higher level patterns of CSCL scripting patterns are those related to

high level pedagogy (e.g. problem based learning, inquiry learning) (Goodyear, 2005). In this case,

46


CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

the pedagogical approach directly related to the CSCL scripting patterns is described in the

SCRIPTED COLLABORATION pattern (pattern 11 from (E-LEN, 2005)).

Figure 3.1 CSCL scripting pattern language conceptual model package and relationships with other models

Moreover, patterns devoted to diverse didactics for specific subject matters are also relevant

when designing a script for a specific discipline. The learning problems, the typical misconceptions

and difficulties that the students face in particular subjects are well documented. While the

strategies related to eliciting desired social interactions are common among the scripts, the insight

and experience of, for example, mathematics education (Learning Patterns, 2005) or programming

languages education (Holland, Griffiths, & Woodman, 1997; PPP, 2005) are also helpful in the

design of scripts for such domains.

Therefore, CSCL scripting PLs are embraced by larger PLs regarding pedagogical approaches

and are complemented with other PLs capturing educational experience of specific knowledge

domains. This is similarly approached, for example in Architecture patterns (Alexander et al.,

1977), where a PL for building a porch completes a larger PL for designing a house; and in

Organizational patterns for agile software development (Coplien & Harrison, 2005), which

proposes that a “Project Management PL” complements a “People and Code PL”.

Having explained that, next subsection focuses on the CSCL scripting PLs package and details

the conceptual model for these PLs.

3.3.1 Aggregation model and types of connecting rules

The conceptual model for CSCL scripting PLs proposed in this dissertation comprises an

aggregation model expressed as a UML class diagram and the types of connecting rules that relate

the patterns situated at the same and different levels of aggregation.

47


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

Figure 3.2 represents the aggregation model of CSCL scripting PLs. Conforming to UML; the

diagram represents aggregation (and composition) relationships and specializations of abstract

classes. The aggregation model fits in well with the target design space, since the good practices

applied when creating CSCL scripts can be grouped at different granularity levels: set of activities

that are organized in CL flows vs. single activities vs. the resources (materials and tools) that

supports the single activities. Patterns at the different levels are complementary and need each other

for completeness, so they can be aggregated or related forming a hierarchical structure (which

represents the structure of pattern languages for CSCL scripts). Though next subsection shows a

graphical hierarchical structure illustrating how the PL included in Appendix A fits in with the

conceptual model, we use some patterns in the explanation of the different aggregation levels.

Figure 3.2 Aggregation model of CSCL scripting Pattern Languages

Some authors already distinguish between macro scripts and micro scripts (Fischer, Kollar,

Mandl, & Haake, 2007). As deeply exposed in Chapter Two, coarse-grained (or macro) scripts

describe general flows of collaborative (or not) learning activities (e.g. those following the Jigsaw

strategy). Fine-grained (or micro) scripts give detailed support within specific activities (e.g. scripts

for argumentative knowledge construction (Weinberger, Fischer, & Stegmann, 2005)). In the same

sense, the highest (coarser) aggregation or granularity level for CSCL scripting patterns is related to

the CL flow: the sequence of activities that make up a learning process. Some examples of patterns

at this level are JIGSAW and PYRAMID patterns (cf. Pattern 1.1 and Pattern 1.2 of Appendix A),

whose solutions form a generalization of actual learning flows. Other patterns directly related with

the learning flow but not necessarily proposing a flow structure are also situated at this level.

Another granularity level refers to the activities themselves. An example of a pattern at this level is

DISCUSSION GROUP (Pattern 2.2). In addition, we propose a third (lowest) granularity level that

48


CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

includes the resources (materials and tools) needed to support the activities. Some examples are

the patterns proposed in (Georgiakakis & Retalis, 2006) such as MANAGING ON-LINE

QUESTIONNAIRES (Pattern 3.2). These tree types of granularity correspond to three aggregation

levels shown in Figure 3.2.

Besides, there are some aspects (such as roles or common collaborative mechanisms, namely

group formation, floor control, awareness) that can be connected directly to some of the patterns at

any of the aforementioned granularity levels. For example, roles can be defined globally at the level

of the whole learning flow, within activities or/and within collaborative tools (e.g. usage of the

FACILITATOR pattern, Pattern 4.1). Thus, the patterns that state a principle about these aspects are

usually integral parts of learning flows, activities or resources. That is the reason why this level has

a composite relationship with the others, which, in contrast, can exist independently.

We have already insisted on the idea that the connections rules between patterns are as much

part of a PL as the patterns themselves. Each pattern provides a possible context for any patterns

that appear at the same level or below it. In other words, a pattern serves to embellish higher-level

patterns, to work alongside patterns at the same level, and to provide a context for lower-level

patterns. This organization provides a powerful way of expressing educational design knowledge

and formulating comprehensible guidance. Particularly, the types of connecting rules between

CSCL scripting patterns at the same and across levels of aggregation are presented in Table 3.1.

Table 3.1 Types of connecting rules (relationships) between patterns at the same and different levels of

aggregation

Types of connecting rules between

patterns at different levels

Types of connecting rules between

patterns at the same level

49

- Complete (embellish)

- (Complement)

- Complete (embellish)

- Complement

- Is alternative to

- Specialize

Four different types of connecting rules are identified:

- Complete (embellish): following the idea of composition indicated by the aggregation model

and other pattern-based approaches (Alexander et al., 1977; Derntl et al., 2006), patterns at

higher levels need patterns at lower levels for completeness. Resources complete activities

that, in turn, complete CL flows. Roles and common collaborative mechanisms complete

resources, activities or CL flows. Patterns at the same level can also complete each other.

This is clearly manifested in patterns at the CL flow, which can be combined in such a way

that a phase of the learning flow is refined by replacing the phase with another pattern at this

level. In all these cases the pattern that is completed with other patterns determines the range

of the whole.

- Complement: some patterns at the same level can complement each other. A pattern that

complements another pattern does not refine or modify the principles of the second pattern


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

(as it happens with the “complete” connecting rule). On the contrary, these patterns form

two parts of a larger whole, not previously embraced by any of the patterns. As an exception,

patterns at the activity level may complement those at the learning flow level by adding

(instead of refining) new phases to the flow.

- Alternative to: some patterns can tackle the same category of problem within a context

whose special details derive in alternative solutions. Alternative patterns can be interchanged

but they cannot be used in a complementary way probably because of contradictoriness or

redundancy (Harrer, 2006).

- Specialize: patterns at the same aggregation level can formulate principles that range from

general design ideas to their reusable specialization (David et al., 2003). Patterns that

formulate general design ideas have more “degrees of freedom” than patterns that formulate

their reusable specializations. “Degrees of freedom” in this context can be understood as the

number of design options that the solution of the pattern does not suggest and are free to

creatively vary.

These dependencies between the patterns provide guidance for their application and prevent

bringing together scripting strategies that do not make sense from the pedagogical perspective or

even inhibit the effects of each other (Harrer, 2006). Next subsection uses a hierarchical structure

(representing the aggregation levels) to illustrate how the PL included in Appendix A fits in with

the conceptual model.

3.3.2 An illustrating CSCL scripting pattern language: hierarchical structure

The patterns listed in Appendix A are organized according to the proposed conceptual model

forming a hierarchical structure (cf. Figure 3.3). The structure is represented as a graph (Salingaros,

2000): the patterns are identified with nodes, which are related by edges (the relationships between

the patterns). The graph shows that there are many paths through the patterns that guide their

application. Because of representational limitations not all the possible connections between

patterns are drawn in the figure. However, the complete relationships presented by the proposed PL

are documented in the pattern format fields devoted to the context and the paragraph relating the

pattern to smaller patterns that each pattern includes.

To illustrate and express the identified types of semantic relationships, we analyze in detail the

connections between some patterns included in the CSCL scripting PL next.

50


CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

Figure 3.3 Hierarchical structure of the CSCL scripting PL showing how the PL fits in with the conceptual

model. The numbers on each node reference the patterns as listed in Appendix A. Because of representational

limitations not all the possible relationships are drawn

There are two clear manifestations of the “is alternative to” and “specialize” relationships.

FREE GROUP FORMATION (Pattern 4.2) is alternative to CONTROLLED GROUP

FORMATION (Pattern 4.3). Both are CL mechanisms devoted to group formation. Assembling

groups is needed to complete the suggestions of patterns at the CL flow, activity level and also at

the resource level (cf. STRUCTURED SPACE FOR GROUP TASKS, Pattern 3.1). However the

specific characteristics of the problem that arise from (slightly) different contexts (e.g. a large

demanding assignment vs. an assignment that benefits from diverse or conflict knowledge) conduct

to divergent solutions that are mutually exclusive.

On the other hand, PREPARING FRUITFUL DISCUSSIONS USING SURVEYS (Pattern 2.3)

and ENRICHING DISCUSSIONS BY GENERATING COGNITIVE CONFLICTS (Pattern 2.4)

are specializations of DISCUSSION GROUP (Pattern 2.2). That is, they adapt DISCUSSION

GROUP to a more specific context and thus related problem, undergoing specialization.

DISCUSSION GROUP is within a context that requires organizations forms for knowledge sharing,

questioning and critique. Pattern 2.3 and Pattern 2.4 add to this context the issue that the

participants may consider their previous results or ideas before sharing the knowledge. In this sense,

51


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

the solutions of the specialized patterns are more concrete in their suggestions, offering less design

options to the users so that the essence of the pattern is not killed.

PREPARING FRUITFUL DISCUSSIONS USING SURVEYS (Pattern 2.3) and ENRICHING

DISCUSSIONS BY GENERATING COGNITIVE CONFLICTS (Pattern 2.4) form also a very

illustrative example of how two patterns at the same level complement each other shaping whole

not previously embraced by any of them. While Pattern 2.3 proposes preparing a survey that the

students answer before the discussion to organize their ideas, Pattern 2.4 suggests providing

students with the answers of their classmates so that they reflect on potentially different approaches

and thus generate new questions and issues to be discussed. The answers to the surveys organized

following the purpose according to Pattern 2.3 can be complementarily used as indicated by Pattern

2.4 for a different purpose. Together, Pattern 2.3 and Pattern 2.4 represent a debate strategy that

spans a two different phases, whose range is not considered separately by each of them.

There are many other examples manifesting the “complement” relationship in the PL. For

instance, the GUIDING QUESTIONS (Pattern 3.3) can be presented to the students according to

MANAGEMENT OF ON-LINE QUESTIONNAIRES (Pattern 3.2). A FACILITATOR (Pattern

4.1) complements the pattern CONTROLLED GROUP FORMATION (Pattern 4.3) since this may

be the role in charge of assembling the groups. Moreover, the learning flow of a whole educational

unit might comprise a pattern at the CL flow level, e.g. JIGSAW (Pattern 1.1), complemented with

another flow, e.g. PYRAMID (Pattern 1.2), that follows or precedes the flow suggested by the first

pattern (Pattern 1.1). Again, the limits of the whole resulting from this concatenation of patterns is

determined by the two patterns (one of them indicates the start of the learning flow and the other the

end).

The “complete” connecting rule also appears when combining two patterns at the CL flow. In

this case, a phase suggested by a pattern is organized according to another pattern (which can be

eventually the same. For example the “Expert group” phase of the JIGSAW (Pattern 1.1) may be

structured following the PYRAMID (Pattern 1.2). The base learning flow, indicating the start and

the end of the learning flow is not modified. In contrast, the proposal of the JIGSAW is refined,

being in the resulting design the PYRAMID an integral part of the adapted JIGSAW.

This type of relationship clearly intervenes between patterns at the different levels. The

knowledge of THE ASSESSMENT TASK AS A VEHICLE FOR LEARNING (Pattern 2.5) may be

considered when completing the design of any of the activity types orchestrated in JIGSAW

(Pattern 1.1). Similarly, STRUCTURED SPACE FOR GROUP TASK (Pattern 3.1) refines Pattern

2.5 by indicating the type of resources that may be useful for supporting the activity. A

FACILITATOR (Pattern 4.1) may also complete the activity design ideas indicated by THE

52


CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

ASSESSMENT TASK AS A VEHICLE FOR LEARNING or the behaviour of certain

collaboration tools according to STRUCTURED SPACE FOR GROUP TASK (Pattern 3.1).

The hierarchical structure depicted in Figure 3.3, which emphasizes the rules that connect the

patterns, provides guidance regarding the order in which the patterns are to be applied. We argue

that all the CSCL scripting PLs that conform to the conceptual model proposed in subsection 3.3.1

follow similar hierarchical structures. This fact allows the definition of general guidelines for

applying those PLs.

3.3.3 General guidelines for applying the PL described with the conceptual model

How can the patterns of a CSCL scripting PL described with the conceptual model be applied?

The main ideas, shared among diverse authors of other pattern-based proposals for different design

spaces (Alexander et al., 1977; Coplien & Harrison, 2005; Lukosch et al., 2006; Schümmer &

Lukosch, in press), is to start at the top (higher granularity level) and work towards the bottom.

When a pattern points to several subtending patterns, they can be also applied or not in any order

but considering the semantic differences indicated by the four types of relationships. Of course, the

decision of applying or not applying a pattern depends on context. A PL can be considered as a map

collecting numerous meaningful paths, but the exact chosen path is subject to the circumstances.

The patterns should be helpful and feasible in a particular situation in order to be selected. The

point is not to use as many patterns as possible, but to choose the patterns that solve the problems

that actually appear in an educational situation. If the context, problem and forces of a pattern match

an actual situation, then the pattern is worth considering.

The progression through the PL requires knowing the patterns beforehand or reflecting upon the

different design possibilities before their selection. In fact, this analysis is enabled by having the PL

at hand, which also provides a basis for discussion. The result is a set of interrelated patterns that

together generate a sequence (a story) that shapes the design of a specific script.

Evidently, each PL has a limited number of patterns. A PL represents the experience of

someone (or a community of practice) when creating CSCL scripts (Alexander et al., 1977).

However, the educational context of an external person using the PL may have specific needs that

request new patterns or for different versions of the patterns. In addition, a user of a certain PL (for

example the PL included in Appendix A) might need to apply a pattern in a way that is not

considered in the map of established relationships. The special characteristics of the educational

domain and the unpredictable characteristics of CL situations impose flexibility requirements when

applying PLs. In general, teachers should be able to consider a new pattern or try a pattern that is

out of sequence, if their intuition leads in that direction. The constant evaluation of the effects of the

resulting script enables the evolution of the PLs.

53


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

All in all, if we provide a teacher with a CSCL scripting PL, the desire is that the selected

sequence of patterns keeps the essence of the constraints that are intrinsic to the pedagogical

principle of each pattern in the sequence. The extrinsic constraints, in contrast to the intrinsic ones,

necessarily derive from the application of the patterns to particular situations. These extrinsic

constraints represent the (arbitrary) design decisions reflected in a script that are suitable for being

modified by the teacher and other involved stakeholders, such as students (Dillenbourg et al., 2007).

This idea is in line with the idea of preserving structure discussed around Architecture patterns

(Alexander, 2003b). Alexander proposes a process that involves step-by-step applications of

patterns in such a way that the whole increases by structure-preserving transformations. These

transformations gradually add symmetries (described as centers) that enables the unfolding of the

whole.

Some ideas of Alexander (2003b), also considered by Coplien & Harrison (2005), can be

adopted as general iterative guidelines when applying the CSCL scripting PLs.

- Consider your educational situation as a whole, get a feeling for how the course is working,

and try to identify its “weak points”. Maybe you have recently applied another pattern,

which left you in a new context or produced explicit forces which are not resolved yet.

- Focus on what can be done to enhance the script, considering the target objectives. Are you

striving for a specific skill development? Or are you seeking for motivating your students?

Read the patterns so that you can find help to resolve these questions.

- Find a place where the application of a new patternthe consideration of a new role, the

addition of a new structured activity, changing the learning flow, - will achieve your goal.

Will any of the patterns help you? Do you know of other strategies that will help? Apply the

patterns (or other strategies) locally.

- Look at the structure of the PL. Each pattern indicates which patterns may come next as

complements or refinements.

- Reflect on the application of the patterns. Do they work? Evaluate the effects of the patternbased

script so that the conclusions provide you feedback for further designs.

This subsection argues that the teacher is the main stakeholder in charge of applying CSCL

scripting PL. Next subsection discusses this issue elaborating on other possible categorizations of

CSCL scripting patterns.

3.3.4 Discussion: other categorizations of patterns

Our conceptual model bears similarities to the conceptualization of the educational design space

proposed by Goodyear et al. (2004). Patterns for designing good learning tasks are in our proposal

patterns at the activity granularity level. Moreover, the supportive space embracing the resources

(tools and artefacts) corresponds to the resource level. Organizational forms that favour the

54


CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

emergence of convivial learning situations are what actually propose the patterns included in the

collaborative learning flow level and vertical level (roles, group formation). We argue that the

learning flow and the other CL mechanisms (common to the flow but also to the activities and

supporting resources) are relevant entities that deserve distinction. Furthermore, the aggregation

structure that provides the relationships “resources complete activities, which complete flows” and

“roles and other common CL mechanisms complete resources, activities and flows” makes our

proposed conceptual model more comprehensive. Previous subsections and the application of the

PL presented in section 3.4 provide foundation in this sense.

Other categorizations of patterns could be also distinguished. For example, Alexander et al.

(1977) differentiate the terms design patterns and construction patterns. Alexander’s design

patterns refer to understanding the geometry of a building and the relationships between parts, while

construction patterns examine the materials and processes needed in order to put the designs into

practice. We distinguish between design CSCL scripting patterns, which are used to devise the

educational design of a script (patterns at the CL flow and the activities levels); and construction

CSCL scripting patterns, which support the implementation of the designs in actual practice

(patterns at the resource and vertical level). The audience of design CSCL scripting patterns is

mainly teachers and learning designers, who create CSCL scripts. Nevertheless, these patterns may

be used by systems designers in requirements analysis tasks. In contrast, construction CSCL

scripting patterns are more intended for system developers (or content providers), although they

should be also considered by teachers and even students, who are the actual users of the scripts.

On the other hand, Vesseur, Lutgens, Broek, Koehorst, & Ronteltap (2005) differentiate five

phases (or levels) in developing and planning education in which design patterns can be useful:

preparation of a (case of study) pilot, preparation of the course, the course itself, assessment of the

course and evaluation of the pilot. The phase on which CSCL scripting patterns (from the

perspective approached in this dissertation) are focused is more related to the preparation of the

learning design than to putting the learning design into effect. Thus, CSCL scripting patterns are

mainly at the “preparation of the course” level. The roles that may use the patterns considered in the

other phases of planning education include the researcher and the evaluator.

This discussion leads us to the ideas developed at the beginning of the section. CSCL scripting

PLs are not isolated. Quite the opposite, they are connected to other PLs. These PLs can be situated

at the same design phase (e.g. PLs dealing with didactics of specific subject matters) or at a

different one (e.g. PLs for planning the evaluation of a course). It is also remarkable the fact that not

all the patterns that may be considered when designing scripts might have a pure scripting purpose

(cf. for example FACILITATOR, Pattern 4.1 of Appendix A). In fact, patterns that may belong to a

CSCL scripting PL can also fit in (with different connecting rules to other patterns) with other (nonscripting)

PLs. If all the possible PLs for educational design are put together, overlapping between

55


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

patterns and PLs will become apparent. An example of this appreciation is that isolated patterns (not

included in our proposed PL) and other PLs fit in with the CSCL scripting PLs conceptual model

and, thus, could be adopted to enlarge the PL of Appendix A. This discussion also supports the

validity of the conceptual model.

3.3.5 Discussion: other sample patterns that fit in with the proposed conceptual model

Interestingly, there are PL proposals that can be embraced by CSCL scripting PLs. As

aforementioned, this fact is manifested in other domains, such as Architecture, where a PL for

designing a house comprises a PL for a porch (Alexander et al., 1977).

It is noteworthy that DISCUSSION GROUP (Pattern 2.2 of Appendix A) is, in turn, part of a

PL devoted to “Debate” (Goodyear, 2005). This PL can be considered a smaller PL embraced by a

CSCL scripting PL. The patterns of the Debate PL can be situated in the activity and resources

levels as well as in the roles and common collaborative mechanisms level. Most of its patterns refer

to fine-grained activities involved in a debate such as PROPOSE THE MOTION or VOTE. Other

patterns are around roles, namely SPEAKER FROM THE FLOOR or CHAIRPERSON. Finally, the

“Debate PL” also considers principles about resources related to tools or materials, e.g. BULLETIN

BOARD and SOURCES OF EVIDENCE.

Similarly, MANAGEMENT OF ON-LINE QUESTIONNAIRES belongs to a PL for LMSs

(Avgeriou et al., 2003). The rest of the patterns of this PL and related PLs, e.g. a PL for

asynchronous CL systems proposed in (Georgiakakis et al., 2006), can be also situated at the

resource level of our conceptual model.

One of the patterns collected in (DiGiano et al., 2003) is a version of the JIGSAW pattern. The

other patterns included in this work can be framed in the CSCL scripting PLs conceptual model as

well. To name a few examples, PIPELINE WORKFLOW as a pattern at the CL flow level,

TOUCHING THE ELEPHANT is at the activity level, EXCHANGE TEMPLATE is at the resource

level, and CONTRIBUTION LAYERING is at the common mechanisms level.

The following examples of actual scripts, generated using the PL of Appendix A, aim at further

expressing the different aggregation levels and relationships that connect the patterns. They also

illustrate how the hierarchical structure conceptually guides the process that can be followed when

applying the patterns. The reader should also note that the patterns selected for each example form

themselves a small PL.

56


CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

3.4 Examples of applying the CSCL scripting patterns

Some of the patterns in Appendix A are drawn from real experiences at our University. This

section looks at three examples, based on real case studies, which consider these patterns (and

others captured in the literature) in order to illustrate how the patterns can be applied.

The experiences are described as stories in the form of sequences that show the process of

growth. The sequences offer different paths (out of the many possibilities for the PL) that result in

particular wholes (scripts). These examples should provide a better feel for the PL and the patterns’

interconnections.

It is important to remember that these sequences are real. They come from our experience, and

they typified the rich ways in which patterns build on each other, as well as the way in which the

language can become alive. In this sense, the PL of Appendix A describes somehow the culture of

our community of practice.

As advanced in the section 3.2, the first and the second experiences are CA (Martínez-Monés et

al., 2005; Jorrín-Abellán et al., 2006) and NNTT (Ruiz-Requies et al., 2006), both used as a starting

point to propose some of the patterns. The results of these experiences are successful in terms of the

target educational objectives. The third experience is called Computer Networks Protocols (TTG, its

acronym in Spanish), designed explicitly applying the CSCL scripting patterns from scratch. This

section is therefore longer, since it also includes the results of the experience evaluation that shows

the fruitful results of following the good practices formulated by the patterns.

3.4.1 Computer Architecture (CA) course

The CA course is part of the core body of knowledge in the Telecommunications Engineering

curriculum in Spanish universities. The specific course in which the following script is applied is at

the University of Valladolid, Spain. It is placed in the fall semester of the fourth year (out of five)

and is made up of 30 lecture hours and 60 laboratory hours. Within the curriculum, the course is the

last of a branch on computing topics that covers programming fundamentals, operating systems, and

computer architecture. The script designed for the course aims at providing contextualized,

integrated and meaningful knowledge; to promote active, intentional and collaborative learning

(Martínez-Monés et al., 2005; Jorrín-Abellán, 2006).

The whole course is defined as a project that develops along the semester, whose objective is

the design and evaluation of computer systems. The class of 100–120 students is divided into three

sessions of 40 students, in which the elementary unit consists of groups of two students (pair). To

enable distinct perspectives of the main subjects within the classroom, five clients are defined,

giving answer to different market sectors and system requirements. Each pair is assigned one out of

57


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

the five clients for the whole course. This way, in each laboratory group, different clients are being

studied throughout the course, following the principles of JIGSAW (Pattern 1.1).

The Jigsaw-based structure is completed with the suggestions of SIMULATION (Pattern 1.5).

The teacher takes the roles of the five clients and the director of the manufacturer companies, while

students assume the roles of a consulting firm and a computer manufacturer. Along the script there

are several project assessment tasks, as indicated by THE ASSESSMENT TASK AS A VEHICLE

FOR LEARNING (Pattern 2.5), which correspond to three subprojects of 4 weeks each. The final

report is to be submitted a month after the course has finished, and therefore, during this period,

there are no lectures where students could meet face to face. In this way, the teacher, which

becomes a FACILITATOR (Pattern 4.1) during the whole course, makes sure that they have time to

execute and plan how they will carry out the subprojects.

The educational design aims at promoting interaction within and between the pairs assigned to

different clients. Each subproject studies different specific issues of the whole problem and presents

two milestones. In the first one, basic decisions are taken, and in the second milestone, each pair has

to submit a technical report to the client (teacher). In each milestone, every laboratory group

(“Jigsaw group” phase of the JIGSAW) holds a debate. The debate is designed as a collaborative

review of the work of the students, arranged as suggested by PREPARING FRUITFUL

DISCUSSIONS USING SURVEYS (Pattern 2.3), and where the problems of the different clients

can be shared and discussed at a laboratory group level following the ideas of ENRICHING

DISCUSSIONS BY GENERATING COGNITIVE CONFLICTS (Pattern 2.4). At the end of the

whole script, a technical report (corresponding to the last subproject) is collaboratively produced

among all pairs that deal with the same case study in each laboratory group (forming accordingly a

PYRAMID Pattern 1.2).

Since the subprojects are demanding assignments that take place along the whole course, FREE

GROUP FORMATION (Pattern 4.2) is proposed to the students when assembling the pairs.

Moreover, the structure of the technical reports is provided to the students as GUIDING

QUESTIONS (Pattern 3.3) that help them to focus on important issues to be covered.

To support preparation and realisation of the debates a telematic tool for automatic

MANAGEMENT OF ON-LINE QUESTIONNAIRES (Pattern 3.2) called Quest (Gómez, Rubia,

Dimitriadis, & Martínez, 2002) is used. As required by the joint application of Pattern 2.3 and

Pattern 2.4, Quest supports synchronous debates in the classroom based on the results of previously

submitted questionnaires that are filled by the students with their opinions about the topics under

discussion.

To offer a STRUCTURED SPACE FOR GROUP TASKS (Pattern 3.1) where the students can

share their reports, the teacher encourages the use of the Basic Support for Cooperative Work

58


CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

(BSCW) (OrbiTeam, 2007). BSCW is a well-known shared workspace system based on web

interface, was used for asynchronous document sharing and threaded discussions. Also it offers

additional features for handling shared documents such as a commenting tool (one student may

“post” comments on another’s document), and an awareness tool (it informs students by e-mail

about the uploading of new documents, their modification, etc.), among others.

The patterns applied in the design of this script are used in order to promote the acquisition of

competencies and skills (e.g. those related to group work), besides specific contents of the course.

Next example deals with a course on a totally different topic (even discipline) which also adopts the

design principles captured in the PL.

3.4.2 The use of ICT resources in Education (NNTT) course

The global objective of the NNTT course is to allow students of the Faculty of Education at the

University of Valladolid to create didactic units in collaboration (Jorrín-Abellán, 2006; Ruiz-

Requies et al., 2006). It is made up of 40 hours including lectures and laboratory sessions. Each

class comprises from 36 to 42 students. Along the course the students should create a didactic unit

that could be eventually used in a real school and design the ICT resources that will support such a

didactic unit. An actual school also participates in the case study by providing specifications and

evaluation of the partial results of the students. As the CA course, the educational situation is

blended and interleaves normal face-to-face activities with technology-supported collocated or

distance activities. Besides knowing and applying the specific contents of the course, the script

employed in this course targets students develop their critic capabilities and skills related to

working in group and coping with strong workloads.

Before actually creating didactic units, the students are encouraged to work around the three

main topics of the course. This phase, which spans from second to fifth weeks of the course, is

scripted according to a two-level PYRAMID (Pattern 1.2). The previous (first) week is devoted to

present the course and the planned script following the indications of INTRODUCTORY

ACTIVITY: EXPLAINING THE LEARNING DESIGN (Pattern 2.1). The first level of the

Pyramid is, in turn, structured in accordance with JIGSAW (Pattern 1.1). The CL flow resulting

from the combination of these two patterns at the learning flow level is refined as follows. Taking

into account the FREE GROUP FORMATION pattern (Pattern 4.2), the students are assembled in

pairs that persist during the whole course. In the “Individual phase” of the JIGSAW every pair

studies one of the three topics in such a way that each topic is assigned to six or seven pairs. The

teacher facilitates a set of articles associated to the different topics and asks the students to discuss

in pairs the ideas of the articles (related to their assigned topic). Then, students should elaborate a

report for assessment purposes but also as a learning task (ASSESSMENT TASK AS A VEHICLE

FOR LEARNING, Pattern 2.5) which pushes them to reflect on a series of questions that they

59


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

should answer in the report. These questions are explicitly provided by the teacher, as suggested by

GUIDING QUESTIONS (Pattern 3.3).

In the “Expert Group” phase of the JIGSAW the six (or seven) pairs that have worked on the

same topic join in a single group to read and discuss the reports written by their partners. The

teacher gives them some ideas about how they should organize the DISCUSSION GROUP (Pattern

2.2) and acts as a FACILITATOR (Pattern 4.1) helping students get started and giving feedback

when necessary. To facilitate sharing of reports a STRUCTURED SPACE FOR GROUP TASKS

(Pattern 3.1) is used. In this case, the employed tool is Synergeia (ITCOLE, 2005), a version of

BSCW focused on learning that provides a shared, structured, web-based work space in which

collaborative learning can take place, documents and ideas can be shared, discussions can be stored

and knowledge artefacts can be developed and presented. Again, in a following activity the group

should jointly write a report in an activity designed according to Pattern 2.5 and Pattern 3.3.

In the “Jigsaw Group” phase (of Pattern 1.1), new groups are formed. Every group comprises a

pair “expert” on each topic. This assembling of pairs into larger groups is accomplished by the

teacher using the criteria of physical proximity in the lab. In this case, the context and forces of the

situation lead to the selection of CONTROLLED GROUP FORMATION (Pattern 4.3) instead of

FREE GROUP FORMATION. In this phase, the students read and present the (second) report

(outcome of the “expert group”) and elaborate a new common report integrating the three different

topics. After that they complete a questionnaire designed with the purpose of PREPARING

FRUITFUL DISCUSSIONS USING SURVEYS (Pattern 2.3).

The second (and last) level of the PYRAMID is devoted to ENRICHING DISCUSSIONS BY

GENERATING COGNITIVE CONFLICTS, Pattern 2.4) in a global debate where all the students

participate. The MANAGEMENT OF ON-LINE QUESTIONNAIRES (Pattern 3.2) is carried out

with Quest.

Throughout the whole script, several concurrent activities need to be synchronized among

different groups. Therefore, the teacher plans some enriching additional activities (e.g. training in

how to design a questionnaire, type of enrichment II) for groups that finish earlier, as indicated by

ENRICHING THE LEARNING PROCESS (Pattern 1.7).

As in the CA course, the script used in NNTT exists before the PL of Appendix A. However,

the presentation of the design of both courses as sequences of patterns illustrates the different types

of CSCL scripting patterns and connections between them. Next subsection introduces a new script

for a course on computer networks. In this case the script is designed explicitly applying the CSCL

scripting patterns from scratch.

60


CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

3.4.3 Computer Networks Protocols (TTG) course

Several approaches for teaching computer network protocols concepts and mechanisms by

means of lab exercises and projects have been reported in the literature. Significant examples

include the use of networking tools (traffic monitors, traffic analyzers, etc.) in real scenarios

(Stevens, 1995), the use of network simulators (Al-Holou, Booth, & Yaprak, 2000), protocol

implementation and network programming project-based activities (El-Kharashi, Darling,

Marykuca, & Shoja, 2002), and even the performing of learning activities with no computer and

network support at all (Surma, 2003).

The script applied in this subsection represents an experience carried out in an undergraduate

course on computer network protocols that combines several of those approaches: networking tools

in real scenarios, network programming, and simulation. The course belongs to the studies of

Telecommunication Engineering at the University of Valladolid. More particularly, the script is

focused on the lab exercises related to the first of the mentioned approaches: the use of networking

tools in real scenarios of traffic interchange for the learning of, in this particular case, concepts and

mechanisms of the Transmission Control Protocol (TCP).

During previous years (before applying the script), those lab exercises simply comprised the

analysis of the traffic that communicating applications running in lab hosts interchanged among

each other (or with applications running in other Internet hosts) through the lab network. The set of

communicating applications included, in a similar way as proposed by (Stevens, 1995), common

client/server utilities (FTP, telnet, web...) as well as user-guided traffic sources and sinks based on

the sock application. The students were requested to set up the applications in a predefined way, to

capture the traffic with the tcpdump tool (Tcpdump, 2006), and to analyze captured traffic

identifying what TCP mechanisms previously explained in theoretical lecturers are involved

(connection establishment, flow control, slow start, congestion avoidance, Nagle algorithm, etc.)

Seeing the protocols “in action” enabled the students to contrast their knowledge of the protocol

mechanisms with their real behaviour thus detecting potential misunderstandings.

Nevertheless, this approach showed to have several weaknesses. Firstly, the large set of TCP

mechanisms under study demanded from the students the setting up of an also large set of traffic

interchange scenarios. Therefore the students’ effort was devoted, to an important extent, to the

performing of those repetitive configuration tasks. This fact precluded them from focusing on the

understanding of the protocols mechanisms themselves and the circumstances under they are

intended to be useful. Secondly, the time required for the analysis of a large set of scenarios

involving single mechanisms made difficult (within the time frame of the course under study) to

devote time for the setting up and analysis of scenarios involving several TCP mechanisms

simultaneously. This fact hindered the understanding of the mutual influence among TCP

mechanisms and, consequently, their differences and corresponding purposes.

61


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

With the goal of alleviating those problems, the two teachers of the course plan to encourage

students to design (not only to analyze) their own scenarios of traffic interchange that trigger one or

a combination of TCP mechanisms. This kind of scenario-design activities helped the students to

understand the circumstances under a TCP mechanism is intended to be useful. Moreover, the

teachers design a script that pushes students to collaborate in groups with other students so as to

complete the traffic analysis and scenarios design tasks. By means of collaborative activities,

students are expected to generate further knowledge as well as to share the work load, thus

providing new time slots for introducing new exercises.

In addition to the above advantages, basically related to the course contents and organization,

the script introduced in the course is expected to generate opportunities for the students’ acquisition

of competencies and skills such as argumentation capacity, responsibility for the own learning,

involvement in group work, etc.

Next subsection (3.4.3.1) firstly introduces the course that constitutes the context of the script.

Then subsections 3.4.3.2 and 3.4.3.3 detail its design, focusing on the type of scenarios and the

specific script proposed to the students. Afterwards, subsection 3.4.3.4 explains how the experience

has been evaluated and what conclusions can be drawn from the evaluation results.

3.4.3.1 Course background

TTG is placed in the fall semester of the third year (out of five) of the studies for achieving the

degree of “Telecommunications Engineering” at the University of Valladolid, Spain. It is the third

out of five courses belonging to the core body of knowledge of the degree’s curriculum that are

devoted to the study of computer network protocols following a bottom-up layered approach. The

first of those courses introduces basic concepts of computer networks and focuses its attention on

media access control and logical link layer techniques and protocols. The second course is mainly

devoted to network layer aspects (routing, congestion control, etc.). Finally, the third course, the

focus of this study, deals with transport-level protocols and, specifically, with the TCP. The

remaining two courses cover application-level protocols.

The course spans a 15-week-long semester and involves 30 lecture hours (one two-hour session

per week) and 60 laboratory hours (two two-hour sessions per week). The 60 laboratory hours are

divided in three different types of exercises: 22 hours involve exercises of analysis and design of

scenarios of traffic interchange, 22 hours are devoted to network programming with the BSD

sockets API (Stevens, 1998), and the last 16 hours propose activities based on the use of the ns-2

(ISI, 2007) network simulator. The script is focused on the activities performed during the first 22

hours.

62


CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

A total of 160 students approximately participate in the course. Due to physical space

restrictions at the lab, they are divided in four groups of 40 students. Consequently, each lab session

is repeated four times a week. The students are arranged in groups of two (a pair) that share the

same lab resources (machine, user account, etc.) and work together during the whole course.

3.4.3.2 Scenarios to be analyzed or designed throughout the script

Scenario-based learning is defined as “...learning that occurs in a context, situation, or social

framework. It’s based on the concept of situated cognition, which is the idea that knowledge can’t

be known or fully understood independent of its context” (Kindley, 2002). Applying this same idea,

knowledge on computer network protocols cannot be fully understood if it is not situated in the

context in which those protocols are used: applications that communicate through a computer

network. Within this context, students are requested to perform two types of activities: analysis of

predefined scenarios of traffic interchange (provided by the teachers) and design of new scenarios

that illustrate a required set of protocol mechanisms. Analysis activities enable the students to

confront real protocol behaviour with the knowledge acquired in theoretical lecturers (thus detecting

potential misunderstandings). Design activities “force” the students to focus their attention in the

circumstances in which a particular mechanism is useful. This helps the students to differentiate the

protocol mechanisms and promotes a better understanding. Table 3.2 enumerates the TCP

mechanisms to study during the 22 first lab hours of the course as well as the type of scenarios that

the students are requested to analyze and to design. The enumerated TCP mechanisms are grouped

in “sets” (left-hand column) related to the script that will be described in the following section.

3.4.3.3 Designing the script

Considering the educational situation as a whole and the weak points identified in experiences

of previous years, the teachers of the course select a sequence of patterns belonging to the PL of

Appendix A. The focus is on finding ways of resolving problems that appear in such a situation,

having in mind the target educational objectives.

Starting at the top level, the teachers select JIGSAW (Pattern 1.1) as the basis to structure the

CL flow of the script. They also decide to complement this pattern with PYRAMID (Pattern 1.2),

by refining the “Jigsaw Group phase” with a two-level Pyramid structure. The result is a CL flow

that combines JIGSAW and PYRAMID patterns (cf. Table 3.3). The formulation of both patterns in

Appendix A indicates the context in which they can be applied and what they suggest along with

the educational benefits that they foster. This information indicates that the selected patterns are

helpful and feasible for the conditions of the faced situation. For example, the adequateness of

JIGSAW is, among other issues, manifested by the fact that the list of TCP mechanisms (and thus

scenarios of traffic interchange) can be easily divided into sets.

63


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

Table 3.2 TCP mechanisms to be studied in the course and the related scenarios of traffic interchange to be

analyzed and/or designed

Set TCP mechanism Scenarios

Common

A

B

C

D

Combined

TCP connection

establishment and

termination

Analysis: telnet session with a “local” machine and web session with

a “remote” machine.

Design: use of sock tool as traffic source and sink with options

TCP Half-close

needed to “force” a half-close scenario.

TCP Reset segments Analysis: telnet session with “unreachable” TCP port.

Design: scenario of retransmission during connection establishment

(e.g. disconnecting network cable).

Retransmission time-

Design: scenario of ARP (Address Resolution Protocol) traffic

out (error control)

capturing during TCP connection establishment (due to expiration of

ARP cache)

2MSL (Maximum

Segment Lifetime) Analysis: scenarios proposed in (Stevens, 1995) for the measurement

time-out (error and characterization of the 2MSL time-out.

control)

Analysis: telnet session in which a sentence is typed (impossible to

identify the mechanism due to human key pressing rhythm).

Analysis: telnet session in which the same typed sentence as above is

“copied and pasted” at once (the Nagle algorithm can now be

Nagle algorithm identified).

(reduction of Design: use of sock tool so as to illustrate Nagle algorithm behavior

overhead caused by (fast generation of small data chunks that will be grouped by the

small TCP segments) mechanism).

Analysis: identification of thedelayed ack” mechanism and its

positive/negative influence in the Nagle algorithm (ack delaying

enables Nagle algorithm to generate larger segments thus reducing

protocol overhead).

Design: using the sock tool, a traffic source requests TCP to send a

large chunk of data. A traffic sink “reads” data from TCP in smaller

chunks. It is interesting to analyze the size of the advertised sliding

windows of the TCP receiving entity when the buffer size is

modified, when “read” operations are separated by a certain amount

of time, when those operations start a certain amount of time after the

Sliding Window

connection is established, etc. (the flow control imposed by the

(flow control)

sliding windows is observed as well as its relationship with the

receiver’s buffer size).

Design: the above scenario is requested to be analyzed again but

running the traffic sink in a Sun Sparc workstation using Solaris

operating system (in order to discover different TCP behavior in

different implementations).

Analysis: using the sock tool, a traffic source and a traffic sink

interchange TCP data within the lab network (the slow start

mechanism is difficult to appreciate due to low delays).

Design: use of sock tool as traffic source in order to illustrate the slow

start mechanism behavior (e.g. using a “remote” web server as traffic

Slow start and

sink. The mechanism can be appreciated if delays are large enough).

congestion window

This scenario is useful to illustrate under what circumstances the

(congestion control)

congestion window decreases the traffic sending rate.

Design: the above scenario is requested to be analyzed again but

running the traffic source in a Sun Sparc workstation using Solaris

operating system (in order to discover different TCP behavior in

different implementations).

Congestion-window Design: identify which of the two mechanisms limit the data sending

vs. sliding window rate and under what conditions

Design: identify which of the two mechanisms force the traffic source

Nagle algorithm vs.

to interrupt the sending of data using as the traffic sink a “far” (in

sliding window

terms of end-to-end delay) web server

Design: scenario of retransmission during the data transfer phase of a

Retransmission time-

TCP connection between two machines located in different networks

out vs. ARP time-out

(not in the lab network, in order to analyze the differences)

64


CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

Table 3.3 Sequence of lab sessions and the corresponding individual and collaborative learning activities

Session Activity description Outcome Supporting tools

and resources

1

2

3

4

5

6

7

Jigsaw phase: “individual work”

Explanation of the educational

design

Each pair works on the common

set of TCP mechanisms

Each pair works on the assigned set

of TCP mechanisms (A, B, C, or

D)

8 Discussion on the test results

moderated by the teacher

9 Jigsaw phase: “experts group”

Pairs that have worked on the same

set of TCP mechanisms (“experts”)

meet together and discuss on the

test results and controversial

aspects (generated during the

discussion)

10 Jigsaw phase:

“jigsaw group” (I)

Each pair in a “super group”

explains to the others the

mechanisms of its assigned set.

Prerequisite: each pair has read

the written report of the other

members of the “supergroup”.

11 Jigsaw phase:

“jigsaw group” (II)

Analysis of “combined scenarios”

according to a “pyramid” structure:

Pyramid level 1

Each pair works individually

Pyramid level 2

The whole “super group” compares

and discusses the obtained results

and tries to obtain a common

consensus

None to deliver

Questionnaire on the common and

assigned set of TCP mechanisms (at the

end of session #7)

Written report on the assigned set of TCP

mechanisms (eight-page document to be

finished a week before session #10)

List of controversial points to be discussed

with other “experts”

Document with a list of discussed topics

and agreed conclusions (one-page

document delivered at the end of the

session)

None to deliver

At the beginning of session #12 students

answer a questionnaire individually. The

questionnaire contains 4 questions on each

set of mechanisms (A, B, C, and D) as well

as 4 questions related to the relationships

among different mechanisms

65

None

Quest tool

BSCW tool to store,

share, and comment the

reports

None

BSCW tool to store,

share, and comment the

list of discussed topics

and agreed conclusions

BSCW tool for

accessing the reports of

the rest of “super

group” members.

Quest tool


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

The students belonging to the same pair work together on the common set of TCP mechanisms

until the fourth session and employ three sessions more to study a different set of TCP mechanisms

(these tasks are all part of the “Individual phase” of the JIGSAW). For assessment purposes but also

with the aim of training students’ writing skills, the teachers ask the students to write a report on the

assigned set of TCP mechanisms (A, B, C, or D). Following THE ASSESSMENT TASK AS A

VEHICLE FOR LEARNING (Pattern 2.5) the teachers give students a lot of control over how they

carry out the elaboration of the report, making sure that they have sufficient time to plan and

execute it well. The reports must be shared at least among the pairs that will join in a “Jigsaw

group” in the tenth session. Therefore, a STRUCTURE SPACE FOR GROUP TASKS (Pattern 3.1)

that facilitates sharing these resources is provided to the students. The teacher selects BSCW as the

actual tool to support this functionality (OrbiTeam, 2007). Of special interest here is the fact that

BSCW logs every action performed on the shared workspace, providing data that were used as a

source of the analysis, as explained in the following subsection.

On the other hand, the teachers plan to organize a DISCUSSION GROUP (Pattern 2.2) about

their progress in the study of the TCP mechanisms before finishing the report. That discussion aims

at clarifying detected misunderstandings and to generate new questions on the TCP mechanisms

intended to motivate further work and collaboration. In this way, the teachers apply PREPARING

FRUITFUL DISCUSSIONS USING SURVEYS (Pattern 2.3) and, consequently, arrange an on-line

survey with questions related to the different TCP mechanisms, so that the students answer the

survey before the discussion and organise their ideas and arguments supporting them. The answers

of the survey are then used by the teachers with the aim of ENRICHING DISCUSSIONS BY

GENERATING COGNITIVE CONFLICTS (Pattern 2.4) in the actual discussion, which takes

place in session #8. The students have the opportunity to read the answers of their classmates and to

notice that their results may be wrong, thus generating new doubts that can be discussed. The

questions proposed in the survey are used by students and teachers as GUIDING QUESTIONS

(Pattern 3.3) of the important issues to be discussed. The MANAGEMENT OF ON-LINE

QUESTIONNAIRES (Pattern 3.2) is facilitated by Quest (Gómez et al., 2002).

Following the number of interconnections with other patterns indicated in JIGSAW and

PYRAMID, the teachers decide to complete the learning flow with the principles proposed by

patterns at other levels. In the first session the teachers, according to INTRODUCTORY

ACTIVITY: LEARNING DESIGN AWARENESS (Pattern 2.1), plan to explain the whole learning

design so that the students are aware and understand the sequence of lab sessions and its goals.

Moreover, the teachers ask the students, as the outcome of the discussion, a list of controversial

points to be also used as GUIDING QUESTIONS in the “Expert group” phase of JIGSAW. In this

phase, the pairs that have worked on the same set of TCP mechanisms join in order to perform a

DISCUSSION GROUP about the controversial points related to their set of mechanisms. The

66


CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

discussion is not formally structured by the teachers using a micro-script but, following the

FACILITATOR pattern (Pattern 4.1), they monitor, get in occasionally un-stuck and intervene

when necessary. The outcome of the discussion is a list of discussed topics and agreed conclusions.

In the “Jigsaw group” phase of the JIGSAW each pair explains to the others (which have studied

a different set of mechanisms) the mechanisms of its assigned set. After that, following a PYRAMID

structure they work on “combined scenarios”. At the first level of the Pyramid the work is

accomplished in pairs, and then the results are discussed and compared in “super groups” at the

second level of the Pyramid. The teachers also act according to FACILITATOR pattern during these

sessions. Additionally, to foster even more the participation of the individual students in every

phase of the script, at the end (in session #2) a final (individual) test about all the TCP mechanisms

is planned.

It is also worth mentioning, that students are involved, at the beginning of the course, in the

decision on how to grade the outcomes generated during the 22 hours of lab work, as well as in the

decision on how to form “super-groups” and how to assign mechanisms sets to each pair. This

involvement is based on a learning technique called “learning contracts” (Anderson, Boud, &

Sampson, 1996). This technique defends that by negotiating with the students different

organizational issues, they try to better understand the course plan and also show a higher

implication in the course development. As a result of this negotiation the teachers apply for the

composition of the groups the principles of FREE GROUP FORMATION (Pattern 4.2) and not of

CONTROLLED GROUP FORMATION (Pattern 4.3).

To conclude, we summarize in Table 3.4 the competencies and skills that the application of this

script supports. Those competencies and skills are aligned with the prescriptions of the educational

guidelines of the future European Higher-Education Space (EC, 2006).

This script is applied in the fall semester of 2005. Next subsection evaluates the effects of this

pattern-based script so that the conclusions test the value of the applied sequence of patterns and

provide feedback for further designs.

Table 3.4 Main expected competencies and skills

Competencies Skill

Thinking and arguing - Argument building

Problem solving and planning design

Responsibility for the own learning

Working with large amount of

information

- Situation analysis

- Experiments design

- Plan and guide own learning

- Understand, take part in, and be

sensible to others’ contributions

67

- Work collaboratively

- Information selection

- Data observation and interpretation

Communication - Explanation of ideas to others


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

3.4.3.4 Evaluation methodology and results

Evaluating the success of an experience such as the resulting of applying the previously

described script is a complex task due to the nature of the factors that must be taken into account,

some of them not easily quantifiable: individual characteristics of learners and educators, social

issues, impact of technology environment, etc. Therefore, the mixed evaluation approach based on

that proposed in (Martínez-Monés et al., 2003), that combines quantitative and qualitative

evaluation methods, has been selected for that purpose. Quantitative methods allow detection of

general trends related to students’ opinions and attitudes, while qualitative methods allow the

evaluator to understand these trends better by introducing context issues and considering

participants’ perspective (Martínez-Monés et al., 2005).

Table 3.5 explains the nature and purpose of the data sources that provide input information for

the evaluation of the project. Data collection and processing is supported by a set of computational

tools: questionnaires are edited and answered by means of the Quest tool; and analysis of qualitative

explanations contained in questionnaires is supported by the Nud*IST tool (SQR, 1997).

Table 3.5 Labels used in the text to quote the data sources of the “Network management” experience

Data source Type of data Purpose

Questionnaire at the

end of the experience

Observations

BSCW logs

Quantitative ratings and qualitative

explanations of those ratings

Registration of interactions among

students by teachers during collaborative

activities as well as their qualitative

annotation

Access to shared documents (for reading,

annotation, modification, etc.)

68

Collection of students’ opinion on

the experience: context, resources,

organization, collaboration.

Identification of expected and unexpected

modes of interactions

among students.

Quantification of information

interchange among collaborating

groups

This evaluation results are structured according to the questions posed to the students at the end

of the experience. The answers to those questions (both quantitative and qualitative) provide some

useful indications for drawing preliminary conclusions on the success or failure of the experience.

The discussion on those indicators and the corresponding conclusions is enriched with data coming

from the other data sources enumerated in Table 3.5. Relevant conclusions as well as the supporting

evidences provided by evaluation data are summarized in Table 3.6. These preliminary conclusions

are sufficient to provide some hints about the value of the sequence of patterns applied in the

experience. We do not need more detailed conclusions for the objectives of this chapter. However, a

deeper analysis, such as the one carried out in Chapter Six, would be necessary to fully understand

the educational experience.


Aspect of

interest

Structure of the

experience

Collaboration

Competencies

and skills

CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

Table 3.6 Relevant evaluation conclusions and associated evidence

Preliminary conclusion Evidence

The structure of the experience is

perceived as a positive aspect in

general.

The experience is successful in

promoting collaboration.

Students consider that collaboration

provides important advantages,

although it requires a greater effort

and creates doubts on the

“correctness” of what students learn.

Computational support of

collaborative activities is adequate.

The experience “forces” the students

to reach consensus, to discuss/listen

with/to others, to build arguments,

and to be responsible for their own

learning.

69

Only 6% of the students have a negative opinion on the

way the experience is structured, e.g.: “working with

other groups has derived in the raising of many doubts.

I do not like depending on others’ work”. Oppositely,

most of the answers emphasize positive aspects of the

script, e.g.: “working in super-groups is new,

interesting, and funny”, “it is easier to understand

certain TCP concepts when they are explained by

experts on them”, “explaining something to your

classmates demonstrates whether you understood it or

not”, “it has reduced the work load”...

Observations (cf. Table 3.5) show that students have

collaborated following teachers’ instructions with slight

differences in the time each group devoted to the

activities of session #10, and #11. BSCW logs have

shown that before session #10 all documents are read at

least 4 times by different groups (all pairs read the

reports written by the other members of the same

“super-group”). Some of the reports are read by up to 10

times by different groups.

Students are asked on the advantages and drawbacks of

introducing collaborative activities in the experience.

Among advantages, students indicate: “it is more

motivating than just listening to a teacher’s

explanation”, “it helps to understand how important is

to prepare your part properly so as to help your group

mates”, “it reduces competitiveness”, “it is good for real

life”. Negative opinions include mostly variations of

“common doubts cannot be solved”, and “it requires

more effort and time”.

Students are requested to grade (in the range 0-10) the

importance of BSCW and Quest tools for their work.

Quest receives an average of 6.77 (deviation of 1.57)

and BSCW an average of 7.86 (deviation of 1.86).

Students are asked to enumerate what skills are required

in order to complete the proposed tasks. The above skills

are the most cited.

As a last interesting evidence found in evaluation data it is worth mentioning that many students

show their concern with the fact that becoming “experts” in a subject (as indicated by JIGSAW)

might imply less knowledge in the other subjects. Nevertheless, when processing the results of the

questionnaire that the students individually answered at the end of the experience (cf. Table 3.3) in

the range 0-10, the overall variance is only 1.72. Furthermore, if we analyze the results of the

questionnaire obtained by each type of “expert”, and taking into account that the questionnaire

includes four questions on each of the TCP mechanisms set (A, B, C, D, as well as four questions

on the “combined” scenarios), the number of failures corresponding to each group of questions is

quite similar. More concretely, the variance among the average number of wrong answers (range of

0-4), calculated for each group of questions and for each type of “expert” is always lower than 0.06.

These results indicate that the script minimizes the apparent problems of JIGSAW.


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

Summarizing, the evaluation results provide indications on that the script designed using the

CSCL scripting PL (of Appendix A) framed within the conceptual model proposed in section 3.3

has fostered collaboration in an effective way. Particularly, the script has contributed to a better

understanding of the applicability of the mechanisms, to a sharing of the workload, and to the

fostering of important competencies and skills for engineers.

Nevertheless, students also point out the fact that this kind of experience implies a different way

of working (possibly requiring from them more implication and a higher level of dedication) and

that sharing “expertise” may sometimes produce the feeling that some concepts have not been

understood properly. As discussed in subsection 3.3.3, this conclusion leaves us in a new context,

making explicit further forces, from which the need of a new pattern emerges. All in all, the

evidences achieved in this evaluation illuminate the fact that the sequence of patterns selected from

the proposed PL for this specific educational situation is meaningful, helpful and feasible.

3.4.4 Discussion: moral preoccupation, coherence, generativeness and creativity

CSCL scripting patterns encapsulate design experience rendering it available for re-use in

concrete educational design problems. The three scripts exposed in this section manifest that

achieving educational benefits by scripting CL is the moral preoccupation of CSCL scripting PLs.

These examples also make visible that the significance of patterns increases from their position in a

structure, and particularly a sequence, of other patterns. The proposed model for CSCL scripting

PLs conceptually illuminates the aim of creating (morphological) coherence of the potential PL

situated in the model (Alexander, 1999). This property is exemplified in the scripts of this

subsection.

In this way, the examples also manifest the generative power of the proposed PL, which enables

the creation of coherent wholes (scripts) in many different forms, with infinite variety in the details

but with a confidence of well-formed results. Though most patterns coincide in the three scripts, the

specific selected paths connecting the patterns though the PL are different. Moreover, their specific

application is different in each course, since the patterns are particularized and adapted to the actual

characteristic of each situation. As discussed in subsection 3.3.3, patterns are intended to serve as

inspiration when designing full-fledged scripts. They offer a balance between rigour and

prescription that provides useful guidance without largely constraining creativity. Quite the

contrary, patterns represent a vehicle of creativity and communication, which enables sharing and

discussing general ideas related to good practices.

On the other hand, it is true that thedegree of freedom” offered by the patterns is not always

the same. This issue has been already discussed in subsection 3.3.1, where it is pointed out that

patterns can be derived from general design ideas, which provides more degrees of freedom, to

70


CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

patterns that formulate their reusable specialization. Degree of freedom in this context is defined as

the number of design options that are free to creatively vary without killing the principles suggested

by the solution of the pattern. From our point of view this is not in contradiction with the

Alexanders’ statement included on page 167 of (Alexander, 1979):

“A pattern language gives each person who uses it, the power to create an infinite variety of

new and unique buildings, just as his ordinary language gives him the power to create an infinite

variety of sentences.”

The sense of creativity that a PL supports is clarified in (Salingaros, 2000):

“A set of connected patterns provides a framework upon which any design can be anchored.

The patterns do not determine the design. By imposing constraints, they eliminate a large number of

possibilities while still allowing an infinite number of possible designs. The narrowing of

possibilities is, after all, an essential part of a practical design method.”

It is clear that ENRICHING THE LEARNING PROCESS (Pattern 1.7) has more degrees of

freedom or fewer constraints that JIGSAW (Pattern 1.1). But JIGSAW supports creativity: it needs

to be adapted to a particular situation, content and disciplines, the task of each activity of the CL

flow needs to be defined as well as the resources needed to support each activity. Teachers (or

learning designers) can even add more activities to those already proposed by the pattern and

probably any other issue that they can imagine (which may be stimulated by the ideas captured in

the pattern). Needless to say, a pattern with more degrees of freedom may be more reusable, but its

reuse may be less “automatic”.

In this line, (Gamma et al., 1995) on page 356 points out:

“When Alexander claims you can design a house simply by applying his patterns one after

another, he has goals similar to those of object-oriented design methodology who give step-by-step

rules for design. Alexander doesn’t deny the need for creativity; some of his patterns require

understanding the living habits of the people who will use the building, and his belief in the

“poetry” of design implies a level of expertise beyond the pattern language itself. But his

description of how patterns generate designs implies that a pattern language can make the design

process deterministic and repeatable.”

CSCL scripting patterns do also require teachers understanding the pedagogical principles that

are under the patterns. The progression through the PLs requires knowing the patterns beforehand

or reflecting upon the different design possibilities before their selection. Teachers are responsible

of selecting and applying the patterns in order to generate a script. Of course, there is an infinite

amount of possible designs but there is also a probability of achieving (quite) similar scripts.

71


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

The scripts exposed in this section consider the use of software tools to support the activities.

However, they are not automatically interpreted by learning environments (e.g. LMSs). It is the

teacher who is in charge of socially mediating the indications of the script (Dimitriadis et al., in

press). Yet the global objective of this dissertation focuses on computer-interpretable scripts, which

enables the automatic management of groups, activities and provision of tools, among other things,

useful in many educational situations. Next section discusses the potential computer-supported

applicability of CSCL scripting patterns focusing on the “life cycle” of scripts, what helps us to link

the contribution provided in this chapter with the objective undertaken in next one.

3.5 Potential computer-supported applicability

Different types of tools may benefit from the use of patterns for CSCL scripts or are needed to

facilitate their use. This section discusses the characteristics of some of them classified according to

the different stages (designing, instantiating, executing) of a CSCL script “life cycle” (cf. Figure

3.4).

Design and

authoring

Resources

searcher

Repository

Awareness

tool

Authoring

tool

...

STUDENTS

72

TEACHER

(CL practitioner)

LMS

Execution

CSCL

script

Groups/roles

management

tool

Figure 3.4 “Life cycle” of CSCL scripts and related tools

Within the phase in which CSCL scripts are conceived and created (design and authored), four

types of tools may be distinguished. CSCL scripting patterns and scripts (generated by applying the

patterns) may be collected in repositories. The main challenges for this type of tool is related to

facilitating collaboration for the joint development of scripts, and to “labelling” patterns and scripts

to ease their sharing. The reuse of CSCL scripting patterns can be fostered by incorporating them in

Instantiation


CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

authoring tools so they may provide advice along the design process. In addition, CSCL scripting

patterns whose solutions propose structures of scripts can be represented computationally and

implemented in authoring tools as a kind of templates that can be easily completed in order to create

computer-interpretable scripts.

To create CSCL scripts, teachers also need to select tools (not to generate them) that are to

support the activities. In this line, semantic search of tools using ontologies is being researched by

Vega-Gorgojo, Bote-Lorenzo, Gómez-Sánchez, Dimitriadis, & Asensio-Pérez (2005). Therefore,

some patterns at the resource level (this is applicable to tools and learning materials) can act as a

mediator between the resource searchers and the user.

During the instantiation of a CSCL script, tools for managing roles and groups are also

necessary. This type of tools should easily enable the creation of multiple groups or roles and the

further binding of individuals according to the knowledge captured in the patterns and the patternbased

structure of a script, which may be quite complicated.

Regarding the interpretation (i.e. execution) of CSCL scripts, the most important types of tools

are players and LMSs. A system that interprets CSCL scripts should consider the information

collected in the patterns. That is, it should be able of interpreting scripts at the learning flow level

or/and at the activity level, provide the needed resources, etc. (Bote-Lorenzo, 2005). The

information captured in patterns may be also used for feedback or adaptation purposes. In addition,

CSCL scripting patterns can be used by awareness tools. For instance, a CL flow awareness tool

(considering the patterns at the CL flow level) will allow participants to be aware of the

collaborative learning flow during execution: which activities have been accomplished, which are

the next ones, in which activities are involved the rest of the participants, etc. In many CL

situations, having such awareness is crucial since participants may change their groups depending

on the phase of the learning flow and may need to know the progress of their future team partners.

3.6 Conclusion

Among the different types of tools involved in the life cycle of scripts, the most directly related

to the main utility of CSCL scripting patterns are authoring tools. Authoring tools can integrate

interactive pattern-based design processes that guide teachers in the design of potentially effective

scripts. The incorporation of interconnected patterns in this type of tools provides a comprehensive

set of well-known design ideas, in a structured way, so that these ideas and the relations between

them are easy to understand.

Alexander’s PL consists of 253 patterns, ranging in scale from an independent (geographical)

region to an ornament. But he also proposes smaller PLs for particular projects (such as building a

porch, for which he provides a PL consisting of just ten patterns). In a similar way, this chapter

73


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

situates the scope of CSCL scripting PLs within a larger design space that considers the

relationships of this type of PLs with other PLs related to different pedagogical approaches and

didactics of specific subject matters.

In this chapter a conceptual model of PLs for CSCL scripting is proposed. It describes the

different types of patterns and relationships among them that can be used for generating CSCL

scripts. The types of patterns are described in an aggregation model that differentiates the patterns

according to their granularity: CL flows which comprises activities that are supported by resources

(tools and material). Roles and common CL mechanisms are modelled as elements that are integral

parts of flows, activities and resources. The patterns associated to the different elements of the

model can be related with connecting rules indicating that a pattern completes another pattern (by

refining the principles of the completed pattern) or that a pattern complements a second pattern

(forming a new larger whole). Patterns at the same level may also complement or/and complete

each other, may represent alternative patterns (mutually exclusive) and specialize other patterns.

The connections between the patterns provide guidance for their meaningful application and prevent

bringing together patterns that do not make sense from the pedagogical perspective. In this sense,

this chapter describes some general guidelines for applying the PLs that can be described with the

proposed conceptual model.

Considering the educational situation as a whole, the patterns should be selected so they are

helpful and feasible for the situation. The recommendation when applying a PL framed within the

proposed conceptual model is to start at the top (CL flow) and work towards the bottom. The

decision of applying or not applying a pattern depends on context. In addition, the resulting

sequence of selected patterns needs to be adapted according to the specific characteristics of the

learning situation.

To show the feasibility of the conceptual model a specific PL for CSCL scripting is proposed. It

comprises only 18 patterns but it illustrates the different types of patterns and relationships

considered in the model. The chapter also discusses how other patterns fit in with the model. New

patterns can be added to this PL or other PLs (reflecting the experience of other communities of

practice) can be proposed. The contribution of this chapter provides to the community a conceptual

model that represents an important starting point towards an agreed high level structure that enables

the sharing and communication of good scripting practices within and between communities.

Some patterns that form the PL are adopted from other authors’ proposals. Other patterns are

formulated by capturing the experience reported in the literature and/or using case studies as a

starting point. It would be very ambitious and unrealistic for a relatively short period of time to

develop a larger PL. Aspect that, on the other hand, is not necessary to reach the objectives of this

dissertation. Alexander et al. need 8 years to finish their published PL (Alexander et al., 1977).

74


CONCEPTUAL MODEL FOR CSCL SCRIPTING PATTERN LANGUAGES

Gamma proposes only some of his famous patterns in his Ph.D. thesis but he needs more time

before writing his book (Gamma et al., 1995).

It is also important to point out that the connecting rules considered in the conceptual model are

quite general and the specification of the particular details that may constrain even more the

relationships depends on particular PLs (e.g. “only the “Expert group” phase of JIGSAW can be

completed with BRAINSTORMING”, “INTRODUCTORY ACTIVITY: LEARNING DESIGN

AWARENESS complements JIGSAW by preceding it”). Future work in this sense may consider the

use of ontologies as a rich way to encode the semantics of the relationships between patterns

(Rosengard & Ursu, 2004; Sicilia, 2006). With this approach, we could explicitly represent the

meaning of terms (patterns) in vocabularies and the relationships between those terms. This would

also allow a powerful automatic organization and retrieval of the patterns.

The examples for applying the pattern exposed in this chapter illustrates that the proposed PL

and potentially any PL situated in the conceptual model comply with the properties of moral

preoccupation, coherence, generativeness and creativity. CSCL scripting patterns offer inspiration

and guidance based on equilibrium between rigour and prescription that enables creativity. They

impose constraints that are related to the intrinsic knowledge of the patterns. In this sense, they

prevent a number of design options while still allowing an infinite number of possible specific

scripts.

With regard to the generation of coherent scripts, this dissertation aims at providing users

(mainly teachers) with authoring tools that incorporate CSCL scripting patterns. Following the

metaphor of Alexander (Alexander, 1999), the genes are the functionalities of the tool that

facilitates the generation of potentially effective scripts adapted to particular situations according to

the decisions of the user. If these tools are accepted and widely spread through the educational

institutions and the scripts can be interpreted by as many as possible learning environments, we are

contributing to technologically enhance the teaching and learning practices. To reach this goal next

chapter undertakes the problem of computationally representing the scripts so that they can be

interpreted by software systems. As concluded in Chapter Two, IMS LD is a significant candidate

language for representing the scripts. The use of this specification, which is being adopted by

several LMSs, would foster the moral purpose of broadly spreading the application of well-known

CSCL practices.

75


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

76


CHAPTER FOUR

IMS LD SUPPORT FOR

COMPUTATIONALLY REPRESENTING

CSCL MACRO-SCRIPTS

This chapter tackles the objective of analyzing the suitability of IMS Learning Design

for computationally representing CSCL macro-scripts, which describe flows of coarsegrained

activities. In order to provide a systematic analysis of this problem, we point out

the requirements of the scripts for their representation using LD. These requirements

include common collaborative learning mechanisms (group composition, role and

resource distribution and coordination) and flexibility demands (mainly flexible group

composition). The possibilities and limitations of LD to support each of these needs is

tested and illustrated by means of significant cases. The chapter collects the lessons

learned from this analysis showing the capacity of LD notation to express CSCL macroscripts

but also considering the support of related specifications and tools.

The contributions of this chapter have been published in (Hernández-Leo et al.,

submitted), (Hernández-Leo et al., 2005), extended version of (Hernández-Leo et al.,

2004), and (Hernández-Leo et al., 2005a), extended version of (Hernández-Leo et al.,

2005b).

4.1 Introduction

How can CSCL macro-scripts be computationally represented so that they are interpretable by

learning environments? As Chapter One pinpoints, the main objective of this dissertation focuses on

macro-scripts rather than micro-scripts. Psychological and pedagogical concepts are involved in

their differentiation (Fischer et al., 2007). However, for the purposes of this chapter (devoted to

computational representations) the distinction is concentrated on their granularity: micro-scripts

describe the fine-grained actions that each participant should accomplish within CL activities, and

macro-scripts orchestrate flows of coarse-grained individual and CL activities. From the patterns

listed in the CSCL scripting PL proposed in Appendix A and discussed in Chapter Three, the


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

patterns at the CL flow level characteristically embody numerous features of macro-scripts.

Therefore, this type of patterns (what we call Collaborative Learning Flow Patterns or CLFPs

henceforth) are of special relevance regarding the pattern-based design of (machine-readable)

macro-scripts (simply “scripts” from now on to achieve a more readable text).

As pointed out in Chapter One, the global objective of the dissertation is to propose a design

process based on patterns for facilitation the creation of potentially effective scripts that can be

interpreted by general learning environments. Accordingly, to enable automatic scaffolding of the

teaching and learning process by means of scripts but without the need of developing specifically

devoted tools, this chapter proposes to formalize the scripts so that they can be interpreted by

engines integrated in learning environments. This approach has many time and cost advantages

related to efforts in development and enables tailorable systems. Chapter Two concludes that the

(XML-based) IMS LD language is the most interesting candidate to computationally represent the

scripts according to the definition of the specification and the interoperability prospects.

LD is broadly accepted as the de facto standard to formally model interoperable Units of

Learning (UoL). The specification is designed so that UoLs can describe any teaching-learning

process (Koper et al., 2004). Nevertheless, the LD support for implementing CSCL scripts is not

clear. The motivation of this problem is twofold. Firstly, since LD is a recent specification (IMS,

2003b), there is a lack of significant examples and efforts that show the possibilities of LD for

CSCL. Secondly, there is a lack of clarity regarding which characteristic of the scripts should be

expressed by the notation itself as opposed to which requirements can be supported by tools or even

other related specifications. Although partial work has been already accomplished (Gorissen et al.,

2005; Bote-Lorenzo, 2005; van Es & Koper, 2006; IMS, 2003a; Koper et al., 2005), a more

complete and systematic analysis is needed. As a consequence, some researchers are pointing out

presumed limitations of LD and alternative Educational Modelling Languages proposals to describe

CL situations are emerging (cf. subsection 2.4.2).

In this chapter we analyze the support of LD to implement the main requirements of CSCL

macro-scripts. Next section (4.2) describes the methodology applied in the analysis. Then, section

4.3 identifies the educational design requirements of CSCL scripts. Each requirement is illustrated

by means of references to CLFPs and actual scripts that significantly reflect them. A set of these

manifestations of the requirements are selected to be implemented using LD. This problem is

approached confronting the differences between the needs that can be satisfied by the LD notation

itself (section 4.4) and the needs that can be solved using tools or related specifications (section

4.5). Finally, section 3.6 concludes the chapter.

78


IMS LD SUPPORT FOR COMPUTATIONALLY REPRESENTING CSCL SCRIPTS

4.2 Methodology applied in the analysis

The analysis performed in this chapter is situated in the analytical phase of the global

methodology considered in this dissertation (cf. Chapter One). This analysis is approached as

follows.

First of all, significant requirements of CSCL macro scripts are identified in the literature. From

the numerous CSCL practices that manifest these requirements, we collect some examples that

significantly feature them. In this sense, the description of the requirements is complemented with

excerpts of actual practices illustrating them. The complete versions of the selected practices are the

CLFPs included in section A.1 of Appendix A and the well-known (in the CSCL community)

scripts listed in section B.1 of Appendix B.

The three renowned scripts employed in the analysis are Universanté, ArgueGraph and

ConceptGrid (Dillenbourg, 2002; Dillenbourg et al., 2007; Berger et al., 2001; Universanté, 2002;

Jermann & Dillenbourg, 2002; Kobbe et al., submitted). The fact that these scripts can be built

using the suggestions of CLFPs is important for the analysis. Universanté script is based on

JIGSAW structure (Pattern 1.1 of Appendix A). ConceptGrid is a variation of JIGSAW and might be

also considered as based on the SIMULATION CLFP (Pattern 1.3 of Appendix A). ArgueGraph

script can be constructed using PYRAMID (Pattern 1.2 of Appendix A) as a starting point. In this

sense, some of the requirements may be present both in CLFPs and specific scripts but others may

appear only when refining CLFPs with other types of patterns (cf. Chapter Two) and particularizing

them into full-fledged scripts.

From the excerpts of actual practices that significantly feature the requirements, we select

representative ones for their implementation with LD. The aim is trying to develop LD-represented

scripts that code the identified requirements. The involved LD elements and attributes as well as

illustrative XML excerpts that express the requirements (when applicable) are provided. Besides,

possible solutions relying on complementary specifications and supporting tools are discussed when

coding the characteristics related to the requirements is not feasible.

The work around the support of LD (level A) for computationally representing CLFPs is

accomplished first (Hernández-Leo et al., 2005; Hernández-Leo et al., 2005a). The main

requirements analyzed to that point are the definition of group hierarchies, rotation of roles,

specification of learning flows (coordination of activities) and CSCL tools. Then, the representation

of full-fledged scripts comprising further requirements is approached (considering also level B and

C of LD). This work is realized at OTEC in the OUNL during a three-month research stay

(Hernández-Leo et al., submitted).

Furthermore, the results of the evaluation phase reported in Chapter Six provide further insight

to the conclusions of this analysis. In that phase a multicase study considers different experiences

79


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

around other LD-represented scripts from different perspectives: teachers and designers authoring

the LD scripts, creation of a script not selected by us and enactment of another script with real

students.

4.3 Requirements of CSCL macro-scripts

As described in the previous subsection on methodology, this section introduces the educational

design requirements of CSCL scripts, which are identified in the CSCL literature. The main sources

are conformed by the review of CL available at (NISE, 1997), the CSCL scripting patterns collected

in Appendix A (especially the patterns at the CL flow levels, CLFPs), well-known CSCL scripts

and, particularly, the current research reports on framing their components and mechanisms (Kobbe

et al., submitted) as well as their flexibility demands (Dillenbourg et al., 2007). Based on these

sources, we classify the requirements for computationally representing the scripts into four different

types, namely group composition, role and resource distribution, coordination and flexibility. Each

requirement is illustrated with excerpts of CLFPs (when applicable) and actual full-fledged scripts.

4.3.1 Group composition

Appropriate and effective composition of groups is crucial in collaborative learning (NISE,

1997; Johnson & Johnson, 1999). Depending on the specific situation, a CL practitioner needs to

think over the composition of the involved group (or groups). This dependency may be implicit in

the learning flow structure (CLFP) of the script or it may appear when refining the structure into an

actual script.

We identify five central features related to group composition: hierarchy of groups, group size,

amount of groups, group formation policies and group formation at runtime. Next subsections

discuss each of these characteristics.

It is noteworthy that a script may not take into account all the features as necessary for success

(although a combination of them is possible). For example, some situations require a certain amount

of groups but they are flexible as far as the group size is concerned, while other situations give more

importance to group size. In addition, some scripts demand group compositions based more on

particular group formation policies than on actual group sizes (Kobbe et al., submitted).

4.3.1.1 Hierarchy of groups

Scripts typically make use of groups forming hierarchies, i.e., groups may be composed of other

(smaller) groups or different (individual) roles.

80


IMS LD SUPPORT FOR COMPUTATIONALLY REPRESENTING CSCL SCRIPTS

This feature largely depends on the CL flow of a script. Thus, hierarchies of groups are implicit

in many CLFPs (cf. Appendix A) and consequently in their particularization into a script. A

significant example can be found in PYRAMID (Pattern 1.1 of Appendix A):

- Each individual participant studies the problem and proposes a solution. Groups (usually

pairs) of participants compare and discuss their proposals and, finally, propose a new shared

solution. Those groups successively join in larger groups in order to generate a new

agreed proposal. At the end, all the participants must propose a final and agreed solution.

Of course, group hierarchies also appear in specific scripts, such as Universanté (cf. Table B.1):

- There are country group and thematic groups. Each thematic group is composed of case

groups.

4.3.1.2 Group size

Defining the desired number of group members is perhaps the most common suggestion of

scripts regarding group composition. They usually recommend keeping group size small for short

activities because, for example, there is not enough time for the group to become effective (NISE,

1997). However, larger groups might be adequate in longer situations (e.g. a course).

With regard to this feature, scripts may indicate the minimum, maximum or desired number of

participants. This aspect is determined in the actual script and not in its CL flow structure (if we do

not take into account that a group has at least two members), which can be (re)used in any length of

time and with many different tasks/activities, etc. An excerpt of a script (ArgueGraph, cf. Table

B.2) indicating group size is:

- An even number of at least 4 participants (works best with 20-30 participants) and a

tutor […] In the “survey” phase, all participants together form the class group and receive

one copy of the questionnaire. In the “conflict” and “elaboration” phase, all participants

are distributed evenly among groups of two…

4.3.1.3 Amount of groups

As aforementioned, some scripts require a certain number of groups or at least a minimum or

maximum amount so that the dynamics they propose are afforded (Kobbe et al., submitted). Again,

scripts may indicate the minimum, maximum or desired amount of groups. This aspect may be

specified either in the CL flow structure (e.g. at least two experts groups, cf. JIGSAW in Appendix

A) or in a particular script:

- At least two different theme groups, two case groups (per thematic) and two country

groups (Universanté).

81


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

4.3.1.4 Group formation policies

Depending on the situation, actually on the practical experience and research related to it,

groups should be heterogeneous or homogenous (NISE, 1997). The groups can be formed either by

the students themselves or by the teacher by referring to existing common features (e.g. gender,

age) or simply using a random assignment policy (cf. FREE GROUP FORMATION and

CONTROLLED GROUP FORMATION, Pattern 4.2 and Pattern 4.3 of Appendix A).

This aspect is determined in the particularized script. The Universanté script offers us an

example of a group formation policy:

- Each “case group” is formed of at least 1 participant per country.

4.3.1.5 Dynamic group formation

Some scripts need groups to be formed at runtime. That is to say, the assignment of a person to

a group (and to a role) may depend on the result of a previous activity. A clear example of this

feature appears in ArgueGraph script:

- In the “conflict” and “elaboration” phases, all participants are distributed evenly among

groups of two, composed of participants with maximal difference in their responses to

the questionnaire. (In this script selecting peers with similar opinions instead of opposite

opinions would counteract the conflict generation principle of the script.)

4.3.2 Role/resource distribution

With the aim of fostering (positive) interdependence, CSCL scripts often make use of

distributing “tasks”, which is related to allocating roles and resources (e.g. the output or result of a

“collaborative (sub)tasks distribution” may be considered as a distribution of roles and/or resources

at runtime).

4.3.2.1 Role distribution

In a script participants may assume one or more roles at the same time (e.g. one of the students

in a group is assigned to the role “scribe”… (Dalziel, 2003)) In addition, participants can switch

these roles with other participants (e.g. rotation of roles, scribe vs. speaker) (Kobbe et al.,

submitted).

Examples of role distribution in a CLFP and in actual scripts are:

- The two students are given specific roles that switch with each problem: Problem Solver

and Listener (TAPPS, Pattern 1.6 of Appendix A).

82


IMS LD SUPPORT FOR COMPUTATIONALLY REPRESENTING CSCL SCRIPTS

- Groups of four students have to distribute four roles among themselves (ConceptGrid

script, cf. Table B.3).

- Each person belongs to three different types of groups, which implies playing specific

roles depending on their “case”, “theme” and “country” (Universanté).

- An example of participants assuming several roles at the same time may be:

- In the particularization of the JIGSAW “Expert groups” phase, experts use simultaneously

a discussion forum where one of the experts is a moderator and the rest are

participants, and a collaborative conceptual map tool where one of the experts is the

writer and the others are annotators.

4.3.2.2 Resource distribution

Another important feature of CSCL scripts is the distribution of resources (Kobbe et al.,

submitted). The amount of resources and their selected distribution may depend (or not) on the

number of groups, roles or participants.

For example, in order to foster knowledge exchange between group members JIGSAW proposes

that:

- Each participant in a group (“Jigsaw Group”) studies or works around a particular subproblem.

Similarly, SIMULATION (Pattern 1.3 of Appendix A) indicates:

- Each participant consults information about the problem to be simulated and prepares

the role of his/her character (with further information that may be available).

Therefore, particularizations of CLFPs into scripts usually keep the resources distribution of the

patterns and include new requirements concerning this feature:

- At least as many participants per country as there are case descriptions […] For each

case description one “case group” is formed […] All case descriptions are distributed

evenly among all case groups (Universanté).

- One copy of a questionnaire for each participant and another copy for each small

group. […] One argument sheet per question of the questionnaire and as many copies of

these sheets as are needed to provide one copy for each participant (ArgueGraph).

4.3.3 Coordination

Without doubt, coordination is an inherent characteristic of scripts. We distinguish between

coordination of (collaborative) leaning activities and coordination of “actions” within activities

83


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

(Ellis et al., 1994). In addition, coordination of artefacts is necessary: artefacts are often created by

an individual or a group and may be used in different activities and by different individuals or

groups (Miao et al., 2005).

4.3.3.1 Flow of (collaborative) learning activities

The coordination of activities that make up a collaborative learning process is organized as a

flow of learning activities. The activities are mostly collaborative, but the learning flow can include

individual activities as well. The main problem of this type of flows falls into the synchronization of

groups and roles along the activities: a person may belong to a group in a certain activity and to

another group in the following one (then she probably needs to wait for the rest of the members in

her second group in order to start the second activity):

- Each participant in a group (“Jigsaw Group”) works around a particular sub-problem. The

participants of different groups that study the same problem meet in an “Expert Group” for

exchanging ideas. […] At last, participants of each “Jigsaw group” meet to contribute with

their “expertise” in order to solve the whole problem (JIGSAW).

Each CLFP proposes a flow of learning activities, which may be enriched or cut down and at

the same time particularized into a full-fledged script. For example, the flow of activities proposed

by JIGSAW is simplified in ConceptGrid (the “expert group” phase is cut down). The same flow of

activities is enriched in Universanté by including “theme group” activities.

4.3.3.2 Floor control

While working together in the same activity, learners’ actions are sometimes guided or

constrained according to floor control mechanisms (e.g. a model of turn-taking in conversations or

when modifying an artefact). Floor control is typically needed in synchronous activities where

participants should know how and when they can interact. That is, floor control aims to manage

conflicts and structuring group work within activities (Boyd, 1996). Floor control policies may be

previously fixed (for example by the teacher) or may change dynamically (on the fly).

For example, when particularizing BRAINSTORMING (Pattern 1.4 of Appendix A) different

floor control policies can be considered (NISE, 1997):

- Different types of floor control can be used when generating ideas: methodically going

around the group, going around the group but letting students “pass” if they cannot

generate an idea (number of passes may be limited), a free floor control (not going

around the group, i.e. waiting for voluntary contributions).

84


IMS LD SUPPORT FOR COMPUTATIONALLY REPRESENTING CSCL SCRIPTS

Most collaborative activities included in CLFPs can use an actual floor control when they are

particularized into a script (e.g. achieving a consensus according to a voting floor control policy):

- In Universanté script, fact sheets and health strategies are shared artefacts that require floor

control mechanism to ensure data consistency.

- Achieving a consensus when answering the questionnaires in ArgueGraph scripts should

consider a floor control mechanism to ensure the consistency of the shared answer.

4.3.3.3 Flow of artefacts

As aforementioned, artefacts (e.g. a document) are often created by an individual or a group.

They may be used in different activities and by different individuals or groups of the same script.

There are many explicit examples of artefacts flows in particular scripts:

- Since fact sheets are created until they are finally available to the teacher in Universanté,

they are used in discussions within theme groups, presented within country groups,

commented by the teacher, and modified by their original authors.

- ArgueGraph requires that the answers to the questionnaires (choices and arguments) of

individuals and small groups are displayed in different activities.

A similar problem appears when the teacher needs data (e.g. traces) in specific supporting

activities for regulation purposes (e.g. providing students with more information according to the

progression along the script).

4.3.4 Flexibility

The main drawback of scripts is their associated “risky” flexibility restrictions. Some of these

restrictions are intrinsic constraints of the script that justify its effectiveness (Dillenbourg et al.,

2007). These “intrinsic constraints” are in fact the essence captured in CLFPs (e.g. participants of

each “Jigsaw group” contribute with its “expertise” in order to solve the whole problem). Scripts

should keep this type of constraints and may add new ones (e.g. pair students with different

opinions). Therefore, flexibility concerning intrinsic constraints is not a strong requirement of

scripts.

However, when particularizing CLFPs into ready-to-run scripts “extrinsic constraints”, without

an underlying essential pedagogical principle, emerge. Inflexible extrinsic constraints can spoil

(needlessly) a satisfactory enactment of the learning situation. An example of extrinsic constraints is

the decision related to the duration of activities:

85


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

- In the ConceptGrid script, students can be allowed between 5 and 20 days for reading texts

and writing concepts definitions, the specific definition depends on the course calendar

(Dillenbourg et al., 2007). Even after defining it according to the course calendar (or the

class duration), unexpected situations may happen (e.g. teachers’ strike, students’ trip…)

and the time structure of the CSCL script should be consequently modified (because

otherwise it will be impossible to finish it).

Not only are modifications on the fly regarding the time structure required but changing

resources (content or tools), the order of the activities and the activities themselves is often also

crucial (e.g. adding a new text for clarification purposes). These flexibility requirements are more

complex in CSCL scripts than in other learning situations since the behaviour of groups is even

more unpredictable (e.g. need of providing additional materials or activities for faster groups so

they do not waste time waiting for the people to be joined in the following activity, cf. ENRICHING

THE LEARNING PROCESS, Pattern 1.7 of Appendix A). However, these requirements are actually

present in any learning situation (e.g. in an individual learning situation usually appears the need of

providing additional material and more time because something is not clear enough); and the

support of LD to specify these adaptive and personalized situations for individual learning are being

deeply analyzed by other researchers (Burgos, Tattersall, & Koper, 2006; Berlanga & García, 2005;

Burgos et al., 2006b; Burgos et al., 2006a; Zarraonandia, Dodero, & Fernández, 2006). That is the

reason why we focus our analysis on a common flexibility-demanding characteristic that

significantly appears in scripts: flexible group composition.

4.3.4.1 Flexible group composition

A typical problem of CL situations, especially blended learning and synchronous virtual

situations, is the variability of students’ participation. It is common that a member of a group leaves

the course or cannot participate in a specific moment. It is often impossible for the teacher to guess

the precise amount of participants that are attending a particular session, whether they will be an

even or odd number or if some of them will join the class afterwards or cannot participate in a

specific moment.

- The current version of ConceptGrid runs with teams of 4, while the ideal group size range

from 3 to 5 (Dillenbourg et al., 2007). If a teacher has 23 attending participants she

should be allowed to form five groups of 4 and one of 3, or three groups of 5 and two of 4,

etc.

More complex situations come out when the participation varies at runtime. These situations

often require unexpected group composition modifications:

86


IMS LD SUPPORT FOR COMPUTATIONALLY REPRESENTING CSCL SCRIPTS

- Several students do not attend the “conflict phase” of ArgueGraph script and the teacher

(or the system) has already formed the groups (pairs). A reconfiguration of groups may be

necessary.

Each requirement described in this section implies a different challenge. However, they are all

shaped around the fact that they involve groups and multi-participant characteristics: specification

of groups (hierarchy, size, amount, formation policy and dynamic formation), distribution of roles

and resources (according to groups, roles and participants), coordination of activities, users’ actions

and artefacts (assuming that there are several participants, etc.), and flexible group composition.

Some requirements notably appear in the CLFPs. In these cases, a first study of the LD support

for expressing these requirements is accomplished in next section. Then, further analysis is carried

out with full-fledged scripts. It is noteworthy that all the requirements are significantly manifested

in Universanté and ArgueGraph scripts. Therefore, both scripts are selected for testing their

implementation with LD. Before codifying those scripts, their corresponding narrative use case

descriptions and activity diagrams are realized (cf. Appendix B) as indicated by the basic design

procedures for the development of UoLs (IMS, 2003a; Sloep et al., 2005).

4.4 Expressing the requirements using IMS LD notation

The problem of implementing the requirements of CSCL scripts using LD is approached by

examining the needs that can be satisfied by the LD notation itself and the needs that can be

supported by related specifications or supporting tools. This section emphasises the role of the LD

notation to express the requirements while next section discusses how tools and other specifications

may complement the implementation of the requirements.

As aforementioned, expressing some of the requirements is initially accomplished using the

CLFPs (cf. Appendix A). Then, the analysis is completed with Universanté and ArgueGraph scripts

(cf. Appendix B). The results of the analysis are collected in tables that also include selected

excerpts of suggested coding. They refer to the characteristics of the scripts that illustrate well the

use of LD elements and attributes for computationally representing the requirements (The complete

UoLs are available at http://gsic.tel.uva.es/collage/scripts and in the attached CD-ROM. In addition,

Appendix B shows screenshots of specific runtime executions (runs) of the UoLs representing the

scripts).

The main elements of LD are revised in subsection 2.4.1 of Chapter Two. For a better

understanding of the analysis detailed in the following subsections the reader might want to consult

the LD specification (IMS, 2003b).

87


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

4.4.1 Group composition

The capability of LD to support the requirements related to group composition are firstly

studied with PYRAMID CLFP, since it significantly manifest these requirements (as analyzed in

section 4.3).

A group is modelled in LD using the role element. Several persons can be associated to the

same role (thus forming a group). Besides, LD enables the design of processes that include several

roles. A collaborative learning situation can be described by associating multiple people and/or

multiple roles to the same learning activity.

Figure 4.1 shows the subtle way in which the hierarchy of groups defined by PYRAMID can be

generally specified with LD by means of nested roles (IMS, 2003b). Left part of the figure (a) refers

to the LD formalization of Pyramid roles. “Pyramid_N” is the role that will be played by the

participants in the last (N) level of the Pyramid. Role “Pyramid_i” refers to the first and

intermediate levels of the Pyramid (i ranges form 0 to (N-1)). Right part illustrates a possible result

of the dynamic role assignment while interpreting (but before running) a (three-level) PYRAMIDbased

UoL.

Role Pyramid_N

created-new=”allowed”

min-persons=”2”

Role Pyramid_i

created-new=”allowed”

match-persons=

”exclusively-in-roles”

1

2 . . M

Pyramid_1

(1)

(a) (b)

Figure 4.1 LD representation of the groups involved in the PYRAMID structure (a) and an example of the

assignment of roles to users in a particular PYRAMID -based UoL (b)

The “Pyramid_N” role should be played by several individuals (minimum of 2 persons, minperson=”2”),

which actually form the largest group of the PYRAMID. Various Pyramid groups can

be dynamically created (created-new=”allowed” determines that multiple instances of a particular

role are allowed (IMS, 2003b)). (The alternative to dynamically creating the number of groups

when instantiating the UoL (occurrences of roles, created-new=”allowed”, can be created) is

defining the actual number of groups at design time: each declared role corresponds to a group, cf.

88

Pyramid_2

(1)

Pyramid_1

(2)

Pyramid_3

Pyramid_2

(2)

Pyramid_1

(3)

Pyramid_1

(4)


IMS LD SUPPORT FOR COMPUTATIONALLY REPRESENTING CSCL SCRIPTS

Table 4.1) When a new occurrence (instance) of a role is created, the new occurrence is also the

parent of its defined sub-roles. Each individual in a “Pyramid_i” group can be bound exclusively to

one “Pyramid_i-1” sub-role (match-persons=”exclusively in roles”). A participant bound to the

occurrence (1) of the “Pyramid_1” role cannot be bound to any other occurrence of the same role

and is also bound to occurrence (1) of “Pyramid_2” role and to “Pyramid_3” role (cf. Figure 4.1).

Note that if a unique individual will be bound to each role in the first level of the Pyramid

(Pyramid_1), these roles are not strictly necessary. In this case, “Pyramid_N” and “Pyramid_1” are

equivalent. “Pyramid_N” represents a group or an individual depending on the environment

associated to the activity that this role plays in a particular moment (act), i.e. whether the service

included in the environment is collaborative or not.

Similarly, Universanté and ArgueGraph characteristics regarding group composition are

represented as indicated in Table 4.1 and Table 4.2.

Table 4.1 Computationally representing the group composition requirements of Universanté script

Requirements

Hierarchy of

groups

(Each thematic group is

composed of (at least) two

case groups. There are

also two country groups.)

Group size

(Since there are at least

two countries, each casegroup

has (at least) 2

persons of different

countries. Since there are

2 cases per theme, each

thematic-group has (at

least) 4 persons. Since

there are four cases, each

country-group has (at

least) 4 persons.)

Amount of groups

(At least two different

thematic groups, two case

groups (per thematic) and

two country groups)

Group formation

policies

(Each case group is

formed of at least 1

participant per country)

Dynamic group

formation

Involved LD elements

and attributes

Groups are modelled using

roles, which can be bound

to several persons. Roles

can be nested, indicating

that a role is divided in sub

roles.

Role attributes min-persons

and max-persons specify

the required minimum and

maximum numbers of

persons bound to the role.

Each group can be modelled

as a role. An alternative is

using the role attribute

create-new, which indicates

that multiple occurrences of

the role (and their sub roles)

can be created at runtime

(as previously illustrated

with PYRAMID pattern)

This requirement cannot be

formally specified but it can

be added as information of

the role in the referenced

resource.

(Not applicable)

Illustrative excerpts, supposing that there will be

2 countries and 4 participants per country, i.e.

2 thematic groups comprising 2 case groups


[…]


[…]



[…]




[…]



[…]




[…]


[…]

[…]


To emphasize that a person bound to a thematic-group can be

exclusively matched with one of its sub-roles (a case-group) the

attribute match-persons of the role element can be used.

[…]



[…]

The resource "R- relation-case-country-groups" can be a text file

indicating “Each case group is composed of at least 1

participant per country”

89


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

Table 4.2 Computationally representing the group composition requirements of ArgueGraph script

Requirements

Hierarchy of

groups,

group size,

amount of

groups

(An even number of at

least 4 participants

(works best with 20-30)

and a tutor. Participants

will be distributed

among groups of two.)

Group

formation

policies,

dynamic group

formation

(In one of the phases, all

participants are

distributed (by the tutor)

evenly among groups of

two, composed of

participants with

maximal difference in

their responses to the

questionnaire.)

Involved LD elements

and attributes

Illustrative excerpts, supposing that in

ArgueGraph there will be only 4 participants,

i.e. 2 pairs

(cf. Table 4.1)


Student



Tutor



Local personal properties can

be used to model groups so

that their value can be

determined at runtime using

global-elements. The persons

with the same value of the

property are in the same

group. Conditions are in

charge of coordinating the

activities and artefacts

according to this value of each

participant’s property (i.e.

according to their group).

4.4.2 Role/resource distribution

(See group formation polices and dynamic group formation)

The tutor dynamically determines at runtime to which group

each student is bound (see second screenshot of survey phase,

tutor, in Table B.9). Depending on the group, access to an

activity containing a different instance of the shared

questionnaire is provided (see screenshots of conflict phase,

student, in Table B.9).

[...]

PairA

PairB


[…]



PairA








Rotation of roles cannot be explicitly specified using LD. However, Figure 4.2 shows a way of

implicitly describing the rotation of the roles involved in the TAPPS pattern: problem solver and

listener. The generic roles “Student-A” and “Student-B” are alternatively associated to the

explanation and listening activities within each act. These activities are connected through a

conferencing service.

90


IMS LD SUPPORT FOR COMPUTATIONALLY REPRESENTING CSCL SCRIPTS







































91




















Figure 4.2 Excerpt of a TAPPS-based LD (arrows point referenced element definitions)

In accordance with the conclusions of the previous subsection, Table 4.3 and

Table 4.4 describe how the role distribution required by Universanté and ArgueGraph can be

expressed with LD. The distribution of resources is also detailed in these tables.

Table 4.3 Computationally representing the role/resource distribution requirements of Universanté script

Requirements

Role distribution

(Each person belongs to three

different types of groups, which

implies playing specific roles

depending on their “case”,

theme” and “country”.)

Resource distribution

(All case descriptions are

distributed evenly among all case

groups.)

Involved LD elements

and attributes

Illustrative excerpts (or explanations),

supposing that there will be 2 countries and

4 participants per country, i.e. 2 thematic

groups comprising 2 case groups

Persons can be bound to one or several roles in the same run of the UoL. In this example

each person should be bound to one country group and one case group (and thus to one

thematic group). The moment in which they are playing each role is specified in the

learning flow using the role-part element. To explicitly indicate that persons can be

matched exclusively to one of the sub roles (e.g. case groups within a thematic group)

LD provides the role attribute match-persons.

The resources can be

associated to activitydescriptions

or to

environments, referenced in

turn by other LD elements

depending on the

distribution needs.

In this example, an environment per “case description”

(a learning-object) is defined. An activity-structure per

case is also defined. Each activity-structure references

one of the environments and a common learningactivity

explaining the task. Each activity-structure is

bound to a role in different role-parts of the same act.

(See package UniversanteUoL.zip at

http://gsic.tel.uva.es/collage/scripts or in the attached

CD-ROM)


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

Table 4.4 Computationally representing the role/resource distribution requirements of ArgueGraph script

Requirements

Role

distribution

(Pairs can be considered

as different roles to be

distributed.)

Resource

distribution

(One copy of a

questionnaire (including

argument sheets) for

each participant and

another copy for each

small group.)

Involved LD

elements and

attributes

(See group formation at runtime, Table 4.2)

The created artefacts (answers to

the questionnaires) can be stored

in local properties (o global if it

needs to be stored beyond the

UoL). If the artefact is created

individually, the property can be

personal (locpers-property) and if

it is associated to a group of type

role (locrole-property)

Illustrative excerpts, supposing that in ArgueGraph

there will be only 4 participants,

i.e. 2 pairs

92

The results of individual questionnaires are stored in local

personal properties


Argument for my choice



The persons in the same group (pair) share local properties

for their joint answers. Using global-elements different

persons can view and set the value of the property.


Argument for PairA's choice



On the other hand, resource distribution is tightly related to the flow of artefacts considered as a

coordination requirement. Next subsection explores this aspect.

4.4.3 Coordination

The learning flows described by CLFPs can be expressed in the LD method. A method

contains one or more plays, which are modelled according to a theatrical play with acts, role-parts

(linking roles to activities) and activity structures (wrapping several activities). These plays run in

parallel, independent from each other. Acts determine whether, when, and for what roles an activity

and resources are to be used (IMS, 2003b). Figure 4.3 illustrates how the learning flow described by

JIGSAW can be modelled using LD. It makes use of three acts whose boundaries are determined by

the synchronization points between the groups (same persons change roles/groups and need to

synchronize with the persons joining their group). In this sense, Figure 4.3 also shows that the

groups required in JIGSAW are modelled using roles (as explained in subsection 4.3.1). The persons

associated to the “Jigsaw group” role can work individually or collaboratively depending on the

activity.


IMS LD SUPPORT FOR COMPUTATIONALLY REPRESENTING CSCL SCRIPTS

method

play

Jigsaw-

CLFP

act role role-part assigned

1.1 (member in) “Jigsaw group” learning-activity: individual-study

1.2 Teacher support-activity: control-activity

Complete act when...

2.1 “Expert group” activity-structure: subproblem-activities

2.2 Teacher support-activity: control-activity

Complete act when...

3.1 “Jigsaw group” activity-structure: globalproblem-activities

3.2 Teacher support-activity: control-activity

Complete act when...

Complete play when last act has been completed

Complete method when play Jigsaw-CLFP has been completed

Figure 4.3 Expressing the JIGSAW learning flow with the LD method

Therefore, the general flow structures described by the CLFPs can be formalized using level A

of LD. More complex flows may appear in full-fledged scripts, as it is the case of Universanté and

ArgueGraph scripts that benefit from level B and C LD constructs (cf. Table 4.5 and Table 4.6).

Table 4.5 and Table 4.6 also indicate the floor control effect that can be achieved with “shared”

properties. This ensures the consistency of the created or modified artefact, however more

sophisticated floor control mechanisms may be required depending on the situation. Properties

together with global-elements (monitor services) are used to set and view the value of artefacts

along the learning process. These LD elements enable the description of flows of artefacts between

activities.

93


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

Table 4.5 Computationally representing the coordination requirements of Universanté script

Requirements

Flow of CL

activities

(Cf. Table B.4)

Floor control

(Fact sheets and health

strategies are shared

artefacts that require

floor control mechanism

to ensure data

consistency.)

Flow of artefacts

(Since fact sheets are

created until they are

finally made available

to the teacher, they are

used in discussions

within theme groups,

presented within

country groups,

commented by the

teacher, and modified

by their authors.)

Involved LD elements

and attributes

The flow of activities is

expressed in the method. A

method contains one or

more plays, which are

modelled according to a

theatrical play with acts and

role-parts. The plays run in

parallel. Acts together with

conditions (and also

notifications) determine

whether, when, and for what

roles activities and

resources need to be

available. Different types of

conditional expressions can

be used to orchestrate the

flow (IMS, 2003b).

Illustrative excerpts (or explanations), supposing

that there will be 2 countries and 4 participants

per country, i.e. 2 thematic groups comprising 2

case groups

This script requires a method with five acts. Each act contains a

role-part per role of the “type” of role that corresponds to each

phase. In the cases that the activities are performed by persons

belonging at the same time to two groups (E.g. “within each

thematic group, the members of each country group create a fact

sheet”), it is necessary to add conditions with two expressions

of type is-member-of-role. See the screenshots of the

“Thematic group: the members of each country group create a

fact sheet” in Table B.7.










- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


Please create fact sheet concerning the "Cancer"

status in your country, Switzerland:



The UoL uses local properties to model fact sheets shared by persons belonging at the same

time to the same country-group and to the same thematic-group (persons who are members of

two roles). A student (in a country group and with a particular theme) can set a local property

that can be viewed and modified by another student (in the same country and thematic group).

The UoL also uses local role properties to model health strategies shared by the people

belonging to the same case-group (same role). A student (in a case group) can set a local role

property that can be viewed and modified by another student (in the same case group).

(As can be seen in Table B.7 the fact sheets are modelled using properties of type “text”.

Another solution is using properties of type URI or “file” so that a document (the fact sheet) is

uploaded. This document may be created with a collaborative text editor (which may implement

floor control policies) or, if the participants working in the same fact sheet are F2F in the same

country, with an editor in a shared PC.)

Properties can be used to

model individual and shared

artefacts. Global-elements and

monitor services are used to

set and view the value of their

own or that of others

properties. These elements are

referenced by the different

activities that require the

artefacts.

The value of the properties modelling the facts sheets can be

set and viewed by the participants by means of globalelements

in the several activities. In this excerpt users can

modify their fact sheet.


[…]


Please modify the fact sheet (Cancer status in Switzerland)

according to the methodological comments:


[…]


94


IMS LD SUPPORT FOR COMPUTATIONALLY REPRESENTING CSCL SCRIPTS

Table 4.6 Computationally representing the coordination requirements of ArgueGraph script

Requirements

Flow of CL

activities

(Cf. Table B.8)

Floor control

(Achieving a consensus

when answering the

questionnaires should

consider a floor control

mechanism to ensure

the consistency of the

shared answer.)

Flow of artefacts

(The answers to the

questionnaires (choices

and arguments) of

individuals and small

groups are displayed in

different activities.)

Involved LD elements

and attributes

(Cf. Table 4.5)

Properties (local or global

properties or local role

properties) can model

“shared” artefacts whose

consistency is managed as

follows. All participants

with access via globalelements

to the property can

view and modify its value.

The final value is the latest

set.

(Cf. Table 4.5)

This solution (whose result

is illustrated in Table B.9)

does not consider the fact

that for the students the

answers of their colleagues

may be anonymous. By

using monitoring services of

global-elements of type

view-property of supportedperson

this cannot be

achieved. However, this

problem could be solved,

for instance, by adding more

local properties.

Illustrative excerpts, supposing that in

ArgueGraph there will be only 4 participants,

i.e. 2 pairs

This script requires a method with four acts. Each act contains

two role-parts one for the activities of the students and one for

the activities of the tutor. The exception is the act corresponding

to the “conflict” phase. This act comprises three role-parts one

for each Pair and one for the tutor. Note that although the role

referenced in the learners’ activities is not explicitly the Pair but

the Students, the conditions manage to show the correct activity

to the students (according to their associated Pair).


[…]

Conflict phase









[…]

[…] […]


The persons in the same group (Pair) share local properties for

their joint answers to the questionnaire and related arguments.



Select


1. Tell the student he made a mistake and give him the correct answer.


[…]


4. Give the student some time to find out the mistake by himself.





The value of the properties storing the choices and arguments of

the individuals and the pairs can be viewed by the participants

by means of global elements


[…]

Individual answer to the questionnaire:

In a courseware, when a student makes an error is better to:


Argument:


[…]


95


4.4.4 Flexibility

A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

The flexibility requirements as far as group formation is concerned are generally approached in

Table 4.7 and Table 4.8. The addressed characteristic deals with the unexpected number of students

that eventually participate in the actual execution of the UoL.

Requirements

Flexible group

composition

(What happens if we do

not have the precise

desired number of

participants or if it

varies at runtime?)

Requirements

Flexible group

composition

(What happens if we do

not have the precise

desired number of

participants or if it

varies at runtime?)

Table 4.7 Computationally representing the flexibility requirements of Universanté script

Involved LD elements

and attributes

Illustrative excerpts (or explanations),

supposing that there will be 2 countries and 4

participants per country, i.e. 2 thematic groups

comprising 2 case groups

The possibility of detailing the maximum/minimum number of persons within each group (cf.

subsection 4.4.1) allows flexibility to a certain extent. In this example, more than 8 students can

be involved. It is possible to have more than 4 participants per country by associating 2 persons

of this country (instead of only one) to one or several case-groups.

Therefore, the flexibility regarding attendance (in a particular moment) that provides this UoL is

that more than 4 participants per country could participate. The limit of flexibility appears when

less than 4 participants per country participate, what counteracts the educational principles of

the UoL. In addition, having too many participants (e.g. more than 8 per country) may not be

recommended.

Table 4.8 Computationally representing the flexibility requirements of ArgueGraph script

Involved LD elements

and attributes

Illustrative excerpts, supposing that in

ArgueGraph there will be only 4 participants,

i.e. 2 pairs

As mentioned in Table 4.7, the possibility of detailing the maximum and minimum number of

persons within each group expresses flexibility regarding group composition variability. In this

example, more than 4 persons can be involved and the small groups can be of more than two

persons depending on the students’ participation in a certain moment. (E.g. if there are five

participants, the teacher can form a group of two and a group of three).

In addition, since the tutor forms the pairs at runtime, the particular needs of the moment will be

considered. Later the tutor can also change the association of a student to a group coming back

to the pair formation activity.

Additional conclusions referring to flexibility which consider the combined analysis performed

in the previous subsections are discussed in next subsection. It also reviews the results collected in

the tables for the detection of LD notation limitations for computationally representing the scripts.

4.4.5 Discussion and revision of the limitations regarding LD notation

Although modelling Universanté and ArgueGraph using LD is not easy and demands a deep

knowledge of the specification and several weeks of devoted work, the analysis performed in the

previous subsections show the many possibilities of LD for representing the requirements of

CSCL scripts. Nevertheless, there are some detailed issues that cannot be formally expressed

using the notation but which may be supported by tools or other specifications.

Regarding group composition, the use of the create-new attribute provides flexibility since a

specific number of groups is not predefined at design-time. However, the desired amount of groups

cannot be explicitly defined in the same way as it can be done with the group size (unless the

relationships between the values of min-persons attributes of roles and their sub-roles are used).

Universanté script requires that each thematic-group has at least 2 case-groups and that there are at

96


IMS LD SUPPORT FOR COMPUTATIONALLY REPRESENTING CSCL SCRIPTS

least 2 thematic-groups and two country-groups. If a thematic-group must include at least 4 persons

and its sub-role case-group can have only 2, then at least another occurrence of the case-group

should be created. Indicating in this way the number of thematic and country-groups is not possible

unless we defined a super-role. In order to represent CSCL scripts similar to this script, having

attributes to explicitly indicate the minimum and maximum number of new occurrences that can be

created during runtime would be useful.

In addition, the relationship between some roles to describe group arrangements as well as other

types of group formation policies cannot be formally specified (cf. Table 4.1). That is to say, it

cannot be described in such a way that automatic binding of persons to roles according to these

characteristics is achieved.

With regard to role distribution, rotation of roles can be implicitly represented by rotating

activities and defining “neutral” roles as proposed in Figure 4.2. Moreover, in the case of the

conference service four different types of system roles (participant, observer, conference-manager,

and moderator) can be distributed. Nevertheless, the solutions pointed out so far for role distribution

do not consider the reasonable situations in which persons assume several roles within the same

activity. The example that we indicate in section 4.3 to illustrate this problem is the following: in

the “Expert Group” phase of JIGSAW, experts may use simultaneously a discussion forum where

one of the experts is a moderator and the rest are participants, and a collaborative conceptual map

tool where one of the experts is the main writer and the others are annotators. In these cases the

solution relies on specifying these roles within supporting services. In this sense, LD defines within

the conference service four different types of system roles (participant, observer, conferencemanager,

and moderator) that can be distributed. But what happens if different roles and other

services are required?

On the other hand, when creating a new occurrence of a role (allowed by the create-new

attribute), new instances of the associated local role properties are also created. This facilitates the

distribution of resources, which in this case could not be accomplished by referencing different

environments to different role instances (these instances are not available at design-time).

Furthermore, when relying on the create-new attribute, the conditions used in Table 4.5 for

checking if a person is a member of two groups at the same time cannot be used. Instead, a new role

modelling this situation should be declared and referenced in the corresponding role-parts (see the

alternative (partial) version of Universanté UoL using the created-new=”allowed” attribute and

local role properties (universante2-uol.zip) available at http://gsic.tel.uva.es/collage/scripts and in

the attached CD-ROM).

Though the LD support for expressing complex learning processes is questioned in the literature

(Miao et al., 2005; Torres, Dodero, Aedo, & Zarraonandia, 2006), the results of our analysis

97


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

indicate that for the studied types of scripts the LD expressiveness is satisfactory. Besides, the

conclusions concerning the support of LD to represent the flow of artefacts between activities are

also positive. Nevertheless, the flow of artefacts between services (tools) supporting the same or

different activities is another problem which is clearly not supported by the specification (Miao et

al., 2005; Helic, 2006; Palomino-Ramirez, Martínez-Monés, Bote-Lorenzo, Asensio-Pérez, &

Dimitriadis, 2007).

Moreover, further flexibility needs to those addressed in subsection 4.4.4 may emerge at

runtime. Some of these situations can be planned a priori considering adaptation issues enabled by

the properties and conditions included in the level B of LD (Koper et al., 2005; Burgos et al.,

2006). However, other unpredictable demands need to be undertaken by teachers and students

via modifying some script features during the enactment (Dillenbourg et al., 2007).

To sum up, many of the requirements are addressed by the LD notation whereas some are not

fully supported. Adding new constructs to LD would increase even more the complexity of the

specification (and would probably decrease its interoperability prospective), what it is not desirable.

At this point it is important to consider the differences and relationship between the LD

specification itself and its relation to other (interoperability) specifications and tooling.

4.5 Supporting the requirements using related tools or specifications

LD relies on other specifications and tools that, conveniently integrated, envisage an extensive

support for the implementation of any teaching-learning process and, particularly, CSCL script. For

example, to implement the questionnaire of ArgueGraph Script there are three possibilities: using

LD properties (cf. Table 4.6), interoperating with IMS Question and Test Interoperability

specification (Vogten et al., 2006) or referencing an external questionnaire tool within an

environment (Hernández-Leo et al., 2006b).

In this section we refer to four different types of tools:

- authoring tools devoted to the creation of the scripts (e.g. Reload (Milligan et al., 2005)),

- players, whose main component is an LD engine (e.g. CopperCore (Martens et al., 2005))

for running the scripts,

- administration tools in charge of managing roles (and groups) and assigning participants to

roles (e.g. Clicc of CopperCore),

- and supporting tools, which refer to any kind of tools used to support an activity or part of

an activity (e.g. a chat (Hernández-Leo et al., 2006b)).

98


IMS LD SUPPORT FOR COMPUTATIONALLY REPRESENTING CSCL SCRIPTS

4.5.1 Addressing the limitations using complementary specifications and tooling

According to the computational representations exposed in the previous section, administration

tools should show to the users (e.g. teachers) the textual information of the roles so that they are

aware of the suggested group formation policies or amount of groups (this information is not

formally specified and cannot be interpreted by the engine). It is also possible to envisage the

possibility of having a dedicated specification to represent this type of characteristics. The resource

referenced in the information element as well as the administration tool should be thus compliant to

this eventual specification. In this sense, administration tools should also adopt the IMS Enterprise

Services specification (IMS, 2004b), which defines how systems manage the exchange of

information that describes people, groups and memberships within the context of learning.

Administration tools are also needed at runtime either as supporting tools, such as a “grouping

service” providing the functionality to (automatically, semi-automatically or manually) assign

people to roles (Burgos et al., 2006), or just as a utility of the player. For example, in the Problem-

Based Learning example included in (IMS, 2003a) students dynamically decide who is going to be

the chairperson during runtime. Once decided, (s)he should be bound to the corresponding

(previously defined) role using, for instance, a utility of the player. In the case of the ArgueGraph

script an alternative to the use of properties is defining the Pairs as roles and using a grouping

service to bind the students to the roles according to their responses. Of course, a “dedicated activity

service” devoted to analyze students’ answers and automatically form the pairs (by setting

properties or binding users to roles) could be used as well. This solution significantly reduces the

workload of the teachers as compared to the solution indicated in Table 4.2.

Rotation of roles can be also realized if the player provides a mechanism that allows roles

switching. In the Literature Circles example (IMS, 2003a), each session, which implies role

rotation, is viewed as a different run of the UoL. Regarding role distribution, supporting

collaborative services may also define their own roles, which should contain references to roles in

the LD. If the number of groups is not known at design-time, the requirement of resource

distribution can be also supported using a “shared repository service”. A different instance of the

service (e.g. a different folder) should be provided to each occurrence of the role participating in the

service. An example of this solution is presented in (Hernández-Leo et al., 2006b). This idea is also

employed for providing a different instance of a “synchronous conference service” (a chat) to the

members bound to each occurrence of a role. In addition, supporting collaborative tools may

implement more sophisticated floor control mechanisms than the effect achieved using properties.

Creating the fact sheet can be accomplished with a “collaborative text editor service” or a

“collaborative whiteboard service” making use of, for instance, turn-taking policies.

With the aim of addressing the problem of specifying the flow of artefacts between tools (not

supported by the LD notation), Palomino-Ramirez et al. (2007) plan to use a workflow standard

99


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

language in a way that complements LD maintaining interoperability. It is interesting, for example,

in a situation in which an external tool for questionnaires is used. In this case, the compilation of the

choices and arguments should be done by the tool. In order to make available this compilation to the

participants in other activities it should be stored either in a predefined property or in another tool,

which can be eventually the same.

As aforementioned, since UoLs can be designed considering adaptation issues, various

flexibility issues can be pre-defined (e.g. activities to be added or removed by the teacher on the

fly). Besides, the design of LD runtime systems meets flexibility requirements (Tattersall et al.,

2005). The main idea behind this design relies on the distinction between an abstract description

(UoL) and its specific instantiations (runs). Consequently, the same UoL can be executed in

different settings with different participants. Administration tools should be also available at

runtime for managing unexpected group composition variations. Moreover, minor modifications to

runs are also possible by changing the details in the related UoL. Furthermore, Zarraonandia et al.

(2006) propose an alternative to introduce slight variations on a run in progress without modifying

the UoL.

Dillenbourg et al. (2007) argue that a supplementary representation of the script (additional to

the actual UoL to be executed) specifying their intrinsic and extrinsic constraints could be also

handled by script engines to support flexibility. In this way, the tools enabling scripts modifications

by interacting with the engines can consider this information (e.g. extrinsic constraints are allowed

to be modified by teachers and students since these changes do not kill the potential effectiveness of

the script). Further solutions for managing flexibility, such as associating several students to the

same (redundant) role (enabled by LD and LD tooling) or such as using artificial agents simulating

not attending students, are also proposed in (Dillenbourg et al., 2007).

Moreover, tooling (mainly players) user interface features are important for the actual use of

scripts (Dillenbourg, 2002; CRAFT, 2007). In this sense, an interesting topic to be studied is related

to the effects of interface features that result from the interpretation of scripts. And, consequently, a

problem would be how the tools can address this problem. Is a general common way of playing LD

valid for every script? Or is needed additional information (e.g. another specification) for describing

this type of aspects?

Finally, it is worth mentioning that another important supporting tool for CSCL scripts is an

“awareness service”. This kind of tool should provide information updated in real time by the

engine about the progress of the participants (and groups) in the learning flow. This is not only

essential for managing flexibility (accomplishing modifications according to the awareness

information) but it is also fundamental to provide an adequate context for each own work by

100


IMS LD SUPPORT FOR COMPUTATIONALLY REPRESENTING CSCL SCRIPTS

understanding the work of others. The LD monitor service facilitates this functionality if it is

previously specified in the UoL (Gorissen et al., 2005).

Along the chapter, we argue that a group-based activity can be described by associating a role

played by several persons or/and multiple roles to a learning activity that provides at least one tool

(LD service) that mediates collaboration. This is true; however LD only defines two basic

collaborative services: e-mail and conferencing. The accomplished analysis makes clear that

collaborative learning situations require more services (e.g. collaborative editors, document sharing

tools, discussion forums, shared whiteboards, etc.). Since the definition of all the possible required

services is an extremely demanding task which, on the other hand, decreases the interoperability

power of the specification (the compliant learning environments would need to implement all the

services), we claim that a feasible solution is generally specifying group-services (as similarly done

with the conference service) so that several common “configuration characteristics” can be

described at design time. Next subsection points out some ideas in this sense, which do not intend to

be a definitive proposal but an initial approach to reach a consensus in that direction.

4.5.2 Discussion: general specification of group-services

LD states that if multiple individuals are to collaborate or work together at the same time, this

has to be done through a service in their assigned environment which supports this collaborative

capability (IMS, 2003b). As aforesaid, due to interoperability reasons LD only defines four basic

services, two of which are collaborative (e-mail and conferencing). Besides, the specification states

that that other needed services should be specified by the designers. The problem is that LD does

not permit to describe collaboration-related capabilities when defining (or configuring) a new

service. Some of the interesting features that can be used to configure group-supporting services

are:

- Floor control policy that guides learners’ actions. If it is fixed and previously established

by the teacher/designer or it is dynamic (it is not previously established) or, simply, there

is not any floor control policy.

- The type of communication skills that is to be used in the collaboration to be supported by

the tool defined in the service (Osuna & Dimitriadis, 1999): writing, speaking, gesturing,

drawing, etc.

- The roles (of the LD) that participate in the same instance of the service. A different

instance of the service should be provided to each occurrence of the role (when create-new

attribute of the role element is set to allowed) participating in the service.

101


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

- If the whole workspace of the collaborative tool described in the service is public or shared

(every participant have access to the workspace), or private (each participant only has

access to his/her workspace) or a mixed workspace (Ellis et al., 1994).

- The type of interaction that is supported by the service. This element distinguishes between

direct interactions with a source and one or more receivers (e.g. a contribution to a

discussion in a chat), indirect interactions, mediated by a shared object (such as a

document or a piece of a puzzle) and participation-oriented interactions, that allow to

annotate “participation” of an actor in situations where no receptor has been identified (e.g.

a post in a discussion forum without answers) (Martínez-Monés, 2003).

- Roles that the service supports (e.g. writer and annotator in a collaborative conceptual map

tool).

- Type of awareness information (updated information about other people’s presence,

location, state of the task, etc.) needed and provided by the service and from what roles is

needed to provide information (Gutwin & Greenberg, 1999). Possible values of the type of

awareness are identity (who is participating?), action (what is she/he doing?), location

(where is she/he working), etc.

To address the specification of these common features of group-based services so that proper

tools support the collaborative activities, several solutions are possible. A first approach refers to

extending LD with an element that enables the general definition of a special type of service, called

(for example) groupservice, whose information model includes the aforementioned features (an

example of this approach is provided in (Hernández-Leo et al., 2005)). Another solution is

developing a new specification for the definition of the collaborative services and their

interoperation with LD (engines). Finally, the creation of an ontology for describing this type of

tools is another promising possibility, which is complementary to the previous ones. Searching tools

with the required features to adequately support the specific activities is addressed in (Vega-

Gorgojo et al., 2005).

Supporting tools may also implement finer-grained scripts (micro-scripts) so that interaction

processes within activities are scaffolded too. In fact, tools implementing particular floor control

mechanisms (e.g. turn-taking polices) also aim at structuring interactions at a micro level. This idea

is discussed in next subsection.

4.5.3 Discussion: “hardwired” in tools vs. computer-interpretable micro-scripts

Floor control polices are highly related to micro-scripts in the sense that they organize the

specific actions that should be accomplished within activities. This argument leads to the idea that

micro-scripts can be embedded in supporting tools associated to the activities of an LD-represented

102


IMS LD SUPPORT FOR COMPUTATIONALLY REPRESENTING CSCL SCRIPTS

macro-script, thus achieving composition of micro- and macro-scripts (Harrer, 2006; Haake &

Pfister, 2007). An alternative approach is computationally representing the micro-scripts as well so

that they are interpreted by an engine.

At this point the following question arises. Can LD be used for computationally representing

micro-scripts? To answer this question, similar research to the detailed analysis contained in this

chapter concerning macro-scripts needs to be carried out. According to a comment included on page

229 of (Koper & Tattersall, 2005), LD is mainly devoted to describe learning flows and it does not

support the specification of detailed learning actions within activities (activity granularity level).

Nevertheless, a positive answer is envisaged if we consider the following example related to

argumentative micro-scripts. The example is devoted to guide the construction of a specific

argumentation sequence within discussion activities (Weinberger et al., 2005) (see also the scripts

that can be generated using the “Debate” pattern language proposed in (Goodyear, 2005)). The first

message of a discussion thread is labeled “argument”. The answer to an argument is categorized as

“counterargument” and a reply to a counterargument is labeled as “integration”. This script could be

easily expressed with LD by means of grouped properties with titles “argument”,

“counterargument” and “integration” and coordination elements (mainly acts and conditions).

Alternatively, other languages specifically dedicated to formalize particular types of micro-scripts

(e.g. argumentative micro-scripts) may be developed. In any case, the interoperability between

macro and micro-scripts should be afforded.

4.6 Conclusion

The results of the analysis described in this chapter show the capacity of the LD notation to

express CSCL macro-scripts. The chapter discusses how the requirements can be supported by tools

and related specifications. Macro-scripts aim at structuring collaborative learning processes of

coarse-grained activities. Their requirements are shaped around the fact that they involve groups

and multi-roles characteristics.

These possibilities of LD to support the identified needs are tested and illustrated by means of

CLFPs and well-known full-fledged scripts. Although it is not possible to broadly affirm that any

CSCL script can be realised following the results of the analysis, these conclusions can be very

useful to implement scripts embracing similar manifestations of the studied requirements.

Recapitulating the different types of generalized requirements, we summarize now how they are

addressed by the notation itself and/or by other specifications and tools:

- The LD roles component and its related elements and attributes together with the joint use

of properties and conditions provide constructs to computationally represent several group

composition requirements. These requirements refer mainly to hierarchy of groups, group

103


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

size and dynamic group formation. The notation provides limited support for the formal

specification of the number of groups and group formation policies. However, these

requirements as well as an enhanced realization of the others can be supported by

administration tools (and also supporting tools such as grouping services or player utilities)

in combination with eventual exhaustive group composition specifications.

- Similarly, role distribution relies on the constructs offered by the roles component,

complemented with the coordination of role-parts, enabling that participants play the same

or different roles. In addition, supporting collaborative tools (group services) may define

specific roles implying different privileges when using the tools. Rotation of roles can be

realized by rotating activities or by using mechanisms provided by the players. The

distribution of resources is facilitated by the coordination of role-parts but also through the

possibility of referencing resources to different elements of LD such as activitydescriptions

or environments. The use of properties or supporting tools also provides

another means of resource distribution.

- Coordinating the flow of CL activities is feasible using the LD method and conditions. The

flow of artefacts between activities can be attained by employing properties, globalelements

and monitor services conveniently referenced by other LD elements. The

consistency of shared artefacts is ensured by jointly held properties. Moreover,

sophisticated floor control mechanisms can be described in the learning flow or achieved

by means of external supporting tools, whose description and interoperation with LD

should be covered by a new specification (or an extension of LD). In this sense, that or

another interoperability specification is needed to address the data flow between

supporting tools.

- Flexibility requirements are also tackled by both the LD notation and its implementation in

tools. The main attributes of roles that enable flexible group compositions are min-persons,

max-persons and create-new. Further flexibility is provided by the capabilities of LD to

support adaptation as well as the distinction between abstract descriptions (UoLs) and

specific instantiations (runs). This distinction affords new developments allowing the

introduction of slight modifications to runs in progress. The probability of reaching

success using scripts would be increased if engines handle the specifications of script

constraints that are allowed to be modified along the whole teaching and learning process

as well as specific user interface features related to particular scripts.

Concluding, computationally representing scripts using the LD interoperable notation provides

the following benefits. Firstly, they can be repetitively and automatically processed. As a

consequence, the scripts become resistant to technological changes. In addition, they can be reused

104


IMS LD SUPPORT FOR COMPUTATIONALLY REPRESENTING CSCL SCRIPTS

in different settings and with different participants. And, furthermore, they can be easily adjusted to

support other learning situations by using LD-compliant authoring tools. Chapter Six provide

further insight to the conclusions of this analysis by evaluating the creation and use of LDrepresented

scripts in real situations.

Of course, LD-based scripts editors should hide the computer representational details laid out in

this chapter, if we actually want to foster the adoption of LD as the base machine-readable

modelling language of ready-to-run scripts. How design processes based on patterns (and

particularly on CLFPs) can undertake this challenge is the focus of next chapter.

105


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

106


CHAPTER FIVE

DESIGN PROCESS FOR THE

GENERATION OF IMS LD SCRIPTS

REUSING CLFPS

Assuming the contributions of the previous chapters as a starting point, this chapter

tackles the objective of proposing a design process that facilitates the reuse of CLFPs

(Collaborative Learning Flow Patterns, a particular type of CSCL scripting patterns) in

the creation of CSCL macro-scripts computationally represented with LD. The aims of

the design process include: achieving a satisfactory trade-off between particularizations

of CLFPs so that the resulting LDs are contextualized according to particular CL

situations and the loss of the meaningfulness captured in CLFPs; allowing teachers to

focus on CSCL critical features that are involved in the elicitation of expected

interaction processes; and not requiring high technical knowledge, particularly of LD.

The design process is implemented in an authoring tool which proves its feasibility and

enables its proper evaluation. The chapter also introduces a framework that

conceptualizes different (existing and potentially yet-to-come) approaches that drive the

creation of full-fledged UoLs by reusing different types of design solutions. This

framework helps us to comprehensibly situate our proposal.

The design process for the generation of CSCL scripts reusing CLFPs is the central

contribution of this dissertation, which has been published in (Hernández-Leo et al.,

2005; Hernández-Leo et al, in pressa; Hernández-Leo et al., 2006e). The “create-byreuse”

framework in which the process is situated has been published in (Hernández-Leo

et al., 2006a).

5.1 Introduction

How can the creation of potentially effective LD-represented CSCL macro-scripts be

facilitated? This is in short the main objective of this dissertation which is tackled in this chapter

benefiting from the contributions of Chapter Three and Chapter Four. The ultimate goal is to enable

participatory modes of designing in which teachers (interested in applying CSCL and without


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

advanced LD knowledge) decide on the behaviour and functionality of LMSs by designing their

own scripts according to the particular needs of their educational situations.

Chapter Three elaborates on how CSCL scripting patterns and their interrelations into pattern

languages enable design processes grounded in practice. From the different types of patterns that

can be used in the design of scripts, the patterns at the CL flow level (Collaborative Learning Flow

Patterns, CLFPs) are of special interest in the design of macro-scripts. CLFPs capture good

practices regarding the structure of coarse-grained activity flows and the involved groups. Thus,

CLFPs are the main patterns considered in the proposals of this chapter (as similarly done in

Chapter Four).

On the other hand, Chapter Four analyzes the capacity of the LD notation to express CSCL

macro-scripts. The conclusions of the analysis indicate that, though with minor limitations that can

be supported with existing and eventually-developed specifications and tools, LD can be

satisfactorily used to computationally represent the scripts. Having the scripts represented with LD

increases the opportunities for their re-use by enabling interoperability among compliant LMSs.

However the complex requirements that demand the descriptions of the scripts together with the

intricate LD computational constructs that enable their representations (cf. Chapter Four) makes

quite difficult for teachers the creation of their own LD scripts.

As advanced in Chapter Two, a promising solution to facilitate the creation of LD scripts relies

on providing authoring tools incorporating design processes that hide the LD notation and use

instead visualizations and concepts easy to understand and use by teachers. Our aim is that these

design processes help teachers to focus on the CSCL critical elements (e.g. learning objectives, task

type, level of pre-structuring, group size) of effective scripts. We exploit the incorporation of

patterns (CLFPs) in a design process to provide teachers with well-known design solutions. The

objective is that this design process achieves a satisfactory trade-off between particularizations of

CLFPs so that the resulting LDs are contextualized according to particular CL situations and the

loss of the meaningfulness captured in CLFPs. Moreover, we argue that this type of processes also

fosters the reuse of patterns more satisfactorily than their “simply” collection in repositories. Along

with the research methodology presented in Chapter One, a pattern-based design process is

proposed in this chapter and incorporated into a (high-level) authoring tool in order to illustrate its

feasibility and evaluate it in real situations with teachers and students (cf. Chapter Six)

It is important to point out that, according to the revision presented in section 2.4.1.2 of Chapter

Two, (at the time of proposing the contributions of this chapter) there is not any high-level (distant

from the specification) LD compliant authoring tools that are specialized in CL. However, there are

several initiatives working towards promoting the widespread adoption of LD that, in a similar

108


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

spirit to our approach, advocate the use of design processes based on the reuse of complete or

incomplete learning design solutions at different levels of granularity.

Therefore, the chapter starts with section 5.2 which introduces a comparison framework for

conceptually analyzing and classifying reusable learning design solutions and processes that drive

the creation of ready-to-run UoLs. Then, section 5.3 concentrates on the role of CSCL scripting

patterns, and particularly CLFPs, in design processes. Consequently, section 5.4 proposes a CLFPbased

design process for the generation of LD scripts (i.e. collaborative UoLs) and exposes its

integration into an authoring tool (Collage). The creation of LD scripts using this authoring tool is

illustrated with several examples (also used in next chapter for the evaluation in real situations) in

section 5.5. A discussion section (5.6) briefly reflects on eventual solutions towards more general

approaches regarding the graphical visualizations and the language independence of script

computational representations. Finally, the conclusions of the chapter are included in section 5.7.

5.2 The “create-by-reuse” conceptual framework

In general, the adoption of LD by teachers in real educational practice greatly depends on the

provision of tools and processes capable of facilitating the creation of computer-interpretable UoLs

(Griffiths et al., 2005). These tools and processes should consider a broad range of types of teachers

with different pedagogical and technical backgrounds as well as diverse didactical contexts: types

of institutions and communities of practices.

As mentioned above, the main problem refers to the fact that technical formalism (XML) and

LD concepts are not familiar to the majority of the teachers. In this sense, the current trend in the

development of LD editors is to hide the LD details by using concepts (and their representations)

closer to the teachers’ concepts, what in several approaches is related to the idea of providing

teachers with specific reusable learning design solutions (Burgos & Griffiths, 2005). However, the

existing and yet-to-come approaches can be quite varied in that the reusable design solutions on

which they rely can be at different levels of granularity (an LD activity vs. the whole flow of

activities included in an LD) and completeness (a complete UoL vs. the bare bone structure of the

flow of the activities of the LD). Moreover, the diverse types of learning design solutions afford

different types of design processes for their reuse and customization (assembly vs. refinement

processes).

This section introduces a create-by-reuse framework that elucidates different approaches for the

creation of UoLs via the reuse of learning design solutions at different levels of granularity and

completeness. This framework is intended to provide criteria for comparing and classifying existing

and forthcoming proposals for creating UoLs, as well as their associated design processes based on

109


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

a certain level of reusability. In addition, the framework provides a “tool” for discussing the proper

level of reuse for user-friendly creation of UoLs according to teachers’ contexts and backgrounds.

5.2.1 Reuse of learning design solutions

Several proposals have been identified for creating UoLs by reusing pre-existing learning

design solutions at different levels of granularity and completeness. These two dimensions

(granularity and completeness) provide an interesting way of classifying and comparing some of

those relevant proposals (cf. Figure 5.1). Furthermore, this two-dimensional space provides a way

of grouping the existing and forthcoming proposals into four general (overlapping) sets:

- Exemplars are ready-to-run (complete) UoLs (LN4LD, 2005; Griffiths et al., 2005;

Griffiths, 2005). These UoL may embrace from one-activity session to a whole course (i.e.,

finer or coarser-grained exemplars). In fact, the final goal of any design process carried out

by a teacher (or learning designer) is obtaining an exemplar that fulfils the teaching-learning

requirements. In other words, an exemplar contains all the information required to be

enacted by an LD compliant LMS (Learning Management System).

- Templates are partly completed exemplars (Griffiths, 2005). There may be also templates at

different levels of granularity as well as at different degrees of completeness. Figure 4.2

shows, as an example for illustration, that an LD template without the specification of the

group size limits is more incomplete than the LD (the latter template with the specification

of the group size limits but still without the resources that are needed in order to achieve a

ready-to-run UoL). Accordingly, the LearningMapR initiative aims at enabling the selection

of templates and exemplars to be reused and customized as necessary or desired (Buzza,

Richards, Bean, Harrigan, & Carey, 2005). Though without considering compliance with

LD, the objectives of the AUTC project fit well with the presented orientation (AUTC,

2003; Hedberg, Oliver, Harper, Wills, & Agostinho, 2002): it seeks for the identification of

learning design exemplars considered as having the potential of fostering high quality

learning and could be redeveloped in more generic templates.

- UoL chunks are portions of exemplars. The granularity of the chunks may range from a

ready-to-use (complete) activity structure (including the activities, environments, resources)

to a learning object (fine grained). In contrast to exemplars, chunks are not “playable” on

their own. The “lego metaphor” is used by Berlanga et al. (2005) in order to explain their

approach to enable reusability and exchangeability of UoL chunks when supporting adaptive

learning design. A similar approach (but not LD compliant) is the proposal of Haake et al.,

(2007) who distinguish between atomic scripts (in the terminology of the “create-by-reuse”

framework it would be a chunk), which support a specific collaborative learning activity,

110


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

and composite scripts (exemplars), which support complex collaborative learning tasks

through sequences of atomic or composite scripts.

- Building blocks or components are partly completed UoL chunks at different levels of

granularity and diverse degrees of completeness. Figure 4.2 includes as an example “an

abstraction of a pedagogic activity type”, which may be similar to the predefined activity

tools that LAMS (LAMS, 2006) offers to users as components that can be graphically

dragged and dropped to describe a sequence of activities. With the aim of dynamically

generating web course structures Giacomini-Pacurar, Trigano, & Alupoaie (2006) use a list

of LD building blocks (what they also name as primary pedagogical models or basic

models), which are associated according to inference rules stored in a knowledge base.

Low level of granularity

(coarse grained)

Exemplars

(Ready-to-run

UoLs of

different

granularities)

Complete

UoL chunks

(A UoL

portion of

different

granularities)

a UoL

a complete

learning

activity

an LD

High level of granularity

(fine grained)

111

an

incomplete

LD

Pedagogic

activity

abstraction

Templates

(Partly

completed

exemplars)

Incomplete

Building

blocks/

Compontents

(Partly

completed

UoL chunks)

Figure 5.1 Dimensions of the create-by-reuse framework: reusable learning design solutions at different level

of granularity and completeness

Nevertheless, the design processes for reusing the learning design solutions in order to create

UoLs (implicitly indicated in some descriptions of the reusable solutions) are even more important

than the reusable solutions themselves. Hence, further topics arise: What kind of design processes

can be applied? To which extent do the processes depend on the type of reusable solution?


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

5.2.2 Design processes for creating units of learning

Considering the previously defined reusable learning design solutions, this subsection presents

different types of design processes that enable the creation of full-fledged UoLs. The existence of

varied types of processes is caused by the different nature of the reusable solutions:

- Refinement: this process is needed to reduce the abstraction level (incompleteness) of

constituents by adding concrete information about numbers of participants, roles, activity

descriptions, resources, etc. This is the basic process to move from templates to constituents

that are closer to an automatically executable representation, which may take in several steps

of reducing abstraction.

- Assembly: this process is needed to reduce the granularity of a constituent by combining

several constituents together or integrating them into a coarser grained process structure.

This activity is especially suited for UoL chunks which are not “playable” on their own, but

have to be integrated into other structures to be operational. While the mere sequencing of

activities without dependencies between them is relatively unproblematic, more complex

learning processes, that require interrelations between artefacts flowing through several

activities or consistency of roles through phases, are more demanding. These relations have

been discussed with proposed solutions in Chapter Three of this dissertation and in (Harrer,

2006).

- Modification: this process may take place orthogonally to the other two. It usually reduces

neither abstraction nor incompleteness, but changes some information inside the constituent.

E.g. in exemplars the creation of a new UoL can be achieved by keeping the process

structure, while changing the concrete resources to move to another domain of learning.

Figure 5.2 shows these typical types of processes for creating complete UoLs. From right to left

a refinement process moving from abstract to less abstract constituents and from bottom to top an

assembly process, which creates a larger scope structure from fine grained constituents. A

modification usually would keep the position with respect to both abstraction and completeness.

The refinement and assembly design processes highlight the basic, stereotypical techniques to

move towards complete UoLs. In practice it is very well imaginable and – from the perspective of a

learning designer – highly desirable to have the option of mixing both approaches within one design

process.

Although learning objects are not “learning designs solutions” strictly speaking, they have been

considered in the framework as the finest grained chunks, which need to be assembled with other

components of different granularity (e.g. an activity building block) in order to reuse them for

creating a UoL. In this case, the result of the assembly is actually a refinement of the component:

the learning object (e.g. a document) completes the component (e.g. an activity building block).

“Refinement by assembly” can be thus understood as a type of mixed design processes.

112


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

Low level of granularity

(coarse grained)

Exemplars

(Ready-to-run

UoLs of

different

granularities)

Complete

UoL chunks

(A UoL

portion of

different

granularities)

Assembly

process

High level of granularity

(fine grained)

Mixed

process

Refinement

process

113

Templates

(Partly

completed

exemplars)

Incomplete

Building

blocks/

Compontents

(Partly

completed

UoL chunks)

Figure 5.2 Design processes for creating UoLs by assembling and refining learning design solutions

To show the usefulness of our classification of design processes, we apply this

conceptualization to a representative tool, namely LAMS (although LAMS models are not

completely compatible with LD), based on the approach of creating by reusing learning design

solutions. The typical design process supported by LAMS is the assembly of LAMS building blocks

(activity tools) into a process sequence by graphical linking of the activity tools. This type of design

process can be considered the “vertical” assembly design process of Figure 5.2. The result of the

assemblage (the process sequence) is a template that needs to be refined (with task descriptions,

etc.) into full-fledged units. This second step reflects a “horizontal” design process that together

with the previous assembly step forms a “mixed process” can be seen as an instance of the angular

design process in Figure 5.2.

Other examples cited in the previous subsection make use of “pure” design processes, for

example (Haake et al., 2007) propose assembling atomic scripts (chunks or exemplars) or/and

composite scripts (exemplars) into new composite scripts (larger chunks or exemplars, depending

on whether they are “playable” on their own). In contrast, the proposal of Buzza et al. (2005) will


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

enable pure refinement processes, if the user selects to reuse a template, or pure modification

processes, if an exemplar is selected.

To sum up, the create-by-reuse framework distinguishes reusable design solutions according to

their level of granularity and completeness and illustrates the basic types of design processes and

their combinations, used to integrate the reusable solutions. Therefore it provides a conceptual

frame to classify approaches with provide design processes based on reusable solutions to facilitate

the creation of UoLs. In addition, the framework provides an instrument that can be used when

discussing several related issues, such as: What is the proper level of reuse for teacher-friendly

creation depending on the institution, community, etc? Which types of learning design solutions are

potentially more reusable, the coarser and/or the more incomplete? How can a proper understanding

of the solutions before their actual reuse be facilitated?

The latter question suggests that the different possible approaches devoted to the selection the

design solutions so that they are appropriate for a particular learning situation deserves a new

dimension in the framework. Though for situating the proposal of this dissertation the current

version of the framework is sufficiently useful, in fact several additional interesting dimensions may

be considered in a more complete framework. Some of them are discussed in next subsection.

5.2.3 Discussion: other potential dimensions

Apart from the current dimensions of the create-by-reuse framework, it is possible to envisage

at least four topics that can be translated into new dimensions: approaches for the selection of

reusable design solutions, types of notations or representations used to present the solutions to the

teachers, languages for their computational representation (not only LD), and types of

pedagogically-based formulations behind the reusable solutions.

Regarding the selection of reusable solutions, different approaches are used: from the use of

metadata compliant with specifications (e.g. LOM or IMS Resource Meta-data specification,

(Duval, 2001; IMS, 2002)) or other types of categories to the use of ontologies (Knight, Grasevic, &

Richards, 2006). Being able to understand the learning design solutions and decide whether they

can be applied in the actual situation that the teacher is facing is crucial in the analysis stage

(previous to the proper design) (Buzza, Bean, Harrigan, & Carey. T., 2004; Griffiths et al., 2005).

For example, Buzza et al. (2005) propose using two types of categories for the selection of LD

templates and exemplars: categories for cognitive analysis based on Bloom’s taxonomy (Bloom &

Krathwohl, 1984) (what the designer wants the learner to know and do) and categories related to

instructional challenges (e.g. lack of student motivation to engage with particular topics).

Moreover, the way of presenting teachers the reusable elements, using from textual to visual

notations (Botturi et al., 2006; Botturi & Stubbs, in press; Waters et al., 2004), plays an important

114


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

role when promoting the understanding of the design solutions and the intuitiveness for their

customization. For instance, the reusable activity tools of LAMS are shown as graphical

components that can be dragged and dropped.

On the other hand, the computational language that we consider in the framework is LD,

however we also point out some approaches that are not LD compliant (e.g. (LAMS, 2006; Haake

et al., 2007)). Providing language independence of learning designs would foster even more their

reusability (Dodero, Tattersall, Burgos, & Koper, 2007). This independence envisages the need of

emergent approaches for creating learning designs when elements from more than one specification,

formalism or model have to be combined in a single UoL, or they have to be transformed before

being delivered to a specific non LD compliant LMS.

Finally, there can be different types of pedagogically-based formulations behind the reusable

solutions. These formulations, which might be related with the approaches used for selecting the

solutions, are typically significant to teachers of particular communities of practices.

One of the approaches refers to using educational taxonomies, such as the taxonomy of learning

activities used in (Conole & Fill, 2005). Griffiths et al. (2005) also point out other candidates

taxonomies to be used as a guide when creating UoLs: the above cited Bloom’s taxonomy (Bloom

& Krathwohl, 1984), the classification of learning activities proposed by Shuell (1992) or the

learning events developed by Leclerc & Poumay (2005). Frameworks for the description of

pedagogically specific LDs can be also useful in this context. The framework for the specification

of collaboration scripts proposed in (Kobbe et al., submitted) is an example. A different approach

advocates the use of primitives, i.e. events that do not necessarily embody a particular pedagogical

view of learning and teaching but which reflect the real situations in the classrooms. Examples of

primitives are “discuss this text” or “research this topic on the web” (Griffiths et al., 2005; Casey et

al., in press).

All these approaches are interesting as ways of providing pedagogically sound formulations that

can be used in the creation of UoL. However, it is not clear to which extent they really provide

reusable solutions beyond mere categorizations. In this sense we argue that pedagogical design

patterns, besides providing a conceptual common ground, represent a structured way of capturing

and communicating educational expertise (cf. section 2.3). In this dissertation we focus on patterns

as the formulations behind reusable design solutions addressing recurrent problems in certain

educational contexts. In our case, these contexts are those that require of CSCL scripting solutions.

5.3 The role of CSCL scripting patterns in design processes

As Chapter Three exposes in detail, a “CSCL scripting patterndescribes a common problem

and its corresponding broadly-accepted solution which can be used repeatedly in the design of

115


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

CSCL scripts. In particular, that chapter proposes a conceptual model for describing CSCL scripting

pattern languages. The model describes the different types of patterns and relationships between

them that can be used for generating CSCL scripts. The types of patterns are described in an

aggregation model that differentiates the patterns according to their granularity: CL flows which

comprise activities that are supported by resources (tools and material). Roles and common CL

mechanisms are modelled as elements that are integral parts of flows, activities and resources. The

patterns associated to the different elements of the model can be related with connecting rules

indicating that a pattern completes another pattern (by refining the principles of the completed

pattern) or that a pattern complements a second pattern (forming a new larger whole). Patterns at

the same level may also complement or/and complete each other, may represent alternative patterns

(mutually exclusive) and specialize other patterns. The connections between the patterns provide

guidance for their meaningful application and prevent bringing together patterns that do not make

sense from the pedagogical perspective.

While subsection 3.3.3 of Chapter Three indicates general guidelines for applying the PLs that

can be described with the proposed conceptual model, the research question in this chapter focuses

on: what is the role of patterns in design processes for the creation of LD-represented scripts?

5.3.1 Assistant vs. templates

Most of the approaches related to e-learning patterns propose to collect the patterns in

repositories so that interested people can go to the repository, read the patterns and reuse the design

experience projected into them. Another approach consists in explicitly incorporating the patterns in

authoring tools in such a way that they provide advice and suggestion along the design process

(McAndrew, Goodyear, & Dalziel, 2005).

In the case of the CSCL scripting patterns, both approaches are valuable. However, as

mentioned above, incorporating patterns in design processes (to be implemented in authoring tools)

potentially facilitates their reuse and the design of experience-founded scripts. The incorporation of

patterns in design processes can be accomplished in two (complementary) ways so that the patterns

act as assistants or as templates:

- Pattern-based assistant: a context-aware advising mechanism based on the knowledge

formulated in the patterns. It is possible to imagine this type of assistant similar to, for

example, the animated Microsoft Office Assistant which becomes visible whenever the

system that detects the user could benefit from its advice.

- Pattern-based template or building block: a ready-made skeleton based on the knowledge

formulated in a pattern that can be refined (and probably assembled) to create full-fledged

scripts (cf. subsection 5.2.1). This idea may remind readers, for example, of Web page

116


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

templates (e.g. for Adobe Dreamweaver or Microsoft Front Page) that enable the easy

production of Web pages by separating their presentation from the content.

Of course, not every pattern that can be used for designing CSCL scripts is suitable of being

represented using a computer-interpretable notation so that it is a template or building block for

creating LD scripts (“an incomplete collaborative UoL or UoL chunk”). Depending on the nature of

the different types of scripting patterns they can be implemented as assistant or as templates (or

building blocks). We discuss this aspect for the different types of patterns considered in our model

for CSCL scripting PL:

- CL flow patterns. When the degree of specialization of the pattern is such that its solution

offers a learning flow (e.g. JIGSAW, PYRAMID, TPS, BRAINSTORMING, SIMULATION and

TAPPS of Appendix A), this pattern is suitable of being provided as a template. On the

contrary, if the pattern offers abstract advice, for example, to enrich the learning flow (cf.

ENRICHING THE LEARNING PROCESS PATTERN of Appendix A), it may be implemented

as an assistant.

- Activity patterns. In this case the problem is quite similar to the collaborative learning flow

level. That is, the generality degree of the patterns DISCUSSION GROUPS (Pattern 2.2 of

Appendix A) or THE ASSESSMENT TASK AS A VEHICLE FOR LEARNING (Pattern 2.5)

does not invite to formalize them as templates but to implement them as advisors. On the

other hand, the specialization of DISCUSSION GROUPS which may be also formulated in

patterns such as the ones that may result from capturing the essence of the two scripts for

argumentative knowledge construction proposed in (Weinberger et al., 2005) could be

represented computationally and implemented as building blocks (according to the createby-reuse

framework proposed in section 5.2).

- Resource patterns. An approach for the formalization of patterns at the resource level

concerning learning objects has been already proposed in (Jones, 2004). Jones implements

the patterns using XML representations and proposes to incorporate them into authoring

tools for learning objects. There is not any proposal (to the best of our knowledge) to

formalize patterns for tools (also at the resource level). However, it is not clear to which

extent such formalization (beyond the aspects directly related to their “configuration”, cf.

section 4.5.2 of Chapter Four) is necessary. At least as far as the design of scripts (we are not

considering the design of tools) is concerned, the designer just needs to select the tools that

will support the activities. In this line, semantic search of tools using ontologies is being

researched by Vega-Gorgojo et al. (2006). Therefore, patterns at this level (e.g.

MANAGEMENT OF ON-LINE QUESTIONNAIRES, Pattern 3.2) can be implemented as

advisors that can act as mediators between the search system and the user.

117


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

- Roles and common CL mechanisms patterns. Again, depending on the degree of

generality-specialization of the patterns they can be represented as reusable building blocks

or as assistants. CONTROLLED GROUP FORMATION (Pattern 4.3) is so general that it

should be implemented as an assistant. In contrast, if we formulate a pattern suggesting a

particular group formation policy for assembling heterogeneous group under certain

conditions of a problem and a context, the pattern could be offered as a building block.

As indicated in the introduction of this chapter, the patterns at the CL flow level (CLFPs) are of

special interest in the design of macro-scripts and they are therefore the type of patterns considered

in the actual design process that is proposed in this dissertation. In particular, we also focus the

problem on the CLFPs whose solutions are suitable of being offered as templates, i.e. from Pattern

1.1 to Pattern 1.6 of Appendix A. Of course extending our proposal with CLFP-based assistants and

the other types of CSCL scripting patterns deserves further work which is outside of the scope of

this dissertation. Nevertheless, the orientations presented in this dissertation represent a starting

point towards this ambitious but interesting goal.

Having analyzed the global problem, we focus in next subsection on the implementation of

CLFPs as LD templates. Due to the nature of this type of patterns (the solution is a “learning flow”),

they can be computationally represented using LD (cf. Chapter Two).

5.3.2 Implementing CLFPs as refinable LD templates

The approach of providing CLFPs as script templates could be accomplished with any EML that

enables the computational representation of the scripts. As analyzed in Chapter Four, expressing the

requirements of macro-scripts (and therefore of CLFPs) using the LD interoperable specification is

feasible. The results of Chapter Four as far as the main characteristics of CLFPs are concerned can

be summarized as follows. LD enables the design of processes that include several roles (LD

element), each of which can be played by several persons. A collaborative learning experience can

be described by associating multiple persons and/or multiple roles to the same learning activity.

Furthermore, LD enables their activities to be specified in coordinated learning flows.

On the other hand, as continually discussed along this dissertation, creating successful designs

of scripts and, particularly, LD represented scripts from scratch is a complex task from both

pedagogical (cf. Chapter Two and Chapter Three) and technical (cf. Chapter Four) points of view.

Since CLFPs formulate group practices in structuring macro-scripts that can be applied to any

discipline (or content) and can be computationally represented with LD, they can be provided as

templates (i.e. partly completed UoLs) that needs to be refined into ready-to-run UoLs (scripts). The

resulting UoLs are potentially effective since the LDs (packed in the UoLs) are based on CLFPs.

That is, the roles, the activities and the learning flow of a CLFP-based LD are determined in the

118


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

particularization of the CLFP; and the CLFP-based UoL consists of the previous CLFP-based LD

and a set of particular resources that depend on a concrete learning situation.

5.3.2.1 From CLFPs to UoLs

The schema of the process that can be followed in order to achieve a UoL based on a CLFP is

illustrated in Figure 5.3. This is the rough approach from the LD notation perspective that is

considered in the design process proposed in section 5.4. The approach considers three stages. The

first stage is the computational representation of a CLFP using LD, that is to say, the edition of an

LD-compliant XML document that describes the CLFP. This XML document is the core of the LD

template. Since an LD document that formalizes a CLFP is an incomplete LD, the second stage

involves the particularization of the preceding document, so as to detail all the elements of a

complete LD. When the actual resources that are to be used during the enactment of the CLFPbased

LD are determined and packaged or referenced within a content package (IMS, 2004a), a

CLFP-based UoL is achieved. Next subsection illustrates this schema by means of an example.

Figure 5.3 From a CLFP to a UoL: scheme of the process for obtaining CLFP-based UoLs

5.3.2.2 Example: UoL based on a JIGSAW LD template

The context of this example is the same Computer Architecture course described in Chapter

Three (subsection 3.4.1). The whole course is defined as a project, which in turn is divided in three

subprojects, whose objective is the design and evaluation of computer systems. To enable distinct

perspectives of the main subjects within the classroom, five clients are defined, giving answer to

different market sectors and system requirements. Each pair of students is assigned one out of the

five clients for the whole course.

The scenario considered here concerns the first subproject, in which students get to know the

client, model the customer’s presumed computational load by mixing standard benchmarks, test real

119


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

machines using the benchmarks, and finally make a recommendation to their client. This subproject

pursues that students learn how to use benchmarks, and get a quantitative impression on a few real

machines (with different CPUs, memories, etc.) as well as they develop skills related to interpreting

and selecting information, arguing, and taking compromise solutions are promoted. The learning

process proposed to the students is briefly outlined next.

For the first activity, students should study customer needs while the educator should in turn

play the role of the client in order to clarify customer needs. Then, students model the

computational load of the customer. In the following activity, students distribute four groups of

different real machines among them, so that each student benchmarks a group of machines.

Subsequently, students benchmark those machines that have been assigned to them, collecting the

results and studying the documentation of the benchmarks and the machines.

Next, JIGSAW pattern (Pattern 1.1) is applied. Students who have benchmarked the same

machine debate the suitability of such machine for their customer according to benchmark results.

This activity will be supported by a (synchronous) chat tool. Finally, students have to debate the

results with other members of their group that have benchmarked different machines. As a result,

each group should generate a technical report presenting and arguing the best solution for their

customer.

To create a UoL representing this scripted CL situation so that it can be interpreted by LMSs

(Bote-Lorenzo et al., 2004), a three-stage process described in the previous subsection can be

applied as illustrated in Table 5.1. Column 1 of this table illustrates the LD representation of the

JIGSAW CLFP. The learning flow this CLFP suggests is included in a play of the LD method: one

act of the play is devoted to the individual study of a subproblem, the discussion of the subproblem

by expert groups takes place in the following act, and a third act is devoted to the Jigsaw group

debate, in which participants are supposed to solve the whole problem.

Column 2 of Table 5.1 represents the teacher customization of the LD description of JIGSAW

for the depicted example: a particular JIGSAW-based LD. This LD specifies that, in this case, the

problem involves deciding which is the best machine for a specific customer and the subproblem

entails testing a group of the available real machines. Besides, it also states that expert groups

debate synchronously.

Once the teacher has determined the binding of this LD with actual resources (tools or

documents), the UoL is achieved. Column 3 of Table 5.1 shows how two specific resources are

referenced within the CLFP-based LD. One of them is a document that includes the guidelines

students have to follow during the discussion. The other one is a concrete chat tool that enables this

debate.

120


The CLFP suggests an individual

study of a subproblem, this

subproblem is discussed in group

of experts, then a Jigsaw group

meet to solve the problem

DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

Again, Table 5.1 reveals that directly using the LD notation to refine the templates may be not

easy for most teachers. We revise the conclusions of this subsection towards a user-friendly CLFPbased

design process for the creation of LD scripts next.

Table 5.1 Excerpt showing the process for obtaining the JIGSAW-based UoL. A sample definition of an

activity and an environment can be found under and tags respectively.

The description of learning flow is shown under tag

1. LD representation of

JIGSAW CLFP


































2. A JIGSAW-based LD

(The teacher customizes the previous

description of the CLFP for the example

situation)




















In the example, which requires a

synchronous chat, the subproblem is to

test a group of the available real

machines using benchmarks. In this

case the resolution of the problem is to

decide which the best machine is for a

specific customer





















121

3. A JIGSAW-based UoL

(The binding of the previous LD for the

example situation with concrete resources)
























5.3.2.3 Discussion: towards a user-friendly CLFP-based design process

Particular resources used in a

particular performance of the

example scenario




























CLFPs and LD have similar purposes in the sense that both aim at describing learning

processes. However, CLFPs represent good practices in natural language and LD is a computational

language that does not help users to conceptualize the pedagogical features of effective units.

Computationally representing CLFPs as LD templates provides the following advantages:

- Software tools can automatically process CLFPs. This facilitates the incorporation of design

techniques in CSCL systems.

- CLFPs can be easily reused and refined into particular CSCL scripts represented with LD.

- The structure of learning situations is dissociated from the learning resources (content,

tools), among other details such as the description of the activities and the particularities of

the roles. Therefore, resources can be reused within different scenarios structures (LDs or


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

scripts). In the same way, LDs or CLFPs can be reused when particularized with different

resources that depend on the concrete learning situation.

- Since the LD specification provides a standard language, the reuse and integration of CLFPs

or CLFP-based LDs in different systems are facilitated.

On the other hand, when formalizing a CLFP, it is possible to achieve one or many templates

that reflect such pattern. For example, there are two possible ways to model groups using LD. The

types of groups indicated by the patterns can be represented with the LD role and the attribute

create-new set to “allowed” (cf. Chapter Four), so that the actual numbers of groups (occurrences of

the type of role) are determined at instantiation time (after refining the pattern-based template but

before running the resulting script). An alternative approach is to determine the number of groups at

authoring time. In this case, authoring tools must incorporate a mechanism that automatically

creates and includes in the template a new role for each group (of a type of group) together with the

rest of the necessary LD elements related to the activities to be accomplished for this type of group.

Similarly, some specific characteristics of each CLFP require specialized attention, for example

PYRAMID (Pattern 1.2) can be applied using as many levels of the Pyramid as necessary. This

needs to be also supported by authoring tools implementing the design processes based on CLFPs in

such a way that its use is intuitive.

In this sense, we also propose the use the diagrams of CLFP solutions (cf. Appendix A) as

visual representations of refinable LD templates with the aim of adding intuitiveness (Waters et al.,

2004) and familiarity (Harrer et al., 2006) to the LD notation system. This intuitive intelligibility

results from the visual similarity to the mental images and ideas that the potential users have or

build regarding the patterns. The particularities of our CLFP-based design process proposal are

detailed in next section.

5.4 A CLFP-based design process for the generation of LD scripts

This section is devoted to propose a pattern-based design process for the generation of LD

scripts whose main goals are:

- Achieve a satisfactory trade-off between the reuse of the CLFPs (keeping the intrinsic

constraints that potentially lead to learning outcomes) and the creation of meaningful scripts

contextualized according to the needs of a particular situation.

- Enable that a conceptualization of the expected interactions (at the macro level) is made

explicit in advance, what requires a focus on CSCL critical elements.

- Make easier for teachers without advance knowledge of LD but with interest in applying

scripted CL by means of LMSs (or similar learning environments) the creation of LDcompliant

scripts.

122


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

Therefore, we start by clarifying the scope of the design process within the outline of the global

system that enables the implementation of LD.

5.4.1 Scope: support the creation of LDs

The Best Practice and Implementation Guide included in the LD specification (IMS, 2003a)

details the different conceptual components of a system implementing LD. Figure 5.4 summarizes

these modules, emphasizing the authoring problem and illustrating what functions are covered by

our design process. Namely, it is not devoted to the enactment problem: instantiating LDs, binding

participants to roles, interpreting an LD, etc. However, being implemented in an authoring tool, it

aims at supporting the creation of LDs. As aforementioned, a UoL is a content package (IMS,

2004a) including an LD and a set of physical resources (content and tools) or their location. The

idea is that the resources that contain learning objectives, prerequisites, descriptions of activities

and information about roles are also created during the design process. The creation of other types

of resources (content or tools supporting the activities) is outside the scope of the design process.

Authoring

IMS LD authoring environment

Production

Instantiating IMS LD

Delivery

Executing/interpreting IMD LD

Creation of IMS LD documents

Creation / selection of resources

123

Text of learning objectives, prerequisites, description

of activities and roles’ information

Other types of content or tools needed to support the

activities, etc. (pictures, web pages, videos, conceptual

map editor, services like e-mail, asynchronous or

synchronous groupware, etc.)

Validation and publication of the IMS LD document

Population of a Learning Design instance (creation of a

run or community of users), assigning actual users to the

instance of the LD…

Actual live interpretation of the Learning Design (it

depends on the technical architecture)…

Figure 5.4 General modules of a system implementing LD

Designer’s Guide, which is also included in LD specification (IMS, 2003a), proposes the basic

procedures for creating a UoL. (Sloep et al., 2005) details these procedures according mainly to

three phases:

- The first phase involves the analysis of a specific educational problem, whose result is a

narrative description of the educational situation.

- Then, the narrative is translated into a UML (Unified Modelling Language) activity diagram

(Arlow & Neustadt, 2001) in the design phase.


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

- The diagram is the basis for the XML instance IMS LD compliant document. In the forth

phase the resources are developed (if necessary) and added to the design. Thus, a UoL is

created.

These basic design procedures are useful depending on the type of audience that creates the

UoLs. That is, different institutions, types of users (learning designer, teachers) or communities of

practice may require different types of design processes. These processes are specially valuable if

they provide a methodology for the analysis phase and enable teachers to understand and edit the

UoLs (Griffiths et al., 2005). The use of CLFP-based templates provides a structure for the first

stage of analysis and creation of LD scripts. However, it is not realistic to consider that scripts are

always structured as indicated by a unique CLFP. Like other types of patterns, CLFPs can be used

collectively in order to define richer CL flows (cf. Chapter Three).

5.4.2 Combinations and concatenations of CLFP-based templates

According to Chapter Three, CLFPs can complete and complement each other generating new

structures of scripts. That is to say, CLFP-based templates can be combined in such a way that a

phase of the learning flow is refined (completed) by replacing the phase with another template. Or

they can be concatenated so that some phases of a script are structured according to one CLFP and

other (separated but consecutive) according to another CLFP (that can be eventually the same). In

this case the flow suggested by the former pattern is complemented with the latter CLFP (the limits

of the whole resulting from this concatenation of patterns are determined by the two patterns).

Figure 5.5 illustrates these two ways of forming CLFP hierarchies. The “Expert Group” phase

of JIGSAW (Pattern 1.1) can be structured following PYRAMID (Pattern 1.2).The result is a

combination of two CLFPs. In contrast, the JIGSAW can be concatenated with PYRAMID by

preceding (as it is shown in Figure 5.5) it in the learning flow of the script.

Now, how does this approach of combining and concatenating CLFPs fit within the create-byreuse

framework?

124


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

The Expert Group phase of the JIGSAW is

structured according to PYRAMID

The first set of

phases of a script

are structured

according to

JIGSAW while the

second set of phases

are structured

according to

(a) PYRAMID (b)

Figure 5.5 CLFPs hierarchies (a) combined CLFPs: jigsaw is completed with PYRAMID; (b) concatenated

CLFPs: jigsaw is complemented with pyramid

5.4.3 The design process in the create-by-reuse framework

We define template in section 5.2 as a partly completed UoL. The level of granularity and

degrees of completeness of templates is varied. Figure 5.6 shows that a template which represents a

CLFP is more incomplete than the template that results from particularizing the pattern into an LD

(actual description of activities, group-size limits, etc. but still without the resources that are needed

in order to achieve a ready-to-run UoL).

Consequently refinement steps are necessary to create a complete UoL. These refinement steps

coincide with the stages depicted in subsection 5.3.2 (cf. Figure 5.3 and Table 5.1). The first

refinement step produces an LD, while the second results in a UoL, ready to be played in an LD

engine. This can be seen as a pure “horizontal” design process with refinement steps.

Low level of granularity

(coarse grained)

Exemplars

(Ready-to-run

UoLs of

different

granularities)

Complete

UoL chunks

(A UoL

portion of

different

granularities)

UoL LD refining the

template

Refinement

High level of granularity

(fine grained)

125

CLFP-based

template

Templates

(Partly

completed

exemplars)

Incomplete

Building

blocks/

Compontents

(Partly

completed

UoL chunks)

Figure 5.6 CLFP-based design process for the creation of LD scripts within the create-by-reuse framework:

refinement process

+


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

Besides the pure refinement process, the potential of the CLFP-based design process is

“mixed”. Combining or concatenating CLFP-based templates involve their assemblage. Figure 5.7

illustrates it. When two templates are concatenated, they are actually assembled forming a coarser

template, which in turn needs to be refined. On the other hand, a combination of CLFPs, which is

also an assemblage of reusable design solutions, results in a refinement of the pattern that is

completed. Both cases imply mixed design processes, having the second case a “refinement by

assembling” step.

Low level of granularity

(coarse grained)

Exemplars

(Ready-to-run

UoLs of

different

granularities)

Complete

UoL chunks

(A UoL

portion of

different

granularities)

LD refining the

combination

UoL

Refinement

High level of granularity

(fine grained)

Refinement by

assembling

Combination of

two CLFPbased

templates

CLFP-based

template

Templates

(Partly

completed

exemplars)

Incomplete

Building

blocks/

Compontents

(Partly

completed

UoL chunks)

(a) (b)

126

Low level of granularity

(coarse grained)

Exemplars

(Ready-to-run

UoLs of

different

granularities)

Complete

UoL chunks

(A UoL

portion of

different

granularities)

UoL

High level of granularity

(fine grained)

LD refining the

concatenation

Refinement

Assembly

Concatenation

of two CLFPbased

templates

CLFP-based

template

Templates

(Partly

completed

exemplars)

Incomplete

Building

blocks/

Compontents

(Partly

completed

UoL chunks)

Figure 5.7 CLFP-based design process for the creation of LD scripts within the create-by-reuse framework:

mixed process (a) combination of CLFPs, (b) concatenation of CLFPs

To this point several important elements of our design process for creating LD scripts are

presented: it uses the “template” as the type of reusable design solution; the pedagogically-based

formulations behind the templates are CLFPs; it enables processes of type “refinement” and

“mixed” (assembly + refinement, refinement by assembling + refinement). Next section tackles

how CLFP-based templates are selected and refined so that it enables teachers to focus on CSCL

critical elements.

5.4.4 Focus on CSCL critical elements: selecting the templates and authoring the scripts

One of the main goals of the proposed design process is to consider the CSCL critical elements

that affect interaction, namely: learning objectives, task type, level of pre-structuring, group size

and computer support. In this sense, our design process is a particularization of the framework

introduced in (Strijbos et al., 2004), which proposes a process-oriented methodology for the design


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

of CSCL settings in view of these critical elements. The methodology implies that a

conceptualization of the expected interaction is made explicit in advance and consists of six steps:

1. Determine which type of learning objectives should be specified.

2. Determine the expected interactions according to the specified objectives. It is related to the

co-ordination of activities and the types of interaction promoted by the different types of

activities (e.g. discussion).

3. Select task-types with respect to the learning objective and expected interaction. For

example, if students have to solve a complex and ambiguous problem with no clear

solution.

4. Determine how much structure is necessary to accomplish the learning objectives, expected

interactions and task-types (e.g. privileged roles within an activity).

5. Determine which group size is best suited with respect to learning objective, expected

interaction, task type and level of pre-structuring.

6. Determine how computer support is best used to sustain learning and expected interaction:

face-to-face or computer mediated (synchronous or asynchronous).

Figure 5.8 shows in detail the design process that we propose. It is not strictly sequential. It

aims at providing guidance but without directing the user through a rigid wizard-style set of steps.

The design process considers two general phases, namely selecting a CLFP-based template and

authoring the CLFP-based script.

The different design tasks included in the design process can be easily mapped to the steps

indicated in the methodology proposed by Strijbos. Step 1 regarding learning objectives is partially

performed in task a and completed in task c. Steps 2, 3 and 4 correspond to a large extent to the

selection of a CLFP (mainly task a). Note that tasks a and b are repeated if the collaborative

learning flow is structured according to a hierarchy of CLFPs (task d). Tasks e and h embody also

step 4 as far as the structure of the interaction processes within activities is concerned. The

description of an activity and the tool that supports it can represent a certain level of activity prestructuring

(e. g. a discussion activity supported by a simple chat vs. a chat with a structure dialogue

interface that allows different roles). Task e clearly refers to step 5 (group-size). While determining

the computer support (step 6) is accomplished in tasks f, g and h.

127


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

Identification and formulation of CL structuring techniques as

patterns (CLPFs) and formalization using IMS-LD

Selecting a

CLFP-based template

Authoring a

CLFP-based UoL (script)

a. Choose a CLFP depending on: The learning objectives proposed

by the CLFP, the type of problem or task the CLFP is more suited to

be applied and the complexity of the CLFP in terms of the

collaborative learning experience needed.

b. Read the help about the chosen CLFP: Understand the learning

flow structure (CLFP) on which the UoL will be based.

c. Determine the title, learning objectives and prerequisites of the LD

d. Specify the collaborative learning flow: The learning flow of the

selected CLFP can be enriched by combining or concatenating CLFPs.

Depending on the CLFP some aspects should be determined (e. g. levels

of the Pyramid CLFP). Additional activities can be also inserted.

e. Define the description of activities, activity completion, the

information about roles (including groups), group-size limits.

g. Determine and configure the resources needed to support the activities

h. Associate resources to activities

i. Package the LD into a UoL

f. Create or select resources (content and tools)

Figure 5.8 CLFP-based design process for the creation of LD scripts: selecting the templates and authoring

the scripts

5.4.4.1 Selecting a CLFP-based template

With the aim of facilitating the choice of CLFPs, the selection has been planned considering the

following premises:

- Potential Collage users may not explicitly know the collaborative techniques formulated in

the CLFPs.

- Users may not be familiar with pedagogical jargon. In this context it is more appropriate to

indicate the meaning of the psychological term. E.g.: positive interdependence means that

team members need each other to achieve a common goal.

- Teachers should be able to select a CLFP, so that the LD they create is adequate for their

educational situation. Moreover, they should find CLFPs addressing their needs even if they

do not know exactly the learning outcomes they want to promote.

128


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

Several approaches can be used to support the selection of the CLFP-based templates, from the

use of metadata to the use of ontologies (cf. subsection 5.2.3). As an initial approach, we propose

the use of the following metadata elements (see task a in Figure 5.8), whose related information is

captured in the patterns (mainly problem and forces fields, cf. Appendix A):

- Name of the CLFP on which the LD template is based.

- Learning objectives that the CLFP elicits. They are related to the gain of conceptual

knowledge, on one hand, and to the gain of meta-cognitive strategies. However, these

objectives have been formulated in a simplified way (so teachers may understand them

better) and classified in two types: attitudinal and procedural objectives. Attitudinal

objectives are related to motivational and emotional competencies, while procedural

objectives refer to the acquisition of skills. An example of attitudinal objective is “to

promote tolerance and respect” (BRAINSTORMING, Pattern 1.4). “To promote analytical

reasoning skills” (TAPPS, Pattern 1.6) is an example of a procedural objective. The fact that

a CLFP can be selected according to objectives fulfils the two first steps of the methodology

proposed by Strijbos et al. (2004).

- Types of problems that are best served with the CLFP. It is equivalent to the selection of

task type proposed in step 3 of Strijbos’ methodology. For instance, the task type of JIGSAW

(Pattern 1.1) is “complex problem that can be easily divided into sections or independent

sub-problems”.

- Complexity or risk in terms of collaborative learning experience needed. Depending on the

conditions in which the CLFP is to be applied or the experience in collaborative learning of

teachers and learners, some CLFPs are recommended above others; e.g. Jigsaw CLFP is

complex and is probably more appropriate for experienced participants (NISE, 1997).

When performing the selection of CLFPs, teachers should make use of these characteristics in a

priority order that depend on their situation. To further support the selection of the templates,

teachers can read extended information about the patterns (see task b in Figure 5.8). This

information includes:

- Overview: apart from the learning objectives, the type of problem and the complexity of the

CLFP, it contains the context in which the CLFP can be applied. It also explains the

collaborative learning flow proposed by the pattern.

- Diagram: a diagrammatic representation of the CLFP solution. The same visualization is

used in the authoring process as the graphical representation of the CLFP-based template.

- Use guidelines: indications and recommendations for particularization / customization,

instantiation and execution (or authoring, production and delivery according to Figure 5.4).

- Example: a sketch of a particular LD based on the CLFP.

129


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

With this information about CLFPs, teachers can be quite sure about the usefulness of a CLFP

for their particular needs. In other words, they can understand the CLFP before reusing it and,

consequently, they can be quite confident of the adequacy of the created UoL before running it in a

real situation.

5.4.4.2 Authoring a CLFP-based script

Authoring a CLFP-based script is actually a process of particularizing and adapting a CLFPbased

template according to the requirements of a particular learning situation. This includes tasks

from c to i, as it is exposed in Figure 5.8. After determining the title, learning objectives (besides

the objectives of the selected template) and prerequisites of the LD, the user should specify the

collaborative learning flow. This task involves configuring some aspects that depends on the

selected CLFP. That is, the user has to decide several aspects of the activity flow or the way in

which the number of groups has been modelled (to be determined at design, using a mechanism that

creates the roles, or at instantiation time, setting create-new argument to “allowed”, cf. subsection

5.3.2.3). A good example is PYRAMID (Pattern 1.2): it specifies the organization of activities (in a

series of levels), and how participants will form groups and interact in each level, but the number of

levels is not fixed. To create an LD based on this CLFP, users must first determine how many levels

they want. Moreover, in this task the user decides if the flow of activities is enriched by combining

or concatenating CLFP-based templates (cf. subsection 5.4.2). In this case, a selection of a new

CLFP needs to be accomplished again. The result is a hierarchical structure of CLFPs presented as a

single template which is graphically represented according to the diagrams visualizing the solutions

of the patterns. Moreover, additional activities can be inserted, as a “didactic envelope”

(Dillenbourg et al., 2007) of the script (pre- or post- activities) or within a CLFP phase (typically

maintaining the group structure of the phase, they may be also individual or collective activities that

involve the whole class).

In this sense, we propose to hide several LD elements that are difficult to understand without

knowing the specification: activity-structure, method, play, act and role-part. These elements can

be substituted by the graphical representation, which symbolizes these concepts (directly related

with the learning flow). For example, the visual representation of JIGSAW (cf. for instance Figure

5.5) denotes that the suggested learning flow has three phases (modelled as three acts within a play

within the method). Each phase includes two role-parts one for the teacher (represented as a grey

circle), which indicates the activities or the activity structures of the teacher in this phase, and other

for the students, which specifies the activities or the activity structures assigned to the student in

this phase. Similarly, the environment LD element can be automatically generated (without the

need that the teacher knows its existence) when the user determines, configures and references the

resources that will be available in each activity (cf. task g and h of Figure 5.8).

130


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

Though more elaborated types of resources can be used to contain the learning objectives,

prerequisites, descriptions of activities and information about roles (cf. task e), we argue that a

simple text description whose edition is facilitated by the own authoring tool implementing our

proposed design process would provide fluency to the design.

All in all, we argue that this design process represents a trade off between generality and

unrestricted design options vs. good reuse and particularization of CLFPs (and hierarchies of

CLFPs) as well as easy authoring of collaborative LDs.

5.4.4.3 Discussion

This design process represents an innovation to the phases recommended by LD specification in

creating a UoL. Selection of CLFPs supports the analysis phase in which a CSCL situation is

planned. It is necessary for teachers to know the CLFP-based templates that are available to plan a

feasible design. On the other hand, the need for understanding those learning flows promotes the

application of CL good practices, i.e. reuse of CLFPs in their own educational situations. The

design phase is highly simplified mainly thanks to the use of specific high-level collaborative

learning structures (CLFPs) instead of raw LD elements. Moreover, the templates are graphically

represented using the diagrams of the solutions captured by the CLFPs. That is, the UML diagram is

not necessary (each CLFP has an intuitive diagram that represents the learning flow) and the XML

code can be automatically generated. Furthermore, available information about each CLFP allows

teachers to understand and easily edit collaborative UoLs.

The proposed design process has been implemented in an authoring tool, named Collage, what

proves the feasibility of the approach and enables its evaluation.

5.4.5 Collage authoring tool: implementing the proposed design process

Collage (COLlaborative LeArning desiGn Editor) is an authoring tool that implements the

proposed CLFP-based design process for the creation of scripts computationally represented with

LD (the authoring tool, user manual and documented examples are available at

http://gsic.tel.uva.es/collage). According to the LD authoring tools framework (cf. subsection 2.4.1

of Chapter Two) devised by Griffiths et al. (2005), Collage is a high-level LD editor whose specific

purpose is CSCL (cf. Figure 5.9). It is LD level A (IMS, 2003b) compliant (Villasclaras-Fernández,

2005) and it is currently being extended towards level B compliance.

131


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

Close to

specification

LD Editor

Specific

purpose tools

General

purpose tools

132

COLLAGE

Distant form

specification

Figure 5.9 Two dimensions of LD tool design (Griffiths et al., 2005)

Collage is developed on top of the Reload Learning Design Editor (LDE), which is an Open

Source, general purpose, close-to-specification LD editor written in Java (University of Bolton,

2004; Wilson, 2005; Griffiths et al., 2005; Milligan et al., 2005). Reload LDE is considered the first

and currently “de facto” reference implementation of an LD editor intended primarily for

developers and early adopters to explore and think about the implications of the specification for

creating UoLs.

5.4.5.1 CLFP-based LD templates as plug-ins on top of Reload LD Editor

Reload draws on a plug-in framework whose architecture is shown in Figure 5.10. Plug-ins can

offer different authoring capabilities (providing controllers and views that fit into the Presentation

Layer framework) in such a way that the validity and integrity of the created LDs is ensured

(accessing instance data model though the Learning Design Model Layer) (Wilson, 2005). This fact

enables the developers of authoring tools for different types of users or pedagogies to focus on the

user interface and avoid handling all the underplaying processes involved in manipulating LD

structures (Griffiths et al., 2005).

Collage is developed as a collection of Reload LDE 2.0 plug-ins. This version of Reload is

XML Schema driven: the final XML manifest for the UoL is created directly by a generic engine

using the specification schema to provide the rules whose elements can be added and deleted. This

is facilitated by reading, parsing and modelling the schema as a Document Object Model (DOM).

The current version of Reload LDE (which was not available when Collage was developed) adopts

the Eclipse Rich Client Platform (RCP) architecture and moves on from the Schema driven

approach. In the new version, resource file dependencies are managed separately and the LD

manifest is created only for export of the final UoL (Milligan et al., 2005).


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

The Editor Presentation Layer is a framework that allows plug-ins to

install new items and views within the Editor user interface

>

Editor Presentation Layer

provide controllers and views

Plug-In

access instance model

>

Learning Design Model Layer

The Learning Design Model Layer manages the internal representation

of the Learning Design instance, and controls the modification of the

instance by Plug-Ins

Figure 5.10 Plug-in framework for an LD editor (Wilson, 2005)

As mentioned above, some CLFPs impose the need of offering specific configurable

functionalities in the corresponding LD templates. These functionalities refer to configuring aspects

that depends on the patterns. Moreover, the graphical representation of each pattern solution, and

thus of each template, is unique. Therefore, Collage includes at least a plug-in associated to each

CLFP (commonalities are implemented in separate plug-ins that are associated to several patterns

(Villasclaras-Fernández, 2005)). Each plug-in is in charge of the graphical representation and the

specific functionalities of each CLFP.

To handle the specification of CLFPs hierarchies (cf. subsection 5.4.2), Collage makes use of

additional information stored in the Collage UoL package. This information is an XML document

that includes the structure of the learning flow in terms of CLFP hierarchies. The current version of

Collage enables combinations of CLFP-based templates. In this case, the plug-ins are not devoted to

the creation of CLFP hierarchies (this is responsibility of the editor). However, the CLFP-based

templates can indicate constraints regarding specific connections of patterns (e.g. it does not have

sense to replace a phase of TAPPS with another CLFP).

Next subsections detail the implementation of design process general phases, selection and

authoring, in Collage.

133


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

5.4.5.2 Selecting a CLFP-based templates in Collage

Collage provides a repository with a pool of CLFPs. The available CLFPs at the moment are

JIGSAW, PYRAMID, SIMULATION, BRAINSTORMING, TPS and TAPPS (cf. Appendix A), but

more CLFPs can be added. A section utility is implemented in Collage according to the guidelines

indicated in subsection 5.4.4.1.

Figure 5.11 shows the interface of the CLFP selection utility, which allows the user to choose a

CLFP directly or select one or several characteristics of CLFPs. The list of CLFPs displayed in the

interface shows only the CLFPs that comply with the selected characteristics. These characteristics

may or may not univocally identify a CLFP and they are retrieved from CLFPs’ metadata.

Further information about each CLFP can be read by clicking on the title of a CLFP in the list

of the selection interface. This information is displayed in a window that provides a navigation tree

including four hyperlinks that show types of information indicated in subsection 5.4.4.1: namely

overview (cf. Figure 5.12 (a)), diagram (cf. Figure 5.12 (b)), use guidelines (cf. Figure 5.12 (c)) and

example (cf. Figure 5.12 (d)).

The more significant functionalities of Collage that facilitate authoring of a CLFP-based LD are

explained next.

Figure 5.11 Collage selection interface

134


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

(c)

(a)

Figure 5.12 Help information about the JIGSAW CLFP: (a) overview, (b) diagram, (c) use guidelines, (d)

example

5.4.5.3 Authoring a CLFP-based UoL in Collage

Collage also conforms to the authoring phase of the proposed design process (cf. subsection

5.4.4.2). Figure 5.13 (a) shows the Collage authoring interface regarding task c of Figure 5.8, where

the title, the objectives and prerequisites of the LD are defined. They can be directly written in the

text boxes provided by Collage.

135

(d)

(b)


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

(a)

(d)

Figure 5.13 Collage authoring interface: (a) general tab, (b) resources tab, (c) collaborative learning flow tab,

(d) form for the description of activities, association of resources to activities, (e) form for the description of

roles (groups) and group-size limits

Specifying the collaborative learning flow (task d) is facilitated with the interface shown in

Figure 5.13 (c). In this example the JIGAW-based template does not have any configurable aspect as

it has been modelled. However, the flow of activities indicated by the template can be enriched by

replacing phases of this CLFP with another CLFP-based template (that can be eventually the same).

In this way, the current version of Collage enables combinations of CLFPs. Although the actual

136

(b)

(c)

(e)


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

number of CLFPs implemented in Collage is not large, there is no theoretical limit on the

combinations of CLFPs that can be described.

The solution adopted in this first version of Collage for combining two CLFPs in a single

template is a simple approach that can be further elaborated in future versions. What can be

replaced by the whole learning flow of another CLFP-based template is a phase of the base template

that corresponds to an LD act (it is not possible to replace a single activity of an act). Besides, the

roles of the CLFP that completes the base template are included as sub-roles of the role

corresponding to the replaced phase.

As the JIGAW-based template, the templates based on BRAINSTORMING and TPS patterns do

not include configurable aspects. In contrast, those representing PYRAMID, SIMULATION and

TAPPS require that the plug-ins that implement them incorporate configuring utilities. Figure 5.14

shows how the Collage plug-in corresponding to PYRAMID includes a functionality that enables the

configuration of number of levels of the Pyramid.

(a) (b)

Figure 5.14 Configuring the flow of the PYRAMID-based template in Collage: (a) determining the number of

levels in the Pyramid, (b) resulting template based on PYRAMID of 6 levels

Similarly, Figure 5.15 illustrates the specific configuring requirement of the SIMULATIONbased

template. In this case the CLFP has been modelled in such a way that the designer must

specify at design time the number of groups (and characters participating in the simulation).

Therefore, the plug-in for this template implements a utility that enables the user to indicate it. It is

worth mentioning that this approach could have been also employed in the formalization of

JIGSAW as an LD template, instead of relying on the option of specifying the number of groups at

instantiation time. Both solutions represent two possibilities with advantages and limitations as

deeply discussed in Chapter Four. For example, the approach adopted for the JIGSAW template is

more flexible in the sense that it is not necessary to know in advance the concrete number of

students (and thus groups) that will attend in the actual enactment of the script. On the contrary,

137


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

defining at design time the concrete groups enables resource distribution (associating a different

environment to the activities to be performed by each group) without making use of external tools

in charge of accomplishing such distribution depending on the occurrence of the group (role

specified in the design) (cf. section 4.5 of Chapter Four for more details).

(a) (b)

Figure 5.15 Configuring the flow of the SIMULATION-based template in Collage: (a) determining the number

and name of characters (roles) and simulation (small) groups that will participate in the Simulation, (b)

resulting template based on simulation with 2 types of characters and 2 simulation groups

TAPPS CLFP (Pattern 1.6) suggest to structure the learning flow so that students are paired and

given a series of problems in such a way that they switch the roles Problem Solver and Listener (cf.

subsection 4.4.2 of Chapter Four). However, it does not indicate the number of problems that

should be pair. This is the configurable aspect of TAPPS-based template and is implemented in

Collage as shown in Figure 5.16.

Figure 5.16 Configuring the flow of the TAPPS-based template in Collage: determining the number of

problems that will be though aloud in pairs

138


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

Apart from the configurable elements of each CLFP and the opportunity of combining several

CLFPs, it is not explicitly possible to add or delete phases and activities. Nevertheless, Collage

allows specifying an activity as not visible, which ensures that it will be ignored during the

execution of the UoL. This can be done in the form (cf. Figure 5.13 (d)) that also enables the

description of activities and the association of the resources that will support the activities (design

tasks e and h). The determination and configuration of the external resources should be previously

accomplished (task g) by means of the Collage interface shown in Figure 5.13 (b). The creation and

search of the resources is outside the scope of Collage (task f) and should be accomplished with

complementary tools. On the other hand, information about the roles/groups including the groupsize

limits (minimum and maximum number of persons that can be associated to this role/group),

which is also part to the task e of the design process, can be incorporated in the script through the

interface shown in Figure 5.13 (e). The forms are accessible by clicking on the graphical

representation of each CLFP phase. Collage also includes the functionality of showing a table with

a summary of the created script. It allows users to check whether they forget to particularize any

element of the template. Finally, packaging the CLFP-based LD into a UoL (task i) can be done

using the utility that Reload provides for its own LD editor (University of Bolton, 2004).

5.4.5.4 Discussion

Since Collage has been implemented as a new editor in Reload, the tool identifies whether a

UoL has been created by Collage or by another Reload editor (in this case LDE), and opens the

UoL using the appropriate tool. However, the LDs created using Collage can be eventually opened

by, a priori, any LD compliant editor. (Note that high-level or specialized editors, such as Collage

or ASK LDT (Sampson et al., 2005), may need additional information about their representation in

the authoring tool, etc.). This point leads the discussion to one of the limitations of Collage: it

cannot be used as a viewer for any UoL. Other types of authoring tools should be employed to

accomplish this goal and to change low-level elements of the LDs created by Collage.

Although Collage can be used by learning designers, the design process that it implements is

specifically designed to be used by teachers. We support the idea that teachers should be able to

intervene actively in the design process, especially if they do not have the support of specific

instructional designers. A massive support of ICT in Education or specifically of LD requires the

participation of teachers, as real practitioners who know the reality of their context and could

possibly assume the adoption of good practices (such as those reflected in CLFPs).

The initial adopted approach for the selection of CLFPs is simple. A more valuable approach

could be, for example, the use of ontologies. Another limitation regards the addition of new CLFPs.

If a new CLFP-based template is to be included in Collage, the plug-ins related to the graphical

interface for editing the collaborative learning flow must be implemented. Although there is no

139


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

limit to the possible combinations of CLFPs that can be created, concatenations of CLFPs (adopting

separate sequenced CLFPs) and inserting additional activities are not allowed yet. At this point, it is

necessary to state that our LD editor approach is similar to LAMS (LAMS, 2006) in that it reuses

predefined “modules” created with lower-level tools. However, Collage does not reuse at the

granularity level of activities yet. It reuses the whole learning flow implied in collaborative learning

best practices. There is definitely value in both approaches as they are complementary.

On the other hand, Collage supports only level A of the specification, which is sufficient to

formalize the learning flows suggested by CLFPs. However, in order to enable the creation of more

sophisticated and flexible collaborative UoLs, we are exploring the use of level B and C. Their

support to computationally representing CSCL script requirements is important and necessary in

many situations, as it is analyzed thoroughly in Chapter Four. We argue that the incorporation of

these level B and C elements in Collage should be accomplished by adding reusable chunks and

building blocks that represent specific learning design solutions (based on patterns or not) which

requires these LD elements.

As aimed by the design process, Collage represents a trade off between generality and

unrestricted design options vs. good reuse and particularization of CLFPs as well as an easy editing

of collaborative LDs. First, a simple intuitive graphical representation of each CLFP is provided.

Second, users do not need to be aware of the existence and function of particular LD elements

which are difficult to understand without knowing the specification. These statements are evaluated

in Chapter Six. The particular scripts involved in the evaluated case studies are detailed in next

section, which also illustrates the CLFP-based design process for the creation of scripts

implemented in Collage.

5.5 Creating LD scripts using Collage

Several different CSCL scripts are involved as show examples or as UoLs that are created by

the participants in the experiences comprising the evaluation of the proposed design process (cf.

Chapter Six). These scripts are introduced in this section (the scripts and some snapshots showing

their execution are also available in the CD-ROM). In the description we illustrate how Collage is

used according to the design process. Particularly, the CTM2 script is exposed thoroughly given

that it is the most relevant script in the evaluation experiences. This script is originally proposed by

one of the teachers participating in one of the experiences considering an authentic learning

scenario that he realizes in his own course (at the University of Valladolid, Spain). It is also the

example proposed to other teachers that use Collage. Besides, the CTM2 script is enacted with

students in an authentic situation.

140


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

5.5.1 CTM2 (Network Management)

The context of this script is a Network Management course (whose Spanish acronym is CTM2),

whose objectives include knowing the different versions of the SNMP (Simple Network

Management Protocol) protocol and familiarizing with the use of scientific and technical literature.

Consequently, the teacher decides that the students should understand the contents of an important

and well-known paper in the field of Network Management (Stallings, 1998), as well as identify its

most relevant ideas. A non-collaborative pedagogical approach might simply consist of providing

the students with the paper, asking them to individually read it and reflect on its content, and finally

request them to write a list of the main identified ideas of the paper. But the teacher also wants the

students to develop competencies related to group work that they will need in their professional

future, as well as to improve the understanding of the paper contents. Therefore, he decides to

create a collaborative pedagogical design, in the form of a computer-interpretable collaboration

script, which takes into account both types of requirements (concepts and competencies).

Table 5.2 Refining the template resulting of the combination of CLFPs towards the ready-to-run script

(students’ activities)

Learning Flow

Phase

individual

phase of

Pyramid level 1

Pyramid level 2

Pyramid level 3

Jigsaw

“expert”

phase of

Jigsaw

“jigsaw”

phase of

Jigsaw

“think”

phase of

TPS

“pair”

phase of

TPS

“share”

phase of

TPS

Group characteristics

Each “jigsaw group” has at

least 3 people. (Plan: 4 groups

of 3 members.)

Each “expert group” has at

least one member of each

“jigsaw group”.

(See Pyramid level 1:

individual phase of Jigsaw)

Each group of the second

Pyramid level comprises from

6 to 8 students. (Plan: 2

groups in this level of the

pyramid.)

In this pyramid level there is

only one group: the whole

class.

Each group of the second level

of the pyramid is one of the

two members of the “Pair”.

(See Pyramid level 3: “think”

phase of TPS).

141

Activity description and supporting

resources

- Read the introduction and one of the three

sections of the paper available in Synergeia

- Discuss (using the chat) your part of the

paper with the classmates that have read the

same part in order to understand it well.

- Explain to the rest of the members of your

“jigsaw group” your part of the paper.

- The group has to agree on which are the 10

main ideas of the whole paper and 2 questions.

Use the tool for questionnaires (Quest).

- Read other group’s results of the previous

phase at home. Their results are available in a

shared repository (Synergeia). Critically

comment their answers (using Synergeia).

- Discuss face-to-face with another “jigsaw

group” and jointly agree on the 8 main ideas of

the paper and 2 questions (use Quest).

Not visible

(there is no task in this phase)

- A speaker of each group exposes their

conclusions to the other group.

- The teacher mediates a discussion aiming at

reaching consensus.

Time

frame

With that purpose, Collage assists the teacher in the creation of potentially effective scripts,

using a proposed design process based on CLFPs. As it is described above, the first steps of the

First face-to-face session

of two hours

Distant

activity

Second face-to-face session of

two hours


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

design process is to select and combine, if required, the LD templates based on the CLFPs that

Collage provides. After reading information about the patterns, exploring examples, as well as

checking the educational benefits and types of problems supported by each pattern, the teacher

decides which CLFPs can be used and how they can be combined in order to structure the flow of

activities. The first column of Table 5.2, Figure 5.17 and the left frame of both Figure 5.18 and

Figure 5.19 show the result of these steps.

Figure 5.17 Planning the learning flow: combining PYRAMID, JIGSAW and TPS in form of LD templates

using a graphical notation in which the visual representation of each template corresponds to the diagram of

its related pattern’s solution

With the aim of fostering discussion and reaching agreement, the teacher selects PYRAMID,

which promotes positive interdependence (i.e. the feeling that the students need each other to

succeed, cf. Appendix A). The number of levels of the template can be configured with Collage (cf.

Figure 5.18). In each level of the Pyramid the groups of the previous level join in larger groups in

order to generate agreed “solutions”. In this case the “solution” consists of successively proposing

which are the most important ideas of the paper and what questions they would like to be answered.

Since the teacher is also interested in focusing the students’ attention on particular topics of the

article, he plans a plenary discussion mediated by him and structured according to the TPS (cf.

Figure 5.19) for the last level of the Pyramid.

142


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

Figure 5.18 Graphical refinement of the template resulting of the combination of CLFPs using Collage (I)

Figure 5.19 Graphical refinement of the template resulting of the combination of CLFPs using Collage (II)

Moreover, the teacher chooses to design the first pyramid level according to the strategy

collected in JIGSAW-based template. The selection of this pattern is motivated by the fact that the

paper can be divided in different parts, because the article includes several sections devoted to

different versions of SNMP. An additional motivation for its use is that the JIGSAW strategy

143


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

reduces students’ workloads but at the same time fosters that they contribute with their fair share

(individual accountability). This pattern (cf. Appendix A) suggests that each participant in a

(Jigsaw) group first studies a particular sub-problem (a section of the paper). Then, the members of

the different groups that have worked on the same sub-problem meet in an “experts group” to

exchange ideas. Finally, each participant contributes with his expertise in the original group in order

to tackle the global problem (i.e. the whole paper).

After selecting and combining CLFPs, the next step in the design process implies refining the

resulting LD template so as to obtain a computer-interpretable script. This step includes

particularizing the description of the learning activities (e.g., reading a part of the paper, discussing

on questions/ideas, etc.), providing information about roles and groups, establishing group-size

limits, and determining and configuring the resources (tools and content) needed to support each

activity. These tasks are accomplished using forms, as it is shown in Figure 5.18, where the first

activity of the second Pyramid level is described, and Figure 5.19, where the Pair phase is refined

by including the description of the activity and the groups. Table 5.2 summarizes the result of this

refining step and details the planned time frame. The refinement also includes indicating the tools

that support each activity. In this script the tools are: Synergeia system (ITCOLE, 2005), which

mainly provides a shared web-based workspace in which documents and ideas can be shared; a chat

tool developed by members of the GSIC/EMIC group (GSIC/EMIC, 1994), and the Quest webbased

questionnaire tool also developed by the same group (Gómez et al., 2002).

5.5.2 NNTT

The “NNTT script” is highly inspired in a real experience that takes places within the course on

the Use of ICT in Education” at the Faculty of Education of the University of Valladolid.

Moreover, this experience is one of the case studies included in the TELL project (TELL, 2005b). It

is a blended situation, where normal face-to-face activities are interleaved with technologysupported

(distant and face-to-face) activities. The experience also makes use of the Synergeia

system (ITCOLE, 2005). The script guides the students in the revision of three topics in order to

produce a deeper understanding of them. Table 5.3 describes this script, which is based on a

combination of the Jigsaw and the Pyramid CLFPs.

Figure 5.20 illustrates how the learning flow of the example can be edited using Collage. After

selecting the CLFP base of the flow of activities, i.e. JIGSAW, the “Expert Group” phase is replaced

with a two-level PYRAMID-based template. This is indicated with the circled “1”, “2” and “3” of

Figure 5.20. “4” points to the whole structure of the activity flow. This tree also provides access to

any CLFP included in the hierarchical structure, thus the activities of each CLFP can be further

particularized. The tasks of describing activities, roles, associating resources to activities, etc. are

accomplished using a form analogous to the example shown in Figure 5.20 (these steps are detailed

144


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

in the worksheet included in the Collage user manual, which is available at

http://gsic.tel.uva.es/collage).

Table 5.3 Refining the template based on a combination of a JIGSAW and a PYRAMID towards the ready-torun

script

Learning Flow

Phase

Individual phase

of Jigsaw

“Expert” phase of Jigsaw

Pyramid

level 1

Pyramid

level 2

“Jigsaw” phase of

Jigsaw

Group characteristics Task and supporting resources

Initial groups: pair of students (at least 2

students). There must be the same number

(approximately) of pairs working on each

of the three topics.

Half of the pairs that have worked on the

same topic form a group at this first

Pyramid level.

All pairs with the same topic.

Three pairs (or four if necessary) with

5.5.3 Pyramid-based paper discussion

145

- Work on one particular topic of the subject

"Use of ICT Resources in Education". The

resources needed to perform the activity are

available in Synergeia. Each pair should

create a conceptual map regarding their topic.

Employ a template and the conceptual map

tool of Synergeia, and upload the resulting

document to Synergeia.

Compare their conceptual maps. (Note that the

conceptual maps are all available in

Synergeia). You can use a chat. Create a draft

document according to a provided template,

and upload the document to Synergeia.

Compare and discuss the draft documents

generated in the previous phase (you can use a

chat).

Create an agreed report according to the same

previous template, and upload the document

to Synergeia.

Discuss using the reports created previously,

which are in Synergeia (you can use a chat).

different topics form a “Jigsaw Group” Create a global final report according to what

has been discussed (a template is provided).

Figure 5.20 Authoring the NNTT script with Collage

The context of the example could be a course about “technical specifications for interoperable

learning technology”. The script specifies a learning situation in which the participants read a paper

titled “The role of teachers in editing and authoring Units of Learning using IMS Learning Design”


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

(Griffiths et al., 2005) and (collaboratively) discuss about the contents of the paper. They have to

achieve gradual consensus about good solutions to address the identified challenges regarding the

way in which teachers can author UoLs using LD. The example is designed for one synchronous

session of 2 hours. However, we do not know the number of students that will attend this session at

design time. The script is structured according to the PYRAMID CLFP and is particularized as

indicated in Table 5.4.

Learning Flow

Phase

Table 5.4 Refining the template based on the PYRAMID towards the ready-to-run UoL

Pyramid level 1 (Individual activity)

Pyramid level 2

Pyramid level 3

5.5.4 Job interview simulation

Group characteristics Task and supporting resources

Each group of the second Pyramid level

comprises from 3 to 6 students. (Depending

on the participants who attend the session,

the script will be instantiated with a concrete

number of groups, which in turn will be

populated with (from 3 to 6) students.)

All the groups of the second Pyramid level

form a single group at this level.

146

Read the paper to grasp the main ideas. A

synchronous conference service is available so

that each student can ask questions to the

teacher.

Discuss your opinions about the paper.

Extract common conclusions about the paper.

Each group presents their conclusions achieved

in the previous phase.

Finally, agree on common conclusions about

the paper (and try to achieve consensus about

good solutions to address the challenges

regarding the way in which teachers can author

Units of Learning using LD).

The objectives of the “Job interview simulation” script, which is collaborative and blended, are

related to the development of the social skills required in job interviews. The script is based on the

SIMULATION (Pattern 1.5 of Appendix A). This script describes a situation in which two students

play the role of “interviewers” and other two students play the role of “candidates”. One of the

interviewers and one of the candidates train a simulation of an interview for a “developer vacancy”.

At the same time, the other interviewer and candidate train a simulation of a job interview for a

“salesman vacancy”. Previously, each participant reads general information about job interviews

and prepares their role according to their assigned interview. After each pair trains their simulation,

they perform it, so that the other pair can observe the role play. Finally, the teacher moderates a

debate about the social skills required in this type of situations.

5.5.5 STA (Advanced Telematic Systems)

The STA script is applied in a graduate course on research methodologies at the University of

Valladolid. In the STA script, the students should try to propose a research question on a complex

multidisciplinary field that involves several keywords. In order to achieve this goal, JIGSAW is


DESIGN PROCESS FOR THE GENERATION OF LD SCRIPTS REUSING CLFPS

employed, where students in the expert group study and propose research questions related to some

of the keywords. Then, students in the “Jigsaw groups” try to merge the research questions.

5.6 Discussion: towards more general approaches

Two of the strengths of our approach consist in the use of graphical representations that are

intuitive and the promotion of interoperability since the resulting scripts are LD compliant.

However, these strengths at the same time are limitations of the approach. First, the use of graphical

representations that strongly depends on the CLFPs implies that adding new CLFP-based templates

or other types of (pattern-based) reusable solutions is a demanding task. Second, this task is even

more challenging if the reusable elements are not represented with LD. This section discusses

potential solutions towards a more general pattern-based design process for the creation of scripts.

5.6.1 Using more general visual representations

There are currently only six patterns incorporated in Collage. However, since they can be

creatively combined in order to create new richer learning flows, it offers some degree of flexibility.

As categorized in (Botturi et al., 2006), Collage provides generative patterns which can then

communicate with a more finalist language (LD) using the graphical representations of the patterns’

solutions. However, one of the limitations of Collage is that the addition of new templates based on

other patterns is laborious: each template has its own representation and includes pattern-specific

functions. To overcome these drawbacks, it would be interesting to study the possibility of using

visual languages for learning design, such as E2ML (Botturi, 2006) or the others approaches

presented in (Botturi & Stubbs, in press), to graphically represent patterns’ solutions. This may not

only facilitate the addition of new patterns (using the same graphical notation) to Collage, but it

may also afford more flexible editing possibilities of the learning flow (e.g., using drag-and-drop

elements of the visual language that can be added or removed from the templates).

Nevertheless, this topic deserves devoted research that investigates the trade offs between

intuitiveness and generality of the different graphical approaches.

5.6.2 Assembling learning design solutions formalized with different languages

The create-by-reuse framework proposed in section 5.2 envisages an interesting challenge

which may be considered in future versions of the proposed design process: the involvement of

learning design solutions formalized with different languages (e.g. the formalisms used in LAMS

and IMS QTI for questionnaires) so that they can be assembled in order to generate an LDcompliant

UoL (or eventually another type of UoLs using a different formalism). Therefore, the

problem that emerging design processes should address is not trivial. Not only do we need to

147


A PATTERN-BASED DESIGN PROCESS FOR CSCL SCRIPTS REPRESENTED WITH IMS LD

assemble and refine learning design solutions at different level of granularity and completeness but

we also need to transform formalizations (Hernández-Leo et al., 2006a; Dodero et al., 2007). These

ideas are illustrated with the following ad-hoc design process example, which is represented in

Figure 5.21.

Collage

Templates

QTI

Learning

Objects

LAMS

Activities

IMS LD

templates

QTI

building

blocks

LAMS

building

blocks

n

Assemble