For those who don't have time to read through this rather long page, I will put my personal recommendation right up here at the top. I think the best option overall would be for us to carefully select and recommend a small number of third party tools that can be used to create and/or manage Sakai content. There are a huge number of possibilities available, covering a wide range across the power/usability tradeoff continuum. Some involve using tools faculty already know, such as Word or PowerPoint, others would require faculty to learn something new, but with a much lower learning curve, far superior work-flow, and much greater functionality than they would experience within Sakai. Faculty will realize far more bang for their training buck using any content creation tool we would choose to recommend than we could possibly hope for if they attempt to use Sakai as their sole development platform. Depending upon the third-party tool selected, these benefits could extend far beyond the scope of the content module per se. To understand why in detail, read on.
In this page, I will attempt to summarize what I have learned about UD Faculty use of WebCT Content Modules, and how this might might impact us during Sakai migration. I begin with a somewhat philosophical discussion regarding the role of content modules in an LMS. This is followed by a listing of features that might be considered essential to any content module-like tool. I then summarize the strengths and weaknesses of 5 approaches for the creation of module-like content in Sakai. Finally, I present a table of WebCT CM features not supported by Sakai, along with what little we currently know about each feature's usage on campus.
A WebCT content module is essentially a wrapper that can be used to organize content into a coherent chunk of instruction. From the student point of view, the integrity of the unit is maintained through a navigation system consisting of a Table of Contents and header links. The Table of Contents is a tree menu that can have any number of levels, and header links can launch auxiliary tools such as a note-taking interface, discussion and glossary. Content pages can be of any type: html, doc. ppt, or even a WebCT quiz or self-test. Once a student enters the module, he is not asked or expected to leave it until the module is complete. If he is interrupted for any reason, a resume feature allows him to pick up where he left off.
It may be interesting to note that a number of other LMS's use the equivalent of a content module as their dominant feature. Moodle, Epsilen and, to a lesser extent, Serf all make the assumption that the primary purpose of the system is the delivery of sequenced content that has been chunked into some sort of instructional units, and that these units can include content from more than one of the LMS's tools. All three of these systems provide interfaces that facilitate the creation and maintenance of sequenced, multi-faceted content. Upon entering the system, both faculty and students are immediately presented with learning modules, and their experience within the system is driven by that structure.
The WebCT interface is based on a different assumption. WebCT was designed to facilitate the creation of course web sites that look and feel much like a commercial web site. This lends itself to a less linear organization of materials, while still supporting a linear approach for designers who prefer it. The web site metaphor is probably a good choice for hybrid courses with a dominant face-to-face component. At the same time, by providing a fully featured Content Module, WebCT allows faculty to create sequenced chunks of instruction on an as-needed basis.
An institution could (and perhaps should) debate the pedagogical merits of linear vs non-linear content, and select an LMS that best suits their preferences. Having done that, how might that institution classify Sakai? At first glance, Sakai would seem to be pedagogically neutral, and thus an appropriate choice for an institution with a wide variety of needs. Looking deeper, however, it turns out that Sakai does not provide strong support for either pedagogical camp, and almost no support for those desiring to generate linear chunks of content.
If we assume that the desire to organize and sequence learning activities drives the need for a content module equivalent, then it is a bit easier to think about the types of goals we need to achieve with a Sakai work-around. For the sake of argument, here are some possibilities, highlighted items or sub-items are not possible with any of our identified work-arounds.
With those criteria in mind, here are five proposed work-arounds, with the strengths and weaknesses of each.
General weaknesses: None of these solutions can provide tracking or seamless integration with other Sakai tools such as quizzes, glossaries or discussions. Where (1) has been indicated as a strength, this refers only to the ease with which Resource files and external urls can be grouped. External content might of course include multimedia or stand-alone activities, but we have no identified way to integrate module activities to the gradebook or any other Sakai tool.
Strengths: (1)(2) It is relatively easy to place files into Resources sub folders representing a content module. It is also possible to add a link to a Resources folder, which could take students to files in other folders, or files on the open web. Within Resources it is possible to rename and resequence files, although the resequencing interface is hard to find.
Weaknesses: (4)(6) Unfortunately, I could not find a way to make a resource entry a relative link, which is bad for portability. Links that go to a My Workspace folder would be portable, however, linked-to files would have to be made public. Navigation links that appear within Resource files (ie, next/prev links) would have to be built and maintained by hand using html. This is relatively easy for files created in html, difficult or impossible for other file types, without resorting to frames. Existing content modules are often a clutter of files, with no easy way for the students to guess which files to open, or in what order.
Strengths: (3)(1)(6?) This is the best solution in terms of navigational aids. Materials (not including those created in other tools) can be grouped with ease, although it is difficult to take advantage of files you have uploaded to Resources without losing the navigational aids. Although I have not yet tested the import/export feature, Sakai to Sakai portability SHOULD be good. It is quite possible, however, that portability breaks down when links are made to Resources files.
Weaknesses: (2)(4)(5) It is imperative that you create events within Melete in the correct sequence from the outset. Resequencing is extremely difficult. Melete is strongest when used in conjunction with the SDK editor. One can write html pages within the tool, and then re-edit them at will. Using existing files within a Melete module is problematic. Under the hood, Melete will make a copy of any file you load into it, whether that file comes from your hard drive or from your Resources. The copied files then become uneditable within Sakai, and inaccessible from outside Melete. It is possible to create an html link to another page WITHIN a Melete page, however, Melete's navigational aids will not be available to students while they are viewing the linked-to pages, so using Melete in this way nullifies the tool's primary strength.
Strengths: (1)(2)(6) IF we assume that faculty will be building modules from scratch, and will not need to include non-html content such as spreadsheets, docs, pdfs, etc. then it will be easy for faculty to create sequenced pages using Matt's templates. Unfortunately, re-sequencing the pages will be painful, and most modules are likely to contain non-html content. Portability should be excellent if the pages are created with relative linking ONLY.
Weaknesses: (4)(5) Re-using a template page within another module would create problems because links created by faculty (such as to an image or other page) would often be absolute, and therefore unstable. The biggest drawback of this strategy is that most faculty will want to use pages they have imported into Sakai, including non-html pages. Using templates is not an efficient way to add navigational aids to existing content unless we create templates using frames.
Strengths: (1)(2)(3)(5)(6)There are a large number of robust, well-documented tools that can be used to build linked pages, many of which also offer educational features such as glossary pop-ups, self-test questions, and branched content. These tools will allow the creation of much richer modules than anything we can hope to do within Sakai. Most of these tools, and certainly all that we would choose to recommend, would enable easy sequencing and re-sequencing of content. Linking to a module either within Resources or on the open web is easily accomplished using a variety of Sakai tools, including the syllabus, the home page, Web Content links. These materials are perfectly portable, and automatically backed up by the copy created on the faculty member's hard drive.
As an aid for those who want to easily convert existing WebCT content modules, I have created a page which can convert any WebCT content module Table of Contents into an html Table of contents. This can be a snippet which could be placed within any properly placed html file, or it could be a free-standing html file, placed at the root of MyResources.
Weaknesses: Faculty must learn to use one or more content creation tools. The only other weakness of this solution are the ones shared by all solutions: no seamless integration with other Sakai tools (quiz, discussion) and no tracking. Many of these tools can create SCORM compliant modules, which means that if and when Sakai's SCORM player is made available, the content could easily converted to a format that would allow tracking.
Strengths: (1)(2)(6) The strengths of this approach are similar to the strengths of using the FCK editor. Best used when building from scratch, although I have developed a web utility that converts an existing WebCT Content Module TOC to a wiki Table of Contents.
Using the converter, one can link to existing resource pages. Current consensus (Matt and Becky) is that these should open in a new window by default.
It is an open question whether learning to write content in a wiki is easier or more difficult than creating the same content in other tools, especially if third party tools are considered.
Weaknesses: Faculty must learn to use the wiki, including controlling editing permissions over pages. Content that can be seamlessly included is somewhat limited relative to other tools, however, links to any other content are possible and would operate no differently from any other link that opens in a new browser window.
There are a large number of advanced, but somewhat peripheral features supported by the WebCT Content Module. These include things like book marking, a resume feature that lets a student pick up where they left off, seamless links to module-specific discussion, and embedded glossary links. None of these features is supported by Melete, and none can be re-produced with any reasonable work-around within Resources. Our hope must be that these features are rarely used, and/or that those who do use them won't miss them very much.
| Feature | Confirmed use | pedagogical impact | work-around or other advice |
|---|---|---|---|
| note taking | none | moderate | live without it, or use a third party tool that supports local note-taking (stored on user's hard-drive, not on server) |
| glossary links | 1 | moderate | live without it, or use a third party tool that supports a built-in (non-Sakai) glossary |
| integrated quizzing | 2 | moderate | ask students to navigate to the quiz themselves at the appropriate spot in the module |
| integrated self-test | none | high | ask students to navigate to the self-test themselves at the appropriate spot in the module, use a third-party tool that supports stand-alone self-test (results will not be tracked) |
| integrated discussion | none | high | instruct students to go to discussion themselves, be sure to create an appropriate discussion thread for them to use |
| chat | none | ? | |
| search | none | low, for small modules | use metadata to tag all module pages. Can Melete pages be searched? Not sure, but Resource pages can. |
| index | none | moderate | live without it, or create one using html |
| none | low | instruct student to send mail separately or use discussion separately | |
| bookmarks | none | low | live without it |
| resume | none | low | live without it |
| selective release | 1 | moderate | live without it |
| persistent TOC | 1 | low | live without it, hand-build a TOC using Sakai tools, use third-party tool that includes TOC feature. |
| tracking both between and within modules | unknown | moderate | live without it |