Wikisoba project/Scope and security

This page is kept as an archival reference.If you want to raise a point about it, please start a discussion thread on the community forum.

This page is for discussion in general terms of the Wikisoba project approach to using Javascript for educational software.

Basic approach

In brief, the approach is based on interleaving human-readable web pages with rendered code pages, typically questions. The web pages are of six types (at least): based on plain text, wikitext, HTML, URLs of MediaWiki pages, URLs of sections of MediaWiki pages, and general URLs. The content is to be pulled into the browser and rendered with a uniform plain skin, so that the reader is not immediately conscious of the different types of page (wiki pages should generate a link to their Talk page, however). The code pages are intended to be JSON-based. They would be based on different "question types", with the understanding that a question may be multiple choice or otherwise, and the answer may be for storing (survey type), testing against a correct answer, or for navigation (conditional branching type). The range of possible question types common in practice is several dozen, and there are numerous ways to vary them.

Example

Students are set a choice of two essays by their tutor. This means they are first offered two branches by a navigation page, with a choice of two buttons. Each branch then leads to some resources pages (explanation of the essay title reading lists that are already online, ad hoc reading lists as bullet points in plain text, wiki page sections, online articles ...). Then there is a page for submission of the essay.

It is natural in the MediaWiki context to think of the submission box as an wiki-style editing box, allowing it to be a drafting area. The submitted essay should not be on public view before the deadline for submission, to prevent cheating. (But after that it probably should, to aid detection of plagiarism.)

Therefore the security issue in this application is in the realm of submissions. There is no real reason for anything else to be kept secret. Naturally all academic testing depends on good authentication.

Table of general types

Type	Short description	Format	Processing	Portability	Comment
Survey	Questions only, e.g. anonymous feedback forms, personalised questionnaires	Multiple choice and some free text comments	Store answers and compute statistics with the multiple choice answers	Surveys are likely to be reused once designed
Test	Questions, which may be of comprehension type (resources before question), linear navigation
Timed test
Hardened test	Timed test with security provided by the maximum protection of the questions before the starting time, and measures against hacking of the answers in real time
Test with sections	Segmented timed test
Adventure	Conditional branching with rewards for accessing nodes
Investigative	Adventure with submission boxes
Assignment	Simple investigative type, without branching. Includes Wiki Education type with marking of student projects based on a wiki page
Edit-a-thon	Simple investigative type, with instructional material on wiki editing on one branch, a list of specified wiki pages to edit on another
Campaign (1)	Special investigative type oriented towards logging account creation and metrics
Campaign (2)	Special investigative type oriented towards logging uploads to Commons
Safe sandbox	Assignment type hardened for child safety

Further factors

Other considerations come up in academia, and more generally in fee-paying education and training.

Segmentation (courses)

The "course" is the standard unit of university study, as the "level" can be said to be in gamified versions. There is not the same need in the Wikisoba approach for segmentation. Time limits per segment do make sense, for testing as assessment.

Accesses

A platform like Moodle has a complex range of access (enrolment) options, via a separate API. It is not clear how much of that is relevant here.

Big problems requiring solutions: a manifesto

1. A de facto standard for quizzes and tests
2. A repository of quiz material where people can collaborate on free educational material with good authoring tools
3. Support for actual practices in the teaching professions, where teachers have used mashups for generations, well before OERs were named
4. Have OERs of value now licensed CC-by-NA released under CC-by-SA

Of these, #1 is arguably a prerequisite for #2: "uploading" quizzes for reuse is still hardly something to be done with facility, and Moodle's features to that end aren't slick. This is a problem that can be solved by technical means, though.

Also, #2 looks like a way to solve #3. There are repositories: but they are traditionally weak in attribution terms. There are large collections of OERs, but they need editing, and they need unrestricted forms of Creative Commons licensing. The view from the educational sector is that: time is always the issue for teachers, but they benefit in terms of professional development by knowing about open licenses, and recognition via attribution is a professional courtesy among educators.

Finally, #3 is a way to argue for #4. Having material relicensed CC-by-SA means that good OER development work need not be a different strand from textbook development in the commercial sector, but an auxiliary to it.