Add more stats

[yacoob]

With the unfortunate demise of ky.is WK users have lost a powerful tool. Why not add this functionality to this app? ;3

Specifically I'd like to see:

• historical data for time needed per level and estimate of this for current level
• n/m stats per jlpt level, school class and popularity

What do you think about this?

[s84606]

That's interesting.. Also because you are not the first asking me for more stats. It seems a lot of work, so it will take a few releases to implement everything (there's also the new IME stuff which is taking me a lot of time).

A rough schedule (after the next release which is already frozen):

Release A:

• Estimate for level 50 seems the easiest thing to do. I could use a weighted average, to make most recent levels more significative
• Estimate for current level seems a little bit trickier, since I'll have to look at the current streak for each apprentice item, but seems ok.

Release B:

• Historical data. This will take a little bit more because I'll have to add histograms to my plot library

Release C:

• JPLT, school class and popularity. Since I've never used kiko's app, I need some guidance here. What kind of data should be plotted? Is it only related to kanji or vocab too? what are the sources?

[yacoob]

relA: why not make it estimate for level N, using same algorithm, with default value of N being 50? The closer N is to current level, the more relevant current streak time becomes.

relC: There were three sets of kanji sets on ky.is:

• JLPT levels - kanji per JLPT level
• school grades - kanji per school grade in which given kanji is learned by Japanese kids
• frequency - kanji per 4 frequency groups, based on newspaper corpus; not sure where this data is from, kanjidic has some indices but they're rather old; there's also this and this

For every set, there was a table of WK coverage - by WK level N, you'll learn A% of JLPTX, B% of gradeN, etc. In addition, there were pages visualising how much of each of three sets you currently know. This would be a large page, with all kanji separated into groups, and coloured according to your profile. Check here for an example.

[s84606]

relA: the reason I thought a different algorithm was needed for the current level is that, using a simple (weighted) average, the expected completion date can end up being in the past. On the other hand, by looking at the API, it's not possible to guess in a reliable way the shortest possible completion time, so I believe I'll implement the two predictions (current level and level 50) with the same algorithm as you suggest (I'll use different weights).

relC: thank you for the input. I think I'll start with a pie (or some more compact) diagram for each of the sets you described. At a later stage, if I can see a suitable way for mobile devices, I'll add a more detailed, kanji-by-kanji representation

[ascendedguard]

Just my two cents on the subject:

It seems all the tools I've used so far for this, including http://peterkinnaird.eu/kani/#levels are fairly buggy, and everyone seems to get different results. Besides level 1 always being a large number due to the difference between signing up for Wanikani and actually using Wanikani, the duration of the following levels can be random.

For example: http://imgur.com/kR0xUMN - I completed Level 1 in 28 days, and Level 2 in 4 hours, while 3 and 4 are more reasonable. On Wanikani Mobile, Level 3 doesn't even appear as it jumps from Level 2 to Level 4 (possibly because 2 and 3 were too close together?). Impossibly low completion times would need to be dropped as well.

[s84606]

Since you are not the first to report this problem (@ankotaro told me level 10 is misplaced in his profile), I believe there's a bug in Wanikani, causing it to set an impossibly early unlock date for some items. Probably the simplest way to fix this is to choose the second unlocked item for each level: I'll schedule this for relB in my list above. Note that I swapped the relative order of relB and relC. Apart from this, there are two sources of differences between the WKM predictions and other apps:

• Levelup times in the DB are recorded at a very low resolution: one day. This arises from the fact they were meant just to be used as markers on the stats page. In relB I'll fix this by implementing a finer resolution.
• There are a couple of a bugs (fixed in the next release): one causing the last level to be disregarded, and the other adding a fixed offset to the forecasts. I did not notice them before, because I had the unwise idea of releasing the app before levelling up;
• The algorithm is quite different from other apps. Basically the app takes all the levelup times, drops the shortest and the longest. Then computes a weighted average, where the weights are an exponential series with cofficient set to 0.707 (level 50) and 0.42 (next level). The rationale is that recent history is more important when predicting completion of the current level. The coefficients themselves, are blatantly arbitrary and clearly show my cultural background :)

[s84606]

Just to tell you that I've committed most of the features described in this issue.

I've left out two things:

• Correction algorithm to fix levels that were passed in a suspisciously short time: requires some effort since I can't reproduce the issue;
• Change granularity (days -> hours). Don't know if I'll ever implement this: there are so many approximations in it that it's probably not worth the cost.

However here is a build, in case you want to give me some feedback. It may still be a little shaky, since it is the result of a merge of three branches. In addition I still don't like the progress diagrams.. they look like cigarette stubs; may change them as 2D bars:

https://www.dropbox.com/s/9qdxarfw9yvduey/WaniKaniMobile-1.7.0pre0.apk

[yacoob]

In short: impressive :)

In details: there are some snags:

• the Estimates box is bit too wordy, how about putting it into a table with two columns, left column adjusted left, right column adjusted right, contents:

Average level time: x
Next lvl in: y
Lvl 50 on:

• The Other screen has More button that shows exactly one extra graph. It looks a bit weird, why segment them like this? Perhaps it'd be better to put all graphs on one page, in collapsible sections, with today's stats expanded by default.
• The bars in JLPT/Joyo progress can be just bars. No need for 3D IMO.
• Levelup time graph is unreadable for some reason. See the screenshot:
• How about grouping the stats in different categories:

Kanji - progress pie chart, JLPT+Joyo progress breakdowns, SRS by level SRS (with an explanation that this is kanji+radicals+vocab) - progress pie chart, by level Time - estimate, time spent per level, progress of kanji/vocab/radicals over time

[s84606]

Thank you for your feedback. Very valuable. I'll comment on each remark:

• estimates: Corrected to make them look as you suggest. I had chosen a verbose description because I could not find a description that could fit in small screens, and it looks ugly if the entries wrap around. Now I've switched to a more compact description and they look tidier;
• The rationale behind this odd segmentation is the avoidance of unneeded bandwidth consumption. The base stats require little or no network access. The "Other stats" trigger a full scan on radicals and kanji, the last graph triggers a full scan on vocabulary items too. However I like your idea of moving everything to a single page, using a collapse/expand paradigm. This way I won't need to download data unless explicitly requested. Of course this requires a considerable change in how stats work currently, so I'll schedule this for a future release;
• 3d vs 2d bars: changed to 2d look. Also I did not like them that way;
• unreadable plot: it looks like the first level lasted months, so the horizontal grid lines (one per day) became so thick to cover the whole plot. Is it correct or there's also a bug in the way levelups are calculated? At any rate I've corrected the scale algorithm to ignore bars higher that 30 days. This is a temporary hack that will be replaced with gesture detection to the let user choose the Y scale autonomously;
• grouping: I'll group the plots as you suggest once I make the plots collapsable. Here's the new APK: https://www.dropbox.com/s/ss1z01iza4cjgzr/WaniKaniMobile-1.7.0pre1.apk BTW, this APK also reorders levels when they look exceptionally short (<= 2d), so it should fix the issue reported by @ascendedguard. This is done as a background daily job, so it may take a few days before it converges to the correct spacing.

[yacoob]

re: bandwidth - you can cache the old data, and update as needed. However, with the new grouping I'm not that sure when is the best moment to refresh the data... short of a "refresh" button, which would be easy but ugly :)

The unreadable plot looks better now - but I think the main change is the background (white now, black earlier). The long first (and maybe second) bar is probably a popular pattern among WK users. Current solution seems fine and is probably the most sensible way to deal with that. Perhaps some visual marking that the bar is off the graph?

[s84606]

Yep, data is cached, the problem is that those graphs require a lot if information that usually the app does not need at startup. Typically, when you open the stats page, the app has just downloaded items from the current level only (because the item browser needs them). When you access the "other stats", it needs to download all the other levels. Grouping them seems a good solution to me, since it allows the user to choose whether to download them or not (some people have tight bandwidth requirements, which I'd like to partially address in the next release). Data will be cached until the "refresh" menu item is pushed, or a review session completes.

As for the visual indicator, yes: that will be the last feature before freezing rel 1.7.0.

[s84606]

Series 1.12.x completes implementation of the issue