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