Implementing Sakai at Yale

1
Implementing Sakai at Yale

• Michael Appleby
• Academic Applications Group
• ITS Academic Media Technology

2
Sakai at Yale

• Infrastructure from pilot to production
• Integration with student information system (SIS)
• Transition from legacy courseware system
• Local enhancements to Sakai
• Custom tool development

3
Pilot 1.0-1.5

• AY 2004-5
• One application server
• Oracle database
• No SIS integration
• Course sites created manually
• Enrollment data entered manually
• Single Sign On (SSO) integration
• Central Authentication Service (JA-SIG)

4
2.0 Production Pilot

• AY 2005-6
• Upgraded to Sakai 2.0.1 m2
• Application server cluster
• Software load balancing (jk)
• Failover for critical servers
• SIS integration
• Light integration with legacy courseware system
• Approximately 500 (of 750) courses during Sp06

5
Cluster Architecture Schematic
6
Cluster Architecture Schematic
7
2.1.2 Production

• Two professional schools migrated to Sakai from
  WebCT and Blackboard
• New tools available
• Roster, Wiki
• Further SIS integration
• UI changes
• Faculty focus groups

8
Managing Development

• Migrated local code repository from CVS to SVN
• Issue tracking (JIRA)
• Wiki (Confluence)
• Meeting notes
• QA progress
• Sakai project site
• Dev environments (OS, DB, IDE) vary

9
SIS Integration

• Sakai offers a mechanism for populating course
  sites based on rosters that can be drawn from a
  SIS
• This Course Management API has been redesigned
  in 2.3-2.4
• Yale does not (yet) use this API
• Our approach is to populate course sites directly

10
SIS Issues

• Yale undergraduates can shop courses during the
  first two weeks of the term
• Students use an online course shopping cart
• Undergraduate schedules are not entered into the
  SIS until the third week of the term
• In some cases the deadline is even later
• Some types of participants are never entered into
  the SIS
• Staff and alumni auditors, visiting fellows,
  postdocs, etc.

11
Yales SIS Integration Strategy

• Create a site for each course
• Synchronize site membership with both SIS and
  shopping cart
• Allow manual subscription
• Use roles to distinguish between shoppers and
  SIS-provided students
• Students who have manually subscribed are dropped
  after final registration data is made available
  in SIS

12
Drawbacks

• Students who subscribe manually often do not
  unsubscribe
• Some non-credit participants must be added by
  faculty or staff
• Registration errors are reported to us rather
  than the registrar
• Proliferation of Sakai roles
• Not all courses are published
• I lost access

13
Running in Parallel

• Classes.yale.edu is still in use
• Several existing applications are integrated with
  our legacy courseware system
• Discussion forums
• Photo roster
• Online course information
• These applications require information from both
  Sakai and the legacy system

14
Legacy System Integration

• Manual subscriptions are pushed to the legacy
  courseware system
• These students appear in photo roster and are
  granted forum access
• Automatically identify syllabi published in Sakai
  and place redirects on the legacy system
• Courses appear in Online course information

15
Legacy System Disintegration

• Classes.yale.edu will be removed from service in
  July 2007
• Existing applications will be rewritten to draw
  information from Sakai

16
Local Enhancements to Sakai

• Modifications to the Sakai UI
• Look and feel
• Developed a Yale skin
• Logos to brand graduate/professional school sites
• Changes to user interface text
• Modified property files
• Documentation
• Updates to Sakai help
• Links to external tip sheets

17
User Interaction

• Faculty manually publish sites
• Many did not notice the warning
• Not immediately obvious how to publish a site
• A simple modification to the syllabus tool helped
  greatly

18
Displaying SIS Data

• Roster
• Class
• Major
• School/College
• Membership tool
• Display users role in each site
• Students can verify their registration status

19
Managing Change

• Local enhancements may not be relevant to the
  broader Sakai community
• Significant effort required to port local
  enhancements forward from 2.1.2 to 2.3
• Sakai code base saw major changes during this
  period
• Local JIRA and SVN are crucial

20
New Tool Development

• Reasons for developing new tools
• Sakai lacks features present in legacy system
• Needed to integrate with existing tools
• Existing Sakai tool does not meet requirements

21
Web Space

• Web Space tool for course web sites
• Hosts large web sites on a separate server
• Content is maintained using WebDAV
• Access permissions controlled from within Sakai
• Individual directories of a web site can be
  restricted by role
• Sakai Resources permissions were not sufficiently
  flexible
• Authentication is integrated with Sakai

22
Redirect Tool

• A simple Sakai tool to redirect to other
  applications (forums, photo roster)
• Tool passes unique course identifier
• Relies on our SSO (CAS) for authentication
• Not useful for users with local Sakai accounts
• Rutgers Link tool performs a similar function

23
Syllabus Browser

• Requirement to browse course syllabi by subject,
  course number
• Existing tool not sufficient
• Limit to subject
• Cross-listed courses

24
Other Tool Development

• Anonymous feedback to instructors
• Feature from legacy system
• Synchronize site membership
• Syncs a role with user IDs in an Excel
  spreadsheet
• Course Reserves tool
• Collaboration with Library