Workflow for coursework and portfolios

Data Flow Diagram of SyrCLE
Data Flow Diagram of SyrCLE:

Courseware and portfolio systems are usually designed as relational databases to allow a minimum of data duplication while giving users different roles and permissions to interact with their content and data. Students and faculty have expectations about how different tools should be used to organize data into familiar structures with implicit rules for interacting with the data in those tools. The design of these tools have not not allowed a lot of interplay between the tools. It is difficult to publish a portfolio that reuses classroom content (ie: assignments and discussion threads) that the student otherwise has access to view and manipulate in the limited manner the tool allows.

Furthermore, if a student enrolls in another institution or another class that doesn't use the same instance of the courseware, the data from the different classes can not be combined to create new content.

What is needed is a student centered content management system that serves as the student's virtual backpack and their main platform for lifelong learning. The interface between their content management system and the classroom management tools deployed in a LMS has not yet been designed.

This data flow diagram is intended to describe the flow of information into, out of and within a distributed, networked LMS that has two main components: course content and student content management tools.

A couple days ago I shared some "reconceptualizing" Sakai and OSP based on some feedback from a couple of our faculty and the problems that Dr. Joseph Shedd (our PI) has shared in our meetings between Weber/UMich/Portland/Virginia Tech.

From these meetings I think I am hearing the following (my own opinions are sprinkled all over here):

  • Dr. Shedd wants to be able to run a pilot portfolio program in Syracuse high schools that students can take with them to college. In my opinion, this shouldn't merely be an export of some files or presentations....it should be richer than that...way richer...it should bring along everything the student did in their coursework. All the content, semantics and assessments that they ever got. Anything less is, well, lame.
  • The attendees at the last Goal Aware BOF were talking about the next "Goal Aware" tool. It sounded like it should be something really general and blog-like to me...something that should allow the student to select some of that old content, tag it with their own goal (and other) metadata and reflect on it, creating a running journal of content, reflection, meta-reflection, etc...this is some folks idea of a great learning tool.
  • Our current crop of Sakai tools have been independently designed and developed as silos. There is no communication between assignments, discussions, portfolios. Jim Pease has been sort of stymied and frustrated even thinking about how to embed the Goal management and rating interface into these tools. The result is functional but far from optimal from a usability perspective. The metaphor of "bolting on" helper tools to add functionality results in needless extra clicks to accomplish tasks. If I were king I would want a suite of simple tools that just work to support a few interaction styles. Less is more. In Sakai it seems like more is more.
  • The current usability issues with OSP and Sakai seem to me to be due to one of a couple of things:
    • Either the design tries to accomodate too many things
    • or the design was done around a workflow that doesn't match what we really want.

I started to create a diagram (that is NOT done yet, but I would love feedback) to get my head around what I think would be a better workflow for a system designed to create portfolios.