It’s Official: Sakai 3 has passed IMS Global’s LTI Certification

Just this week IMS made the official LTI certification test suite available and I am very pleased to announce that Sakai 3 has passed the certification tests with flying colors (i.e. 100%). Now we can display this cool “Basic LTI Enabled” image with our software. As of this writing, this distinction is shared only with Desire2Learn. You can keep up-to-date on the progress of LTI certifications by watching: Common Cartridge and Basic Learning Tools Interoperability Progress.

While the Sakai 3 LTI consumer has the potential to bring interesting 3rd party tools into the learning management system, our primary motivator for this work was to provide a way to surface Sakai 2 tools within Sakai 3. Using LTI to solve this problem has positioned us well and we are anxious to see other developers implement the LTI provider server-side interface. Thanks to Dr. Chuck, Sakai 2.7 will ship with both an LTI consumer and LTI provider!

For more information on Basic LTI, see: Basic Learning Tools Interoperability. If you are interested in the certification test suite, see: Sakai 3 Basic LTI Widget Passing Certification Tests.

Mix and match Sakai 2 and Sakai 3 tools

I am very pleased to be able to share an important update with the Sakai community regarding the ongoing efforts to create a flexible migration path from Sakai 2 to Sakai 3. I have been blogging recently [1] [2] about the development of a new Basic LTI widget for Sakai 3. This effort builds on the existing capabilities [3] of Sakai 3 which allows you to expose entire Sakai 2 sites within the Sakai 3 portal (i.e. with the addition of Sakai 3’s social networking features). The next step in this hybrid evolution was to add the capability to expose individual Sakai 2 tools within Sakai 3 sites. Furthermore, since we were developing this new capability as a Sakai 3 widget, this means that an end user could place multiple Sakai 2 tools onto a single Sakai 3 page (i.e. something not currently possible in Sakai 2). This may sound like a subtle distinction, but as you will see in the embedded video it is an important distinction as it helps to break Sakai 2 tools out of their silos. Instructors can now author pages with custom workflows that may include both Sakai 2 tools and Sakai 3 widgets!

Skip to 12:30 into the video if you want to skip the summary and background…

So now we are beginning to see a migration path for existing Sakai 2 implementations that looks like:

1. Sakai 2 for course sites and Sakai 3 for project sites.
   1. Reduced risk deployment as there is no hard dependency on Sakai 3 being available. For example, if Sakai 3 were to go down, users could easily be directed back to the Sakai 2 portal.
   2. Sakai 3 portal may or may not be the default portal (i.e. implementers choice).
2. Placement of Sakai 2 tools alongside Sakai 3 pages within a Sakai 3 site.
   1. Maintains more of a Sakai 2 user experience while allowing access to Sakai 3 capabilities within a single site.
   2. Provides a nice transition between #1 and #3 for those that find it valuable.
   3. Increases risk as now users are dependent on Sakai 3 remaining available.
3. Mixing and matching Sakai 2 and Sakai 3 tools all on the same Sakai 3 page within a Sakai 3 site.
   1. Provides the greatest flexibility for course and project site design.
   2. Provides the most “native” Sakai 3 user experience while maintaining access to Sakai 2 functionality.
   3. Custom workflows may be created with both Sakai 2 tools and Sakai 3 widgets (i.e. even if you are just exposing Sakai 2 tools, this capability does not exist in Sakai 2).
   4. Maintains same risk profile as #2.
4. Implementer’s selection…
   1. You do not need to think of the previous three deployment strategies as mutually exclusive or synchronous.
   2. You can make any or all of these solutions available to select user populations as you see fit at any time – all based on your local goals and comfort levels.

For example, one possible migration path may look like:

1. Build confidence in Sakai 3 and keep risk at a minimal levels.
   1. Deploy Sakai 3 alongside Sakai 2 with hybrid mode enabled.
   2. Continue to use Sakai 2 for course sites.
   3. Begin to experiment with Sakai 3 portal and project sites.
   4. Make Sakai 3 portal available to select user populations to validate access to Sakai 3 social networking capabilities as well as access to Sakai 2 sites.
   5. Make Sakai 3 project sites available to select user populations.
2. Make Sakai 3 portal the default portal for all users.
   1. Continue to use Sakai 2 for course sites.
   2. Expand use of Sakai 3 project sites.
   3. Develop fallback plan to mitigate dependency on Sakai 3 portal availability (i.e. you still have a fully functional Sakai 2 portal sitting there).
3. Early adopters begin relying on Sakai 3 for course work.
4. Full adoption of Sakai 3 for both course related and collaborative work.

There is a lot to consider here and to complicate matters further I predict not one migration will be identical to another. However, we hope that we have provided enough capabilities and flexibility to tailor each migration to fit the institution’s needs. Furthermore, there is a lot experience in our community in this area as almost all of us have made a similar migration in the past. This time things are a little different… This time we have direct control over both systems and can make the migration smoother.

Let’s continue the discussion in person at the annual conference. Christian Vuerings and I will be presenting on this topic in sessions titled “Integrating Sakai 2 and Sakai 3”. There will be two regular conference sessions and a technical demonstration. See you there! L

[1] http://bit.ly/9Brbdl
[2] http://bit.ly/bXVPVI
[3] http://bit.ly/bQKjlm

Sakai 3 Basic LTI Widget Sprint

I am pleased to update the Sakai community on the outcomes of a two day coding sprint to produce a Basic LTI consumer widget for Sakai 3. Dr. Charles Severance, Noah Botimer, and I participated in the sprint which the University of Michigan CTools team was kind enough to host. Don’t worry if you are not familiar with the Basic LTI specification. It is an up and coming specification from IMS which is currently in draft status. In a nutshell, it allows separate applications to be loosely integrated through an IFRAME. In the first iteration, known as “Basic” LTI, the remote system trusts some user information from the local system such as the identity of the user and the roles of the user (e.g. Instructor, Learner, etc.), and then automatically provisions accounts and tools appropriately. Essentially, this allows a remote tool to appear in a learning management system (LMS) as if it were a local tool. From an industry perspective, this will allow a standard way for say publishers to provide hosted textbook content to a variety of LMSs. It could also create an environment where we begin to select tools à la carte for inclusion into a local LMS implementation; i.e. selecting the tools that best fit the pedagogy used by the instructor. For a quick primer on LTI, I would suggest watching the video IMS Basic Learning Tools Interoperability by Dr. Chuck.

So the reason that I wanted to explore LTI was perhaps a bit less lofty. Simply, I wanted to use it as a mechanism to place a Sakai 2 tool into a Sakai 3 site as a widget on a page. The work that has been accomplished to date (see: Sakai 2+3 Hybrid Status Update) has been largely about exposing entire Sakai2 sites in the Sakai 3 portal. This work is still very much applicable, but supports a different use case than what I hoped to accomplish with an LTI widget.  In this case, we want to be able to support a mixture of Sakai 2 and Sakai 3 tools and widgets within the context of a Sakai 3 site. This will help us make the transition from 2–>3 without a “big-bang” approach. For example, Sakai 3 will not have a PostEm tool day one, and that should not present a roadblock to Sakai 3 adoption. You should simply be able to place the PostEm from Sakai 2 in your Sakai 3 site along with all of the other native Sakai 3 widgets.

So after two days of intense coding, we had a widget that could consume a sample Basic LTI Provider. Many thanks again for the help from Dr. Chuck and Noah Botimer! You guys are awesome! There was certainly more work to do, but the plumbing had been laid and now I could focus on refining working code. Beyond the mechanics of creating an LTI launch, we wanted to add some settings to the widget:

1. Create “virtual tool” registrations so that the same widget could be provisioned many times under different names; i.e. the same widget could be reused for sakai2.calendar, sakai2.postem, sakai2.etc.).
2. Allow for administrative control over Basic LTI widget placements; i.e. the system administrator could define default values and/or lock settings that could not be modified by instructors. For example, you could use these locked settings to create the virtual tols described in #1.
3. Settings to control user privacy:
   1. Should the user’s name be released to the remote system (i.e. first, last, full names)?
   2. Should the user’s email address be released to the remote system?
   3. Should the user’s user-name be released to the remote system?

I spent the next week wrapping up these enhancements to the code. The next step was to invoke the Basic LTI provider that is currently slated for release in Sakai 2.7.0. I mean that was the whole point of this exercise after all!  In doing so, I discovered a bug that cause the Sakai 2 provide to choke – it did not like the “/” character in my context_id variable; see: BLTI-23. The shortest path to resolution was rolling my sleeves up and fixing the code. So along the way, I accepted an invitation got wrangled into becoming a committer on the BLTI project! After fixing BLTI-23, we decided that the length of the Sakai 2 siteId could be a problem as we cannot predict the length of context_id that remote systems will pass, so next came BLTI-24. 🙂 A few commits later, and the we were in business! Yeah! I could display a Sakai 2 within a Sakai 3 site placed as a widget on a page.

So what is next?

1. At least one screencast demonstrating the work to date – probably two. One showing the Basic LTI plumbing and passing of the LTI certification tests, and another showing Sakai2 tool placements in Sakai 3 sites.
2. Some of the information in an LTI launch needs to be secured from end users. This will be a chance for me to learn more about access control in Sakai 3; see: KERN-591.
3. The widget itself needs some renovation. I will likely copy the existing Remote Content widget and add the LTI settings.
4. Create some virtual tools for existing Sakai 2 tools and add these to the out of box Sakai 3 experience.
5. Work on the Sakai 2 Basic LTI provider servlet to make it more robust and support the specific Sakai 2/3 integration use cases.