The Living Schoolbook

I sent an email out to a few people in the OSP and developer community in Sakai with the following contents. I need to flush this idea out a little more. It sounds a bit preachy and a probably fails to convey the idea I have in my head.

The Sakai community has developed a Java based system that allows developers to deploy services and tools for use in collaboration, teaching and learning. The Sakai developer community has, with input from faculty, developed many tools for use in teaching practice. Many of these tools are modeled against existing tools present in other learning management systems. Common workflows found in other systems' tools are captured and embedded in tools like the Sakai assignment, discussion and test tools (for example). To faculty and students, the UI and workflow that are presented by these tools ARE Sakai. To them, the tools are the services that Sakai offers.

Sakai (and many other Learning Management Systems) present a challenge to institutions, teachers and learners. Communities of practice that desire to adopt Sakai for their own use are often forced to adapt their practice to Sakai tools or to develop/modify tools to meet their own needs. As the local community changes their practice over time they have to continuously modify tools to accommodate the changes. This is a costly process that may impede adoption and acceptance by teachers and learners.

The faculty and students at adopting institutions has to learn to skip from tool to tool to support their practice. For example, if an instructor wants to present some reading material to students, ask them to write an assay about the reading assignment and engage the students in group discussion about their learning, this sequence requires no fewer than three Sakai tools. If the teacher wanted to have the students peer review each others work and then reflect on the entire assignment, the workflow gets very frustrating to manage.

A movement in the Sakai community is growing around the frustration behind the user experience. This community consists largely of designers and Human Computer Interaction specialists that plan to spend a lot of time in the field doing heuristic evaluations of existing tools and ethnographic studies of how local communities of practice work. These experts will be able to make incremental improvements to the existing tool design and model new tools that will be able to support certain workflows that occur within those communities of practice. The success of these new or improved tools to meet everyone's needs depends on how well those local workflows reflect universally accepted practice. Surely, experimental changes will be require further local development to provide new features. In general, the "business logic" of a community of practice will be encapsulated in each tool design.

As an instructional technologist, who sits somewhere between the faculty and the developers, I see a gap between the UX group's effort and the developer's technical knowledge of system architecture. There is a need for a new type of community participant that engages the pedagogy group to gather requirements around services that make sense to teachers and learners, and enlists the expertise of the developer and UX communities in the creation of an abstract layer of pedagogical services and basic UI components (not tools) that provide a selection of discoverable services in Sakai that will allow communities of practice to model their own teaching and learning practice independent of specific tool design.

The Goal Management project that started at Syracuse University began as a single tool that allowed a user (likely a teacher or program administrator) to articulate learning outcomes. We made a modification to the standard assignment tool to allow the teacher to identify the learning outcomes (from the goal management tool) that each assignment addresses and then later assess students' work in terms of those outcomes. The original plan was to make a number of other tools (discussion, tests, OSP) "goal aware" as well. This is very difficult to do well for a variety of technical reasons. Technical problems aside, a pedagogical problem exists with this approach. Once the tool is made "goal aware", that functionality exists everywhere. We have added a configuration to turn it on or off, but it lies at the tool placement level. This means that the creator of the site needs to make a decision to enable a feature when they create the site or later go back and turn it on. What seems like a better approach would be to establish "planning" and "assessment" services that would always available to a user in Sakai, regardless of the tool being used.

We can envision a scenario where a workflow is authored by a teacher where they invoke a "planning" service to describe the next activity, complete with deadlines, outcomes and rubrics. The teacher then invokes the "assignment" service and deploys their activity. Students log into Sakai and automatically invoke a service where they see that their teacher has just asked them to write an essay. They write the essay and invoke the "turn in" service and upload their file. The teacher sees the student has turned in the assignment and invokes the "assessment" service that prompts them with their planning information, the student's work and a means to assess the student. They see the student needs help on this assignment and invoke the "private discussion" service and begin a week long dialogue with that student about how they could improve their understanding on the topic. As the private discussion progresses, the student makes some notes in their reflective journal about something important that they just realized. The student later turns in their assignment and the teacher reassesses the work.

The above scenario can be supported now with existing Sakai tools. However, there is no thread that ties the different activities that would occur across several tools together. Further, this scenario would currently require some significant overhead and planning on both parties. Jumping from tool to tool; discovering that new content was available; and realizing that the content in one tool related to previous activities in another tool all contribute to the problem. Moveover, if a new service was created for a locally created need, it too could be invoked and inserted into the workflow without changing the other service designs.

I believe that there may be a large percentage of faculty needs that could be met by thinking in terms of services that have meaning to our primary audience, rather than thinking in terms of tools. A great number of us understand the frustration that exists when we talk to faculty about how to use Sakai or how best to develop a tool. We have to keep in mind that these faculty are the tip of the iceberg, the early adopters that elect to engage a highly technical group because of the recognition of the potential. The majority of our audience lies outside of this group, waiting for us to start talking their language. Let us make it our mission to learn to do so.