It has been a while since I have written about the Sakai Hybrid integration between CLE and OAE. With some visioning help from David Goodrum and some technical wizardry by Steve Githens, we managed to hit a major milestone leading up to the Sakai 2011 Conference. This milestone allowed us to perform a live demonstration of a couple of important use cases:
- Using the Sakai OAE portal to launch directly into a CLE site experience.
- Being able to pull individual CLE tools into OAE content pages as widgets.
The first use case is important if you want a single URL for your users to enter their LMS experience regardless of whether they are primarily CLE or OAE users. This mode will allow CLE users to ease into an OAE experience while maintaining a very familiar CLE user interface. In other words, think of it as a new portal for CLE that has some new capabilities.
The second use case is targeted more at users who are adopting the complete OAE user experience, but still need access to some functionality provided by the CLE (think of Assignments, Gradebook, and Tests & Quizzes as examples). This capability allows one to pull one or more CLE tools into an OAE content page as widgets. The other interesting thing is that the underlying technology behind this tool integration is what is known as IMS Learning Tools Interoperability or LTI for short. This technology will not only allow OAE to pull in external CLE tools, it will also allow OAE to pull in other LTI enabled tools or applications (think EtherPad, WordPress, Moodle, or Blackboard as examples).
David Goodrum introduces the Hybrid concept and value proposition:
Lance Speelmon demonstrates Hybrid use cases:
Steve Githens expands on possibilities:
Finally we wrap up with some Q&A:
I am a member of the program committee for the upcoming Sakai conference in Los Angeles on June 14 – 16. I would like to invite you to join us in Los Angeles, and to solicit your help in both defining and creating the agenda.
Many of the conference attendees will be using or evaluating Sakai, but we hope to include broader content that speaks to effective systems and practices with technology-enhanced teaching, learning and research.
We have created a Request for Presentation Suggestions to allow broader participation in suggesting the conference content and presentations that would be most helpful. Please take a moment to share your suggestions about the sessions and content that would be most beneficial. This information can be submitted and reviewed immediately.
We have also posted the Call for Presentation Proposals requesting proposals for conference sessions, pre-conference workshops, birds of a feather topics, and showcases/tech demos. Please consider sharing your expertise in a formal session, or an informal discussion or demo.
I look forward to seeing you in June…
Best regards, Lance
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.
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   about the development of a new Basic LTI widget for Sakai 3. This effort builds on the existing capabilities  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:
- Sakai 2 for course sites and Sakai 3 for project sites.
- 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.
- Sakai 3 portal may or may not be the default portal (i.e. implementers choice).
- Placement of Sakai 2 tools alongside Sakai 3 pages within a Sakai 3 site.
- Maintains more of a Sakai 2 user experience while allowing access to Sakai 3 capabilities within a single site.
- Provides a nice transition between #1 and #3 for those that find it valuable.
- Increases risk as now users are dependent on Sakai 3 remaining available.
- Mixing and matching Sakai 2 and Sakai 3 tools all on the same Sakai 3 page within a Sakai 3 site.
- Provides the greatest flexibility for course and project site design.
- Provides the most “native” Sakai 3 user experience while maintaining access to Sakai 2 functionality.
- 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).
- Maintains same risk profile as #2.
- Implementer’s selection…
- You do not need to think of the previous three deployment strategies as mutually exclusive or synchronous.
- 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:
- Build confidence in Sakai 3 and keep risk at a minimal levels.
- Deploy Sakai 3 alongside Sakai 2 with hybrid mode enabled.
- Continue to use Sakai 2 for course sites.
- Begin to experiment with Sakai 3 portal and project sites.
- 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.
- Make Sakai 3 project sites available to select user populations.
- Make Sakai 3 portal the default portal for all users.
- Continue to use Sakai 2 for course sites.
- Expand use of Sakai 3 project sites.
- Develop fallback plan to mitigate dependency on Sakai 3 portal availability (i.e. you still have a fully functional Sakai 2 portal sitting there).
- Early adopters begin relying on Sakai 3 for course work.
- 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
I was very pleased to join Lois Brooks at the 3rd Annual Ja-Sakai Conference (translated) hosted by Kumamoto University. The day prior to the conference Ryuichi Matsuba asked me to provide a presentation to his colleagues regarding how Indiana University’s software developments are organized and the various roles that team members play (slides link). I only was able to finish about one half of the presentation due to time constraints, but we did have some good discussion on related topics. I was very happy that Lois Brooks was able to participate in the discussion as she was able to field some of the questions I could not address directly. Thanks Lois!
Afterwards, Professor Makoto Miyazaki of Kumamoto University provided a sneak-peek of his Ja-Sakai presentation (kindly translated into English) detailing their ePortfolio development efforts which include:
- uPortal as the primary landing page for students. This provides the launch points for accessing both of their WebCT CE6 and Sakai 2.6 OSP instances.
- Student artifact submissions via the natural WebCT user interfaces.
- Automated batch transferal of the artifacts over to Sakai OSP Matrix for evaluation.
- A newly developed OSP tool which they call “Notifications” which is a type of dashboard that allows users to easily see pending work and links directly to the tools for completion.
This work is in support of their competency-based curriculum and will be presented at the 2010 Sakai Annual Conference in Denver, Colorado. For more information about Kumamoto University’s portfolio practices, see: http://www.gsis.kumamoto-u.ac.jp/en/gp.
The following day was the conference which started with some very kind opening remarks from Dr. Shin-ichi Abe, Vice President and Trustee Kumamoto University and Dr. Takeshi Mase, Nagoya University Graduate School of Information Science. After the opening remarks, Lois Brooks provided a very nice presentation titled “Technology and Learning”.
Following Lois’ presentation, I delivered “Sakai 3 and the next major web technologies”:
The remainder of the conference was conducted in Japanese, so Lois and I were kindly escorted by Tomomi Nagata and Yuuki Tsunemoto to a vegetarian lunch with twelve different types of tofu and a traditional Japanese tea ceremony at the local Samurai house. We then finished our afternoon at Kumamoto castle before returning to the conference center for the Ja-Sakai reception. Some key takeaways for me from the reception:
- Nagoya University has officially announced their plans to migrate from WebCT to Sakai. The other universities are watching very closely.
- Kansai University, the largest private university in Japan, has adopted Sakai in partnership with a commercial entity (NS Solutions?). Their biggest issue with Sakai is the lack of custom workflows and were very excited to see the work coming out of Sakai 3 to help resolve this issue.
- Learning Java is presenting a problem to Sakai related development and lowering this barrier to entry is an important concern (e.g. think PHP developers). Much of Sakai development is occurring at the edge in Japanese Universities.
- Japan now has at least two commercial partners that are active in the Sakai space.
- Internationalization and localization of both Sakai the software and Sakai the website continue to be a hurdle for Japan.
I would like to convey many special thanks to our very kind and generous hosts from Kumamoto:
- Dr. Ryuichi Matsuba
- Dr. Shin-ichiro Kubota
- Dr. Hiroshi Nakano
- Ms. Tomomi Nagata
- Ms. Yuuki Tsunemoto
PS – Ryuichi Matsuba made good on his promise to Sakai last year and unveiled two new Sakaigers at the conference this year. As you can imagine, the Japanese find the Sakaiger very endearing and kawaii!
PPS – I was a bit overwhelmed at how many QR Codes I saw in Japan – they are everywhere! Maybe what piqued my curiosity the most was the fact that the promotional materials for the conference (both print and web) contained QR codes. I thought I remembered Google starting to promote QR codes with Google maps, and that was indeed correct. I have now equipped my iPhone with a QR reader called QuickMark QR Code Reader and now I am able to read QR codes. I am using the QR Code Generator from the ZXing Project to generate QR codes. It looks like this technology is on the verge of adoption in the US and we should encourage it. Scanning a QR code with your phone sure beats typing a URL on a mobile device! I have also seen these displayed on business cards for a quick way to get a new contact into your address book. Very cool!
I am returning from a very productive trip to Japan to participate in the 3rd Annual Ja-Sakai Conference (which I will blog about shortly) – but I did want to provide a quick update on the progress I have made in developing the Sakai 3 Basic LTI consumer widget. In my previous post on this subject, Sakai 3 Basic LTI Widget Sprint, I outlined five action items:
- 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.
- 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.
- The widget itself needs some renovation. I will likely copy the existing Remote Content widget and add the LTI settings.
- Create some virtual tools for existing Sakai 2 tools and add these to the out of box Sakai 3 experience.
- Work on the Sakai 2 Basic LTI provider servlet to make it more robust and support the specific Sakai 2/3 integration use cases.
So let me address these in order:
- I still do not have any screencasts to show. I have made some significant progress on #3 so I am waiting to complete the UI overhaul before recording any screencasts. Please be patient – I will have something to show very soon.
- I am pleased to report that the implementation of securing the appropriate LTI launch parameters (i.e. secret and password) has been completed. Each launch node which contains the settings, now will have a sub-node which can only be read or modified by an administrative account. This sub-node contains the LTI secret and password. The service then masks the complexity of the implementation with this sub-node so that the user interface contract did not change. So the end result is that if the LTI related nodes are found via search or some other mechanism, we no longer need to be concerned that any related sensitive data will be exposed to unprivileged users.
- I am also pleased to say that some significant progress has been made on a new user interface for this widget. Using the code from the Remote Content widget is proving to be quite useful and delivering a nice user experience. There has been some debate about whether the Preview capabilities from the Remote Content widget are appropriate for this use case, but assuming that adding these capabilities to the service are not too time consuming, I plan on including this feature for user testing if nothing else. I personally believe the preview capability is worth providing, but I am willing to be proved wrong.
- No progress has been made regarding virtual tool registrations. I believe this use case is not unique and will extend beyond the Basic LTI needs. I have been procrastinating on this topic until I have the time to engage in the discussion fully. I expect that will be when the other action items are complete and we can apply focus to this one particular aspect of delivery.
- Some good progress has been made on the Sakai 2 BasicLTI provider. Through my work on BLTI-24, the provider is a bit more robust. And through Steve Swinsburg’s work on BLTI-31 we are now closer to having a tighter relationship between the Sakai 3 consumer and the Sakai 2 provider. This tighter trust relationship assumes the consumer is closely related to the provider (e.g. maybe within the same domain). I envision using this high trust configuration in conjunction with some auto-provisioning to keep a Sakai 2 and Sakai 3 system in synchronization, which we expect to be common for most hybrid implementations.
Since Sakai 3 is a ground-up rewrite, there is plenty of opportunities to rethink assumptions that have accumulated over the years. One of those areas where a fresh look should do some good is in course export/import formats. Sakai 2 has its own proprietary format which provides a “full fidelity” capability to move from one course site to another without losing anything. While not losing anything is desirable, it comes at quite a cost; i.e. not being compatible with anything else on the planet. This approach is not uncommon and I see now that Moodle also has its own proprietary format.
While there are some good open standards for course export/import (e.g. IMS Common Cartridge or SCORM), they will not provide a “full fidelity” export/import workflow where one could export from Sakai 2 and then import into Sakai 3; i.e. some information would get lost in the translation. Now, supporting these open standards would have other important benefits, they are not first order solutions for simply getting from Sakai 2->3. My hopes are that one day an open standard could be expressive enough to cover such a use case, but the innovation curve in the applications and tools may always exceed the ability of a lowest common denominator solution.
With that said, we thought it would be beneficial to see if Moodle’s export/import format provided enough capability to move data from Sakai 2->3 without losing any critical structure. If this worked out, we would have one great feature out-of-the-box: the ability to move from a course from Moodle to Sakai and vice-versa. It will be interesting to see how this works out and I will keep you updated as progress is made…