GLUE!: An architecture for the integration of external tools in Virtual Learning Environments UNIVERSITY OF VALLADOLID GSI...
Outline <ul><li>Introduction </li></ul><ul><li>Integration problem </li></ul><ul><li>Analysis of existing proposals </li><...
Outline <ul><li>Introduction </li></ul><ul><li>Integration problem </li></ul><ul><li>Analysis of existing proposals </li><...
VLEs: Virtual Learning Environments <ul><li>  VLE, LMS or CMS ? </li></ul>
VLEs: Virtual Learning Environments <ul><li>Limitation => Number of tools included in their distribution. </li></ul>
VLEs: Virtual Learning Environments <ul><li>Limitation => Number of tools included in their distribution. </li></ul>
What if… <ul><li>…  I need other tools? </li></ul><ul><ul><li>Image processor </li></ul></ul><ul><ul><li>Presentation tool...
Solution regarding the VLE <ul><li>Design and develop a new VLE that may include such tools </li></ul><ul><ul><ul><li>e.g....
Solution regarding tools <ul><li>Design and develop tools for a specific VLE distribution </li></ul><ul><ul><li>Developmen...
Integration of external tools in VLEs +
Outline <ul><li>Introduction </li></ul><ul><li>Integration problem </li></ul><ul><li>Analysis of existing proposals </li><...
Integration problem (I) <ul><li>m  VLEs and  n  tools </li></ul><ul><li>i   VLE contracts and  j  tool contracts.  [Ghigli...
Integration problem (II) <ul><li>The integration problem is not new at all. </li></ul><ul><ul><li>Renewed research interes...
Outline <ul><li>Introduction </li></ul><ul><li>Integration problem </li></ul><ul><li>Analysis of existing proposals </li><...
Moodle modules and specific extensions for VLEs <ul><li>The integration agent makes the whole development effort. </li></u...
Defining tool contracts <ul><li>IMS Tool Interoperability Guidelines </li></ul><ul><ul><li>Loose integration. </li></ul></...
Generic architectures <ul><li>[Fontela:09]. “ Towards a Generalized Architecture for the Integration of Tools in LMSs” </l...
Outline <ul><li>Introduction </li></ul><ul><li>Integration problem </li></ul><ul><li>Analysis of existing proposals </li><...
Motivation <ul><li>GLUE! (Group Learning Uniform Environment) </li></ul><ul><ul><li>Architecture for the integration of ex...
GLUE! In Moodle (Educator interface)
GLUE! In LAMS (Educator interface)
GLUE! Architecture
GLUE! main interactions (requests)
GLUE! Main technological decisions <ul><li>REST interfaces </li></ul><ul><ul><li>Simple and easy to develop.  </li></ul></...
Outline <ul><li>Introduction </li></ul><ul><li>Integration problem </li></ul><ul><li>Analysis of existing proposals </li><...
Current prototype Web content
Configuring the Moodle adaptor (administrator) <ul><li>1.- Configure the URL to connect to the GLUElet Manager. </li></ul>
Creating and configuring instances (educator) <ul><li>1.- Select the “GLUElet” activity </li></ul>
Creating and configuring instances (educator) <ul><li>2.- Select the external tool </li></ul>
Creating and configuring instances (educator) <ul><li>3.- Select the configuration of groups/groupings </li></ul>
Creating and configuring instances (educator) <ul><li>4.- Configure this tool for each group created in Moodle </li></ul>
Creating and configuring instances (educator) <ul><li>5.- Visualize the instances for each group </li></ul>
Using the external tools (students) <ul><li>1.- Natter chat instance using the Moodle groups </li></ul>
Using the external tools (students) <ul><li>2.- An instance of Google Spreadsheet for all the students </li></ul>
Using the external tools (students) <ul><li>3.- Dabbleboard shared whiteboard and chat for each group </li></ul>
Using the external tools (students) <ul><li>3.- Media Wiki page for each group </li></ul>
Outline <ul><li>Introduction </li></ul><ul><li>Integration problem </li></ul><ul><li>Analysis of existing proposals </li><...
Conclusions <ul><li>Integration problem </li></ul><ul><ul><li>Which is the  development effort  ? </li></ul></ul><ul><ul><...
Future lines <ul><li>Security </li></ul><ul><ul><li>Currently credentials are manage in the internal registry. </li></ul><...
Links with other integration proposals <ul><li>Apache Wookie Server </li></ul><ul><ul><li>Integration of W3C widgets </li>...
Outline <ul><li>Introduction </li></ul><ul><li>Integration problem </li></ul><ul><li>Analysis of existing proposals </li><...
References <ul><li>[Alario-Hoyos:10] C. Alario-Hoyos, J.I. Asensio-Pérez, M.L. Bote-Lorenzo, E. Gómez-Sánchez, G. Vega-Gor...
References <ul><li>[Livingstone:08] D. Livingstone and J. Kemp . Integrating Web-Based and 3D Learning Environments: Secon...
GLUE!: An architecture for the integration of external tools in Virtual Learning Environments UNIVERSITY OF VALLADOLID GSI...
Upcoming SlideShare
Loading in …5
×

1. (slide share)glue-integrationofexternaltools

1,193 views

Published on

GLUE! Architecture for the integration of external tools in Virtual Learning Environments. This presentation contains the description of the integration problem, analyzing previous works, the GLUE! architecture, and the current prototype

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,193
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • The outline of this presentation includes: -Introduction. -The description of the integration problem -Brief analysis of existing proposals -GLUE! Architecture. That is our proposal to integrate external tools developed with multiple technologies in VLEs. -Prototype including Demonstration -Conclusions and future work -References
  • So, let’s start with the introduction
  • -Virtual Learning Environments, Learning Management Systems, Content Management Systems. -For this presentation that is not a relevant issue. -For this presentation just think in a VLE as a software platform or system that may support the design, enactment, and evaluation of learning situations by including a set of tools. -Some examples of VLEs according to this definition are Moodle, LAMS, .LRN, Sakai, Blackboard, MediaWiki, etc.
  • One of the main limitations of VLEs is the number of available tools that are included in their distributions to support learning situations. Moodle screenshot: - Chat - Forum - Multiple choice - Questionnaire - Wiki (collaborative text editor). - File system - Calendar … - and few more tools
  • LAMS includes more tools than a Moodle distribution LAMS (apart from the aforementioned in Moodle) ADDITIONALLY - Map tool - Mindmap - Notice board - Voting system - Spreadsheet tool
  • -Include other tools. I would like to design a learning situations including for instance… -Tools included in the VLE distribution do not like the educators or do not fit the requirements expected in a learning situation.
  • Gridcole and Pelican are two examples of PhD dissertations that have designed a VLE to include tools developed as grid services and web services respectively. More specifically, Gridcole has more than five years and was presented by one of my advisors to defend the integration of loosely-coupled external tools in learning situations. However these approaches: -Entail a high design and development effort. -Besides, requirements imposed by the VLE have to be accepted by tool providers. In Gridcole, such requirements did not become mainstream and the number of tools to be integrated was reduced. -There are several VLEs in the market that are already used in education (Moodle, LAMS, …) -A final drawback, is that educators that are used to a VLE may be reluctant to change to another one despite expected benefit; the reasons: learning effort, adaptation period; institutions promoting the use of a specific VLE. For instance, my university promotes the use of Moodle as a VLE in a Virtual Campus
  • Design and develop more tools for a specific VLE distribution with the functionality I do not have or do not fit my requirements -Development effort to use a new tool in just a VLE -The most important issues is that there are lots of tools in the web that educators are already using in their classes Examples: Google Docs, Wikipedia, Picasa, Delicious, Dabbleboard,…
  • Example: Let’s take Moodle and Google Docs, and let’s try to imaging a Google Document as part of a Moodle activity Moodle. - Courses - Learning design (quite limited but it is a learning design) - Some tools in the distribution - Manage roles and groups. Google Docs - External tool that can be used in a Moodle activity as a collaborative text editor allowing the educator to review the different versions of a document… It would be also great if groups and users defined in Moodle will be in Google Docs.
  • First, let’s try to offer a global vision of the integration problem 1 M VLEs with different features, APIs and architectures. N tools developed for a varied range of purposes, with different technologies and interfaces. 2 From different VLE and tool providers 3 Every tool and every VLE may impose different conditions to be integrated These conditions are defined as part of the VLE and tool CONTRACTS A contract can be defined as the set of expected behaviors, APIs, URL that a tool or VLE needs to implement to accomplish their integration. Each tool can offer one or more contracts that can be specific for one single tool or offered by several ones. The same can be said for VLEs but they are most frequently specific. 4 The difference between contracts is the integration cost. 5 Due to the technological and functional heterogeneity between tools and VLEs this cost is directly related with a software development effort. 6 This effort should be assumed by the integration agents. They are anybody willing to accomplish the integration: for example the VLE provider, the tool provider or a third party. This agents normally expect a benefit in return: recognition, reputation, economical compensation, but behind this, is that people use this integration. Benefit in terms of community acceptance. 7 The higher benefit would be achieved by integrating the higher number of tools in the higher number of VLEs. This could imply a huge development effort that would not be worthwhile to be assumed by the integration agents. So, it is important to analyze several design issues when developing a solution for the integration problem OTHER THINGS THAT CAN BE INCLUDED IN 7 The higher the number of tools integrated in a VLE =&gt; the higher the number learning situations that can be performed =&gt; the higher the number of educators that will choose such VLE for their courses. However some educators may be reluctant to change the VLE they are accustomed, or some institutions may impose a specific VLE. Therefore the higher benefit will be achieved by the integration the higher number of tools in the higher number of VLEs
  • SOME ADDITIONAL COMMENTS The integration problem is not new at all. But, now there is a recent renewed interest due to two factors -The spreading use of VLEs -The spreading use of educational tools available on the web It is important to consider the lessons that can be learnt from the previous work And so, the paper identifies the main design issues and alternatives when dealing with the integration problem. This issues should be considered by VLE providers, tool providers or a third-party willing to accomplish the integration of tools in VLEs. And analyze the existing proposals This analysis should be useful for those developing new tools or VLEs but also for those trying to propose a solution for the integration of tools on VLEs.
  • Very brief analysis of existing proposals
  • Moodle modules or specific extensions such as Blackboard Building Blocks, MediaWiki extensions, LAMS modules… -The integration agent normally makes the whole development effort to integrate a specific tool in a specific VLE. -Drawback: This effort cannot normally be reused for any other tool or VLE. It is a specific integration. -Advantage: You can get a tighter integration between the tool and the VLE. -However, you can have a tighter integration, such as the one in the project Sloodle (that integrates Second Life in Moodle). -Another example can be Moodle Rooms that integrated Google Apps as an additional activity in Moodle. To do so, a domain account in Google Apps is necessary. -One more example is EduJudge project to integrate Questournament in Moodle. SLOODLE and MOODLEROOMS are third-party agents that want to integrate this tools. In the third example the tool provider assumes the development effort.
  • IMS Global Learning Consortium initiative Loose integration. Web service-oriented Generic architecture what normally means loose integration. This architecture is oriented to web services and includes several additional services.
  • They try to reduce the development effort. They are focused to different kind of tools. They allow only generic interactions. As a conclusion this architectures try to decrease the development effort of integration agents. The price to pay is a loose integration.
  • My research tries to propose an architecture that allows the integration of external tools developed with multiple technologies in different VLEs. This architecture has been inspired in the previous work of my group in the integration of loosely coupled services in VLE but also by your work with the integration of Widgets in learning systems. Some initial requirements: -Reducing the development effort that must be made by the integration agents to integrate several tools in several VLEs. -Increasing the expected benefit allowing the integration of several tools in several VLEs -Keeping the original functionality of VLEs with respect to CSCL situations: Groups and learning design if they are available in the VLE -Educators and student should watch the external tools as another VLE tool. -Easy to install in a VLE, just as another module or extension.
  • Just the idea. I can add an activity in Moodle called GLUElet that includes all the external tools that can be integrated.
  • Just the idea. I can add an activity in LAMS called GLUElet that includes all the external tools that can be integrated.
  • The architecture is composed mainly by three parts. -VLE ADAPTORS. *They provide an interface for the interaction of the educators and students with the GLUE! architecture. *This interface is embedded as part of the functionality of the VLEs. *These adaptors are equivalent to any module or extension of the VLE, so they do not modify any code in the original distribution of the VLE. *Due to the heterogeneity of VLEs, every VLE needs an adaptor *Their main functionality is to request the creation and configuration of tools instances to the next element of the architecture (GLUElet Manager) depending on the users/groups that compose an activity. It can also delete tool instances. *After the creation of the tool instances a reference that includes the VLE activity, the tool that is going to be used and the reference to the tool instance in the gluelet repository is stored in the ID REPOSITORY. This repository is just a new table in the internal VLE database. -GLUELET MANAGER *It stores the tools that can be integrated in the INTERNAL REGISTRY (database) and return them to the VLE adaptors when requested (when creating a new gluelet activity). *This REGISTRY contains information about the tool and about the tool adaptor that must be used. *When requested the GLUElet Manager contacts the tool adaptor to create or delete the tool instances. *The main functionality of the GLUElet Manager is to manage the tools instances. -IMPLEMENTATION MODEL ADAPTOR *This element is in charge of creating or deleting instances. *It also contains different configuration templates for each tool that will be requested from the VLE adaptors. *This element should know the interfaces and APIs of the tools. In this case, several tools may have the same interface (some Google Apps, widgets, etc.). So, one tool adaptor can be used for several tools. This is the reason for the name implementation model adaptor. *The main requirement for these adaptors is that they have to return a URL representing the tool instances for each educator/student. If the tool is not a web tool, this adaptor should wrap it in a web interface. The learning cycle in this architecture is the following. 1.- The educator creates a new activity and selects an external tool from the ones available in GLUE! 2a.- The educator configures the external tool following a configuration template contained in the implementation model adaptor. 2b.- The architecture creates instances depending on the users/groups in the activity 3.- After that the student performs a learning situation 4.- He can use the tool through the URL provided by the architecture. Finally the ideas behind the GLUE core and periphery is that GLUE core is something that we provide because it is mandatory for this to work, while periphery elements are those expected to be developed by third-parties. Of course we will provide some of these adaptors. -GLUElet Manager -Implementation model adaptors
  • GET tools from GLUElet Manager GET configuration from Implementation Model adaptor POST configuration from VLE adaptor GET instance from VLE adaptor DELETE instance from VLE adaptor
  • -GLUE has REST interfaces. VLE adaptors makes REST requests. GLUElet Manager receives REST requests and make REST requests, Implementation model adaptor receives REST request -Atom for data exchange format
  • We are currently developing a LAMS adaptor and planning a MediaWiki as VLE adaptor. Regarding the tools we have to prioritize the adaptors for the experiences that we want to carry out in the next course Adaptors (specially tool adaptors are expected to be developed by third-parties
  • SECURITY We need to provide a compromise solution for security OAUTH=&gt; But what about the tools that do not use OAuth =&gt; Two-legged Oauth (signing) or three-legged Oauth (delegating the authorization) =&gt; How to get the key and secret =&gt; Off-line like in Basic LTI?? Every tool can offer an authentication API with their own credentials. Another idea could be OpenID (if everybody would use OpenID) =&gt; Problem solved. Another idea keep credentials of different tools in an external server (LDAP) in the VLE (adaptor) associated to every VLE account (but you have to publish this credentials). PROTOTYPE Develop more VLE adaptors and implementation model adaptors. But they are expected to be developed by third-parties. VALIDATION Evaluation in real courses with real students. To measure the number of tools that can be integrated and the effort to develop a tool adaptor.
  • 1. (slide share)glue-integrationofexternaltools

    1. 1. GLUE!: An architecture for the integration of external tools in Virtual Learning Environments UNIVERSITY OF VALLADOLID GSIC/EMIC http://gsic.tel.uva.es Carlos Alario Hoyos July 1 st , 2010
    2. 2. Outline <ul><li>Introduction </li></ul><ul><li>Integration problem </li></ul><ul><li>Analysis of existing proposals </li></ul><ul><li>GLUE! </li></ul><ul><li>Prototype </li></ul><ul><li>Conclusions and future work </li></ul><ul><li>References </li></ul>
    3. 3. Outline <ul><li>Introduction </li></ul><ul><li>Integration problem </li></ul><ul><li>Analysis of existing proposals </li></ul><ul><li>GLUE! </li></ul><ul><li>Prototype </li></ul><ul><li>Conclusions and future work </li></ul><ul><li>References </li></ul>
    4. 4. VLEs: Virtual Learning Environments <ul><li> VLE, LMS or CMS ? </li></ul>
    5. 5. VLEs: Virtual Learning Environments <ul><li>Limitation => Number of tools included in their distribution. </li></ul>
    6. 6. VLEs: Virtual Learning Environments <ul><li>Limitation => Number of tools included in their distribution. </li></ul>
    7. 7. What if… <ul><li>… I need other tools? </li></ul><ul><ul><li>Image processor </li></ul></ul><ul><ul><li>Presentation tool </li></ul></ul><ul><ul><li>Shared whiteboard </li></ul></ul><ul><ul><li>Network simulator </li></ul></ul><ul><ul><li>… </li></ul></ul><ul><li>… the tools that are included in the VLE distribution do not fit the functionality required by the educators? </li></ul>
    8. 8. Solution regarding the VLE <ul><li>Design and develop a new VLE that may include such tools </li></ul><ul><ul><ul><li>e.g. Gridcole [Bote-Lorenzo:08] – Dissertation in 2005. </li></ul></ul></ul><ul><ul><ul><li>e.g. Pelican [Velez-Reyes:09] </li></ul></ul></ul><ul><ul><li>High effort. </li></ul></ul><ul><ul><li>Requirements have to be accepted by tool providers. </li></ul></ul><ul><ul><li>There are already many VLEs in the market. </li></ul></ul><ul><ul><li>Educators that are used to a VLE may be reluctant to change to another one. </li></ul></ul><ul><ul><ul><ul><li>Learning effort </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Adaptation period </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Institutions promoting the use of a specific VLE </li></ul></ul></ul></ul>
    9. 9. Solution regarding tools <ul><li>Design and develop tools for a specific VLE distribution </li></ul><ul><ul><li>Development effort just for a VLE. </li></ul></ul><ul><ul><li>There are lots of available tools in the web. </li></ul></ul><ul><ul><ul><ul><li>Mash-ups, web applications, web services, widgets, etc. </li></ul></ul></ul></ul>
    10. 10. Integration of external tools in VLEs +
    11. 11. Outline <ul><li>Introduction </li></ul><ul><li>Integration problem </li></ul><ul><li>Analysis of existing proposals </li></ul><ul><li>GLUE! </li></ul><ul><li>Prototype </li></ul><ul><li>Conclusions and future work </li></ul><ul><li>References </li></ul>
    12. 12. Integration problem (I) <ul><li>m VLEs and n tools </li></ul><ul><li>i VLE contracts and j tool contracts. [Ghiglione:07] </li></ul><ul><li>Integration cost => software development effort </li></ul><ul><li>Integration agents => benefit (community acceptance) </li></ul><ul><li>Design issues </li></ul>
    13. 13. Integration problem (II) <ul><li>The integration problem is not new at all. </li></ul><ul><ul><li>Renewed research interest due to the change of context: </li></ul></ul><ul><ul><ul><ul><li>Spreading use of VLEs. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Spreading use of educational tools available on the web. </li></ul></ul></ul></ul><ul><li>Lessons learnt: </li></ul><ul><ul><li>Identify the main design issues and the alternatives. [Alario-Hoyos:10] </li></ul></ul><ul><ul><ul><ul><ul><li>Integration partnerships </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Technological decisions </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Functional specificity </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Number of contracts offered </li></ul></ul></ul></ul></ul><ul><ul><li>Analyze the existing proposals. [Alario-Hoyos:10] </li></ul></ul>
    14. 14. Outline <ul><li>Introduction </li></ul><ul><li>Integration problem </li></ul><ul><li>Analysis of existing proposals </li></ul><ul><li>GLUE! </li></ul><ul><li>Prototype </li></ul><ul><li>Conclusions and future work </li></ul><ul><li>References </li></ul>
    15. 15. Moodle modules and specific extensions for VLEs <ul><li>The integration agent makes the whole development effort. </li></ul><ul><li>This effort cannot be reused for any other VLE or tool </li></ul><ul><li>Tighter integration </li></ul>[Livingstone:08] [http://www.moodlerooms.com/] [Regueras:09]
    16. 16. Defining tool contracts <ul><li>IMS Tool Interoperability Guidelines </li></ul><ul><ul><li>Loose integration. </li></ul></ul><ul><ul><li>Web service-oriented. </li></ul></ul><ul><ul><li>Current tools and VLEs do not follow these guidelines. </li></ul></ul><ul><li>Wookie Server </li></ul><ul><ul><li>Loose integration. </li></ul></ul><ul><ul><li>W3C Widgets. </li></ul></ul><ul><ul><li>Many simple tools will be following this contract. </li></ul></ul><ul><ul><li>But not all the tools are W3C widgets. </li></ul></ul>[http://www.imsglobal.org/ti/tiv1p0/imsti_guidev1p0.html] [Wilson:08]
    17. 17. Generic architectures <ul><li>[Fontela:09]. “ Towards a Generalized Architecture for the Integration of Tools in LMSs” </li></ul><ul><ul><li>Focused on web services </li></ul></ul><ul><li>[Asensio:08]. “ Adding mash-up based tailorability to VLEs for scripted Collaborative Learning.” </li></ul><ul><ul><li>Focused on web applications </li></ul></ul>
    18. 18. Outline <ul><li>Introduction </li></ul><ul><li>Integration problem </li></ul><ul><li>Analysis of existing proposals </li></ul><ul><li>GLUE! </li></ul><ul><li>Prototype </li></ul><ul><li>Conclusions and future work </li></ul><ul><li>References </li></ul>
    19. 19. Motivation <ul><li>GLUE! (Group Learning Uniform Environment) </li></ul><ul><ul><li>Architecture for the integration of external tools in different VLEs. </li></ul></ul><ul><ul><li>Requirements: </li></ul></ul><ul><ul><ul><li>Reduce to development effort for the integration agents. </li></ul></ul></ul><ul><ul><ul><ul><li>Simple architecture </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Loose integration with the tools </li></ul></ul></ul></ul><ul><ul><ul><li>Increase the expected benefit in terms of community acceptance. </li></ul></ul></ul><ul><ul><ul><ul><li>Integration of multiple tools in multiple VLEs </li></ul></ul></ul></ul><ul><ul><ul><li>Keep the core functionality of VLEs. </li></ul></ul></ul><ul><ul><ul><ul><li>Groups </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Creation of different tool instances. </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Different configurations for each tool instance </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><li>Learning design </li></ul></ul></ul></ul><ul><ul><ul><li>Educators and students watch the external tools as another VLE tool. </li></ul></ul></ul><ul><ul><ul><li>Easy to install in a VLE. </li></ul></ul></ul><ul><ul><ul><ul><li>Just as another module or extension </li></ul></ul></ul></ul>
    20. 20. GLUE! In Moodle (Educator interface)
    21. 21. GLUE! In LAMS (Educator interface)
    22. 22. GLUE! Architecture
    23. 23. GLUE! main interactions (requests)
    24. 24. GLUE! Main technological decisions <ul><li>REST interfaces </li></ul><ul><ul><li>Simple and easy to develop. </li></ul></ul><ul><ul><li>It is main part of the GLUE! contract. </li></ul></ul><ul><ul><li>There are several web tools that are already offering a REST interface. </li></ul></ul><ul><ul><li>There are several integration proposals using REST. [IMSLearningToolInteroprability] [Wilson:08] </li></ul></ul><ul><li>Atom </li></ul><ul><ul><li>Data exchange format. </li></ul></ul><ul><ul><li>Standardized and commonly-used in the Web. </li></ul></ul><ul><li>Xforms </li></ul><ul><ul><li>For the configuration templates. </li></ul></ul><ul><ul><li>Generic and supported by several browser (with plug-ins). </li></ul></ul><ul><li>Loose integration of tools </li></ul><ul><ul><li>Embedding tool instances in the VLE interface </li></ul></ul>
    25. 25. Outline <ul><li>Introduction </li></ul><ul><li>Integration problem </li></ul><ul><li>Analysis of existing proposals </li></ul><ul><li>GLUE! </li></ul><ul><li>Prototype </li></ul><ul><li>Conclusions and future work </li></ul><ul><li>References </li></ul>
    26. 26. Current prototype Web content
    27. 27. Configuring the Moodle adaptor (administrator) <ul><li>1.- Configure the URL to connect to the GLUElet Manager. </li></ul>
    28. 28. Creating and configuring instances (educator) <ul><li>1.- Select the “GLUElet” activity </li></ul>
    29. 29. Creating and configuring instances (educator) <ul><li>2.- Select the external tool </li></ul>
    30. 30. Creating and configuring instances (educator) <ul><li>3.- Select the configuration of groups/groupings </li></ul>
    31. 31. Creating and configuring instances (educator) <ul><li>4.- Configure this tool for each group created in Moodle </li></ul>
    32. 32. Creating and configuring instances (educator) <ul><li>5.- Visualize the instances for each group </li></ul>
    33. 33. Using the external tools (students) <ul><li>1.- Natter chat instance using the Moodle groups </li></ul>
    34. 34. Using the external tools (students) <ul><li>2.- An instance of Google Spreadsheet for all the students </li></ul>
    35. 35. Using the external tools (students) <ul><li>3.- Dabbleboard shared whiteboard and chat for each group </li></ul>
    36. 36. Using the external tools (students) <ul><li>3.- Media Wiki page for each group </li></ul>
    37. 37. Outline <ul><li>Introduction </li></ul><ul><li>Integration problem </li></ul><ul><li>Analysis of existing proposals </li></ul><ul><li>GLUE! </li></ul><ul><li>Prototype </li></ul><ul><li>Conclusions and future work </li></ul><ul><li>References </li></ul>
    38. 38. Conclusions <ul><li>Integration problem </li></ul><ul><ul><li>Which is the development effort ? </li></ul></ul><ul><ul><li>Which is the expected benefit ? </li></ul></ul><ul><ul><li>Is it worthwhile or not? </li></ul></ul><ul><li>GLUE! </li></ul><ul><ul><li>Architecture that allows the integration of external tool in VLEs reducing the development effort and increasing the expected benefit. </li></ul></ul><ul><ul><li>Simple contracts imposed to integration agents. </li></ul></ul><ul><ul><li>Main limitation: Loose integration </li></ul></ul>
    39. 39. Future lines <ul><li>Security </li></ul><ul><ul><li>Currently credentials are manage in the internal registry. </li></ul></ul><ul><ul><li>Institutional credentials. </li></ul></ul><ul><li>Prototype </li></ul><ul><ul><li>Develop more VLE adaptors (LAMS in progress). </li></ul></ul><ul><ul><li>Develop more Implementation model adaptors. </li></ul></ul><ul><li>Validation of the architecture </li></ul><ul><ul><li>Educational experiences. </li></ul></ul><ul><ul><li>Effort to develop a new adaptor. </li></ul></ul>
    40. 40. Links with other integration proposals <ul><li>Apache Wookie Server </li></ul><ul><ul><li>Integration of W3C widgets </li></ul></ul><ul><li>Knowledge about IMS Basic LTI </li></ul>[Wilson:10]
    41. 41. Outline <ul><li>Introduction </li></ul><ul><li>Integration problem </li></ul><ul><li>Analysis of existing proposals </li></ul><ul><li>GLUE! </li></ul><ul><li>Prototype </li></ul><ul><li>Conclusions and future work </li></ul><ul><li>References </li></ul>
    42. 42. References <ul><li>[Alario-Hoyos:10] C. Alario-Hoyos, J.I. Asensio-Pérez, M.L. Bote-Lorenzo, E. Gómez-Sánchez, G. Vega-Gorgojo, A. Ruiz-Calleja. Integration of external tools in Virtual Learning Environments: main design issues and alternatives. Proceedings of the ICALT 2010 (accepted for publication). July 2010. Sousse, Tunisia. </li></ul><ul><li>[Bote-Lorenzo:08] M.L. Bote-Lorenzo, E. Gómez-Sánchez, G. Vega-Gorgojo, Y.A. Dimitriadis, J.I. Asensio-Pérez, and I.M. Jorrín-Abellán. Gridcole: A tailorable grid service based system that supports scripted collaborative learning. Computers and Education, 51(1):155–172, 2008. </li></ul><ul><li>[Velez-Reyes:09] J. Vélez-Reyes. Pelican, a platform for the design and development of collaborative learning scenarios. Support for dynamic aspects . PhD thesis, UNED. Spain, 2009. </li></ul><ul><li>[Ghiglione:07] E. Ghiglione and J. Dalziel. LAMS “Tools Contract”. In TenCompetence Workshop. UPF. Barcelona, June 2007. http://www.tencompetence.org/files/Barcelona/presentations/session1/-Ghiglione.pdf . </li></ul><ul><li>[Wilson:08] Wilson, S. Sharples, P., Griffiths, D.: Extending IMS Learning Design services using Widgets: Initial findings and proposed architecture. Open Workshop on Current research on IMS-LD and Lifelong Competence Development Infrastructures, Barcelona, Spain, 2007. </li></ul>
    43. 43. References <ul><li>[Livingstone:08] D. Livingstone and J. Kemp . Integrating Web-Based and 3D Learning Environments: Second Life Meets Moodle . UPGRADE: The European Journal for the Informatics Professional, 9(3):8–14, 2008. </li></ul><ul><li>[Regueras:09] L.M. Regueras, E. Verdú, J.P. de Castro, M.A. Pérez, and M.J. Verdú. A Proposal of User Interface for a Distributed Asynchronous Remote Evaluation System: An Evolution of the QUESTOURnament Tool . In Proceedings of the ICALT 2009, pages 75–77, Riga, Latvia, 2009. </li></ul><ul><li>[Fontela:09] J. Fontenla, M. Caeiro, and M. Llamas. Towards a Generalized Architecture for the Integration of Tools in LMSs . International Journal of Emerging Technologies in Learning (iJET), 4:6–11, 2009. </li></ul><ul><li>[Asensio:08] J.I. Asensio-Pérez, M.L. Bote-Lorenzo, G. Vega-Gorgojo, Y. Dimitriadis, E. Gómez-Sánchez, and E.D. Villasclaras-Fernández. Adding mash-up based tailorability to VLEs for scripted Collaborative Learning. In First International Workshop on Mashup Personal Learning Environments, pages 14–17. Maastricht, The Netherlands, September 2008. </li></ul>
    44. 44. GLUE!: An architecture for the integration of external tools in Virtual Learning Environments UNIVERSITY OF VALLADOLID GSIC/EMIC http://gsic.tel.uva.es Carlos Alario Hoyos July 1 st , 2010

    ×