Wikisoba project/Scope and security: Difference between revisions

From Wikimedia UK
Jump to navigation Jump to search
(start page with intro and example)
 
(→‎Example: start table)
Line 9: Line 9:
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.)  
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.
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==
 
{|border=1
!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 with the multiple choice answers||Surveys are likely to be reused once designed||
|}

Revision as of 15:33, 7 April 2015

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 five types (at least): based on plain text, HTML, URLs of MediaWiki pages, URLs of sections of MediaWiki pages, 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 with the multiple choice answers Surveys are likely to be reused once designed