Planet Sakai

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.

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.

The WebLearn team have developed a new help document for the wiki: https://weblearn.ox.ac.uk/access/wiki/site/info/local-wiki-help.html

It has been authored in the wiki itself.

My focus is shifting ever more toward community-based activities that inform and shape Sakai 3. Again, I think Sakai 3 represents for us not just a new codebase and user experience, but also new ways in which the community comes together to produce the product.
At the end of last week I participated in a two-day virtual working session with our Teaching and Learning community, led by Josh Baron and David Goodrum. They are in the midst of trying to distill and organize the functional brainstorming that's been worked up over the last several months in a google spreadsheet. About 20 of us spent 6 or 7 hours a day, two days straight, on the phone together; I admired everyone's stamina, and was heartened by the level of interest. The practical aim of this ongoing effort is to provide clear input for the designers that are trying to shape Sakai's user experience, by laying out a clear and well-rounded picture of many of the core tasks and activities they're trying to serve. At the same time I think this group's effort may be paving the way toward what might soon become a functionally-led roadmap, as they draw rings around fundamental capabilities.
Last week also brought published results from a first round of user testing, ably led by Daphne Ogle at UCB, for a set of Sakai 3 wireframes.  Several members of the UX community are moving into a new cycle of testing this week as well. One of the benefits of Sakai 3's shift client-side is that one can move from wireframes to prototypes far more quickly, and we can iterate on them relatively rapidly. The hope is that this will prove to be yet more empowering for our user experience and accessibility specialists by providing them direct, frequent and practical influence on Sakai's development. I expect in the next few weeks we'll be refining a community-based practice of feedback loops. If you're at all interested in this work, I'd urge you to join the conversation on the sakai-ux list. 
Meanwhile the Product Council is going to start wrestling with the question of how it can help usher the Sakai 3 development work toward a completeness and maturity that serves the wider community. Sakai 3 as a whole has just recently formally entered incubation, and in treating it the council will need to ratchet up existing standards while also fleshing out new sets of objective criteria in cooperation with some of our expert sub-communities. You can be part of this ongoing discussion on the management list.

This has been some time in coming, but Sakai 3 as a whole is now in incubation. It wasn't too long ago that "Sakai 3" stood as a category within which other projects were being incubated (e.g. K2, Groups), but we've come to the realization that although this compartmentalization may have made it easier to think about the issues piecemeal, it wouldn't be helpful for producing the earliest iterations of a product that needs to hang together.

The challenge for the product council in taking Sakai 3 on these terms is obviously the size of the issue. In the 2.7 release decisions the framework and the broader context was already set, and we were looking only at implications if a new piece were to be slotted into place alongside the rest. We have no such luxury with Sakai 3. A release readiness decision in this case is as big as the entire product.

At the same time we'll be weighing Sakai 3 against new standards, some of which will differ in kind as well as degree from the guidelines that ruled the earlier days of Sakai's history. Developing and clarifying these standards in cooperation with our expert sub-communities should be a central activity for the product council in the months ahead. Now that Sakai 3 is formally in incubation we can begin that work in earnest.

-Clay

My new book (thanks to Allen B. Downey and Jeff Elkner) was featured in the Creative Commons blog: http://creativecommons.org/weblog/entry/20559 "Chuck Severance, clinical professor at the University of Michigan’s School of Information, recently published a new textbook in 11 days because...

My new programming language that always compiles, never has bugs, has perfect style and is generally delivered on time, (all IMHO) is English. Developers must have a screw loose. Generally they refuse to write anything down, often they say the documentation is in the code, any yet, most of their leasure time is taken up [...]

This is an Administration Site role which give the participant rights to audit or view all sites managed by the Administration Site.

Specifically, a participant with the audit role may:

• visit all sites managed by the Administration Site (including unpublished sites)
• read announcements
• read assignments and student submissions
• see the site calendar
• read chat transcripts
• see all files in resources including hidden material
• read the email archive
• see all site member details
• read all wiki pages
• see all ’sign-up’ meeting details
• use Site Stats tool
• see site membership (in Site Info)

The admin role is more powerful than the member role.

The admin role can visit and ‘maintain’ all sites that are managed by the Administration Site. A participant with the member role has to be a participant within a site in order to visit it it, and (as usual) has to have the maintain role within a site to be able to configure it. In addition a participant with the member role in the Administration Site is able to create sites from with any site where they have the maintain role.

The maintain and contribute roles are very similar.

The maintain role is allowed to change tool permissions and add site participants and create new sites (so long as they are a member of an Administration Site) but otherwise the roles are almost identical. The contribute role is meant for staff members who are expected to author content, modify forum discussions, make announcements and the like but who are not actually site maintainers.

The access role is for student-type access, if ’students’ are required to author content or moderate Forum discussions then the permissions for the access role should be modified in the tool itself.

In general students should never be given the contribute role.

Every year the Sakai community holds a teaching award competition. The prize this year includes a free trip to the Sakai conference which will be held in Colorado, Denver. The details are given below.

The WebLearn team are happy to help anybody who is thinking of submitting an entry: simply get in touch with us via the usual email address: weblearn@oucs.ox.ac.uk

The announcement

The deadline for the Teaching with Sakai Innovation Award is fast approaching– March 15. Please consider helping your faculty apply for this award. Innovation is broadly defined, some may call it active learning or student-centered learning. Here’s an article from yesterday’s Campus Technology describing one of the past winning courses: http://campustechnology.com/articles/2010/02/03/teaching-with-sakai-innovation-award-call-for-entries-open-thru-march-15.aspx

Call for Entries: 2010 Teaching With Sakai Innovation Award (Deadline: Monday, March 15, 2010)

The Teaching with Sakai Innovation Award publicly honors successful pedagogical innovation and best practices in teaching and learning in a Sakai environment. Winners will receive a trip to the 2010 Sakai Conference, June 14-17, 2010, in Denver, Colorado, USA to give a featured presentation about their teaching with Sakai. All entries will become part of the OpenEdPractices.org repository of best teaching practices. The award is sponsored by IBM, with additional support from rSmart and John Wiley & Sons.

For more information about the award and the submission deadline, go to the Teaching with Sakai Innovation Award web site (http://openedpractices.org/twsia).

Many thanks,

Kate Ellis

Learning Technologies Consultant
Indiana University Bloomington
Teaching and Learning Technologies Center
Wells Library 305 West Tower
812-855-9024
kdellis@indiana.edu

Release Date: 29 January 2010

The Sakai Foundation is pleased to announce the latest maintenance release for Sakai 2.6.x and 2.5.x.

-----------------------------
The Sakai 2.6.2 maintenance release provides a set of bug fixes that improve upon the Sakai 2.6.1 release. Over 80 issues have been addressed by 2.6.2.

Fixes have been applied to the following tools/services: assignments, blogger, citations, common, email archive, forums, messages, polls, post'em, preferences, providers, schedule, search, section info, site info, sites, syllabus and worksite setup.

• Sakai 2.6.2 Release Documentation (Overview, Installation, Configuration, etc.) is on the wiki at: <http://confluence.sakaiproject.org/display/DOC/Sakai+2.6>
• Sakai 2.6.2 fixes are listed with details at: <http://confluence.sakaiproject.org/display/DOC/Sakai+2.6.2+Fixes>
• Sakai 2.6.2 Release Artifacts (source, binary and demo versions) are available at: <http://source.sakaiproject.org/release/2.6.2/>

------------------------------
The Sakai 2.5.6 maintenance release provides a set of bug fixes and security enhancements that improve upon Sakai 2.5.5. Over 130 issues have been addressed in this release.

Fixes have been applied to the following tools/services: announcements, assignments, blog, calendar, content service, entity service, entitybroker, event service, forums, gradebook, mailtool, messages, post'em, polls, portal, portfolios, profile, providers, reports, resources, roster, rwiki, schedule, search, section info, site info, sites, syllabus, Test & Quizzes, user service, web content, webdav and worksite setup.

• Sakai 2.5.6 Release Documentation (Overview, Installation, Configuration, etc.) is on the wiki at:  <http://confluence.sakaiproject.org/display/DOC/Sakai+2.5>
• Sakai 2.5.6 fixes are listed with details at: <http://confluence.sakaiproject.org/display/DOC/Sakai+2.5.6+Fixes>
• Sakai 2.5.6 Release Artifacts (source, binary and demo versions) are available at: <http://source.sakaiproject.org/release/2.5.6/>

---------------------------------
Older versions of Sakai
Users of pre-2.5 versions of Sakai are strongly encouraged to update to the Sakai Community-supported Sakai 2.6.2 or Sakai 2.5.6 releases in order to take advantage of the feature, performance and security enhancements provided by the Sakai 2.5 and Sakai 2.6 series.

The Sakai open source community develops, tests, and maintains the code for all Sakai releases. For the most current release and the immediate prior release, the Sakai Foundation uses its resources to oversee and manage the development, QA testing, patching, and releasing of incremental numbered versions.

For earlier versions, the Foundation no longer provides this oversight and coordination of the community contribution to the codebase. This does not mean that these earlier versions are not used and maintained by some institutions in the community, they are. Institutions running an older version may of course continue to do so, applying patches, bug fixes, and enhancements as they wish. These modifications are committed to the Sakai SVN code repository and are available for others to use if they wish. But the Foundation does not coordinate testing or validation of the code changes, and does not create a concomitant roll-up into an incremental release.

I recently had the pleasure of setting up a Jasig CAS server on campus. The install went without a hitch. I initially brought it online with a self signed certificate, which was a no brainer as the Tomcat docs are great.

Once we got our SSL certificate though, I realised that the private key and keystore I had initially generated for the self signed certificate wasn't used for the the Certificate Signing Request that the sysadmin's had sent away to the Certificate Authority. So I had a private key for the SSL certificate but the one in the keystore was different. Problem 1. And it's not possible to import a private key into a keystore using keytool because it doesn't have this ability. Problem 2.

Thankfully, this is fixed in Java 6: keytool can now import a PKCS12 file into a keystore. But first you need to get your certificate and private key into that format. You can use OpenSSL for this:

openssl pkcs12 -inkey /path/to/private/key -in /path/to/certificate -export -out bundle.p12

Now we have a file called bundle.p12 which we will import into our keystore via keytool:

keytool -importkeystore -deststorepass changeit -destkeypass changeit -destkeystore /path/to/keystore -srckeystore /path/to/bundle.p12 -srcstoretype PKCS12 -srcstorepass changeit -alias 1

The alias 1 is required to tell keytool to import the first certificate in the PKCS12 file.

Finally the Tomcat config:

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="/path/to/keystore" keystorePass="changeit" />

Like most of the nerd world, I sat in my office listening to streamed pirate audio from the Apple announcement of the iPad last week. Like most of the nerd world, I had high hopes for the iPad - I...

Brian Moynihan has posted his Masters Thesis on University of North Carolina School of Medicine’s LMS evaluation, which eventually came down to a shootout between Blackboard and Unicon-supported Sakai. There’s a lot that’s of interest in this paper, particularly around the complexity of higher ed IT environments and the need for integration, but these two paragraphs particularly caught my eye as being relevant to the general LMS evaluation process of many schools:

(...)
Read the rest of Academic Study of Blackboard vs. Sakai at UNC School of Medicine (1,039 words)

---

© michael.feldstein for e-Literate, 2010. | Permalink | 4 comments | Add to del.icio.us
Post tags: Blackboard-Inc., Sakai, Sakai Project

The Conference Program Committee has come up with a list of candidates for Keynote Speaker. We'd like you to tell us who you would like to hear speak at the conference. Please take a couple of minutes and mark your 1st, 2nd, and 3rd choices on this online survey <http://www.surveymonkey.com/s/FNQP2NG>.

We appreciate your input.

You know how we always think of the Internet as a web of facts that are interconnected to one another? Well, here's a story of random interconnected stuff that led me to step out of my comfort zone. Warning: This blog post jumps from one thing to the other a lot. About 2 months ago, I finally got rid of my dino-phone (circa 2007) to make a leap into 2009 and bought a Motorola Droid (I know, the

On Thursday 28th and Friday 29th of January, Laura and Anne-Sophie went off to Birmingham for the JISC Institutional Innovation Exchange meeting.

One of the activities was the Trade Fair... With 7 sold products, we didn't do such a bad job! Thanks for all who bought our products. For those who would still like to have a look at them, you can find all the information you need below.

Overall, it was good to see all projects and people again, and to find out what progress they made.

Information on the conference can be found at http://sakaiproject.org/sakai-european-regional-conference-2010
 
Remember to register before 15th of February to get the benefit of the Early Bird Registration Fee at https://www.upv.es/pls/sosak/sic_eusakai.REGISTRATION?p_vista=poliformat&P_IDIOMA=i

The Schedule for 3rd European Conference that will be held in Valencia, Spain from 1 to 3rd of March 2010 is NOW available at http://www.upv.es/var/eurosakai_schedule.html
 
If you have any questions, doubts, or you just need more information, contact eurosakai2010@upv.es
 
WE HOPE TO SEE ALL OF YOU IN VALENCIA

The Open Ed conference theme for 2010 is OER: Impact and Sustainability.

November 2-4, 2010, the seventh annual Open Education Conference moves to Barcelona for its first convening outside of North America! The 2010 conference venue is CosmoCaixa, designated Europe’s best science museum in 2006.

The Call for Papers is open through May 15. Submit your paper now!

The Open Education Conference has been described as “the annual reunion of the open education family.” Each year the conference serves as the world’s premiere venue for research related to open education, while simultaneously creating the most friendly and energetic atmosphere you’ll find at any academic conference.

Open Ed 2010 is jointly organized by the Open University of Catalunya, the Open University of the Netherlands, and the David O. McKay School of Education at Brigham Young University

Assignments 2 has entered incubation.

As many of you know, assignments 2 has been baking for some time at IU. Although it's another unavoidable case of a project not entering incubation until it's rather far along in its development - and so our Sakai 2 precedents may mislead the casual observer about the process - I'm still happy to have it incubated so far in advance of any release decisions. More room to breathe and do the right thing.

So far I see a feature-driven development process which is then polished with usability testing. I think the Product Council could use the occasion to flesh out our review criteria, eg. those for accessibility with the help of the WG already making big strides.

I'd also like to point out the fronts along which assignments 2 has been compelled to engage - with gradebook and a variety of helpers, with OSP, TurnItIn, and maybe others. This may be a challenge for UX coherence in Sakai 2 contexts, but I think it helps confirm that the underlying capability is pivotal, and should inform the Sakai 3 UX at an early stage, provided we can trace it back to its essentials well enough. As with many things in Sakai 3, it won't be enough to first develop a tool and then look for horizontal integration points after the fact.