We’ve expanded the shake warnings in lesson quizzes and reviews to handle more common mistakes like typos from users not yet familiar with typing kana. We’re planning to turn this change on production this week, possibly tomorrow (February 17 PST).
This didn’t involve any change to CSS or HTML. In jStorage, items that had auxiliary_meanings now also have auxiliary_readings. Entries for both can now also have a new type called “warn”.
On the JavaScript side, we’ve updated answerChecker’s evaluate function to implement this feature. The function still accepts the same arguments as before.
The results returned from answerChecker’s exception field can now be either a boolean or a string. If it is a string, it is displayed in the tooltip. It if it is a boolean and true, it results in a shake, without a message.
The shake warnings we’ve implemented are prioritized over the previous results returned by evaluate. The first shake warning that matches is returned, and the rest of the evaluation is skipped.
Do these changes have an impact on the API. I mean is the subject endpoint modified to return auxiliary_readings and do both auxiliary_readings and auxiliary_meanings have new types in the API results?
Sorry, I made a mistake. You’re correct that properties like those don’t seem to exist. I must have misremembered.
P.S. Unrelated, but any chance that you or someone else who works on the front end can at some point take a look at these latency improvement suggestions? (~6x latency improvement during reviews.~10x in lesssons, ~3x of which is achievable simply by making a backwards compatible change to jStorage for which permissively licensed code and a large number of QUnit tests are provided.)
I’m quite new wanikani scripts, or even just javascript in general so forgive me if this is a dumb question, but this in particular:
I’m debugging through an existing scrip called double-checker but I don’t seem to see this behaviour. So for example one of the new shakes mentioned in the announcements is “Entering the reading into a Meaning answer field”. So for the meaning of “交じる” I type in “majiru”. But in the response the exception is still false. Am I misunderstanding something? Should the exception field in this case have a string of the warning?
I’m looking at it right now, but it’s going to take some time to evaluate the changes. There are a lot of combinations of options that users can select, and I want to make sure nothing is going to break. (I realize a lot of people have been using the forked versions for a while, but that doesn’t mean all paths through the code have been tested).
I’m also looking at cleaning up some of the old code and integrating it into Wanikani’s new Enhanced Answer Checker interface. They’ve added a lot of Double-Check’s answer-checking options natively (very nice!!!), and any that aren’t yet integrated would be better off transitioned to the new interface’s plugin list.
How did you guys know how to use the new enchanced answer checker, or what its interfaces are and what its capable of? Is there documentation somewhere?
Is there a clean way of getting the list of plugins for enhanceAnswerChecker? I know you can replace the default list by passing a second argument to enhanceAnswerChecker(), but I didn’t immediately see a way to actually get the default list since it didn’t seem to be publicly exposed.
Also, if you have any questions about why certain changes in the forked version were made, I’m happy to answer them.
Finally, I’m not sure if you are planning to merge the burn warning functionality (which is now pretty mature), but if there are any style / quality related changes that would increase the chance of it being merged, I’m happy to oblige.
I think most of it isn’t documented. I think the main ways people learn this stuff is
look at a related script and see what they did
look at the publicly exposed variables in the browser console and investigate what they seem to do
read WaniKani’s javascript source code using the browser’s developer tools. Some of it is minified, which can be a pain, but their newest code mostly has source maps so you can read the original code with all variable names etc. intact.
The only way to extract the default plugin list programmatically is to get the source code of the function via enhanceAnswerChecker.toString() and parse the source code.
But you don’t necessarily need the default list. If you capture the enhanceAnswerChecker() function, you’ll be passed whatever list is actually used, which is currently the default list since WK doesn’t override the default.
So far, I’m understanding everything, though I’m still working my way through the code.
I will probably merge it, but, to be honest, I’m a bit dubious about it.
Personally, I think people should only change answers in two circumstances:
Real typos… i.e. you 100% knew the right answer, including saying it correctly in your head, but your fingers mistyped it due to fat-fingering or misalignment on the keyboard.
You typed the right answer to the wrong question… e.g. you thought it was asking for the reading and you answered the reading correctly, but it was actually asking for meaning. So, after the warning, you reenter the correct answer successfully.
Neither of those cases means that your knowledge of the item was lacking, so there’s probably no reason to hesitate in burning the item. But if you do hesitate, I wonder if you are being too lax about changing answers.
So, essentially, I’m not keen on encouraging potentially harmful features. But if a feature has a legitimately beneficial purpose, I have no problem integrating it, even if it does require self-control to use properly. And in that case, I usually leave the feature disabled by default, so people are less likely to abuse it by accident.
In my case, by reading the Wanikani source code in the browser’s developer tools.
Maybe I’m doing something wrong, but when I log the arguments to enhanceAnswerChecker(), I only see WaniKani calling it with one argument. So I’m not sure you would be able to get a list of WaniKani’s own plugins by monkeypatching enhanceAnswerChecker if that’s what you were suggesting.
I think at least my own personal use of the burn warning feature is consistent with the principles you mentioned. I use it for a few things:
When I get a question wrong, I try to think of the correct answer and (even if I remember it) mark it wrong and move on to the next question. Sometimes, instead of just thinking the correct answer, if I’m on autopilot, I may accidentally retype it.
I use the fact that other scripts can trigger the warning with the confburn flag to warn if I relied on “do you even kana” or took a long time to answer the question.
I could imagine people wanting to use the “always warn” setting to make sure people feel they know words well enough before burning, even when they legitimately got the burn review right.
I think there is a really hacky way of getting the list, but I’m not sure I would recommend it. If you temporarily redefine the Array.prototype.length getter and then call enhanceAnswerChecker() or maybe evaluate() on the returned answer checker, I think it does eventually call .length on the array you want. So you could get a reference to the array that way and then copy it. But again, not sure this is a good idea.