The Living Schoolbook

A Class Journal is a formative, reflective, emergent portfolio.

This data flow diagram illustrates the how teachers and students would interact to create, discuss and assess a private (student to teacher) class journal. Periodic review of student blogs (chronologic, personal, reflective portfolios) is likely to be a common interaction style that many teachers would find useful as an venue for formative feedback.

Blogs frequently allow readers (in this case the course instructor) to leave text comments (which this would also support). However, this interaction style would leverage the ability of students and instructors to identify learning outcomes for the journalling process and allow assessment of each blog entry on an ad hoc basis for formative assessment purposes.

Student blog posts would appear as messages in the instructor's inbox. Instructor's would periodically read the blog posts and send back either plain comments or comments with assessments (as related to tagged goals). An important feature of this interaction style is that it supports the idea that "knowledge is emergent" by allowing students to add new learning outcomes to their Goals and to tag their blog posts with those tags. Assessment of student learning, then, can be done in response to student Goals and Faculty Goals (related to the original activity description).

Again, once the course ends or the student leaves the institution, they have the option to keep a copy of all of these posts, assessments and comments for their own use, much like they do with email.

An important assumption is that a system that can engage in this sort of messaging becomes standardized, allowing students to remix and reuse their content from other activities in multiple classes at multiple institutions.

Discussion data flow in a distributed system looks a lot like email. It should!

This data flow diagram illustrates the how students and teachers could interact in a distributed LMS to engage in a group discussion.

A discussion tool is another typical tool found in courseware. The discussion tool is used to allow a teacher to set of "forums" or "threads" of conversation related to the course material. Like the assignment tool, it also lives and dies with the course worksite.

An alternative approach would be to distribute the messages between the courseware system and a learner centered platform, much like email systems do. The difference between the a distributed leaning management system discussion and traditional email systems would be that this content would be stored in a standardized format that allowed users to easily re-use the content in their other courses or portfolios.

Again, once the course ends or the student leaves the institution, they have the option to keep a copy of all of these discussions for there own use, much like they do with email.

Again, there is a lot of duplicated data in distributed system like this which may end up causing issues for storage. However, this does allow each learner to retain a record of all of the discussions that occurred in their classes...forever if they wish to. Similarly, this frees the institution from maintaining the course indefinitely "just in case" students need access to their data.

An important assumption is that a system that can engage in this sort of messaging becomes standardized, allowing students to remix and reuse their content in multiple classes at multiple institutions.

Assignment data flow IF a system was distributed, allowing students to truly own their data

This data flow diagram illustrates the how students and teachers would interact in a distributed LMS to carry out the traditional graded assignment workflow.

A frequent use of courseware is to assign work to students, collect that work from students, assess the work and release the grades to students. In most courseware systems, this is all done in one tool. The Assignment tool (or the assignment and gradebook tools) "live" in a course. The design of courseware is mainly to facilitate the instructor's ability to manage the course.

An alternative approach would be to distribute the various transactions between two systems, the courseware system and a learner centered platform. Each set of tools would be designed and configured with the primary user's interest in mind.

The student would receive a message in their "inbox" with the assignment instructions, learning outcomes and rubric for the assignment.

The student would then do the work, saving their "drafts" in their own system and eventually sending back a response to the assignment with their work attached. Note that a copy is sent to the instructor, with the original content still on the student system.

The teacher would receive the student work in her "inbox" and (assuming that there is to be no formative feedback) evaluate the work against the rubric and releasethe grades back to all of the students.

There is a lot of duplicated data in a system like this which may end up causing issues for storage. However, this does allow each learner to retain a record of all of the assignments, work and assessment data that occurred in their classes...forever if they wish to. Similarly, this frees the institution from maintaining the course indefinitely "just in case" students need access to their data.

An important assumption is that a system that can engage in this sort of messaging becomes standardized, allowing students to remix and reuse their content in multiple classes at multiple institutions.

I am giving a presentation to a smallish group of 4 people today at FCMS. Here is the "teaser" provided on their site:

Portfolios can be used in a small classroom setting to organize and present a project or can span a student's entire education experience. The portfolio experience can be designed to be a highly structured guidance to scaffold students' learning/thinking or can be left as a blank canvas for students to form their own ideas and organize their own learning experiences. How will Syracuse University think about portfolios? Expect to engage in thoughtful conversation about portfolio evaluation techniques, scaffolding processes and types of portfolios.

I made a screencast of the OSP setup we have here in the School of Education. I wasn't able to interview a student so that I could show off their portfolio, but it really does look pretty good.

Instead, you get to see some test data... Ipsum lorem...

The file is pretty big (56MB) and it doesn't "stream" well. I used IShowU to make it and for $20, its a pretty good little app! I just wish it would create a "fast start" movie. Maybe I missed something in the setup...

Regardless, I tried to take the viewer through the following:

• Drivers behind our pilot
• Our plan for organizing students into cohorts
• The types of sites we use in our instance of Sakai
• Some documentation and a conceptual model I wrote about Portfolio Templates (on confluence).
• Some preliminary web designs for what we wanted the portfolios to look like.
• A description of the different data structures created to support our plan and their availability through the Community Library. (See the attachments to that page of confluence).
• A demonstration of what evaluators get to see when they look at student portfolios published using our "Portfolio Review" Template .
• A description of our alternative method for assessing student portfolios using the Data Point tool.

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.

Our faculty have settled into a 1-4 rating scale for EVERYTHING that we do in the School of Education, regardless of the activity or the standard being measured in our assessment system of Goal Aware tools and OSP.