dollar/kanjicaptcha — Issue #2: Defining the functionality
Author: ACPie
Created: 2012-01-20 16:26:58+00:00
State: open

I'll reiterate and expand >>>/a/60145311 here on Github, as requested.
I think it would do the project a lot of good to define its functionality in more concrete terms, getting it to a point where programming can start getting done with clear goals in mind. The main functional problems I see in this project are:
1. Injecting the captcha
I don't code frequently, and never in a web environment, so I don't know anything about implementing this in practice. There should be some consideration as to where the box would be located, how it would interact with the button (grey it out, put out an error message if it's pressed without regarding the captcha and so forth) and how it would look.
2. Choosing the content
This, I suspect, is the heart of the project, at least as far as /a/ is concerned.
Katakana and hiragana should be simple enough to implement, the user would just have to type in the correct pronunciation in English letters. A system implementing kanji quizzing should have all the component needed to implement this, so it would be a waste not to include it, especially for the newfags' sake.
Kanji is the harder part. The simplest way to go about it would be to present a kanji, chosen in random or according to some order out of the standard Japanese government list, as a picture, and have the user input it using his chosen input method. The main drawback here is that continued practice using this test alone would merely train people in operating certain IME methods based on character appearance, or in the act of looking up a character and copypasting it.
A better method would have to demand of the user some kind of translation of pronunciation for the kanji. The problem here is that lists of kanji usually have a whole mess of details attached to each kanji, like definitions, keywords and many different readings. I don't know if it's possible to choose from these details in a way that would present the user with a challange that wouldn't be completely arbitrary, like guessing the particular reading that appears first in the database. So, there needs to be something else. Training people on matching the kanji to their Heisig keywords could work, but I would say that it favors Heisigfags over people using other methods. We could do it the other way around, for example by showing the Heisig keyword as the challenge, and having the user input the kanji as an answer, a solution that would be a little more acceptable for non-Heisigfags.
Another method could involve words rather than individual kanji. There are various lists out there, some of theme arranged by frequency or by some other order that would be helpful to a learner. With words, there is usually one reading, and when there are more it should be simple enough to have the program accept either, while still keeping th exercise meaningful. This could be a nice solution, giving people practical training, though not as thorough or as techincal as a purely kanji-based test.
3. Choosing the regime
The thing that will make or break this tool as a part of people's lives is their ability to live with it. Some people wouldn't be comfortable with getting hit with a new question whenever they shitpost, and some wouldn't want to be dealing with randomly chosen kanji, alternating between yesterday's stuff and weird shit they've never even heard of.
People should be able to choose how frequently they get challenged. A basic set of options would be every time, randomly at an average rate of x per hour/day, randombly at a probability of x per page view and x tests every y hours with no further tests inbetween.
Along with that, there should be some control over the ordering of things, the setting of goals and possibly over the repetition. Anki is a great example for that part, it gives you a set of options granting you pretty thorough control over the way the program trains you. Seeing as Anki is based on SRS, a tried and tested training modality, copying it could give very nice results and possibly save some coding work depending on the avilability of open source programs implementing SRS.

I hope you'll read this wall of text and find it useful. I hope I'll be able to be of service in this project and see it through, there should be plenty of non-coding work I could do.