Given that Sakai 1.5 was a feature-impoverished, unusable wreck, I fully expected 2.0 to be unusable as well. After spending half a day with it, I think it’s safe to say that I was wrong. While 2.0 is certainly not nearly as mature as other FOSS LMS’s such as dotLRN and Moodle, I think it may just be roughly competitive with entry-level Blackboard or WebCT Campus Edition. That’s an impressive leap to make in 6 months.As one of my colleagues observed, Sakai feels very “Blackboardish”. That can be good or bad, depending on how you feel about Blackboard. The upside is that it is, on the whole, reasonably intuitive to get around in. The downside is that it’s not exactly ground-breaking in how it organizes pedagogical experiences. We haven’t been able to try out Melete, Sakai’s course content presentation system (its release was delayed by a week or two), and that’s an important area I’ll want to look at. And I’m still poking around; the devil is in the details with these things. But so far most of the parts seem to be there and they seem to be mostly usable. If the Sakai community can maintain the same pace of improvement through the next two releases, this platform could be solidly competitive by this time next year. (Sakai releases a new version every six months.)
This is not to say it’s without its holes and problems. Let me start with the two most revealing ones regarding the blind spots of the Sakai community:
- The discussion board is unusably bad. As I noted in a previous rant, Sakai’s discussion board makes all the classic UI mistakes in discussion board design. That hasn’t changed from 1.0 to 2.0; in fact, unless my memory is playing tricks on me, it’s possible that the interface has gotten worse. I seem to recall that there was a way to view the text of all posts in a thread via a pop-up window. That option is nowhere to be found in the 2.0 interface. In addition, there is no way at all to sort the threads. Not by date, not by author.
- There is no support for groupwork within a class. None at all. Really.
To me, what this says is that (a) distance learning teachers have not played a significant role in the interface design and (b) the four big institutions at the core of the Sakai project aren’t giving a whole lot of thought to using Sakai beyond basic web-enhancement of F2F classes. Because nobody who had any serious intentions to teach hybrid or fully online class would let these two problems persist. They are both deal-breakers. And since other areas of the UI have clearly gotten some work, it leads me to worry that the folks driving Sakai are really just that clueless about what makes for a great distance learning platform. (Or, alternatively, they don’t care that much. My experience is that the degree to which a school is committed to fully online learning is inversely proportional to the popularity of their sports teams. If campus life is a big part of the school’s brand value, then selling distance learning just doesn’t appeal that much.)
Two more shortcomings and annoyances:
- Sakai breaks the browser “Back” button from time to time and doesn’t tell the user. You have to figure out for yourself that you can only move on from a screen with “Submit” or “Cancel” button by clicking on either “Submit” or “Cancel”. You also have to figure out for yourself that sometimes (but not always), the only way to back up to a previous screen within an individual portlet is to click on the small upward-pointing arrow at the top edge of each portlet window. I’m told that session management is challenging to do right in a portalized environment, and apparently Sakai 2.0 takes the cheap way out, at the cost of some usability.
- While Sakai has very nice, fine-grained permissions for a number of applications, including discussion boards, file sharing, and a few others, the interface for setting those permissions is pretty bad. It’s a bunch of check boxes that look like they were named after the Java classes the programmer happened to be using.
These are annoyances, but they’ll have a material negative impact on both utilization of the system and number of calls you get to your help desk (assuming you have one).
OK, so what would I like to see by Sakai 3.0? There are a million small to medium-sized features I could list, but playing the bullet point game doesn’t tend to yield excellence in learning environments. Instead, I’d concentrate on a few big things:
- Fully integrate Sakai with uPortal, including their session management. This would both solve the “Back” button problem and go most of the way toward solving the lack of support for groups within courses. It would also allow for the creation of sharable, re-usable content containers that float free of any given course instance but can be easily pulled into any given course instance. (uPortal has very powerful and flexible groups, roles, and permissions structures. My experience with LMS’s is that the designers always get these three pieces wrong because they have too narrow a sense of how they might be useful in a learning environment.) And also, uPortal is a great integration framework, supporting WSRP and JSR-168 for the hard stuff and iframes and RSS for the easy stuff.
- Integrate Sakai with Moodle on an application-by-application basis. The Moodle community would never make the discussion board and group work mistakes that the Sakai community made. They’re a very teaching-centric development community. At the same time, Sakai’s plumbing is undeniably impressive. I think Moodle’s chocolate would taste great with Sakai’s peanutbutter.
- Integrate support for IMS Learning Design. As I said, Sakai isn’t exactly ground-breaking as a learning environment. But best-in-class LD support could change that by allowing instructors to call tools into an interface that scaffolds the course by pedagogical experiences rather than by software function. The best example I’ve seen of this potential in action is LAMS, though Moodle, ANGEL, and SUNY’s SLN all do this to some degree (and I haven’t yet seen the LD integration into dotLRN).
The good news is that the Sakai community is working with the uPortal and Moodle communities, respectively, on achieving the first two of these goals. I’d like to see those efforts put on the front burner and I’d also like to see a commitment to LD. With those three big changes plus incremental improvements across the rest of the toolset, Sakai 3.0 could be very impressive.
Hi Michael
Thanks for sharing your findings about Sakai 2.0. Recently I was at a Sakai marketing demo here in Switzerland and I was very disapointed about the fact that there is absolutely no group functionaliy within a course althout the claimed that the big difference between Moodle and Sakai would be that Moodle wold focus more on Content wherby Sakai would focus more on collaboration. I found that this is not true at all. In addition there is almost no support for content or nice content integration into the course and the course – well – is very flat and unimpressive to me.
Have you ever looked at the open source LMS OLAT (http://www.olat.org)? I’m heading the development there and we think that OLAT has very similar goals as Sakai. In fact, not only the goas are similar, many interface issues are similar and the technology and architecture is also very similar. But the big difference is that OLAT has a six year development phase behind and is fully productional already now, including all the features that are not yet available in Sakai and won’t be for some time.
The OLAT course structure by the way is very much inspired by IMS Learning Design alias EML, however we decided to not implement the standard since it was not finalized at the time we started the development of the new course runtime engine and we saw some issues in the role / group concept in LD. We also had concerns about the quality of the standad after having implemented IMS QTI 1.2.1 which is horrible (technically and also the concepts behind).
I would be very interrested to hear from you what you think about OLAT!
If you have questions, please contact me!
Sincerly
Florian Gn㦩
To be fair, the Sakai team has been building it from the inside out. The plumbing is further along than the face it presents to the end users. Even so, Sakai has two very fundamental problems in terms of perception. First, they made a mistake by claiming that 2.0 would be competitive with the commercial products without explaining what they meant by “competitive.” Technically, Sakai is competitive with the commercial products, but only in a minimal way. They really need another year to get fully up to snuff.
But also, there is currently nothing very interesting about Sakai from a teaching and learning perspective. While I suppose there is some value in having a FOSS Blackboard clone, that’s not really what would excite me about a new LMS.
The gamble Sakai has made is that, by building an architecture that is highly granular in its modularity and is reasonably service-oriented, they will ultimately be able to achieve and sustain a higher pace of innovation, since more of the code will be re-usable in the service of building new applications with new affordances. In principle, I strongly agree that this is a good gamble to take. dotLRN has certainly demonstrated that it can work; their pace of innovation is strong and accelerating despite a developer community that is still small relative to their rate of progress. We’ll see if it pans out similarly for Sakai. They need to show developers that it is, in fact, a good platform for innovation before they will be able to attract a large number of innovators.
I haven’t heard of OLAT before, and it looks very interesting at first glance. I’ll definitely spend some more time with it when I get a chance.
I noticed that Sakai conference participants were primarily men (70-80% I think). We discussed this — and it seemed indicative of the fact that higher education insitutions sent their programmers and not their teachers to the conference. Hence perhaps, the sense many of us had at the conference that the community had not yet thought enough about what makes for a great environment to teach in.
Unfortunately, there is a grave imbalance in the numbers of women in technology related jobs:
“Women–who comprise 51 percent of the population and earn more than half of all bachelor-level degrees awarded–earn about one-quarter of the bachelor-level computer and information sciences degrees awarded by U. S. academic institutions. More disturbing is the trend line: the share of all computer science degrees awarded to women in the United States has fallen steadily from a peak of 35.8 percent in 1984, to only 27.5 percent in 1994–the lowest level since 1979.” http://www.umbc.edu/cwit/rationale.html
Or see:http://www.typepad.com/t/trackback/2472712
I would hope that Sakai (and SUNY for that matter) would work to address this imbalance. But clearly this is a BIG issue — as I saw one night at the conference when I raised this issue over drinks and my male colleagues (I was the only woman at the table) went mute and one got up and left the table.
The comments about Sakai 2.0 were appreciated and helpful. Sakai Chief Architect Chuck Severance has a plan for the level of integration with uPortal that you described. The first step will be a WSRP version that will run in any WSRP, the integration you describe will be later. Chuck also met with Moodle’s Martin Dogiamas last Friday here in Washington, DC to discuss the path to interoperability. I expect Chuck will provide some notes in the next issue of the Sakai Update. Learning design is very important; Sakai partner University of Hull has some research results and experience that should lead to supporting both a lightweight and full learning design.
You are correct: Sakai put its effort into the architecture first. This supports a number of “tools” developments by the Sakai partners that should lead to a very rich learning system.
Our uPortal colleagues and the GAPS developers will appreciate your comments about groups and permissions. Dan Ellentuck and his colleagues have done an excellent job maturing that development. To make this available to other applications, the team is separating GAPS from uPortal; uPortal will continue to access GAPS through an interface.
Michael – thanks for the comments. I would generally agree with all of your conclusions critiques and suggested go forward recommendations for the project. One of the key facts abot Sakai is that its future development and direction will increasingly be driven by effort from the community and not the founding members.
The most difficult task you propose is to be “more LD”. It is easy to be “like all the other boring LMS systems” – the pattern is familiar to all and while not exciting – it is functional. With LD, there is a lot more “artistic interpretation” and many different opinions as to what LD *should* be.
For me, instead of trying to figure out a-priori the exactly what LD means, I wold prefer to improve Sakai’s support for WEBDav Web Services, and content management in general. Then Sakai can become the “boring enterprise LMS” but can easily be extended in LD directions.
For my own part, to play with the idea, I have already written a Visual Basic desktop application that interacts with the WebDav. I and others are puttering with PHP, Flash, and other ways to build new capabilities without forcing them into the “straightjacket” that is Sakai. I really look forward to the many different wasy that Sakai can be used. But a critical pre-requisite is to build a rich enough framework to make LD style fit right in.
Thanks, Jim and Chuck, for giving us some feedback from the Sakai team perspective. It’s always good to know that somebody is listening.
Jim, on the uPortal/GAPS integration (do you mean PAGS?), I would be particularly happy to hear that the integration will allow Sakai to use uPortal groups, roles, and permissions, rather than simply mapping Sakai’s constructs to uPortal’s. uPortal has very powerful and flexible groups and roles that could be highly beneficial in an online learning environment
Chuck, I agree that taking an open approach for an environment that supports experimentation rather than staking out one particular philosophy is a great direction to take. That said, I would argue that it is important for Sakai, beyond implementing WebDAV and general web services, to support the IMS LD specification (probably through Coppercore). LD is pedagogy-agnostic (which is not the same thing as being pedagogy-neutral/neutered). I don’t care much if Sakai provides an authoring interface; one of the nice things about LD is that it provides clean separation of those concerns. But import of LD-compliant files to populate and structure a course display would be a huge step forward.
Since you both have been kind enough to visit, I’m going to push my luck and make one more strategic suggestion. Shut down the listservs. Throw out Confluence. Any development-related collaboration that does not require development-specific tools (like a bug tracker or source control system) should take place using Sakai’s core tool set. If the core tools are currently not adequate for those collaboration purposes, then they are probably not yet adequate for distance learning purposes either. The more developers are scratching their own itches rather than somebody else’s, the faster the core collaboration tools will improve.
Michael, I’m one of the pushers for Confluence use within the project, even though I know the benefits of “eating our own dog food”. (I used to work in the VMS operating system group, which lived well by that motto for a time.) In this case I’m not sure it applies even theoretically, since open source software project management is a different problem domain from the ones that Sakai focuses on. (If managing programmers is like herding cats, that would mean we need cat food, right?)
From a purely practical standpoint, the problems are worse. We itchy developers don’t have the freedom to scratch ourselves — we’re assigned to other work, and can’t get reassigned to produce, for example, a useful scalable discussion forum ASAP. Very often the reason Sakai 2.0 is missing what seem like dealbreakers to you (and to me) isn’t that “they don’t care that much” but that there just hasn’t been enough “they” to get the necessary development done in the allocated time. The weight of history still drags on Sakai to what may be a surprising extent because more work has (necessarily, I think) been put into revising the core than into revising the legacy tools.
As far as I can see, project management, collaboration between engineers and user representatives, and public accessibility have all improved since we began using Confluence and JIRA. I’m not eager to go back to relying solely on stovepiped mailing lists and uploaded files.
Obviously, not all Sakai developers would agree with me on this — just my point of view! But I also thought that some VMS engineers might have benefited from spending more time with the Mac OS and MS Windows….
Wow. It looks like the Sakai team has discovered my little blog. Welcome, Ray. Thanks for posting.
I feel compelled to challenge you on a few points, though. First, you haven’t yet convinced me that Sakai can’t support developer collaboration in theory, as you put it. The OpenACS developer community has used their discussion board for communication from Day 1, and it is the same discussion board in the OpenACS-based dotLRN LMS. As far as I know, they have never used a listserv. The only external collaboration tool that I’m aware of them using is IRC for synchronous conversations. If you can give me specific examples of how developer collaboration needs diverge from learning community collaboration needs, I’m all ears. But until then, the general assertion that there is a difference doesn’t really sway me. (In fact, I would argue that online learning is an integral part of the FOSS distributed development experience, but that’s another conversation entirely.)
On the practical side, I think your comment about the “weight of history” is apt, and for more reasons than the one that you mean. Your comment suggests that there are few developers working on Sakai who are not paid employees of the four major partner institutions. Given that the grant money is going to run out soon, this isn’t a very heartening sign. In his opening paragraph on this thread, Chuck Severence said that Sakai’s “future development and direction will increasingly be driven by effort from the community and not the founding members.” What community? Where are the community members who are working on the teaching tools?
I don’t mean this to be a rhetorical question; I don’t assume that nobody is working on them. I just see very little evidence (beyond the work at Foothills) that it’s going on. I see a lot of institutions peering in the window from the sidewalk, but I don’t see a lot of evidence of development yet. Admittedly, I wasn’t able to attend SEPP in Baltimore, so I missed one major opportunity to see this activity. But I know a number of colleagues who went, and none of them came back raving (to me, anyway) about the amount of community development they saw. I want Sakai to succeed beyond its funding and grow into a strong community-driven project. I just don’t see evidence that it is doing so yet.
Lastly, I have seen a number of comments by various Sakai project team members (both in this thread and elsewhere) that they do care about online teaching and learning, and that they just haven’t gotten to it yet. I do believe that you folks all really mean it. But it begs the question: In what sense do you care about it? OK, you believe developing a strong foundation will lead to the proliferation of good learning tools. But what have you done to validate that belief? How have you checked your plans to make sure that the frameworks you are putting together are really implemented in a way that optimises the ease of creating innovative teaching and learning tools? And what does the phrase “innovative teaching and learning tools” mean to the Sakai team, anyway? What is it, exactly, that you are trying to enable with your frameworks? In what sense, if any, is concern about excellence in teaching and learning shaping the day-to-day decisions you make about the underlying frameworks?
Again, these aren’t rhetorical questions. I don’t assume that you haven’t asked them yourselves and answered them somewhere in the Sakai documentation. I just haven’t found the supporting documents, threads, or listserv archives yet.
Please don’t misunderstand me. I really am delighted that you all are making the effort to communicate here. And I believe that Sakai is an interesting way to approach a noble goal. I even think that the impressive leap of progress you made from 1.5 to 2.0 is evidence that the FOSS purists may be underestimating the strengths of your model. But the Sakai team’s rhetoric around the importance of both community-building and pedagogy so far hasn’t been matched (in my opinion and from my vantage point) by execution or, more troublingly, even evidence of a clear plan for execution at a later date. As somebody who is rooting from the outside for a Sakai win, I’d feel better if I could see more of a game plan.
Beth, I don’t mean to be ignoring your comment (especially in light of the experience you describe). Perhaps one reason why your colleagues may have been at a loss for words is that it’s hard to think of ways in which the Sakai project itself could make a meaningful dent in the much bigger gender gap problem in software development. At best, it might provide an enticing project that universities could use to attract women programmers. But for the most part, my own feeling is that this really needs to happen at the university level.
I appreciate that Michael, since the lack of response to my comments on your blog were beginning to feel like the silence I received over drinks in Baltimore.
I do think that Sakai has some obligation to at least acknowledge the fact that the conference was dominated by men.
I was sitting at the last meeting of the conference with all the board members sitting up front and there was quite a bit of discussion about the importance of diversity, and how Sakai was important because it could accomodate diversity — and yet not a mention was made of the lack of diversity at the conference itself in terms of gender!
While you are right that this needs to happen at a university level, I think that the Sakai board (and others at the conference) could have acknowledged this gender gap, and that to do so would have been meaningful.
Consider that Sakai is, for many of us, as much a philosophy as a program.
So, what would have happened if the board and the conference participants had openly acknowledged this lack of gender diversity?
Perhaps administrators would go back to their campuses and make more of an effort to send their female colleagues to the next conference.
Perhaps when the CIO on a campus was next hiring programmers, s/he would be more aware of the gender gap.
Surely, more can be actively done than sitting back and hoping that Sakai becomes enticing to women. I think that acknowledging the problem and discussing it openly is an important step — although I have often felt lately like I am talking to myself.
Great thread here. I blogged a response a few days ago:
http://web.mit.edu/benbr/notes/2005/06/28/#050628sakai
It is unfortunate that most of the tools shown in Sakai are primarily administrative as opposed to collaborative. But in order to support collaborative tools you need to get some of the basics in place and working. For example, as you mentioned, Sakai doesn’t support groups or sectioning, so we’re pushing forward on a tool to create groups and sections. Pretty dull in some ways, but it will make it possible to do much more interesting work later on.
There is some development going on beyond Melete. There are a few discussion tool projects – the one out of Cambridge University looked especially cool – and some tools using image repositories. I saw a very cool plugin to the rich text editor called Twin Peaks that lets people insert links to library resources from anywhere in Sakai. There was a lot to see at the conference.
But there is still a lot of hard work to be done on the framework, and on the administrative tools. I think many schools are quite rationally waiting for the platform to stabilize before they start developing on it. I’m not worried about the money running out – many schools have been paying their developers to work on Sakai and will continue to so.
Beth’s comments were very revealing as I don’t know if there was much thought given to the extent of gender diversity at the Baltimore Sakai conference. I would like to add though that the Sakai Board comprises 10 people, of whom 4 are women, and as an example of gender diversity that’s a pretty powerful one
(Full disclosure, I am a member of the Sakai Board).
Thanks for your response Babi, I did notice that the board was gender balanced — but (for me) that made the extreme lack of diversity at the conference itself (80/20 from what I could see) only more apparent.
A few comments on Sakai and LAMS in relation to Learning Design (LD). First off, its worth noting that we (LAMS) been in regular contact with various Sakai folk from the start of the project. We remain keen to work together, but our sense has been that Sakai has been under very tight deadlines that have limited their ability to “come up for air”. In the meantime, we’ve implemented Spring and (more of) Hibernate in our next major release to help future integration if desired.
My major concern for Sakai is the assumption that LD will be relatively easy now that most of the software infrastructure is in place. From our experience of building LAMS – this is unlikely to be the case.
LAMS is, in effect, a multi-actor workflow system incorporating both a “core” workflow system and a suite of workflow-enabled activity tools. LAMS allows recording, monitoring and intervention for its workflows, and visualisation of workflows for both authoring and monitoring.
This functionality is quite different to traditional LMSs. One of the byproducts of this difference is that when we built LAMS, we had to completely rebuild every LMS tool (forum, chat, quiz, etc) to make them “workflow enabled”. This lesson remains the most painful one we learned. From speaking with many technical (and pedagogical) colleagues, it is also the least understood. Many people still assume you can just drop existing LMS activity tools into a sophisticated worflow framework, and expect them to work.
NB: If by “work” you mean “presents a URL pointing to the activity tool at the relevant step in the workflow”, then this hopefully shouldn’t be too hard (we’ve just done this with Moodle – see http://lamsfoundation.org/integration/moodle/walkthru.html – especially figures 12/13/14).
But if you want to do things like retain single-sign-on, implement sub-groups, allow teachers to monitor/intervene, allow an authoring environment to create a set of instructions to configure and populate the activity tool, and allow the core workflow system to create a full record of each student’s activities (so this can be exported and stored in an e-portfolio system), then your activity tools all need to richly communicate with the workflow core about these things.
The best quick illustration of the problem is a series of graphics I presented at a Cambridge MIT Initiative conference in April 2004, where I compared the architectures of OKI, Sakai and LAMS. The final two slides illustrate the problem between hopes and reality for LD tools from our experience of building LAMS – see
http://www.lamsinternational.com/CD/html/resources/presentations/LearningDesign.CambridgeExtra.ppt
For a paper reviewing the development of LAMS, and the challenges we faced with the IMS LD spec, and some reflections on a “LD activity tools API”, see
http://www.lamsinternational.com/CD/html/resources/whitepapers/Dalziel.LAMS.doc
For a detailed discussion of LAMS, IMS LD and activity tools interoperability from the UK CETIS EC-SIG discussion list, see http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0505&L=cetis-ecsig&T=0&F=&S=&P=1014
Hope this helps. I think Sakai has great potential. I also realise some people don’t see the value of an approach like LAMS. But for those who are interested in how to combine them, the lessons we learned along the way may be useful.
James Dalziel
Some comments from a Sakai interaction design guy:
* “Sakai feels very “Blackboardish”. One of the goals of the Sakai project is to create a replacement CMS for the core schools (Michigan, Indiana, MIT, Stanford and later UCBerkeley and Foothill). While none of these schools used Blackboard alone, their CMSes evolved in the same environment as Blackboard. In fact, most of the tools can be traced to their unix-webpage heritage (newsgroups, chat, home page, etc). but with an integrated look and interaction design, single signon, common data store, etc) So one key intention was to replace what was there-hence a basic CMS look, feel, action, organization. We are keeping our clients(instructors and students) happy by not changing too much too fast in a critical system for their courses.
Another Sakai goal is to provide a platform for innovation to develop teaching and learning tools-but at Stanford that cannot happen until we move our faculty and students to a comparable CMS (in terms of user experience) to our existing CourseWork CMS (home grown and open-sourced, but suffering scaling problems that require a new architecture).
We see this as an 80/20 problem: 80% of the faculty want to continue teaching much as they have (the early and late majority in “diffusion of innovation” terms); 20% are pedagogical innovators who want to try new tools and change learning activities (project-based courses, studio science, problem-based activity integration, collaborative knowledge building courses). We must support both groups. But the 80% has to come first to a campus academic computing support group such as ours.
Innovators will not stop innovating if the CMS does not initially support them (it does not now), but we want to work with them and especially to support transfer of their innovations out of their original sites.(The big failure of most innovations in learning technology). Inclusion of their tools in the CMS is the best way for us to support transfer.
* “the four big institutions at the core of the Sakai project aren’t giving a whole lot of thought to using Sakai beyond basic web-enhancement of F2F classes.” This is true for Stanford and, I believe, several of the other core schools.. We look to our partners in SEPP to add the enhancement/changes for distance learning needs.
* “I was very disapointed about the fact that there is absolutely no group functionaliy” Because Sakai’s starting point was CHEF (UMichigan’s CMS) that had a flat structure, the architecture needed to be redone for use even in the other core schools. As has been pointed out, this is the BIG change coming up next. It must be or we at Stanford cannot implement.
“I noticed that Sakai conference participants were primarily men” and “. . .it’s hard to think of ways in which the Sakai project itself could make a meaningful dent in the much bigger gender gap problem in software development ” Because Sakai started architecture-out, a preponderance of the people participating have been from computer architecture and programming groups on the different campuses. These groups are often WMDs: white male-dominated (note that this is not true at Stanford’s Academic Computing). Sakai is not alone in this regard as Michael notes. Where does the dent start–in K-12 and university CS education, in hiring practices ?
I am working with the Sakai interface and interaction design team and with the user support groups. we are approaching gender parity in these fields. These groups will be more evident (and more influential) as Sakai is adopted. This is not to ignore your observation, but to place it again in the larger domain of software development, which has a lot of old (or maybe young) boyism required to play.
” I’d also like to see a commitment to LD.” There is a “pedagogy/teaching-learning” discussion group in Sakai. Malcolm Brown of Dartmouth and Phil Long of MIT head the group and I have been active in its discussions. Also, see (and contribute to) the pedagogy section in the Sakaipedia. (http://bugs.sakaiproject.org/confluence/display/ENC/Pedagogy+Information)
In the dg we have talked about the “silo-ization” of learning activities in traditional CMS tools and the need for finer granularity and modularity within these tools so that activities can be combined into sequences (exactly as in LAMS and the LD spec). But with the need to fill the 80% side of the solution, we have stuck with the basic tool paradigm and not chunked their actions (Samigo has started with its QTI web services interface). I have been assured by Joseph Hardin that next year is the year of pedagogy in Sakai.
Probably half of the discussion in this on-line group during the past several months has been about functionality needed for assync discussion – what’s needed to facilitate learning (and teaching) rather than just having superficial grade-driven studentposting.
We look forward to a fully inclusive community with the teaching and learning support/research/practitioners more involved in Sakai development and design activities after it expands from its rushed architecture-out effort.
* “Where are the community members who are working on the teaching tools?” Most schools like Stanford have a group of programmers working on their own CMS or gluing a proprietary CMS to their other enterprise systems. The pitch was made at SEPP in Baltimore for these schools to have their programmers work on tools etc for Sakai. Rather than an army of individual programmers, I expect institutional members to play the biggest role in Sakai development. We at Stanford will continue to work of different components of Sakai and for inclusion in the general release. Others are developing or getting started: we talked to Columbia and others about enhancements to Samigo, and to Simon Frasier about using their Sakai event sign up tool.
I must admit that our current focus is on replacing the existing campus CMS.
But we are looking forward to getting innovative tools included in the Sakai toolset, initially for our early adopters.
Thanks for the very thoughtful response, Michael.
I really shouldn’t have brought the theoretical argument up first, since it encourages the Is-It-a-Future-or-Is-It-a-Now? fog which surrounds so much Sakai talk. I did, though, so — into the fog! That theoretical side has much more to do with community and financial support than “purely technical” (as if there ever is such a thing) restrictions. A distributed open source project would benefit from integration with a bug tracking system, ability to link tasks to milestones and schedules, easy publishing to the outside world, and (most of all) the much greater community of skilled open source developers who aren’t employed by higher ed institutions — none of which are top business priorities for a team whose primary targets are course sites and online learning.
But it’s absolutely true that a really useful and flexible online collaboration suite can support online learning, course sites, and software development pretty well, and all those missing elements could plug into our theorized collaboration suite one by one — once it exists! When we get to that point, it may turn out to be a fairly trivial matter to integrate non-Sakai-centric development tools.
Until then, though, I owe it to our end users to do my work efficiently by any means necessary, whether it makes good propaganda or not.
(Think of the way that savvy instructors and students who feel constrained by Blackboard’s functionality and UI will seek out an external weblogging host so that they can get what they need. Obviously, it’s not always ideal for them to be taking university-based roles out of the university system. But is the proper response to ban the use of external weblogging hosts, slap the wrists of the savvy instructors and students, and send them back to Blackboard? I’d say a better response is to figure out what they need, get better-than-adequate support for it within the university, count on carrots working better than sticks, and in the meantime not interrupt their work.)
Back to the real world. I don’t take any of your questions as rhetorical. We ask them inside the project, too — probably more heatedly. I agree with Ben’s summary. Since first cuts at core framework services and a new presentation layer weren’t available until Sakai 2.0, since they’re still not fully proven, and since Sakai 1-through-2 has been more about the core than about best-of-breed functionality, schools have wisely been cautious about sinking a great deal of development into new integrated applications. It’s being done, but the best approach is probably to design defensively, with loose coupling between the application and the framework, and that’s a skill which doesn’t always come naturally to developers or funders. Given such constraints, I’ve been amazed and delighted by the amount of labor being volunteered worldwide.
Beth, I understand that this is a good news and bad news response, but the gender skew was more pronounced on stage and in the audience than it is day-by-day in the project. Not only are there typically smaller numbers of women in back-end architectural development (which the conference heavily slanted toward), but in that group there are typically smaller numbers of women who feel an impulse to publicly hold forth. I agree that the end result was telling.
Ben, thanks for the encouraging summary of work that is going on, and thanks especially for your blog post on the work you’re doing with Sakai groups (http://web.mit.edu/benbr/notes/2005/06/30/#050630sections). I look forward to posting a response with my own thoughts as soon as I can clear a little time. I would love to see more Sakai developer blogging, either in the form of a blog collection similar to Mozilla’s or a single group blog in the style of Apple’s WebKit project or the Jotspot developers’ blog. And by the way, I don’t find the work you’re doing on groups to be “pretty dull”; anything mission-critical to teaching and learning is inherently interesting to me. And a good, flexible implementation of groups certainly falls into that category.
Babi (and others), I’d be interested to here what you all think that SEPP partners could do (with support from the Sakai community) to use the Sakai development project as a tool in their diversity-promotion strategy.
James, your comments about the challenges of LD are really important and interesting. Can you give us a little more concrete detail in terms of, say, what has to be done to make a discussion board work with an LD workflow framework?
Chuck (Kearns), your description of the Sakai team’s goals and current thinking is fantastic. It clarifies a lot about why 2.0 looks the way it does as well as the priorities of the project.
Ray, your points are all well taken regarding the practical realities of the development team’s needs, especially in the short run. That said, I still believe that Sakai would benefit from the developers striving to eat more of their own dog food over time.
To make a discussion forum work with LD, it could be as simple as connecting a system that displays tasks according to the Learning Design to a system that provides a Forum. For example, you could use Coppercore (another LD system) to run a Learning Design where the third task involves a link to a Moodle forum via URL.
Along similar lines, Figure 13 from the LAMS/Moodle integration walkthrough (see my previous post) shows a LAMS sequence linking to a Moodle forum via URL as the third step in a LAMS sequence.
So the question is, what else might you want from the interaction between LD system and Forum? (NB: I’ll use Forum here as a proxy for any activity tool)
One basic requirement might be a shared security context and provisioning of user information from LD system to Forum. This way, when users who are logged into the LD system move to the Forum, this requires no extra login. It also doesn’t require the teacher/sysadmin to set up users in the Forum separate from setting up users in the LD system prior to getting started.
Following on from this, you’d also probably want to be able to instantiate the Forum from the LD system automatically, rather than set it up by hand each time it is needed.
All of the above would hopefully be possible with IMS TI, and is pretty typical of LMS-tool integration (eg, Blackboard Building Blocks). So what does LAMS do that goes beyond this?
(1) LAMS provides a central authoring environment where you can configure the Forum and populate its starting threads, etc. So the Forum needs to provide an authoring interface to LAMS authoring to make this possible. This includes an agreed XML format for capturing the Forum configuration information that is stored in the Learning Design, and is later used to setup the Forum at run-time.
(2) The LAMS Forum has an option called “Lock when finished”. This allows the LAMS workflow engine to “lock” an activity once it is completed. After that point, a student can return to the activity and view it, but can’t change/add to it. In many cases in higher education, you would probably leave a Forum “unlocked” to allow for further discussion; but there may be contexts where you want to have several separate discussion forums at particular points in a sequence, and lock each one as that step is completed (rather than mix all the threads together, and end up with ongoing debate on an earlier topic). Whether you allow locking of a Forum is a pedagogical decision that depends on your context – the point here is, with LAMS, locking is *possible*. (The locking feature becomes more relevant for other LAMS tools, such as Q&A, where you might want to elicit an initial response from students, then build on this response for further discussion/debate, without students being able to go back and change their original answer – as this might remove the basis of a later debate).
(3) Some LAMS activity tools (but not Forum at the moment) have a feature called “Define in Monitor” – this allows an author to define the text for an activity (such as voting categories) while the sequence is live – rather than only beforehand at the design (authoring) stage. This means the Forum needs to provide an interface for “intervention” by the teacher while it is running live. A related feature is the ability of teachers to post directly to the Forum while it is running live (another form of “intervention”). Another type of intervention is “force complete” – that is, move a student on to the next activity.
(4) All LAMS tools can be run in “small group” or whole class mode. First, a teacher sets up a grouping task earlier in the sequence (say, randomly allocate all students in a class to 4 subgroups), then the teacher “applies” this grouping to the Forum. In this case, the Forum then needs to know to create 4 parallel versions of itself (rather than just one) with only the specified students in each relevant area (rather than the whole class).
(5) In LAMS Monitoring, there is a screen that shows the whole sequence, with a green dot for the current position of each student. So a Forum needs to be able to report on which students are currently “in” this activity.
(6) In LAMS Monitoring, another screen allows the teacher to click on any activity for any student, and see “what the student saw” when they were in that activity – that is, the student’s own contributions and any other contributions they are entitled to see (eg, for their subgroup only).
(7) In the next version of LAMS (V1.1), students will be able to export a record of all their activities for a sequence (together with all those of other students they interacted with) as a single file – we call this “portfolio export” – in the sense that you could store this LAMS activity record in an e-portfolio. The implication of this feature is that the Forum needs to know how to generate this report, and provide it to the LAMS core to have it aggregated with other records to produce the portfolio export file. In certain contexts, it may also be necessary for portfolio export to be able to present an “anonymised” version of records from other students (eg, Forum postings from student 2, student 3, etc, rather than Bob, Jane, etc.
(8) In the next version of LAMS (V1.1), any activity in authoring can be run online or “offline”. So you may want students to debate a topic at a certain point in a sequence, but whether they debate this f2f in class or online in a Forum will depend on your context, pedagogy, etc. If you run this activity “offline” in LAMS, the online sequence will just present a text “placeholder” informing students that this task takes place offline. In addition, you can print out information for the teacher (such as the debate topic, instructions on how to run the debate, etc) and potentially information for students as well (advice on debating practice, etc). So the Forum needs to be able to run in either online or offline mode, present the appropriate online interface, and be capable of printing off instructions instead of running an online Forum.
(9) In LAMS V1.2, tools will be able to recieve input data, and generate output data for other tools. V1.2 will alos include more complex branching and conditionality. Taken together, this means a Forum could, potentially, have two streams – one for students who scored 8+ on a prior test, and another for those who scored 7 and below. You could also have a subsequent task (maybe another Forum), where students were again divided into 2 streams, but this time according to whether they had posted 5+ contributions to the previous Forum (or not). While the details of this area are complex and far from finalised, the point is the Forum may need to know how to accept certain input data from other tools, and provide certain output data for others.
Quite a bit of work for a simple Forum! And that’s without any discussion of actual Forum functionality, or anything on lower level deployment/management/security issues….
From a different perspective, Scott Wilson has describe four things that tools need to offer in their services interface:
– activation
– closedown
– monitoring
– intervention
(see standards.edna.edu.au/idea/ summer2005/ppt/OTF20050209_scottwilson.ppt – slide 37). This is one way of categorising the issues raised above.
Related to this, Scott has a new paper on workflow in education – see http://members.imsglobal.org/forum/ims/dispatch.cgi/f.altilabwork/showFile/100041/d20050615182617/No/SOAandWorkflow2.pdf
I think this is an excellent paper for those interest in LD and workflow issues.
Hope this helps!
James Dalziel
Hi Michael
I wanted to let you know that we just released OLAT 4.0.0. I know, this discussion is quite old, I just didn’t see an email somewhere so I could dop you this note privately.
OLAT 4.0.0 has many new features like support for SCORM, a portal style homepage and an upgraded shibboleth 1.3 interface. Much more, to much to list here. If you are interrested, check out the detailed release notes on
http://www.olat.org/public/download/releasenotes/4-0-x.html
or download the double-click easy installer version to get a quick hands on impression:
http://www.olat.org/public/download.html
Cheers
Florian