Well, maybe not real progress, but it feels to me like I’m reaching a definite conclusion. After lots of looking around, flirting with open source (Sakai/OSPI), discussing and checking recommendations from all over, including the good folks at TappedIn, and the solutions in use by colleagues at other CUNY schools, I came to a list of criteria/needs for any eportfolio solution we could use.

Let me lay it out–

We’re going to be starting in fall 2006 with a group of students (200-250) starting the Teacher Education program. Eventually we’re going to extend the program to other departments, and other student groups, but we won’t find a 100% one-size-fits-all solution, especially not one that can work well for more technically advanced programs like Multimedia Programming or Video Arts and Technologies.

So with an eye toward the TED students to begin, and enough flexibility to expand later, these are the criteria.

• Ease of use–the system has to be clear and simple enough for technologically unsophisticated students (and faculty) to learn with a minimum of training and support.
• Reflection-centered–the system has to include not just opportunities, but demands, for self-reflection and comments from others. A plain collection of documents won’t be sufficient–the system needs to build reflection into design and implementation from the start.
• Transportable–the material in the eportfolio needs to be easily assembled into a presentation that can be available on the web, or burned to CD, or moved to another eportfolio system, when the student graduates or transfers.
• Brandable–we need to be able to create separate templates, with logos and distinctive setups, that will identify the portfolios with our institution and with specific departments/programs within our institution.
• Institutionally-funded–we need a solution which is supported and financed by the college–not by students. This rules out many of the commercial publisher’s products. We may explore other options for continued access after graduation, but for enrolled students, and for a period of time (how long?) after enrollment, the college should pay the costs.
• Robust–we need a system built on reliable back-end programming, scalable for large numbers of students in the future, and relatively crash-free and minimally bandwidth intensive.
• Versatile–we need to be able to use many different file types (including various multimedia formats), and have choices (at least within reasonable limits) about graphic interface and design templates (“skins”).

And there’s probably more I’m not thinking of right now. But that’s the major list, in no particular order.

The one system which seems to come closest to meeting all those criteria is Johns Hopkins’ EP. It’s a bit on the expensive side, but the license is perpetual, for any number of virtual installations or users. So it’s a fixed one-time expenditure for the license, and ongoing costs are limited to hardware upgrades and ongoing training. That’s a big plus, because once the system is in place, I can use the budget line where it’s going to be most needed, for training faculty and supporting students and faculty. That can get expensive as the project grows, and I don’t want to have to keep throwing money at licensing.

I’m about 90% convinced at this point that this is the best solution for us. I still need to get the buy-in, of course, from my IT folks, faculty, and higher administration. But there’s an open window here, and I’m hoping that in the next week or two I can pull something through that window.

If we’re really going to be up and rolling in fall 2006 (as I want to be), it’s time to get the pieces in place.