From news@gmane.org Tue Mar 04 03:33:20 2003 From: John Norman Subject: RE: LMS/VLE rants/comments Date: Fri, 9 Dec 2005 13:32:29 -0000 Lines: 143 Message-ID: <22585576.1134135343809.JavaMail.tomcat5@mahimahi.ds.itd.umich.edu> References: <11092568.1134057033105.JavaMail.tomcat5@mahimahi.ds.itd.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'Masson, Patrick'" , "'Patrick Carmichael'" X-From: postmaster@collab.sakaiproject.org Fri Dec 09 14:37:23 2005 Return-path: Received: from girlinterrupted.mr.itd.umich.edu ([141.211.14.73]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EkiPZ-0005Hg-V4 for gccsd-sakai-dev@m.gmane.org; Fri, 09 Dec 2005 14:35:46 +0100 Received: FROM mahimahi.ds.itd.umich.edu (mahimahi.ds.itd.umich.edu [141.211.253.162]) BY girlinterrupted.mr.itd.umich.edu ID 4399882F.CEBD4.13395 ; 9 Dec 2005 08:35:43 -0500 Received: from mahimahi.ds.itd.umich.edu ([127.0.0.1]) by mahimahi.ds.itd.umich.edu (JAMES SMTP Server 2.1.3) with SMTP ID 280 for ; Fri, 9 Dec 2005 08:32:47 -0500 (EST) Received: from caret.cam.ac.uk (ns-map.ds.itd.umich.edu [141.211.253.192]) by mahimahi.ds.itd.umich.edu (Postfix) with ESMTP id DF0D914023 for ; Fri, 9 Dec 2005 08:32:46 -0500 (EST) Received: from insidepixpool.dmz.caret.local ([192.168.101.17] helo=linarite) by caret.cam.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1EkiMP-000182-85; Fri, 09 Dec 2005 13:32:35 +0000 To: X-Content-Type-Outer-Envelope: text/plain; charset="US-ASCII" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <11092568.1134057033105.JavaMail.tomcat5@mahimahi.ds.itd.umich.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcX8DyZ3lFYRKl4wQm6UNi17qriurgAtEXDw X-CARET-Spam-Score: -1.4 (-) X-CARET-Scan-Signature: 35b8bacd9f92a946d21fffd0f2ce35db X-Content-Type-Message-Body: text/plain; charset="US-ASCII" Archived-At: I should chip in her as Dan's PHB :) Our strategy at Cambridge is to try and get the best of both worlds. I am dismayed by the either/or tone of many discussions on this topic. If you start from a monolithic place you will find yourself wanting/needing to be loosening things up. If you start from a very loosely coupled place you will find yourself wanting to provide some coordination (broker service in SUNY plans I think). Although the Sakai project and the SUNY design (and others) are at different places on the spectrum I hope we can have conversations that lead to learning from each other and conversion, or at least an understanding of when one approach is better than another and when it is not. John PS and from my point of view Dan is free to continue to voice his opinions. He has had an interesting experience of building a custom LMS for a multi-departmental course based on Wiki technology before joining CARET. But perhaps some of this belongs on the strategy and advocacy list rather than Dev? > -----Original Message----- > From: Dan Sheppard [mailto:dan@caret.cam.ac.uk] > Sent: 08 December 2005 15:48 > To: sakai-dev@collab.sakaiproject.org > Cc: Masson, Patrick; Patrick Carmichael > Subject: LMS/VLE rants/comments > > Concerning Patrick Masson's and (to a certain extent) Ian Dolphin's > comments on LMSes in general (beyond intergration with repositories). > > (I'll post the summary of the responses I received concerning > Repository/VLE integration to here and sepp-library in a moment). > > I should say from the start that I'm primarily a developer, and don't > pretend to speak from anyone other than myself, though I'm trying to > reflect what I believe is strategy amongst my immediate managers, where > I know it! > > I mentioned that VLEs are seen here, in some ways, as a sepcial case of > VREs, or that VREs are a more primary purpose. I agree with Ian in a > dislike for this jargon, and I'm sorry for lasping into it! What I > really mean (I think) is that at a research-led University, much of our > teaching in terms of styles of interaction, is derivative of, or based > upon, how research is performed, rather than teaching as it might be > seen as an adaptation of school teaching to a different demographic. > > I know that sounds vague, but things like group size, formality of > "courses", open access to learning resources, the degree of direction > and self-motivation, and so on, have real practical implications on any > system we might deliver to campus. > > A collegiate University also has incredibly complex reporting and > responsibility structure, which impacts on any top-down type approach. > Essentially, nobody has the whole picture of a researcher or student's > learning experience other than that person themselves. That's part of > the reason, I think, that we're after a system which focuses on the > individual first, then their researching role, and then their teaching > role, and allowing people to exchange their various roles in different > contexts with ease. > > It's these concerns which are the outstanding pressures, as I see it, in > choosing a learning system. I think that many of these issues are > reflected in Oxford University's report on the choice of Bodington > (fine-grained access control, no course registration, etc). > > The real 'selling' point of Sakai, as I see it, at the moment as a tool > is its community and adopters, rather than its codebase. And a large > number of research-led (comparatively) resource-rich Universities are > adopting it, some completely committed to it at least in the > medium-term, and so we can be reasonably sure that where needs of > research-led Universities are not met by Sakai, then they will be > forthwith, and Sakai won't move in a direction incompatible with this > use (not that this will be its exclusive use!). > > Also, it currently does the job tolerably well: group management can be > easily delegated, it accomodates small informal teaching groups, > navigation between many fragmented informal components > > This is why, I think, we have interests in, for example, the JISC VRE > Sakai work. > > We've spoken a lot recently here, internally, about approaches to > providing resources along those lines, and the SUNY LMOS model > (mentioned by name!) was the other leading contender. > > I don't disagree with any of the downsides to using an integrated LMS > that Patrick raised. Core tools are often behind the state-of-the-art, > and need to be integrated into a VLE. It could be argued that a set of > enterprise-type services (single-sign-on auth, LDAP, common navigation > 'frame', etc) can be used to support a set of tools. > > Part of the problem we find, though, is that many of the enterprise > tools are not suited to an environment like this (it's difficult, for > example, for LDAP, to capture the creative anarchy of the way many > research and tutorial groups tend to assemble and disperse). > > Users also seem, in practice, to react positively to the consistent > navigation and style provided by these tools. The more vociferous users, > those who have more issues with the presentation of identity, may react > against the blandly repetitive styling and the attribution issues > raised. But the majority, as far as I can tell, react positively to > simple navigation around a single server (rather than the >1000 we must > have here at the moment, each with their own tweaks and > ideosynchrosies). I realise that the navigation and branding issues are > distinct, but they're highly entwined. > > Also, as more tools are added, the problem starts to escalate with an > assembly of interoperating tools (as O(n^2)), but remain linear (O(n)) > with each tool which is added to an LMS framework (obviously this is a > simplification). Also, it becomes simple to develop "mix-and-match" > tools from services already in the framework because of their > comonalities. > > As the issues you raise concerning lock-in become apparent there are > starting to be standards developed which allow "external" applications, > like IMS launch, though they're currently a little immature. > > Another advantage to a deployer at the moment, of course, is that Sakai > exists! Personally, if I were given a good integrated, styled, LMOS, > with excellent delegated user management, and plenty of tools, I would > be very pleased, but I've yet to see anything approaching this at the > present time. But good luck in developing such! > > Personally, I agree that there's currently no VLE/LMS which I could be > comfortable as describing as "good": just some which are heading in the > right direction, and really very few extant alternatives. > > Dan. > > ---------------------- > This automatic notification message was sent by Sakai Collab > (http://collab.sakaiproject.org/portal) from the Sakai Development site. > You can modify how you receive notifications at My Workspace > > Preferences. ---------------------- This automatic notification message was sent by Sakai Collab (http://collab.sakaiproject.org/portal) from the Sakai Development site. You can modify how you receive notifications at My Workspace > Preferences.