Hi
For the last few weeks or so, I am noticing that often when writing 子 , either alone or as as component of a larger character, the second stroke often does not register yet the app allows me to continue to the third stroke and then marks the character correct. The final character is missing this second stroke.
I am probably writing too quickly, but this never happened before.
It’s not a big deal, but thought you should know.
Could you let us know what characters/words you’re seeing this on? I’m not able to reproduce it on my device after a few tests but I’d like to look closer.
Follow-up questions that would be helpful. Is this happening during learn, test, or review mode, or all three? Also, a screen recording of the bug in action would be great!
Thanks in advance
-Jake
P.S. Have you tired refreshing local data at all to see if that changes anything?
I will keep an eye out for it and let you know.
My impression is that it happens during review mostly, and in any character in which 子 is a component. Definitely when I’m writing too carelessly or fast.
Could it be that handwriting recognition is converting just the first stroke to 了？Or does Skritter only accept three strokes for 子？
Yeah, this is exactly what Skritter does. Sorry, I didn’t quite realize that is what is happening based on your first post.
We have a short cut for 子 where you can write it as two strokes 了 + 一 . We also accept three-stroke writing. Both of them will be marked as correct. This is mainly to save time in the app, and also because this is how most native speakers write these when not focusing on perfect stroke order or doing calligraphy. A similar short cut exists for 纟/糸（the first two strokes can be combined into a single stroke)
i can confirm that this is aquite a bit bug and i am experiencing it all the time. quite often the website takes it as the wrong stroke (the shortcut) and usually it not very sensible from the shape or anything, so i dont know whats going wrong in the algorithm.
Same happens for the radicals of 建 and 阴, as well as for tje radical of 后
I have never reported it because its not too big of a bother but i would say abnout half the time when i have to correct skritters grading this is the reason
I’m not sure I follow, so please correct me if I’m wrong, but it seems like this would be a feature for most people, not a bug. As @SkritterJake says, these components are not written as separate strokes by most native speakers, except in very specific contexts, such as calligraphy.
Would you mind explaining what you think the problem is? It seems to me like you’re saying that you try to write e.g. 了 in two strokes, then Skritter incorrectly gives you the whole character instead of just the top part. But why would this lead you to correct Skritter’s grading? Treating the shortcut as incorrect here makes very little sense to me!
In the best of worlds, Skritter would be able to figure out if you intend to write it with one or two strokes, but since this is probably impossible to get right every time, I’m much more inclined to accept errors in the current direction. The alternative would be that many people who actually want to write 了 with one stroke ended up frustrated because they would now have to write an additional stroke. While I haven’t conducted any survey to really figure this out, I bet people who want the shortcut outnumber the people who don’t want it by large factor.
Now, if it’s the case that it doesn’t recognise the correct stroke even if writing carefully, that’s a problem, but if someone is writing quickly, I’m inclined to think that we’d rather have too many shortcuts registered compared to too few.
But like I said, I might have misunderstood what you’re saying, so please explain if that’s the case. 
I think you misunderstood, the problem is not that both variants are accepted or the one of them is favoured in recognition, the problem is that the stroke recognition algoritm quite commonly misjudges which one was actually written. And that goes both ways, so quite often I do have to write an extra stroke
sorry for my awful handwriting. So what is happening is that the user tries to write the two stroke 了 but skritter thinks that after the first stoke, the user tried writing the one stroke shortcut variant. So it subsequently rejects the second stroke.
The other way around also happens: the user tries writing the one stroke shortcut variant, but skritter thinks it is just the first stroke of the two stoke variants, so when the user subsequently does the horizontal stroke of 子, it gets rejected as skritter is expecting the second downward stroke of 了 instead
I made another picture to illustrate the point more
Here we have two variants with each stoke having a unique color. Left hand side is the legend, right hand side is what the user is writing and how skritter is interpreting it.
The use is trying to write the 2 stroke variant, but skritter interprets its as the first 2 strokes of the 2 stroke variant (seen right up). Thus it rejects any strokes of the next component of the hanzi, like the 日 from 阳. To continue the user has to make a wrong stroke to convince skritter that is actually completed the radical. (seen right down)
Thank you for illustrating! Just to clarify one more point, though, is it displaying correctly in the app? For example, what you describe would be extremely annoying with raw squigs turned on, because you wouldn’t know if Skritter recognised the shortcut ro the two-stroke version. However, no one has mentioned raw squigs in this discussion, so I assume that is disabled. That would mean that at least you should be able to see which version Skritter recognises. Naturally, if you write fast enough, you don’t want to wait and visually confirm which version Skritter thought you wrote before proceeding, so this would still be a problem, I just want to confirm that you actually do see what you are writing and that you aren’t using raw squigs.
i do not know, i do not use anything but raw squigs. i assume it would show correctly without it tho.
Also this yes
If I understand everything you’ve described correctly, nothing here is a bug per se. A frustrating experience, for sure, but not unexpected behavior. Basically in positions where multiple similar strokes are possible, our recognition algorithm picks the one it thinks is closest to what a user wrote. Sometimes that is the same stroke the user intended to write, sometimes it is not. In the default “snapped strokes” mode, it is quite obvious which strokes those were, but in raw squigs, it it fairly invisible which strokes Skritter thinks the user wrote. There’s no visual feedback as to where the app thinks the user is at until the recognizer says the character is completed and it shows the guide character in the background. Raw squigs is a mode where it’s freeing to see what was written in its unaltered form, but also frustrating sometimes because there are these invisible guides and metrics which the user still must conform to.
And this frustration between what the strokes look like on the screen (and what the user intended when they wrote that stroke) and what the recognition algorithm thinks the user wrote is what led us to create “rawest squigs” mode in the mobile apps, where Skritter preserves the raw user input, but turn offs stroke recognition entirely and lets the user be the ultimate judge on whether what they wrote is correct.
So if you’re already a user who prefers the freedom of using raw squigs and can depend on yourself to honestly judge whether you wrote a character correctly, I recommend trying out the “rawest squigs” setting. Otherwise, either adjust your writing style so the recognizer picks up on the intended strokes a bit better, or switch back to the default snapped strokes mode so that it is more visually apparent which strokes Skritter thinks you have already written.
This is most definitely a bug of your recognition algorithm. As it picks the wrong one. I cannot fathom by which definition of a bug you go, but I as dev definitely think an algorithm that does not work as expected is bugged. (expected here is defined by what your are trying to do, not by the incorrect behaviour of you algorithm)
As for how to solve this, you are taking the wrong approach. Rawest squigs is not solving the problem it is ignoring it. I do not understand why people would pay and use this website if they turn on rawest squids. If you do that you can literally achieve the same with anki for free. I have used that before I came here. Really the only thing you guys offer that one cannot achieve for free with little to no extra work is handwriting recognition. Pinyin? Anki can do keyboard input checking. Tones? either use text input as well or check in head. meaning? you are literally doing it equivalent to anki.
I am really sorry, but i seriously think you need to reevaluate your approach towards bugs. A while ago I reported that there are sync problems when often switching between the website and phone. How did you solve that back then?: You did not fix the bug instead you forced the bugged behavior always.
I have to do that a lot because I split my learning into smaller chunks. This irritated me a lot every day until i decided it is easier to just switch off my internet and only turn it on when i want to sync it. because of that i sometimes miss the audio for cards.
you guys seem to have a lot of technical debt and i think this is mostly caused by this attitute towards not properly fixing bugs but just making dirty workarounds. You really need to address your technical debt before you add more features. I am really worried that if you do not address your technical debt soon its gonna put you out of business.
Currently, out of the depth of my heart I cannot say that I would recommend your app as much as I wanted to. My experience as a power user has been extremely frustrating. And i hope I expressed this well and politely but with a tone that emphasises the importance of this. I am not here because I want to put you down, I am here reporting bugs because I want to help you. And i can advise you this: Focus on what makes you different from competitors. There are so many apps the teach kanji with pictures, videos etc. You do not need this. What you really need is that when a user comes onto your platform is that they have the best experience with what makes you distinctive: Kanji/Hanzi writing.
Please before doing anything extra, focus on your core experience and get that perfect.
Now back on topic:
It seems that currently you currently your algoritm only judges written strokes based on the user input for that stroke as well as all previously recognised stroken. Consider changing this to the following, instead of disgarding, keep the heuristic data for all previous stroken and upon the user writing the next stroke reevaluate the previous strokes based on that. This would allow you to retrospectively correct strokes that were incorrectly recognised. Yes I am aware that this drastically increases the amount the search space, but you limit evalutation to the last 4 strokes, so that would only complicate the search by 4! So it would take 24 times longer in the worst case, which i do not think is possible. If you need help implementing that algorithm I can help.
Cheers and best wishes
sirati
also something i want to put into a separate message. I have adjusted my writing style as much as possible to the biases of the algorithm. it helps somewhat but it doesnt solve the issue.
Further as Olle said 3
I write much too fast for that to make any difference. When skritter did not recognise one of my strokes, my hand usualy already wrote up to the next 5 strokes before I can stop it and redo the wrong stroke
Keeping track of stroke accuracy on alternative variations (say above a certain confidence threshold) and switching tracks based on future input is a cool idea that would catch some specific instances, but could also introduce other issues. It’s a good suggestion and we’ll definitely explore it, but even with the leniency of backtracking n steps, it doesn’t get to the core issue that Skritter could still miscategorize strokes and the user would be unaware of it. It could improve stroke acceptance by some amount, but it’s hard to say for sure just talking about the concept of it. And widening the problem space for stroke acceptance in raw squigs isn’t necessarily always desirable. For instance, as it is, I’ve mistakenly written entirely different characters with the same number of strokes in raw squigs mode and only realized it when the character was completed!
A future improvement we have planned is to add some more dynamic adjustments to how we detect strokes. While a 丿 stroke on its own might be better recognized by some slanted line, like say /, if it’s scaled down in the context as a part of a larger character, like say in 训/訓, it’s almost certainly going to be inputted closer to something like 丨.
Of course in the meantime we’ll look into tweaking some of the strokes you mentioned. But as @SkritterOlle stated, if we do have to choose between two similar strokes, we want to bias towards the shortcut stroke for the reasons mentioned.
This has happened to me as well. I think this is a fine tuning issue. As far as I am aware there are just certain components where this problem occurs. i can try recording this in the future. This might be fixable by checking if strokes that should intersect, do so. and that strokes that should start higher than another do so. as far as i can tell this is currently not a criteria for stroke recognition
##
new post/not continueing onwards from before
here an example: while i wrote the stroke clearly to low, the geometry does not match the fused stroke one well at all
I guess I am adding this here, so to not open a new topic
When abbreviating the 8th stroke of 劑 skritter gets stuck. The hanzi does not finish and even asking it to show you the next stroke does not even show any. This seems to be reproducable
There was an error with one of the shortcut strokes that 劑 used on the website, I’ve fixed it up. Thanks for the report!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
