1
Solved

Option to reveal answer after drawing

Currently Ringotan basically reveals the answer already while drawing the kanji.

While this looks really cool, it has a few downsides:

  • the user is influenced and draws the kanji differently than if he had not known part of the answer
  • the user doesn't see what he drew exactly
  • due to that the opportunities to learn how to draw the character more exactly are lost

Since Ringotan already supports stroke-by-stroke detection of whether the kanji was drawn correctly I suggest to add a new option "reveal answer" which can be set to "while drawing" (current behavior) or "after drawing"

The "after drawing" option would change to following:

  • the answer is only revealed after a wrong stroke or once the kanji was completed and the finger lifted
  • instead of the partial answer, the drawing of the user is displayed (behaving like a scratchpad)
  • once the answer is revealed, it is displayed below the scratchpad-like input of the user

Since I expect this kind of feature to improve retention and writing accuracy a lot, I'd be willing to donate €50 to support the implementation of this feature on iOS.

1 reply

This is how a few other apps work, but I absolutely hate it.

Firstly, you claim it improves writing accuracy, but my experience has been the exact opposite.  Because you don't get immediate feedback when a stroke is off, you end up making the same mistakes over and over without noticing anything is wrong.

Secondly, this style of input doesn't work at all with the input detection used in Ringotan. If your strokes are drifting away from where they are drawn in the font, the app might mark your drawing as wrong when they should be correct, simply because your strokes are shifted too far in one direction.  To get this to work you'd need an input detection algorithm completely different from Ringotan's, which would (unless you use some sort of ML) ultimately be less accurate.

I'm still considering the other request, but I think I need to decline this one.

A

Ok, thanks for explaining why you won't implement it, sounds plausible.