Dashboard > SakaiPedia > Sakai and Pedagogy
  SakaiPedia Log In | Signup View a printable version of the current page.  
  Sakai and Pedagogy
Added by charles kerns, last edited by charles kerns on Apr 07, 2005  (view change)
Labels: 
(None)

Information about teaching and learning support activity within Sakai Project and community is listed here:

The Pedagogy Discussion Group

The SEPP Pedagogy discussion group (Pedagogy DG) is intended to be a forum to enable the Saki community focus on the issues of the practice of teaching and learning and their relationship to the Sakai project. The DG is informed by the idea that good practices in teaching and learning have a role to play in helping shape the direction of Sakai development. This DG will be relevant to those with an interest in (1) developing tools and facilities that promote good practice in teaching and learning; (2) those who support users of Sakai and who want to assist these users in the realization of good T&L practice; and (3) those with theoretical and research interests in what kinds of practices encourage deeper learning. As is the case with the other discussion groups, the Pedagogy DG can spawn more specialized investigations, work groups, and other efforts as the opportunities present themselves.

Summary of a "thread" in the Pedagogy DG discussing need to support specialized learning support tools.

In the discussion, I think we have near consensus on the need for development to support specialized activities, especially those leading to better learning. Also, Sakai can provide the development platform that will provide a rich base for developers and allow widespread innovative tool distribution--in fact, without Sakai developers continue to face the same problems of high development cost without prospects for widespread use.

The discussion also talked about methods for development: within Sakai, outside of Sakai for prototyping then bringing into Sakai. Also a more lightweight development model was discussed.


  • Tim Alton kicked off this topic when he brought up the cost of a new discussion tool and its probable limited acceptance based on how few users currently post on discussion tools at Indiana: "The conclusion we have to draw . . . is that faculty aren't using the tool we have all that much. That argues against pushing hard for yet another tool." And later: "When I wrote about the paucity of utilization, I was floating a question of ROI, essentially. Cost/Benefit. Taken to an extreme, is the high benefit to a single class worth the cost of developing an expensive tool."
  • Dirk Herr-Hoyman agreed with Tim's characterization of the problem but argued " I don't agree that it should be expensive to do innovation for a new model for discussion forums . . . What we need is the means to quickly try some new approaches . . . That exploration will cost, the main cost ought to be in prototyping etc."

Tim Alton responded: "a rapid prototyping environment is a good (idea) . . . However, I'm skeptical that it could be done cheaply. (A discussion ensued about the efficacy of blogs and wikis in communities of practice, the need for applets, sites that feel like desktop apps and work toward providing a set of tools that would run within the browser) Tim then reposed his initial question: "whether a tool is worthwhile to build, adopt,
maintain, and integrate into a higher ed environment if it serves the needs of only a fraction of the faculty."

  • John Norman: "On tools for a small fraction of faculty; that is why we are so interested in the tool interoperability work with IMS. My rationale (for Cambridge) is as follows: . . . We believe that in some situations, we can enhance the teaching. . . . But we cannot afford to develop all the tools we would like. Developing a tool that 'plugs in' to Sakai/Bb/WebCT has advantages; (1) we can save a lot of user admin interface-type development and (2) we can exchange tools with other universities and reduce the average cost.
  • Dirk Herr-Hoyman pointed out that there are many worthwhile high-cost niches in academia: "I think we MUST move to a model with tools that benefit some smallish niche are built. One size doesn't fit all. Of course cost is a factor, but we shouldn't let that deter us. If all we ever build is tools that are for EVERYONE, I think that's not a good think.
    So, what's the ROI on a niche tool? Let me turn this around, what's the ROI on graduate study in some discipline like biochemistry for the brain.

My model here would be lightweight, low cost development. And see what happens next. Might have to put "in the field" to know if it works. Later, we worry about a higher cost "enterprise" deployment."


  • Joseph Hardin: "One of the main goals of the Sakai effort is the support of rapid innovation in online pedagogy and research practices, and the rapid dissemination of such innovation. This means support of experimentation with large and small communities and the customization and personalization of tools and techniques to fit local needs, all within the context of as much interoperability as we can provide. Out of these experiences will come the broad suite of tools that individual schools, teams and users can choose from. Niche thinking is my type of thinking."

  • Dr. Chuck (Severence) discussed some methods for getting "niche" functionality: "Because the Sakai discussion API in Sakai is pretty clean, folks could write 3-4 discussion tools that all were compatible and interchangeable if programmers were reasonably careful to explore different approaches to the display of discussion. . . . Another variant is to write add-on tools that add value to Discussion. Like a "discussion grading tool" - that in instructors use if they want to have a quick way to grade the discussions . . .
    By encouraging many flowers here we can avoid the problem of never being
    able to define perfection. Each time 4-5 people will get together they will
    want to redesign discussion no matter how many times it has been redesigned
    in the past.
  • Vivie Sinou" agreed with the idea of "add-on" tools and argued special features are needed to support learning: "A big problem with discussion is that it is often confused with learning. Faculty make limited use of e-discussion perhaps because the current tools don't quite cut it. Without the right "add-on" tools that Chuck is proposing (a great approach), faculty and learners don't have the necessary controls and functionality to add value to discussion in a way that it promotes new ways of thinking, synthesis, and evaluation. The dialogue is often unfocused and light and, as a result, learners don't participate as they don't see value in "talking." Many faculty . . . have been asking for a "discussion grading tool." Others want a "discussion synthesizer tool," a "peer discussion rating tool," "polling," and much more."
  • Charles Kerns identifies two reasons why innovative teaching has not been supported by instructors or by new tools:
  1. Pedagogical methods do not transfer (to other sites) when the support load is too high. If faculty have to fight with setting up groups, facilitators, etc; to come up with work-arounds with software tools that are built to support old top down teaching methods, and to spend an extra 10 to 25% of their time for a course to carry out the new methods---the instructors burn out in a few years and scare away other faculty . . .
  2. There has been no common platform for publishing software that supports pedagogical innovation. . . .pedagogical innovations . . . were not bundled with the basic CMS package for the campus . . .(they) had no integration into the campus IT infrastructure: they had different authentication methods, different file storage, their own database, no links to class rosters, no link to the cms gradebook, etc. One reason that Stanford got into Sakai is to move away from stove-piped innovations into an environment that integrated them into the basic campus IT and CMS systems."

*Mara Hancock: "I see this conversation as pointing directly at the Sakai framework value proposition. The ability to simultaneously meet the needs of a diverse set of users and to also narrow the focus and create or adopt tools that address distinct pedagogical needs is fantastic! This doesn't mean one tool can do it all. It means choice and being able to go deep based on real teaching and learning needs.

The added benefit of the Sakai project is that if I don't have to have the resources to create all these tools within my institution or pay the big bucks for each and every additional tool, I still can deliver innovative tools to my instructors and students. And, if we work within some common UI principles and UCD methodologies we might actually be able to do this in a way that ensures usable tools and smaller learning curves for the end-users (students and faculty). At UC Berkeley our general requirements for a learning system framework are simply stated as a flexible, reliable, and responsive enterprise system and services. Having niche tools and general tools alike are the promise I am counting on fulfilling!"

*Ben Brophy: "to be able to provide a platform for profs who want to develop tools.
Today it would be very difficult for a clever grad student to author a tool that plugs into Sakai - there's too much arcane JSF and legacy point that creative and talented faculty and their teams will be able to contribute, without going through the select cadre of trained Sakai developers.

*Bill Crosbie: "There is an opportunity to make Sakai an academic analog to the LAMP framework, to provide a way to quickly build tools that meet the needs of local communities. As a resource let me recommend Clay Shirkey's article, Situated Software.

http://www.shirky.com/writings/situated_software.html>http://www.shirky.com/writings/situated_software.html In brief - Clay provides compelling examples of software being exceptionally useful when it is situated within a particular social context. . . . making things too generalized may make it difficult for it to be useful for any one community. (Note this is an issue with tools, not frameworks. This only works with a solid platform upon which to build.)

*Tim Alton: ". . .group needs are highly localized and particular. Groupware such as Lotus Notes tries to be flexible enough to encompass small groups as well as large ones. But flexibility increases complexity, reducing the tool's attractiveness and increasing its costs.

Shirky's points about the need for highly specialized solutions are well taken, but institutions can only encourage them, not provide them. The challenge for any institution is not to create wondrously and universally useful collaboration solutions, but to create a limited number of solutions that are acceptable balances of cost and benefit."

*Kerns: We should also note that Sakai developers can "harvest" the research of the past 15 years. Many prototypes have already been made and we may be able to jump start the process to the third or fourth level of refinement for many feature enhancements by just reviewing what has been done already in prototype environments that have not transferred out of their original development sites. Some of these prototypes are listed in Resource area of this site. Any other studies/development projects that have built the features that have been suggested and have done evaluations?

Finally, Are there any development models that we should look toward? "Sakai as the educational LAMP" has been suggested. Any other ideas?

I am part of an online graduate program at Indiana that extensively uses discussion forums, groups, and the discussion grading tool in Oncourse. We would not be able to use a Sakai-based CMS that did not offer that functionality. No one has talked to us about this project (in fact I just stumbled onto this page) and I really hope that Tim and the others talk to more folks who are going to be dependant upon this technology - especially for completely online classes - before making decisions about the main tool that can be effectively used for building asynchronous constructivist learning communities.
Thanks!

Site running on a free Atlassian Confluence Open Source Project License granted to Sakai Foundation. Evaluate Confluence today.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.5.5 Build:#811 Jul 25, 2007) - Bug/feature request - Contact Administrators