The Living Schoolbook

 The following is a segment of a larger story that I wrote to attempt to summarize the history of the Living SchoolBook, a research group in the School of Education at Syracuse University.  In this entry I begin to talk a bit about our involvement in the Sakai network and our contribution to that group.  If you haven't read any of the previous articles about the history of the LSB, you may want to look at the previous entries related to this topic.

Our First Sakai Tool

Since we had no experience developing in java or on Sakai, a request was made for funding for consulting services from rSmart in order to ensure that we could design and build a prototype “Goal Management” tool by the next conference.  The LSB and the office of the CIO shared the cost for of a contract for 40 expert hours of rSmart developer time.  rSmart developers met with the LSB team to review the requirements for the tool and made several helpful suggestions.  The rSmart developer believed that the tool would take us one man-month worth of effort to build the tool.  However, LSB developer’s lack of experience with Sakai was acknowledged as a significant challenge.  The remainder of the consultation contract was to be held in reserve to be used on an as needed basis to answer LSB developer questions.    

Two LSB developers (Jim Pease and Huan Yang) worked on the tool development for approximately 3 months with occasional questions to the Sakai community development lists and rSmart developers.  rSmart's Chris Coppola and John Ellis met with us to review the requirements document for the project on a couple of occasions.   By the end of that development period and we were able to more fully describe the impending business need for this tool as well as demonstrate a prototype tool at the Austin Sakai conference. 

It should be noted that we felt that having a relationship with a Sakai commercial affiliate like rSmart would help us the risk of NOT being able to meet our own goals.  In retrospect, the community lists and existing documentation were very useful to our developers and the contracted time with rSmart was barely scratched.  We only used about 3 hours of the 40 we had budgeted for.

Other contributions - both ways

Engaging the community in discussions about what a portfolio should be and how to use the software to get what yu want out of it is a valuable part of the open source model for software development.  I believe that the information I took from the development, testing and documentation efforts for Sakai/OSP 2.0 and 2.1 and helped to shape and change our own expectations of our own assessment system.  Our efforts may have helped to nudge the community in a sllghtly different direction when thinking about portfolios as well.  It should be noted that as of the writing, OSP 2.4 requirements state that matrix cells and wizard pages will be "goal aware".  The University of Michigan, Indiana University and rSmart appear interested in this new approach to portfolios.