Sakai 3 Basic LTI Widget Passing Certification Tests

A quick blog post demonstrating Sakai 3’s new Basic LTI consumer passing the LTI certification test suite. You will get to see the first look at the new Sakai 3 widget but more importantly, you will see it passing 100% of the certification tests! This is a prelude to the screencast where the use of the BLTI widget will be used to expose Sakai 2 tools onto Sakai 3 pages as widgets. Stay tuned…


Filed under Uncategorized

3rd Annual Ja-Sakai Conference Report

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:

  1. 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.
  2. Student artifact submissions via the natural WebCT user interfaces.
  3. Automated batch transferal of the artifacts over to Sakai OSP Matrix for evaluation.
  4. 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:

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:

  1. Nagoya University has officially announced their plans to migrate from WebCT to Sakai. The other universities are watching very closely.
  2. 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.
  3. 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.
  4. Japan now has at least two commercial partners that are active in the Sakai space.
  5. 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!

1 Comment

Filed under Education, Sakai, Technology

Status Update on Basic LTI Widget for Sakai 3

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:

  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.

So let me address these in order:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Leave a comment

Filed under Education, Sakai, Technology

Sakai 2->3 Integration Status Update

David Goodrum asked me to provide an update to the Oncourse Priorities Committee [1] regarding the progress made towards Sakai 2->3 integration and migration. In doing so, it became clear that this kind of update might also be useful to the community at large. There are two overarching goals to achieve in this project: 1) seamlessly exposing Sakai 2 functionality within Sakai 3 (which we are dubbing “hybrid” mode) and 2) content migration.

The hybrid mode will allow institutions to adopt Sakai 3 at a pace that is comfortable for them. For example, Sakai 3 will not have all of the functionality available in Sakai 2 day one, but their will be some compelling functionality that institutions will want to adopt before all of the functionality gaps have been closed. Hybrid mode will facilitate this approach by allowing institutions to deploy Sakai 3 and take advantage of the new features while still relying on Sakai 2 for the features not yet available in Sakai 3. The following video demonstrates the first step in realizing hybrid mode: the ability to expose entire Sakai2 sites within the Sakai 3 portal.

We anticipate that institutions will want to start using Sakai 3 for full-fledged project and committee work before course work. This capability supports this use as Sakai 3 sites can be used for project sites while Sakai 2 continues to serve the course site needs. The next step in the hybrid mode evolution will be the ability to place individual Sakai 2 tools onto Sakai 3 pages which live in Sakai 3 sites. This will give the user the ability to mix and match both Sakai 2 and Sakai 3 functionality in a single user experience.

Next: content migration. The primary use case that we are tackling first is the ability of an instructor who taught a class last semester in Sakai 2 to be able to import that site template into Sakai 3. The following video demonstrates an initial deliverable where one can export content from a Sakai 2 site and then import that content into a Sakai 3 site. Please keep in mind that this is very early work and is rough around the edges, but the methodology and underlying service is sound.

Moving forward, focus in the following areas is required:

  1. Exposing individual Sakai 2 tools on Sakai 3 pages within Sakai 3 sites.
  2. Exploring a results mechanism so that a tool hosted in Sakai 2 can report results to a tool hosted in Sakai 3 (and vice-versa). As an example, you might want to use a Sakai 3 Assignments tool which will need to report outcomes to a Sakai 2 Gradebook.
  3. Continued effort to import Sakai 2 site templates into Sakai 3 for semester-to-semester transitions.
  4. Deeper content migration that will not only transfer site templates, but also include full user content. For example, this will likely be a requirement to migrate a project site from Sakai 2->3.


Filed under Sakai

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.


Filed under Sakai

Sakai 2+3 Hybrid Status Update

I am happy to provide you with a status update on the progress that has been made since the previous post: Sakai 2+3 Hybrid pre-alpha. I think you will be most pleased with the outcomes and in many ways provides a better user experience than what is available in the Sakai 2 portal! The speed at which you can switch between tools is quite amazing. Check it out:

Many thanks to: Ian Boston, Paul Bristow, Oszkar Nagy, Christian Vuerings.

1 Comment

Filed under Sakai

Importing content from Sakai 2 into Sakai 3 (take 3)

As the week begins winding down, I wanted to draw your attention to some progress I have made in this area since my last blog entry: Importing content from Sakai 2 into Sakai 3 (take 2). First, I would like to point you to a screencast I recorded on the subject earlier today:

Next, I would like to address some of the action items from the last post:

  1. All user uploaded content is currently stored in a BigStore under /_user/files. After discussing with Ian Boston, I will most likely refactor the import code to store its content in that BigStore as well. Although, the BigStore concept will likely be redesigned in the near future, so any work I do in this area will be nicely abstracted so that this behavior can be changed easily when and if BigStore is redesigned.
  2. With the move to BigStore, I will have to take a look at access control lists (ACLs) so the the user importing content will have the proper permissions.
  3. Next, I need to take a look at the contract between K2 and the “Content & Media” widget so that the imported content appears properly within the user interface.

This work is complete and you can see it working in the video. The refactor to the /_user/files BigStore was pretty straightforward, except for one self inflicted bug, and luckily the call to FileUtils.saveFile() already handled all of the access control permissions for me. The Content & Media widget expects files to be stored under /_user/files, so things started behaving as expected after #1 was complete.

I do have the plans confirmed with Dr. Chuck and Noah Botimer to spend two days developing a Sakai 3 BasicLTI consumer. I am excited to tackle that problem – coding sprints are always full of such great energy! Until next time, Lance

Leave a comment

Filed under Sakai