1 / 40

Extending Moodle Across the Institution: Integration Strategies and Methods

Extending Moodle Across the Institution: Integration Strategies and Methods. Academic Technology, San Francisco State University. Andrew Roderick, Technology Development Manager Clifford Tham, MOODLE Developer Daniel Koepke, Software Developer. Workshop Agenda. Introduction

jessicaboyd
Download Presentation

Extending Moodle Across the Institution: Integration Strategies and Methods

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Extending Moodle Across the Institution: Integration Strategies and Methods Academic Technology, San Francisco State University Andrew Roderick, Technology Development Manager Clifford Tham, MOODLE Developer Daniel Koepke, Software Developer

  2. Workshop Agenda • Introduction • What Is Integration? Worldview • Case Study – Lecture Capture • Integration in Practice • Open Discussion, Questions, Comments

  3. About Us • San Francisco State • 1,500 faculty and 30,000 students • Commuter campus • Moodle since 2007 • Branded as iLearn; customized • Moodle 1.9.9 in Fall • 2,400 courses

  4. Who Are You • Your name • Your institution • Your role • Why are you here? • Favorite classic rock song?

  5. Why Integrate?

  6. An Integrated World • Blackboard buys Elluminate, Wimba • Moodlerooms releases Joule • API’s now a selling point • Key purchasing decision (“will it integrate with my existing environment”) • “Should I be integrating?” is now“What should I integrate?”

  7. Our Worldview • Choose the best options for our users • Build, buy, and/or download • Focused is better than monolithic • Experience, functionality matter most • Is it nice to use? • Does it do what people need it to do?

  8. Design the Experience • Understand your environment • Think about the gestalt • Pick your pieces carefully • Don’t just choose what’s available, easy • Don’t let technology dictate the choices • Take control of your design!

  9. Do Not Want!

  10. Integration • Wire together the pieces we have • Loose coupling • Choose what to expose, what to hide • Façades hide seams between systems • Not all or nothing: might make it seamless for students, but show the software to faculty

  11. Integration with the LMS • Bring content and functionality into the learning context • Courses • Activities • Not just about delivery of static content • Expose content’s functionality • Expose content to LMS’s functionality

  12. How About A Case Study?

  13. Case Study – CourseStream • How it works • Faculty presents lecture • Lecture is processed into multiple formats (rich media (flash), video only, audio only) • Faculty distributes content

  14. Case Study – CourseStream • Workflow w/o Integration • Faculty login to Echo360 system • Copy links • Distribute – via email, web page • Other options include rss, publisher plugins

  15. Case Study – CourseStream • Integrate into LMS (Moodle) • Users already using • Simplify faculty workflow • Hide multiple systems faculty don’t need to know about • Automate distribution

  16. Case Study – CourseStream • Echo360’s Moodle Publisher Plugin • Publishes to Moodle Calendar • Out of course context • Out of faculty’s control • Calendar may not be heavily used component

  17. Case Study – CourseStream • Integrate into Moodle • Put it further into context of the learning experience • Give control back to faculty • Allow faculty to integrate into teaching • Focus on teaching and course design instead of technical details

  18. Case Study – CourseStream • SF State’s Echo360 / Moodle Integration • Resource • Block • Management Component • Administrative Component

  19. Case Study – CourseStream • Use Case • Place in topic w/ other resources • Place all in one topic • Block, populating auto • Block, by topic • Reuse

  20. Case Study – CourseStream • Removed faculty’s necessity to acknowledge the existence of echo360 server • Simplified Workflow • Still allowed faculty flexibility • Faculty can focus on course design

  21. Design of Integration Resource – Method of distributing content (PDFs, MP3, DOCs, Web Page, Text Page) Blocks – Method of delivery content, activities secondary to course materials Management Interface – Method of distributing content (PDFs, MP3, DOCs, Web Page, Text Page)

  22. Resource Seamlessly integrate lectures into course design using the Echo360 Resource

  23. Integrate lectures into course design By topic/theme By chronology By course materials Quizzes, Lectures, Assignments, etc Resource

  24. Block Group several lecture captures together and present as one unit with the Echo360 block

  25. Creating / Editing a Block OR, Choose which lectures to include in the block Select format to distribute to students Choose the order in which lectures appear for students Display all lectures from one Echo360 course

  26. Block • Group • Reuse / Repurpose • Contextualize

  27. Managing Your Lectures View all the captured lectures available to your Moodle course

  28. Managing Your Lectures View and manage the captures available for your Moodle course View list of lectures available for use Rename lecture captures View lecture capture metadata Preview lecture format without placing in course

  29. Managing Your Lectures • Preview lecture without placing in course • Lists lectures that are available for use • Rename captures • View capture metadata

  30. Integration is like Watercolor

  31. Integration in Practice • What to integrate? • How to integrate? • Application readiness • Moodle readiness

  32. What to Integrate? • Prioritize real, known needs • Improve the things people already do • Software people already use • Why does it make sense… • In the LMS context? • In your environment? • To your users?

  33. What to integrate? Getting Input. • Needs assessments/task analysis • Governance • Usage/Impact • Applicability to teaching and learning tasks

  34. How to Integrate? • Link to or embed • Content, functionality, interactivity • Many integrations will mix-and-match • Façade for display, common functionality • Jump into application for more • Where does it belong in Moodle? • Resources, blocks, activities, etc.

  35. Application Readiness • What does the application provide? • Application Programmer’s Interface (API) • Syndication (Atom/RSS) • IFRAME • Link • Authentication/authorization

  36. Moodle Readiness • Moodle provides most extensibility with • Blocks • Resources • You may need to change core code to handle more advanced cases • Moodle 2.0 changes things up • Repository API, more

  37. Taming Moodle • Option 1 • Limit changes to modules, blocks • Avoid changes to core code, work around obstacles • Option 2 • Make wholesale changes to Moodle • Re-architect many underlying structures • Best Option • Minimize changes to core code, but change what is necessary for your campus • Balance between changes to core code and foregoing usability, maintainability

  38. What to Turn Off in Moodle

  39. Integration examples • Available API or Custom (roll your own) • SIS, Authentication, other institutional data • Syndication • Repository • Application

  40. How Much Is Too Much? • Issues to consider: • Interface • Multiple integrations doing the same thing (ex: repository + library) • Technical (scalability, performance) • Security

More Related