Duke's eLearning Roadmap and the Sakai Transition


Published on

Presentation for JasigSakai2012. Session description as follows: Duke's move from Blackboard to Sakai involves much more than simply planning and executing a mass migration: it serves as a key step in Duke's larger eLearning strategy which hopes to shift the focus away from the LMS as a one-point solution for all eLearning needs, and instead leverage the LMS as an integration point for a suite of available Duke and non-Duke tools.

Participants attending the session will be better able to assess and plan similar transitions or implementations. Through a review of Duke's experiences and lessons learned, participants will be able to adapt successful models to their own campus culture and manage priorities to better align their projects with broader institutional goals.

Published in: Education, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Bb - about 1600-1700 active courses each semester
  • Flexibility: open source = can be coded, developed for, changedOptions: several vendors and support unitsCommunity: several peer institutions: Stanford, Yale, Columbia, Rice, UNCGrowing Global: Bb licensing was per FTE - $$$ whenever we need to add more people; Understanding the constraints of the license for who we wanted to add was not clear
  • Initial experience with Sakai; some of the feedback “tainted” by manual management of roster, lack of integration with SISS; sorting based on email accounts instead of last name,etcFindings from UNC pilot:Spring 201111 faculty, 11 coursesFeedback and survey results were favorable. Most issues with integration/logins, etc.
  • We decided to do this transition in 1 year. (Feedback from other schools showed that faculty and students disliked having parallel systems running for too long).Limited Phase 1 in Fall 2011. Even with only 200 faculty, Phase 1 ended up affecting nearly 5000 students.Choosing faculty for a limited releaseData from surveys -using feedback to improve support and SakaiLooked for power users, faculty with experience in Bb that had tests, quizzes, assignments, used tools. Basically – getting the people that would be hardest to please/move onboard earliest – and using their feedback to support changes and improvements
  • Students responded favorably (note Spring comparison is to student results from Spring pilot on UNC system). student n=400
  • Sample from student response. Key difference with Sakai - Bb didn’t have a ‘schedule’ tool at all.
  • Faculty response - tools mostly meeting their needs.Noted pain points: blog and wiki were inferior to Bb tools (we used Learning Objects blog and wiki tools in Bb). SAMigo (tests&quizzes) was a big shift for users. Lots of issues, re-learning, etc.
  • Migration of Bb content - what migrates is outlined on the support sitePart of the strategy - as requested by faculty groups. Bring over last 4 years (starting with F2007) of their stuff. We brought over everything up to Summer 2011. Lines up with data retention policy.Migration is not perfect - we’ll discuss later
  • Phase 2 - open to all – started much broader communication push(borrowed the ‘checklist’ idea from UNC-CH)Reiterate these three things as much as possible:Change is coming and whenFaculty have to take actionThere is help and where to get it
  • Also – 1155 Sakai Project sites since we rolled them out in Nov 2011During the first open semester, over half of courses now taught in Sakai. LMS use up overall – half as much in Bb)
  • Looking to Summer – we shut Bb off on June 30th. Lingering question: what happens with users who didn’t move to Sakai in the Spring?
  • We benefited from two vendors working together.Uniconhandled aspects of planning and key integrations (ex: SISS) plus developments, and Longsight handled hosting and support.Working with vendors allowed us to gain knowledge quickly without spending time researching, re-training staff, and setting up new systems. This was crucial to allowing us to focus more on the migration and faculty training efforts.
  • Our core challenge working with vendors: coordination. We heavily relied on our own internal project managers to keep up with vendor communications, and to help make sure all Duke staff involved in the efforts understood proper escalation channels, responsible parties, etc.
  • Looking at an integration holistically:for example: understanding the relationship between site title, site id, roster connections, APIs, external integration calls, and SISS identifiers for sitesConsider whether/how to do source code reviews, load testing, checking for memory links, in addition to the criticality of functional checking. Who does these functions? At what cost?You don’t always have the resources to do full regression – so what are the areas that could be affected.
  • *see next two slides
  • Integrating Duke Toolkits was an essential part of the eLearning strategy moving forward. Using Toolkits, we can manage groups and access to several Duke provided/supported tools. Tech note: Toolkits is based on Grouper.
  • Toolkits can be accessed via Sakai through Site Info > Add Participants. Toolkits opens in an iFrame. Course instructors and project site managers can look up and add Duke users, add guests (using Open ID – yahoo, gmail, aol, etc), or batch add both Duke and non-Duke users. Mapping roles between Sakai, WordPress, Confluence and other tools has proven to be somewhat complicated.
  • We had to stage migrations of Bb content at key times. Weperformed a ‘mini-migration’ of all F2007-S2011 content for our 200 ‘Phase 1’ faculty. This gave us a chance to test the import process at scale.We staggered imports for concurrent semesters as we went along. We also had to decide on ideal timing for migrating Bb ‘ORG’ sites to Sakai Project Sites.
  • We kept terms organized – even with live Sakai semesters (ex: Fall 2011 for Bb migrated and live Sakai courses)Communication issues (Please check your content from the move!)Large files tended to fail
  • We followed a shared plan. Updated monthly so the whole team knew what had been communicated and to whom.
  • Change your gateway! We ended up creating a new HTML page linking to our support materials, pulling in multiple FAQs from our support pages, and linking to Sakai.
  • This is a page from our support site. Keep important information about the transition readily available and linkable. If administrators, faculty, or student groups ask – provide links for all info. Update as much as possible – at least after every milestone.
  • We added countdown timers in various places. The main summary for instructors and…
  • …we also added countdown timers and announcements in Blackboard itself. We also added information and links about the transition directly into the course template for the Fall and Spring semesters (during the transition) telling faculty and students that the change was coming.
  • Monthly updates on the CIT blog tracked milestones, made formal announcements, and were used for email newsletter content.
  • Try to base communication on data (newsletter stats, Bb usage stats, course creations)Update the university on the progress (Sakai Updates monthly, posting reports)
  • Sometimes the best approach is the simplest. We ended up refining the message (from ‘Sakai is here!’ to ‘Blackboard – Gone Forever’ to try to ramp up the immediacy of the move).We put up posters, sent out postcards and even affixed labels to coffee sleeves with the simple message: “All Blackboard sites – Gone Forever!”
  • We put up posters, sent out postcards and even affixed labels to coffee sleeves with the simple message: “All Blackboard sites – Gone Forever!”
  • Hardest part was training the ‘trainers’ (instructional technologists,etc) before we knew enough about how Sakai worked, would function, and even before integration and tools decisions were finalized.Training mostly took on two forms: formal workshops and drop-in office hoursNOTE: Bye Bye Blackboard was a special series we only offered in the Spring specifically for those wanting more help migrating content, saving Bb data, etc.
  • Sakai built-in documentation is a great start - but hard to update and often not written for your particular audience (not to mention tool names change, etc).Needed a separate place to update and maintain docs, instructions, videos, support info http://support.sakai.duke.eduUsing a blog technology (like WP) makes it possible to quickly add FAQs and documentation ---being responsive to needs. Whenever possible have support people write – or at least draft- the documentation since they’re answering the questions anyway (in our case, our Sakai Instructional Designer and several other CIT consultants wrote the bulk of the FAQs, guides and examples).
  • Sakai built-in documentation is a great start - but hard to update and often not written for your particular audience (not to mention tool names change, etc).Needed a separate place to update and maintain docs, instructions, videos, support info http://support.sakai.duke.eduUsing a blog technology (like WP) makes it possible to quickly add FAQs and documentation ---being responsive to needs. Whenever possible have support people write – or at least draft- the documentation since they’re answering the questions anyway (in our case, our Sakai Instructional Designer and several other CIT consultants wrote the bulk of the FAQs, guides and examples).
  • OIT = Office of Information Technology CIT = Center for Instructional TechnologyBb support - OIT Service Desk – first line of support; Teaching/Learning = Tier 2 CIT; administration and technical = Tier 3 (CIT+OIT)Inst. Designer - Helped ease CIT into supporting role, answering questions, writing documentation.
  • Open Source: Set expectations. Educate your users. Not everything can be – or should be –tweaked and changed overnight.
  • Duke's eLearning Roadmap and the Sakai Transition

    1. 1. Shawn Miller, Duke University Neal Caidin, Duke University Ed Gomes, Duke University June 10-15, 2012Growing Community;Growing Possibilities
    2. 2. Charting Duke’s AcademicTechnology Landscape 2012 Jasig Sakai Conference 2
    3. 3.  Who ◦ Technical Working Group ◦ Functional Working Group ◦ Faculty, staff, students 2012 Jasig Sakai Conference 3
    4. 4.  Approach ◦ Faculty input – focus groups, teams ◦ Identify and create use cases ◦ Environmental scan – what are other schools doing, why? ◦ Detailed analysis – functional comparisons; technical documentation and resource needs; costs 2012 Jasig Sakai Conference 4
    5. 5.  Duke’s strategic priorities ◦ Internationalization ◦ Knowledge in the Service of Society ◦ Interdisciplinarity ◦ Collaboration and Connection 2012 Jasig Sakai Conference 5
    6. 6. 2012 Jasig Sakai Conference 6
    7. 7.  Central component – most heavily used system other than email and SISS Gateway to other systems License with Blackboard coming up for renewal The one technology that most faculty used (even for non-teaching related tasks) 2012 Jasig Sakai Conference 7
    8. 8. 1999 2012 2012 Jasig Sakai Conference 8
    9. 9.  Flexibility Options Community Global 2012 Jasig Sakai Conference 9
    10. 10. Goals and Phases 2012 Jasig Sakai Conference 10
    11. 11. 2012 Jasig Sakai Conference 11
    12. 12. 200 faculty700 ‘staff’5000 students 2012 Jasig Sakai Conference 12
    13. 13. 2012 Jasig Sakai Conference 13
    14. 14. “The schedule is awesome! One of myprofessors just loads everythingneeded for the day onto theschedule ‐ lecture notes, links toreadings, things that are due, etc. Itmakes the site very user‐friendly.” – Nicholas School student 2012 Jasig Sakai Conference 14
    15. 15. 2012 Jasig Sakai Conference 15
    16. 16.  23,000 Bb Course Sites migrated by the end of Fall 2011 2012 Jasig Sakai Conference 16
    17. 17. 2012 Jasig Sakai Conference 17
    18. 18. Active LMS Coursesites (unique) Spring 2011 vs. 20121600 1353140012001000 845 831 800 600 400 200 0 Bb Spring 2011 Bb Spring 2012 Sakai Spring 2012 2012 Jasig Sakai Conference 18
    19. 19. June 10-15, 2012Growing Community;Growing Possibilities
    20. 20. Organizing a transition effort 2012 Jasig Sakai Conference 20
    21. 21.  Organize teams to address different aspects of the migration Teams reported to a larger Duke Sakai team comprised of members of all sub-teams Sponsors: executive group overseeing the project address issues of scope, budget and high level communications Members of teams comprised of staff from different units 2012 Jasig Sakai Conference 21
    22. 22.  Technical & Hosting Strategy Integrations Migration Planning Communications Training & Documentation Support Model Governance 2012 Jasig Sakai Conference 22
    23. 23. Technical & Hosting Strategy 2012 Jasig Sakai Conference 23
    24. 24.  New Partnerships Bring New Opportunities... 2012 Jasig Sakai Conference 24
    25. 25.  …and New Challenges 2012 Jasig Sakai Conference 25
    26. 26.  You still need local staff: ◦ Research Sakai community resources (Jira, Confluence, listservs) ◦ Troubleshoot, identify and communicate issues to vendors ◦ Design, test and approve fixes and developments ◦ Define roles and permissions ◦ Manage roster and integration issues 2012 Jasig Sakai Conference 26
    27. 27. Integrations 2012 Jasig Sakai Conference 27
    28. 28.  Looking at the integrations more holistically may have been beneficial. Involving the right business and technical people in integrations Testing is critical. 2012 Jasig Sakai Conference 28
    29. 29.  Kaltura media gallery Bb Parity ◦ Wimba voice tools using Basic LTI ◦ Ereserves ◦ Respondus LockDownBrowser ◦ Export Official Grades to PeopleSoft ◦ Eliminated some integrations (Library Guides) Finding Post’em useful in some cases SISS, Shib, LDAP Toolkits* 2012 Jasig Sakai Conference 29
    30. 30. 2012 Jasig Sakai Conference 30
    31. 31. 2012 Jasig Sakai Conference 31
    32. 32. Migration Planning 2012 Jasig Sakai Conference 32
    33. 33. 2012 Jasig Sakai Conference 33
    34. 34.  Last 4 years of Bb content Worked with Longsight to use existing Bb-Sakai import tool Multiple modifications to import tool code When is the quality of the migrated content “good enough”? Also employed workarounds (bFree, WebDav) . Size of archives, a number of sites over a gig Total # of sites migrated – over 28,000 2012 Jasig Sakai Conference 34
    35. 35. Communication 2012 Jasig Sakai Conference 35
    36. 36. 2012 Jasig Sakai Conference 36
    37. 37. 2012 Jasig Sakai Conference 37
    38. 38. 2012 Jasig Sakai Conference 38
    39. 39. 2012 Jasig Sakai Conference 39
    40. 40. 2012 Jasig Sakai Conference 40
    41. 41. 2012 Jasig Sakai Conference 41
    42. 42. 2012 Jasig Sakai Conference 42
    43. 43. 2012 Jasig Sakai Conference 43
    44. 44. 2012 Jasig Sakai Conference 44
    45. 45. Training and Documentation 2012 Jasig Sakai Conference 45
    46. 46. What workshops did participants attend? Bye Bye Blackboard 1% Assignments, Assessments and Gradebook 10% Sakai Quick Start 8% Sakai:Providing feedback with the gradebook 9% Sakai:Tests and Quizzes 13% Sakai:Assignments 12%Sakai: Discussion Boards, Email and Communication 6% Sakai: Syllabus and Schedules 6% Introduction to Sakai for Teaching 57% 0% 10% 20% 30% 40% 50% 60% 2012 Jasig Sakai Conference 46
    47. 47. 2012 Jasig Sakai Conference 47
    48. 48. 2012 Jasig Sakai Conference 48
    49. 49. Support 2012 Jasig Sakai Conference 49
    50. 50.  Model based on Blackboard support Partnership between Duke OIT and CIT Local monitoring in additional to vendor-provided monitoring Emergency response / vendor vs. local-hosted differences Instructional Designer specifically hired for the project. 2012 Jasig Sakai Conference 50
    51. 51. Governance 2012 Jasig Sakai Conference 51
    52. 52.  Project managers brought decisions to Sakai Team and sponsors Transition Advisory Board Working on permanent governance model – people shifting out of transition roles Standardizing a process for new development requests, bug fixes and integrations. IMPORTANT: open-source means different things to different people. Set expectations. 2012 Jasig Sakai Conference 52
    53. 53. June 30th is coming… thenwhat? 2012 Jasig Sakai Conference 53
    54. 54.  Self-service (course creation) ◦ So far, so good ◦ Benefits – do not have to wait for administrators, no middle man; combine sites the way you want (instructors); open up project sites to campus community ◦ Some pushback from professional schools Toolkits ◦ Facilitating some batch creation of courses for professional schools (ex: all Law courses) Course content linking problem Better streaming/media management Other bugs that need to wait for 2.8/2.9 2012 Jasig Sakai Conference 54
    55. 55.  Partnering with Fuqua School of Business (and other Duke developers) ◦ Team assignments ◦ Improving the schedule tool Exploring Sakai Portfolios Sakai 2.8 or 2.9 in 2013 OAE? 2012 Jasig Sakai Conference 55
    56. 56. 2012 Jasig Sakai Conference 56
    57. 57. Duke Sakai TeamYvonne Belanger Dwayne MarloweCara Bonnett Mark McCahillDavid Bracken Chris MeyerNeal Caidin Shawn MillerDeborah Deyulia Elise MuellerSamantha Earp Lynne O’BrienEd Gomes Josh QuanLaurie Harris Christine Vucinich 2012 Jasig Sakai Conference 57