More information is available on the managed Sakai 3 project to deliver Sakai 3.0 by the end of June 2011.
- Welcome and Overview of Session
- Portfolio Innovations to Date in Sakai 3.0
- U of Michigan - Erica Ackerman
- MATI Montréal - Jacques Raynauld
- University of Capetown - David Horwitz
- New York University - Lucy Appert
- Portfolio "Action" Verbs
- Sakai 3.0 Teaching & Learning Lenses
- Viewpoints of Future Users of OSP
- A Portfolio Vision Statement for Sakai 3.0
- Discussion Groups on Topics Generated at this Session
- Recommendations & Wrap-Up
- Janice Smith, Three Canoes
- Lynn Ward, Indiana University
- Robin Hill, University of Wyoming
- Jacques Raynauld, HEC Montreal
PowerPoint from Planning for Portfolio Functionality in Sakai 3.0
Overview of Session
Several participants gathered in Denver for the session on Planning for Portfolio Functionality in Sakai 3.0. OSP Community members shared how work on portfolio "action verbs" has been integrated into planning by the Sakai Teaching and Learning Community for the development of Sakai 3.0. A large part of the session was devoted to four break-out sessions on the following topics: Personas, Migration from Sakai 2 to Sakai 3, Integrating Newcomers, and OSP Governance - Community Organizing Moving Forward. Here is a brief summary from each of these sessions based on the notes gathered during the small groups.
Small Group Recommendations
A question had been raised during the initial part of the whole group session regarding the importance of knowing and documenting the different perspectives of the various users of portfolios (e.g. faculty, students, institutional staff). What are the users' goals? What are they expecting? What portfolio functionality is currently used and what is still needed as we plan for Sakai 3.0? It was suggested that portfolio user research be conducted in a similar manner to the successful work done on the Learning Activities project, which used Goal Directed Design (GDD) as a methodology. "Goal Directed Design describes a six-step process for talking to users, analyzing what they say and do, and most importantly, making decisions about whether different users can be satisfied by the same interface or will require different interfaces." (See more on GDD at: http://confluence.sakaiproject.org/display/UX/Goal-Directed+Design). People interested in participating in this type of research could take advantage of the experience of those who were trained in GDD via the Learning Activities project. By interviewing different users, the existing personas could be extended and gaps identified in the work already completed by both the Learning Activities group and those working on the Sakai Learning Capabilities Design Lenses.
Migration from Sakai 2.X to Sakai 3.0
The migration group raised important questions regarding how existing users of portfolios in Sakai 2.X will migrate to Sakai 3.0. Some institutions have a large number of portfolio users, like Virginia Tech. LOI in The Netherlands has 6,000 portfolios at present and Rutgers has 6,000 portfolios as well. How should these portfolios be migrated? Is is only necessary to migrate the data? Questions were raised about going from the old model to a new one, but what is the new model? OSP in Sakai 2.X has value; matrices and presentation portfolios address very different needs at different institutions. One suggestion was to focus on portfolio IMS standards and build the new tools around them. Another suggestion was to be sure that forms in Sakai 3.0 do not require users to know the XML stack. There was also discussion of new functionality for the matrix which could lead to improved use of portfolios for evaluation and assessment.
Integrating Newcomers into the OSP Community
The newcomer group emphasized the need to find better ways of welcoming those who are new to portfolios and new to Sakai. For example, a glossary of Sakai/Portfolio terms would be helpful in introducing new concepts to conference attendees and casual visitors to Sakai Confluence. Terms to be defined in the glossary would include Confluence, Hosting, Collaboration, Teaching and Learning, Open Source Portfolio, Samigo, Trunk, Contrib, Provisional, Core, Skin, and JIRA. The complexity of portfolios and of the portfolio tools in Sakai is scary. There is an ongoing problem with curious administrators and faculty in relation to the portfolio tools in Sakai. "I have heard a lot about Sakai/OSP. What does it do?" Marketing Sakai portfolios is also difficult. Portfolio beginners need help in navigating the differences, as well as the transitions, between student presentation portfolios, professional portfolios (for promotion and tenure as well as or other professional accreditation.), course portfolios (using rubrics to evaluate student work in relation to standards), and institutional accreditation portfolios. Schools that are driven to use portfolios for purposes of institutional accreditation or advising (leading to better retention) need a better API allowing integration between student and coursework and institutional information. Beginners also want more help in trying out portfolios before committing to the process.
OSP Governance - Community Organizing Moving Forward
The governance group talked about breaking habits that have long been in place in the OSP community. We have put too much weight on our current way of doing portfolios in Sakai and our current way of organizing the OSP community. Is this the same community moving forward? As portfolio functionality is progressively integrated into Sakai, should the OSP community become more of a special interest group than a separate community? Do newcomers join portfolio groups or something broader? How do newcomers enter the portfolio community process? Is there a place for smaller contributions to the portfolio functionality in Sakai as well as larger contributions? Is there a way to value and acknowledge different levels of commitment among community members stemming from some being paid for their work (by their institutions) and others volunteering their own time? We need to balance institutional needs with community needs as we consider how to come to consensus on the future of portfolio functionality in Sakai. There should be more alliances across institutions as well as alliances across the community, in addition to the promotion of institution-centric needs. Perhaps consensus is needed only when it matters rather than at all decision levels.
The new teaching and learning lenses require rethinking of the tools in Sakai 3.0. The community needs to collect all available ideas to continue the lenses into practical terms. If we follow the analytic thinking of the portfolio action verbs too closely, we are in danger of losing the big picture. We should no longer assume the primacy of "tools" and "outcomes," but focus on higher level concepts such as "folio thinking" and "integrative learning." There is no longer one portfolio but many portfolios in Sakai: portfolios for learning, assessment, presentation, accreditation, and a number of others. We need to manage multiple types of portfolios in Sakai, In addition, many portfolio functions will have a mixture of purposes. (For example, assignments may have some reflection and feedback components.) As a community we can collect results of various institutional experiments with portfolio functionality in Sakai 3.0 to feed into the design process. These R and D experiments are exploratory and do not indicate a commitment to how future portfolio functionality will be expressed in Sakai. What can we learn from the R and D process? How will experimental designs feed into community vetting of Sakai 3.0 code? Can user and usability studies help us determine how best to build portfolio features into Sakai?
One area of potential change is the OSP Community call. It was thought that JIRA should not be the primary way to set the agenda for the call and that the agenda should be re-focused to become more broad-based. The agenda should be posted ahead of time and should include time to work on portfolios for Sakai 3.0. One suggestion was to use alternate weeks to focus on functional issues and technical issues. (A similar suggestion after the conference was to alternate between these areas on each call, with functional issues coming first one week and technical issues the next.)