I'ld like to give an example.
Over the past Stanford academic year I built a desktop Java application designed to provide high-stakes language skills testing. The desktop application is tightly integrated with the Stanford University deployment of Sakai, Coursework.
The test is called the "Simulated Oral Proficiency Interview" (SOPI) and is administered by the Stanford Language Center. This rSmart newsletter has background information on SOPI.
I'll cut to the chase.
The SOPI test is administered under highly controlled conditions. The student only gets once chance, ever, to take the assessment. The assessment materials are so tightly controlled access is denied to the instructional staff. There is all sorts of complex authorization requirements for this project.
Sorta tricky to have a Sakai site where the instructor can't get at the materials, eh?
The assessment takes the form of a series of Quicktime movies. Each movie presents a question to the user. The user's response is recorded in a Quicktime movie, which is stored away for review by the instructional staff. The sequencing of the assessment is structured through an awkward XML file. To hit the schedule for the 2009 SOPI assessment we decided to leave the XML format as it was - there is lots of room for improvement.
The SOPI Application is written in Java, using the Swing Application Framework (JSR-296), Axis, and Apple's Quicktime for Java. A desktop app was written to avoid all the Java / Quicktime / Sandbox / multi-Browser issues, and to push security up several notches. It does all the things you expect - pretty boxes with movies, live audio waveforms, etc. I've a writeup in the works over at www.czwxllc.com, my companies site, and I'll put up one of the screen play movies used during development so you can see it.
To support the (baroque) security requirements the SOPI assessment resources are not stored in the Language Classes' Sakai site. Rather a 'sister' site is created. We called these Sopi Resource sites officially, but most often just 'sister-sites.' This is a custom Sakai site type with a new role, the standard Resources tool, and a real-time monitoring tool created by Zach Thomas of Aeroplane Software. Sakai site properties are created which provide references to class site sections - a single SOPI Resource site can provide content to rosters from various class-site sections.
The test is given in a controlled lab. 20 to 40 students may be starting the test simultaneously.
Stanford is running a modified Sakai 2.4.x
The SOPI Application uses Sakai webservices to
- support 2 user sessions, a super-empowered 'agent' and the end user
- determine which SOPI assessments are currently enabled
- to get user site membership information
- to get user Stanford affiliation information, which changes the desktop app's UI
- to store user progress, including resume state
- pulling of XML and Quicktime movie content from the Resouces tool
- pushing Quicktime movie content into the Resources tool
As the user proceeds through the assessment the responses are queued up and asynchronously uploaded to Sakai as the assessment plows along. The load-balanced pool of Sakai servers does pretty darn well in accepting 30 odd movies all at once.
The major changes to Sakai to support the SOPI assessment were
- modifying the Resources 'webservlet' tool to not swallow all sorts of sensible exceptions, such as quota violations. These are now reported back as HTTP RFC responses to which the App responds.
- using a locally developed version of Sakai login which has far less overhead. We wrote this code during our first rollout of Sakai at Stanford long ago.
I found this model of Sakai development, that of using REST and Axis, to be really fun and efficient. The more recent versions of Sakai would of made this even easier. I look forward to catching my dev environments up to the most recent Sakai and seeing what drops out of the SOPI codebase - less code, less to break.
My next experiment is to create a language assessment app which uses a cell phone. How could this not be cool?