I just created a few screencasts about the Open Source Portfolio. Hopefully this documentation (funded by Weber State University) will help others understand how to use the OSP tools in Sakai.

I start by introducing how to setup a worksite in Sakai, how to import data structures from the community library and how to recreate a teaching "Best Practice" from another university as a way to jump start the portfolio discussion in just three screencasts.

See the complete docs here

Setup a demo site

Import and export a form

Recreate an Existing Portfolio Best Practice from the Community Library

I've been working with a small team at Weber State to give them a quick "leg up" on some of the "ins and outs" of the OSP tools so that they can move forward with an initial implementation of their own matrix and portfolio template. I asked Vicki Napper if I could quote her, because I think she really nails a problem that the OSP community has.

She said (in reference to the built-in ambiguity of the tool suite):

"Should the term open source mean ...without an opinion about use? I don't think so. Open source's power is that many people are thinking about common problems...but they need to document why they chose the solutions they did and why it works for them."

I think its telling that (given the popularity of ePortfolio's in education circles today) OSP doesn't have many adopters nor contributors. The charge ahead is largely lead by a few large institutions. I stopped for a second and told her my opinion:

"Its rather amazing that their isn't some "out of the box experience" isn't it? Not even a "basic portfolio" that lets you throw together a few pages. The community of schools that have been building it have been very cautious not to pigeon-hole the software into one or two uses. None of us like it, but are unsure what common portfolio experience "other" schools would find most useful. This would require a research (maybe even a marketing) budget to discover what "other people" want. Keep in mind that the schools throwing resources into OSP are ALREADY using it to support THEIR portfolio processes and any resources they have for OSP are spent on that activity...not on the kind of research that would likely benefit newcomers. Of course, they are open to new ideas, but often the effort required to participate in the discussion is a barrier to the input of new ideas."

I'm feeling empathy for Nathan Pearson as he tries to get his head around the basic functionality of OSP, its application and history. I think Nathan has the newcomer's perspective in mind in his UX effort.

I wonder what sort of research effort should go into this before Sakai 3.0? It would seem an ideal project for a UX group to take on as a purely exploratory piece....and not just from current users, but from potential users that are frequently turned away by the traditionally high barriers.

I recently have begun working with a small team at Weber State University. Their School of Education is interested in moving forward with an OSP implementation. My proposal to them included:

• an OSP overview
• informal training of the tools they need to complete their project
• documentation of those tools on the public Sakai wiki

This approach will benefit the team involved in the immediate project, their successors and the entire Sakai community. We’ve allocated about 15 hours to writing an overview of the tools and how to use the “Forms” and “Portfolio Template” tools. The effort will be largely guided by Weber State’s needs, but I believe that any newcomer to OSP will find the documentation we write to be useful.

A few weeks ago I mentioned that I was interested in doing a bit of freelance consulting for OSP. A couple people asked me if I was available/interested in doing work outside of OSP for Sakai in general. Of course, I am. The Reports tool (now core, like the rest of the OSP tools suite) seems to blur the boundaries between OSP and Sakai. In a nutshell, the reports tool allows someone to define SQL based reports that can be run against the live database or a set of data warehouse tables (you may have noticed a bunch of tables named "dw_xxxxx" in your instance). To complicate matters, much of the data related to portfolios are stored in XML on the file system and are therefore unavailable to the reports tool unless converted. The system is powerful, but poorly understood by the community and sparsely documented.

I have set up an account and a project at fundable.com to see what sort of interest the community has for this effort.

The Sakai Reports tool documentation needs improvement.

Many schools deploying OSP as a portfolio system want to use custom reports to aggregate data for institutional purposes. The reports that the community has included in the OOTB experience have little to do with the type of data that schools would actually want to report about. Building custom reports for your institution makes a lot of sense, but very few schools have been successful at it because they just don't know how.

I would be interested in investigating and writing related community documentation in Sakai confluence if anyone is interested in funding my independent effort to do so. My initial guess is that I will probably need to also document the job scheduler and the data warehouse in order to successfully move the documentation forward. While it is difficult to promise a "complete package" will result from my effort I feel that a few good interviews and some time devoted to understanding and disseminating the capabilities (and limitations) of the report tool functionality would benefit the entire Sakai community.

I whipped up some rough-and-ready portfolio items for the upcoming e/merge2008 conference for Stephen Marquart in response to his questions about possibility to use the OSP tools to do something he normally does with a simple php script.

He wanted a simple form where a conference organizer could enter structured data about a "presentation", including a (rich text) description, as well as presentation files (pdf or PowerPoint) for download. I created the form to prompt the user for that information.

I also created a Portfolio Template that (by default) shows the list of "presentations" added to the portfolio with links to detail pages. Stephen wanted to be able to show the appropriate icon next to each presentation file, but I realized that the mom-type of the file does not get brought along in the XML document, just the URL (and that isn't even complete).

Anyway, here is my "rough and ready" answer to his request:

• Conference Presentations Portfolio Template
• Presentation Form

I'm sitting on our porch swing on a hot Saturday morning. My kids (2 and 5 years old) just ate their pancakes and are playing in the sprinkler and plastic pool. It's going to be a hot one and I probably need to break down and put the air conditioners in the windows today. For the first weekend in quite some time, I am probably not going to work…on anything…on portfolios, Sakai, coursework, side projects…nothing…I'm going to spend some family time.

Last month I finished my long-in-coming master's degree in Information Management at the iSchool at Syracuse. My eight-year stint at Syracuse University supporting students and faculty is complete. I did all that I could to make my recommendations for next steps and close the projects associated with the grants that funded the Living SchoolBook.

I don't have a "real job" right now, at least not in the sense that I really wanted or planned for. Without getting into the details, I am currently paying the bills working on a couple of Sakai/OSP and Drupal related projects out my home. While I enjoy working with the Sakai and OSP community and software, there are issues with doing this sort of work as an independent consultant.

First of all, a lot of what makes working with an open source project a very rewarding experience is the opportunity to "get in the game" and participate in the "upstream discussion". When employed by SU, I was encouraged (and paid) to participate where I could and to help shape the direction of the software in a manner consistent with our objectives. As an independent consultant, I feel that I still need to participate and not be a "free rider" on the community of professionals that work so hard to make this useful software. However, I recognize that I will rarely be paid to engage in these conversations and I do so at my own short-term loss…one less beach trip for my family in exchange for my personal gratification and credibility in this meritocracy-driven community.

Second, there is all of the "meta-work" associated with managing your own micro-business. Filling your own business pipeline, creating invoices, learning the business tax rules and all of that sort of stuff is more time spent not DOING anything that adds value to any project or my quality of life. I hardly even know what I am talking about here…I am so green…

I am passively pursuing an option for more "stable" employment in the community, but part of me asks (Letterman-style), "Is this anything?" about the whole Sakai/OSP self-employment idea. I wonder what sort of demand there is for someone like me to provide consulting services to schools looking to engage in agile, short-term projects around the OSP tool suite.

It strikes me that with the right people in the room, a small, devoted team could make great strides in an OSP project in just a 1 or 2 week sprint if they had just a little "leg up" and just-in-time "support". I could provide that "leg up" and help a small team to make something useful quickly, document ideas for new enhancements and features…and LEAVE when they want me to. The transaction costs within a small team are much less expensive than between that team and me, so knowing when to leave (and for schools to know when to tell me to leave) is an important decision that an institution would need to make in order to ensure that they were getting the biggest ROI on the project.

I think that these sorts of sessions could spin-off a lot of documented examples and material to contribute to the community library (the OSP community's emerging body of knowledge around deployment strategies and data structures). I could play a role in documenting projects I am involved in and ensuring that they are contributed for others to use.

Keep in mind, this is not necessarily something I believe is sustainable as a business model long-term; however, given my current situation, I would be willing to discuss how this model might work (or not) for individual institutions. This sort of short-term employment would simultaneously add value to the community and (I believe) be a low-cost way to start getting productive with OSP with real, tangible results that we build together. If this is something you think you want to talk about, let me know.

I have been so impressed by the incredible amount of work and diligence I have seen demonstrated by the administrators, teachers and support staff here at the RINET Sakai conference over the last two days. It is really amazing to me to see the hard work that we did on Goal Management at Syracuse in use by real people. The Goal Management tool and the Goal Aware Assignment tool are one of the key components of the RIEPS (Rhode Island Electronic Portfolio System) implementation of Sakai and OSP. Their implementation is supporting:

• 15 districts
• 25 High Schools
• 40,000 students
• 3,200 teachers
• 13,000 courses

The thing that is "right" about RIEPS is the enterprise decision that they made to support a large school reform movement. It is something that an enterprise decision can do to shape the discussion on a very large scale. By providing support and services around the authoring and assessment of student portfolios as a means for students to demonstrate competency in the state and district standards and expectations necessary for a student to graduate, they are making a radical departure from the world of high stakes standardized tests that most of the rest of the country is involved with. It is a big deal.

Attending this conference are quite a few folks who have been talking about portfolios in the context of "cloud computing", using Web 2.0 tools (Google docs, Twitter, Facebook, etc.) and mobile devices to enable and empower individual teachers to engage students using tools that they already love to use. This very forward thinking group sees the possibilities that these tools afford for "socializing" information amongst the other learners (the teacher being one of those learners) in the class and promoting constructive dialogs around issues relevant to the curriculum. The keynote speaker in the morning was Philip Long from MIT who showed a lot of interesting examples.

As cool as all that was (and it was cool stuff that many folks around the room were really interested in), I feel pretty certain that most teachers will find it difficult to make an investment of their time to research tools that they would like to use and to integrate them into their class on a regular basis. In fact, it might be a bad idea to start developing plans to use a service that isn't supported by your district for a number of reasons:

• They are subject to change faster than you may want them to since you have no relationship with that provider to provide a consistent service
• They may not be regulated in a manner consistent with your school's privacy policies and could be vulnerable to attacks, exposing student information to "ne'er-do-wells"
• The company may be taken over and your data sold

Furthermore, an ad-hoc "cloud computing" strategy draws on the enthusiasm, passion and energy of the early adopters of technology while providing little support for the rest (majority) of other teachers to bring them on board with the change. While the idea of a "Yahoo Pipes-style" mashup of information as a part of a Web 2.0 portfolio sounds pretty cool, its complex nature compounds the above problems and creates a rather brittle model that I wouldn't entertain for long without engaging in serious discussions with each of the component service providers.

While talking briefly with Trent Batson about this idea, he mentioned that he is starting to think less in terms of "life long" portfolios and more in terms of them being ephemeral bits that serve a purpose for a very short time. This was a big shift for me as I had been thinking (and hearing others thinking) of portfolios as the large pile of "my stuff" and presentations of that stuff for various purposes. The notion of a P-80 (Preschool to 80 years old) portfolio was mentioned several times during this conference.

Of course, the flip side of the coin that everyone is sensitive to is an institutionalized/enterpise system that places too much emphasis on institutional needs for accountability and not enough on providing services that provide an environment for authentic learning. Based on what I am seeing here and the excitement that the teachers are describing in having access to a system that allows them to constantly communicate with their students (this is one of the first times I have seen a truly teaching and learning centered Sakai conference), I think that this effort will result in some big changes in the culture of the classroom if it continues to receive the support it needs. Among the exciting things I saw:

• Large numbers of Rhode Island teachers (many of whom professed not to be early adopters) are using the RIEPS system and are really excited about it.
• They have a relationship with a commercial affiliate and seem receptive to engaging in the community discussions relavent to their work so that they can support and change their system at their own pace.
• The effect of the system appears to be a lever by which the RI schools can affect school reform away from standardized tests and towards assessment for learning.
• Teachers are being draw into and are asking for professional development space within RIEPS and having "light bulb" moments in which they see the connection between the technology they are using and how it can be integrated into their classes

One of the most significant uses of the Goal Management work that we did at Syracuse was the RIEPS (Rhode Island Electronic Portfolio System). RIEPS is a product of the collaboration between rSmart, IBM and RINET (Rhode Island Network for Educational Technology). RINET reminds me a bit of the NYS BOCES system and has created a technology and social infrastructure for the Rhode Island School districts to support the goal of meeting standards across the curriculum without degenerating into a high stakes testing situation. The RINET team is hosting the first Sakai conference from with a K-12 focus to share what is happening around the country with K-12 Sakai. This is a different audience with slightly different needs from the higher education community and its cool to see them coalescing as a group. I am here to co-present a higher education perspective to this primarily K-12 audience and to see how K-12 is using (and wants to use) Sakai and OSP.

Michael Korcuska introduced the idea of P-80 and introduced himself by giving his brief biography from elementary school, through high school and then on to college and beyond. He emphasized the commonality and overlap between the needs of K-12 and higher education. There is a common thread and a continuity through life. He mentioned that open source software (like Sakai) is no longer considered "bleeding edge". He made the point that for K-12 systems with very tight budgets, an open environment that does not differentiate features and functionality based on price is a key factor that districts need to consider when making a choice about an LMS. He showed a clip of Father Guido Sarducci's "Five Minute University" (its out there on YouTube) to illustrate the difference between the learning that might occur in an environment of high stakes testing versus the deep learning that happens in collaborative learning environments.

He drew a chuckle when he suggested that the teachers in K12 get involved in the Sakai community by participating in the lists, checking out the wiki and coming to the Sakai conference in Paris this summer (hahahaha!). Remember those tight budgets?

I spoke with Bill Fiske, who has been involved in training teachers in Rhode Island. I asked him how the implementation of the Sakai course management and portfolio system had an impact on the culture of the classroom. He said he believed that teachers still measure their own success each day on their perceived success as presenters. He stressed that the emphasis needs to shift to how well the students did today.

Responses to the question, "What do I want in my collaborative Learning Environment?"

A session was held where the K-12 community was asked what their expectations of Sakai might be. Steve Foehr took notes...here is what he passed on to me:

• Professional social networking tool
• Good content management tools
• Flexibility – build from a variety of learning models
• Interoperability with other tools
• Ability to pull out tools when useful to purpose
• Allow equal access
• Engaging to students
• User friendly, opportunities for professional development
• An environment that replicates what happens in a classroom.
• Remove the walls between educators
• Breaking down the distinctions between learning and accounting for learning
• Equalize technology skills among teachers
• It’s not more work, it’s different work
• How do we manage performance issues when we get big?
• Seamless access to each user’s data, the data you own.
• Multiple loci of control.
• One to two minute videos to show how we use Sakai.
• Showcase of best practice.

Michael Korcuska pledged to get the complete list up on the K-12 wiki.

K-12 issues for coalescing effort

During an afternoon panel discussion a few strategic areas were suggested around which the K-12 community could begin coalescing.

1. Student portfolios
2. Professional development
3. AP courses and credit recovery (making up courses for students that fail a class)

The first two areas definitely resonated with the discussion in the morning in which the participants discussed their current projects with Sakai.

A recent post from Michael Feldstein regarding the lack of an course export feature in Moodle got me thinking. In his post Michael mentions that:

...universities should insist on support for some standard export capability in any platform they adopt.

I know that he is most likely commenting on the decision making process that occurs before an organization elects to adopt a platform. However, when I first read it I wondered, "Insist on that support from whom?"

For schools that deploy proprietary solutions, this is a pretty easy question to answer. You would go to the vendor with all of your support questions, feature requests, complaints and feedback. You usually don't get a lot of options and most of us IT folks feel comfortable with this long standing "one stop shopping" model.

When you decide to use open source software, that same question can be (and has been) answered in a number of different ways. The strategy that your IT group decides to pursue in answering this question can have a lot to say about how vested you are in the "open source" idea of freedom, local control of "your IT destiny", "shared risk" and long term viability of your solution. The institutions involved in the Sakai and OSP communities have approached these questions from a few different directions.

Dipping your toe

Some open source software (notably Moodle in the LMS space) are very easy to setup and configure. It is so easy to do and takes up so few resources that the ROI on the 10 minutes it takes to set up make it really easy to just say, "Wow! This is great" and just run courses with it as it is. I've heard of teachers setting a Moodle server up in their classroom on a desktop computer just because they can. This is frequently the first phase of a pilot deployment of Sakai.

Sakai is substantially more difficult to set up than Moodle. However, there are a few vendors that make running a pilot quite easy via their ASP models for hosting. An institution could simply accept the community released or vendor supported offering and focus on the training and use of the system to support their own processes.

I have a hard time believing that this really leverages the benefits of the open source community. In some ways, this is pretty much the same boat as using a proprietary solution. I believe that an institution needs to engage in the upstream discussion about the design of the software in order to really extract the additional value that a community created software solution can offer.

Hoe your own row

At the other extreme of the spectrum are those institutions that design, build and support their own custom version of the software. Indiana University, Stanford, Berkeley, University of Michigan, Cambridge and the University of South Africa are institutions that have dove in the deep end of the pool and contributed a lot of resources to the discussion and development of Sakai. In many ways, these institutions have the ability and the mandate to change the way that the software works in order to meet their local needs.

In the past there have been some concerns that the direction that these schools were taking Sakai were not always in the interest of the community. They were (and often still are) scratching their own itches by developing new tools or modifying existing tools. Furthermore, it has been somewhat difficult for a school that hasn't decided to pursue this strategy to engage in the often highly technical discussions that accompany the development of these new ideas.

Developer for hire

To bridge the gap between the frequently chaotic world of bleeding edge development and the pragmatic needs of faculty and students some institutions contract with a freelance developer or vendor to span the gap and act as their proxy to deliver the functionality that they need. This make a lot of sense, particularly if the developer/vendor is able to negotiate the community process, build community consensus around an ideas and get other institutions to climb on board with the idea long term. Ultimately, you don't want your idea to be so unique that you need to support it yourself forever. If there is such a need, the vendor needs to build a long term relationship with their client to ensure that the "one off" feature is maintained (with a great cost to the sponsoring university) over the long term.

My gut tells me that this approach makes sense for a few "proof of concept" projects, but if the idea has value to teaching and learning communities, it will be better off for everyone if the project is vetted by the community at some point and rolled into a community release.

Upstream consensus building

Many open source projects have multiple distributions to serve different needs. A notable example is the multiple flavors of Linux distributions, which are amalgamations of a number of other projects that are going on around the world. The Enterprise distributions of Linux typically draw from well vetted and supported versions of it's component projects.

I don't see much in the way of an upstream community from which Sakai/OSP can be derived from. This is part because of the relatively young age of the project. Over the next couple years I hope that Sakai is able to stretch out a bit. I think that the real strength of the vendor supported solutions will come when there is sufficient room in the community to engage the untapped resources of faculty, instructional designers and local developers to discuss and build consensus around pieces of functionality that meet a wide swath of needs.

I think about the current answers to Michael Feldstein's question. What do we do if we want to insist that a piece of functionality exists in Sakai? If you are one of the heavy hitters in Sakai, you can easily engage in discussion and get to developing quickly. If you are school that is currently "dipping its toe" in the Sakai water, that move may seem daunting. It may be far easier to ask a developer/vendor to proxy for you in that discussion. While pushing off the heavy lifting onto a vendor sounds like a good idea at first, we have to acknowledge that vendors take on a lot of risk developing solutions that do not have broad appeal. They also take on a lot of additional transaction costs by negotiating the community consensus building process.

Perhaps the best thing that a vendor can do is to engage a potential client in "process based" consulting to help them get their own voice heard, to make the connections with the right community connections and get that upstream discussion happening way before they invest their own resources in the development of new processes.

I just had a great phone call yesterday with Chip from Serensoft about some posts I had made about accreditation portfolios. I had never met Chip before.

A common feature in many portfolio software packages includes the ability to publish a piece of work for a select group. At the School of Education at Syracuse University we have run a pilot for a few years where students have created portfolios at the end of each semester. Throughout this pilot, the portfolio authoring and review process is compressed into a short time frame at the end of the semester. My observation is that the students view the portfolio as just one more "to do" that needs to be checked off before they can pass their class.

Few students create term papers for fun. There is no motivation to do so. However, some constructivist teachers see the opportunity for students to publish their ideas and receive feedback from their peers and experts in the field. They can imagine their students generating new knowledge from the feedback they receive and discussing what they learned in the classroom. At the same time, they probably worry that their students will make them look bad, that they will say inappropriate things and that they will come under fire as a result.

While the restriction of the audience may be an important for some portfolio authors (particularly when discussing sensitive subjects, like elementary school students), I think that it may be too tempting to guide students to be too restrictive about their audience when publishing. When the emphasis of a school's portfolio implementation is to support portfolios for internal assessment events, it is probably too easy for schools to drop the ball on encouraging and motivating students to publish for outside audiences.

When I wrote for the LSB web site, I was writing for the general Sakai and OSP communities and had one of my rss feeds aggregated on Planet Sakai. When I started, it was a bit of a grind. I was new to it, wasn't sure anyone was reading it and sort of felt like a tree falling in the forest. I wondered if was worth the time it took to write it. Two years and a few months later, when I go to conferences I see that a few people have read my blog. Once in a blue moon I get a phone call or an email from someone (like Chip) who read something I wrote and who asks me a question about it. If I had restricted my writing to a smaller audience, I’m not sure that I would get that sort of feedback. Jakob Nielson and others tells us we’ll never hear from most of the people that see our blogs. That’s too bad, because that criticism/feedback is a big motivator for me to write more. When I write more, I do more research and I learn more.

However, students are not yet motivated and faculty find that getting a self sustaining discussion rolling to be time consuming. The culture of the classroom is one of planned units, curriculum to cover and deadlines. Reading student blogs is obviously new work that competes with whatever they do now and flies in the face of the current culture of the classroom. Building a self sustaining community of portfolio authors and peer reviewers in the classroom often feels contrived and artificial - because it is. See the Jakob Nielson article.

If an existing classroom culture did not exist, I might make the following suggestions to teachers and programs that want to begin using portfolios:

Open it up

Encourage students to publish emerging ideas for a broad audience and use that as fodder to generate classroom discussion.

Make it ongoing

If you have assessment event for which you require students to publish to a narrow audience, also encourage an ongoing, formative blog or journal component to the portfolio that is NOT tied to grades.

Read your student's blogs/portfolios

Make it part of your routine. Give them formative feedback regularly to encourage them to keep developing it.

Point others to your student’s work

I believe that getting feedback from outside the classroom will get student's blood flowing. It will be easier for you down the road to get them to participate in global discussions.