User:JimTittsler/Sandbox/NDLRW

= National Digital Learning Resource Workflow =

Goal: To encourage teachers to develop and reuse digital learning resources, and to make those resources available to their students without significantly adding to individual schools' infrastructure.

Subgoal: Strengthen networks of like-minded teachers as they collaborate in developing useful resources.

Traditional solution

 * packaging strictly following an international standard
 * tools that simplify creating, editing, combining, and translating existing packages
 * each package contains metadata conforming to a standard taxonomy
 * repository containing resources created across the country
 * clear license framework that encourages reuse
 * quality control review process to vet resources
 * search engine that allows average teacher to readily find relevant material
 * learning management systems that accept packages from repositories or users
 * ability to share content packages internationally
 * collection point for student artifacts
 * interconnection between student resource use and student/class management
 * major infrastructure investments and ongoing maintenance centralized

Impediments to that ideal

 * interoperability has not been guaranteed by existing packaging standards
 * which packaging standard?
 * authors frequently want Web 2.0 style freedoms
 * experience suggests typical authors are careless about metadata (and licensing)
 * needs a librarian or curator to maintain repository consistency
 * requires software development to reach starting point
 * requires significant time, staff, and budget to it do right

Alternatives

 * 1) simply "use the web"
 * 2) suggest some structure, like MediaWiki (WikiEducator)
 * 3) use GoogleDocs (or equivalent Zoho, Microsoft, etc. offerings)
 * 4) Learning Management System

Use the Web

 * so unstructured it is hard to reuse content or capture it for local deployment
 * may not provide enough focus for all learners/situations
 * available since 1990

Structured Web Content

 * use a wiki or content management system to contain resources at the page level
 * shares cost burden across staff members with expertise
 * authors can build or strengthen a community of teachers with similar goals and interests
 * individuals can develop resources individually if they wish, but don't need to feel they must
 * pages are less likely to become stale than packages, because the barrier to update/revision is lower
 * wikitext and templates provide enough structure that tools can be written to import/export in other formats
 * content is easily transferable between like installations, including institution-specific
 * metadata can be embedded in templates or comments
 * text pages are readily indexed by traditional search engines
 * custom search boxes are possible
 * parallel instances can provide multiple language support
 * WikiEducator has an existing, enthusiastic community
 * built on MediaWiki whose code is ugly, but has been proven to scale well and be secure
 * hardware/software resources to run local instance can be small and are well understood
 * very low barrier to entry, with additional flexibility as you become more fluent in the environment
 * rich text editor extension available for text areas
 * OpenOffice can export wikitext, Book extension can export OpenOffice doc format
 * rapidly developing tool for exporting collections of pages in PDF
 * proof of concept tool that allows exporting to traditional LMS
 * available now, can be used immediately and incrementally refined
 * in the simple case, can be used for deployment and student interaction
 * peer review provides better quality assurance than an individual practitioner
 * convention over configuration: a suggested, evolving "best practice" that allows outliers
 * allows incremental "just in time" and "just enough" YAGNI agile software development
 * content-centric redefines interoperability to being able to store/extract/index/reuse content, rather than interconnecting specific technologies
 * An example of one way this could work is diagrammed at OpenOffice-WikiEducator Workflow

Disadvantages to a wiki (and WikiEducator in particular)

 * everything is open
 * quality control concerns may require using specific revisions of pages rather than latest version
 * everyone must agree to the open license
 * unit of transaction is typically a page rather than a package (collection extension goes some way toward changing this)
 * encourages a proliferation of ad hoc connectors between different technologies that can be dated as things continue to evolve
 * to date there has been no good quizzing solution