User:Drakefjustin/Fill-in-the-blanks

Comments and feedback is welcome.

Identity
Name: Justin Drake Email: drakefjustin (gmail.com account) Project title: Fill-in-the-blanks

Contact/working info
Timezone: CEST (UTC +1) Typical working hours: 10:00-13:00; 14:30-19:00; 21:00-22:30 Skype: Randomblue12

Abstract
This project aims to make learning content from Wikipedia articles more interactive, in a very simple way. I propose to develop a fill-in-the-blanks extension for MediaWiki. The tool would allow links from selected portions of an article to be (semi-randomly) removed, and replaced with a blank input box. The key observation is that an article's wikilinks hold pertinent and localized information, ready to be exploited for active learning and quizzing. Automatic correction and scoring will be available, with the option for users to override decisions.

Implementation details
What? MediaWiki extension or jQuery gadget

Language PHP or javascript

Main challenge GUI

Below is an architectural plan. In brackets are existing extensions which could be useful. Everything is still open to change.


 * 1) Retrieve and manipulate basic structured information from article
 * 2) Retrieve links (RemoveRedlinks  - especially Linker::link)
 * 3) Find non-liked instances of linked concepts
 * 4) Identify sentence structure of article [e.g. to remove at most one link per sentence] (see work done on sentence-level editing)
 * 5) Skinning
 * 6) Hide links (RemoveRedlinks)
 * 7) Provide standardized input boxes [the boxes should be of same length, to give no clue about length of link] (InputBox)
 * 8) Give instant feedback [and possibility to override automatic corrections if the user feel answer given is correct] (ArticleEmblems)
 * 9) Scoring and statistics
 * 10) Provide scoring (SkinBuildSidebar)
 * 11) Keep log of progress (use the Toolserver?)

Other comments

 * I want users to have the usual Wikipedia experience, so I want to build upon current skins.
 * The extension should be computationally light-weight, and I will focus on providing an optimized tool.
 * The MediaWiki API is an option to retrieve the set of links.

About me
I'm a fourth year student in mathematics at the University of Cambridge, UK. I completed my undergrad there, and I am currently enrolled in a Master's program called "Part III". This is probably my last year as a student. In particular, I should be completely free this summer, for full commitment on this project.

I don't have any experience programming for MediaWiki, but I use MediaWiki through Wikipedia a lot. I am relatively tech-savvy and I already coded basic stuff in HTML, Javascript and PHP, and less basic stuff in C. For sure this will be a great learning experience, and I look forward to it.

I am especially enthusiastic about this project as it relates to stuff I did at the start-up weekend in Cambridge, and there are plans to complement this extension with other work trying to make Wikipedia more interactive.

Deliverables
I feel that the project is very much doable in the given time frame. Therefore, I expect to be able to code most of the features discussed above. In particular, the goal is to have a basic working product by the end of the summer, as discussed in the project abstract. Having said that, I don't want this project to be classified as "too easy". There are further fancier features to be developed if time permits, which include:
 * 1) Per-sentence selection for quizzing.
 * 2) Improved automatic correction with synonyms and variant names, variant spellings and misspellings, stemming, etc.
 * 3) Automatic recording of quiz results for signed-in users. (E.g. store results in user/Example/Fill-in-the-blanks/Results.)
 * 4) Customization of density of links to remove, level of randomness, instant feedback, etc.
 * 5) Advanced scoring and statistics.

Project schedule
First half of summer


 * Extraction of links and mapping of "concept-space" within an article. (Indeed, Wikipedia policy is not to link concepts multiple times, so I will have to retrace every instance of a linked concept.)
 * Have a usable and neat UI, with basic functionality.
 * Testing, tweaking, optimization, and rethinking of best way forward for second half of summer.

Second half of summer


 * Reach a useful product, which is easy to use.
 * Add a selection of more fancy features (from the above list).
 * Testing, tweaking, optimization, and rethinking of best way forward for future.