These comments are in response to the Sakai 3.0 Proposal at the Sakaiproject. A shorter version was posted to the Teaching and Learning email list on the Sakai Collab site. The original version is on another page.
First, my background with Sakai and online learning management systems: I support instructors at the Stanford Language Center, which covers foreign language instruction for undergraduates and ESL for graduate students. I also teach in the ESL program for graduate students (English for Foreign Students), and have used Sakai since we began piloting it in spring of 2006 as CourseWork 5.0. My familiarity with online course learning management systems also extends to using it as a graduate student, where I used CourseWork 3.0 (aka CourseWork Classic) , in courses for a grade. However, my responsibilities now allow me to have super-user permissions on our current version of Sakai (2.4), and I participate in many of the support and planning meetings.
Overall, I found the possibilities raised in the Sakai 3 Vision proposal to be quite exciting. The proposal to strengthen Sakai as an academic collaboration tool is very encouraging, since online tools have so much to offer in this area. Improving the content creation ability is also a welcome addition to the proposal, especially because the idea of a “flexible widget-based user experience” reflects current trends in consumer-based operating systems. Also, the move to look “beyond sites” will add much needed flexibility to Sakai, perhaps even in areas beyond those discussed in the proposal.
However, while these are all very important potential improvements, I felt that perhaps there might be other areas that deserve consideration. There is a need for more focus on the enhancements to one of the tasks that Sakai already does rather well: managing courses. There is huge potential for improvement in the way that Sakai can support teachers, beyond student-teacher and peer relationships, but I see nothing in the vision proposal related to these areas. For example, it addresses how awkward content creation is, but does not mention how this varies by role. Students (in “access” role) may spend many hours working in Sakai, but it is usually across several courses, while instructors (in “manage” role) must plan courses and lessons, and then assess the range of students in the class. User interface issues are immediately apparent: most student-level pages will fit on one screen, while instructors usually have to scroll to see a full page, often with the Save button at the bottom.
However, beyond user interface issues, Sakai seems to be designed with only a two-dimensional teacher-student interaction in mind, especially when looking at the roles and possible permissions. The proposal’s emphasis on collaboration addresses peer level interactions, but there is no mention of any possibility for establishing hierarchy. However, hierarchy is a reality of education around the world: teachers are often grouped together into units such as grades and departments with administrators such as coordinators and department heads. Curriculum is mandated from above, or shared among instructors, but often delivered to students in a very different form. In the department where I work, we have tried to create a set of permissions that would enable a coordinator, who is in charge of a group of instructors, but we ended up just creating new “resource” sites just for instructors to get mandated material and assignments. Even then, however, the roles are not what we would like: If the instructors are made students in that site they can download documents, but cannot export assignments. Consequently, they are left as instructors, but coordinators have found cases where instructors have accidentally deleted material. Also, coordinators create certain required assignments that instructors import from these resource sites and use for the term, but if they find there is a mistake, they need to have instructors download them again. Ideally, however, if the author makes a change, it should propagate out to all copies. This has been implemented for assignments within a site here, after considerable planning and effort by the developers, but there is no concept of a hierarchy beyond the site.
The vision proposal also does not show an understanding of the different areas where teacher-student interactions happen. Sakai seems to be almost entirely skewed toward facilitating homework such as assignments and reading materials, with very little in the way of facilitating a 70 minute classroom lesson. If our concept of a 70 minute lesson is simply a lecture where students take notes, then, indeed, there certainly is not much to facilitate, but if we look at the types of activities that expert teachers might make use of in a lesson, we can see many more possibilities. Small groups are almost always part of these activities, so it seems that the ability to quickly make ad-hoc groups of students, and provide each one with unique, permission specific resources would be a good place to start.
One of the tests I use for any application of classroom systems is a listening activity for language learning that I have worked with for many years. In the low-tech version, I prepare two short (30 sec) audio clips of news or some other natural speech, along with a transcript for each. I put students into two groups and give each group one of the transcripts and a pair of scissors and tell them to cut out 15 words to make a fill-in-the-blanks listening exercise for the other group. When they are done, they exchange cut-up passages and listen to each passage once or twice (as a group) and try to fill in the blanks (as a group). The object of the activity is for them to try to figure out what is difficult to hear in natural speech (function words and reduced forms). Translating this to a high-tech version seems like it would very straightforward, but I have run into several difficulties. Using the resources or assignments on the Sakai site is ruled out from the beginning, because any documents uploaded are visible to all members. The drop-box is a good (almost low-tech) way to do it, but it requires putting a copy of the document into each and every student’s drop box, keeping track of who is in what group. Then the “switch” requires distributing the group-created problems one by one again. Also, with this activity, as is often the case with in-class work, there is always very little for the individual students to go back to if they want to review. Moving to a high-tech implementation should accomplish this, but in reality, is not straightforward. Finally, it is important to note that instructor control is essential: Once the playback portion starts, allowing only one pass at a time through the audio really emphasizes the characteristics of natural speech that make it difficult. Unfortunately, while a teacher can control this trivially with a cassette player in front of a class, it is almost impossible to control over the on computers with individual users. A couple years ago, I did something similar to the drop-box option in our language lab, but found that the activity was far less communicative than the low-tech version, because each student was on a separate computer, reading the transcript and listening to the audio file with their headsets on. This experience showed me the individual nature of student-computer interactions, which runs against the communicative aims of the language classroom. The solitude starts with the first login, which leads to a private page, but could be reduced by somehow providing the resource to a page that is shared by all members of that ad hoc group, and viewed on a single, shared screen – this is essentially a hardware requirement and is perhaps beyond the scope of Sakai.
Also, I found myself somewhat perplexed at the inclusion of social networking among the primary driving forces in designing the next generation of Sakai. If this is meant to be an effort to enable RSS feeds to be sent out and pulled in, then I can see many benefits if authentication and privacy issues are addressed. However, many institutions use Sakai as a course management system, and therefore rely heavily on the ability to implement authentication so that students can’t see what teachers do until they need to and the public can’t ever see what students do. Social networking is very exciting and useful, but it seems that Sakai would be better going with its strengths, rather than trying to do something that Facebook, MySpace and LinkedIn will always do better. Sakai does a good job of facilitating course management, and can offer the benefits of working with an open community, but institutions need to retain and guarantee control of privacy and of resources in their own implementations.
Finally, there is also mention of open teaching practices. While this may be a worthy initiative to contribute to education on a global scale, I think that many teachers are not very comfortable with the idea of their materials being available to an audience beyond the students enrolled in their course. The lessons they create are the product of all of their education, work and experience and some teachers are very hesitant to just give that away. Just as facilitating classroom interactions would be an area for Sakai to improve, the ability to facilitate distance learning is another important area to develop, but it is difficult to imagine how a conscientious teacher could commit to providing a useful level of interaction with an unspecified number of students.
I feel strongly that we should not miss this opportunity to use Sakai 3.0 to re-think the LMS and academic technology in general, and this will involve serious consideration of what Clay Fenlason termed, the “user-facing functionality”. Maybe the things that LMSs do were revolutionary 10 years ago (15?), but now just about anything online can upload documents, facilitate collaboration and provide some boundaries. I teach a series of classes for non-matriculated students (in Continuing Studies) so I can’t use our LMS, but I use 2 pbwikis (one for administration, one for collaboration, for a total of 4GB of storage), grandcentral and email and accomplish everything I need. In fact, grandcentral offers my students a telephone interface for an audio response, which is something that Sakai hasn’t even thought about yet.
It is very valuable to talk about new ideas like social networking, but there are any number of other things that could be included in future versions Sakai, whether that is 3.0 or later. Just to name a few:
Maybe these are already being seriously considered for Sakai, or maybe they are specific to my field, but my point is not the details but the direction. I would argue that the one of the most important tasks in front of us is to start surveying various fields and trying to think seriously about how technology can really change the way that we teach and learn. The LMS of tomorrow should not just be a replacement for what has been done on paper, but a way to facilitate and even foster the innovation of teachers. I cannot stress this enough: the goal is not just to facilitate instruction, but to facilitate innovation.
Finally, as Ray Davies pointed out, it is important to make it clear who is jumping to whose tune. One important implication in the Sakai 3.0 proposal was usability. However, I think this should be expanded so that usability really has an established place in the Sakai project. I had the opportunity to talk with a user experience engineer at Google who explained why their products are just so easy to use: they run every imaginable user test on them, including eye-tracking and at-home observations. We can’t really expect to be able to do that with Sakai, but if we are honest, our users have come to expect that kind of usability from anything they use online. Some sort of standards should be set out for testing the kernel and tools before they reach schools that will depend on them. So perhaps I am saying that that the user experience side should call the tune, if for no other reason than the fact that the people who decide the budgets to give to Sakai related projects are usually strongly influenced by user-facing functionality.
January 15, 2009