As long as you give the option to continue typing in Hiragana I don’t really mind, as others said, IME autocomplete might hint you the answer, but to each their own, with their quest for Japanese enlightenment.
On the other hand, if the addition of this feature is gonna delay other cool features / content in the super secret to-do list, then I’d say “Don’t”
As others have stated, it would allow a bit too much fuzziness in my eyes to still make the SRS work correctly in reinforcing the right grammar. If this didn’t take considerable amount of re-working I wouldn’t really mind, as each person is free to learn / use it in the way they want, but I’d rather see some other suggestions / features implemented instead of this. (I do however agree with the showing of Kanji in the answer field after submitting!)
One thing I will note is that a few months ago I failed to recognize the た方がいい grammar point since I always see it as たほうがいい on bunpro. I think the “I would prefer hiragana input with kanji in the answer field after submitting.” option would be good as it lets people who do not read the sentences also have a chance to see it with kanji.
An obvious solution right now is to just read the example sentences, but personally I usually avoid the example sentences since they spoil the SRS for me and for simple grammar points I don’t usually go back very often to look over them.
Maybe you could roll out a little experimental Kanji acceptance on some higher tier questions to let people try it out and see if it’s a good or a bad?
I think showing the answer in Kanji (in the cases where that is the common way to spell it) would be good regardless of whether you implement Kanji input.
I am also still not in favor of Kanji Input, and have actually come up with even more reasons to oppose it. However, I am still not opposed to showing answers in Kanji and think this could add value without any drawbacks.
The arguments against Kanji input have already been discussed at length in this and the other thread, so I’ll just summarize them, and add a few new ones below:
To put my perspective bluntly, I am against implementing a feature that creates unnecessary false positives, undermines the efficacy of the SRS, makes unbiased self-grading nearly impossible, and reinforces bad habits, especially when implementing this feature takes time away from other projects that would definitely add value to the platform instead of potentially degrading it.
Ya and this is a grammar learning site, why focus on anything but grammar
@nekoyama Thank you both for in depth replies. And thank you to everyone who filled out the poll(s) and commented.
It is clear from that implementing kanji answers isn’t the right choice. It does seem to be the case that everyone agrees that at the least, seeing the answer in kanji form after submitting would be good, as it will help cement the mental relation between the grammar and the kanji.
Bunpro is really lucky to have a great community of learners who are passionate about making Bunpro better and are willing to voice their opinions.
Being able to offer up an idea and get feedback on it helps us a lot. Even if an idea is shut down, it is still worth making the post because it stops us spending time on that idea, allowing us to tackle more important features and changes.
Thank you 
I would love some kanji input. I’m using bunpro on my phone, and that’s a nice way to slowly increasing my typing speed using the kana swipe keyboard. Quite often, the kana are automatically converted to kanji so I have to manually go back and type again.
On pc/Mac, I don’t really mind, for my use case it won’t really make a difference ^^
Another thing to consider is that not all answers need kanji.
Why would I type a grammar point in kanji when most Japanese people type it out in hiragana?
Not many people are typing out 居る or 鉛筆 lol
In my opinion if you’re typing out the kanji then you already know the kanji reading. I like to see the hiragana so when I think of the grammar point I connect it to the phonetic reading. Otherwise my brain will go grammar-> kanji-> kanji reading-> answer.
I would love this. For whatever reason, I’ve always found it awkward and confusing that I couldn’t enter Kanji, probably because that’s generally what I’m doing elsewhere ( with the exception of Wanikani, but it makes sense there).
Hello! Just to verify, with 81% in favour of allowing kanji input in the poll at the time I post this, why was the conclusion that it shouldn’t be added?
For context, I found this thread as a new user looking for an existing bug report when my correct kanji input was rejected 
It’s obviously fine not to add it, just looking for clarity on the reasoning given a significant majority of users who voted here were in favour.
I think you misread the poll or I misread your comment. The 81% was about displaying the kanji as the answer after submitting. This is how it behaves now on the website (not on the app yet, AFAIK).
So if a cloze asks for 今 you type いま in kana and after you validate the answer 今 appears.
(I personally think that it’s the best compromise, I don’t really see the point of accepting kanji in the input, especially when in some cases like 方 or 間 or 中 for instance getting the correct reading is important).
That’s very possible! Though the second option being “it should not accept kanji input” led me to believe the first one had meant “it should accept kanji input”.
I was just surprised to type in 聞きます and have it marked incorrect without any indication that it doesn’t handle kanji input (on purpose).
Maybe the simplest solution would be to restrict the input field to only allow hiragana, and show a tooltip explaining the choice so the UX doesn’t just make it seem broken.
Yeah I think the poll is a bit messy due to being split in two parts. The 2nd poll is only for the people who don’t want kanji accepted as input.
Isn’t it effectively what it does currently? I tried answering in kanji right now during a review and the input box shook and I got a tooltip telling me to answer only in hiragana or katakana (although the rationale wasn’t given).
Ahh, I’m using the iOS app, that’s probably the difference
It’s marked as alpha software so missing features shouldn’t be surprising!
I sometimes use the android version (also alpha) and I noticed oddities there too, so I wouldn’t surprised if it were the case. Hopefully they’ll bring those apps up to speed eventually…
Hahaha! 
I totally did not check the date of the original post. Made a long response to the OP, which is surely moot/irrelevant at this point. Oh well. I’ll just wrap it in summary, in case anyone actually wants to read it…
I answered ‘No preference’ simply because there was no option for ‘It’s okay, but maybe a bit risky, and so I would make it low priority’, which IMO is a bit lower than ‘It would be nice to have’.
Personally, I don’t see much of a ‘use case’ for it. Or rather, there is a use case, but I don’t think there would be that many people who would actually use it. Of course, I could be wrong, but right now I just don’t see there being a widespread demand/purpose.
Plus, I could see this as being quite a significant development task, probably requiring quite a bit of new design of both code and UI. If the design is not well thought-out, it could easily end up becoming a development resource sink-hole. But that’s just my personal guess – I could easily be wrong about any of that.
If there was an existing library or tool out there that already had well-proven support for this, and it could be adapted by BP, rather than developed from scratch, then maybe it wouldn’t be quite so risky. But I have a hunch that due to BP’s already quite unique customer/user-base and their already quite customized UI, that even if there was some existing tool out there, it would still have to be customized quite a bit, and thus the overall risk might be about the same as if they were to develop something from scratch.
With all that being said, I can predict that eventually, at some point in the future, Bunpro will almost certainly have to ‘take control’ of their current text-input feature-set and develop their own custom library of input tools/widgets, so that they can introduce new innovations with confidence and control. I mean: Not just tweaking things here and there and hoping it works without breaking something else, but being able to introduce new features that they will be confident that they work well together with all existing features.
But I just don’t know if the BP software-base is at that point yet where such a core feature can be developed in that confident way.
Don’t get me wrong, I’ve been constantly impressed by what BP has done over the years. But I still feel plenty of ‘rough edges’ in the UI, the overall site and app, the data organization, user-feedback/bug-reporting, etc. If I could make one recommendation for development, it would be to take some time to polish-up and clamp-down on improving development quality and internal testing.
Specifically, if it’s not already being done, I might recommend building up a scaffolding of automated testing (from unit testing to acceptance testing to integration testing), and having a system of automated-integration.
Basically, having an automated system which builds and deploys the entire site/app at least once a day (to a non-public development server, for example), and which will fail-fast whenever there are, say, any unit tests failing.
From that foundation, do something akin to test-first programming: 1) where each new feature is first supported by tests (which initially fail, because the feature doesn’t exist yet, and are programmed in order to make the tests pass), and 2) where any changes to existing or ‘legacy’ code is first supported by some tests which exercise the existing functionality (if such tests don’t already exist), and any changes/refactoring is done such that it doesn’t break this test-scaffolding.
Obviously, I don’t know to what extent you guys already do something along these lines (and there are many variations of how to do it of course, the above is just an example), so maybe the above advice is not really necessary.
I’m just saying that, while I love all the progress BP has made, to me it doesn’t feel as solid as I would expect from a project which fully embraces that level of commitment to automated testing/integration/quality-control. That’s why I’m a bit skeptical that the system could really afford to take on the potentially big risk of revamping such a core component as the text-input controls. (Again, I could easily be wrong. This is just my own impression as a user observing from the outside.)
Sorry for long, ranty comment. Just brainstorming thoughts, so I won’t bother trying to edit for brevity.
Given the Bunpro team’s commitment to listening to customers and their track record, I’m confident that no matter what, at the end of the day, they will manage to develop the site/app in an appropriate way that will overall be a great thing! I’m just raising my ‘devil’s advocate’ cautions of potential hurdles and pitfalls that might cause such development to be more painful or take longer than originally hoped for.
Cheers!
Hi there !
I might be a bit late with the topic, but I’d like to add my thoughts anyway.
Coming from wanikani/kamesame and anki, I’ve recently started using the vocab decks, and I feel very frustrated that kanji answers are not accepted. I think the same about grammar points however it’s less annoying and less of a “must have”.
I’m doing all my japanese studies on my phone using Gboard as a japanese keyboard and am used to the “type the reading then select right kanji/vocab”.
When practicing vocab on bunpro I feel like something isn’t right, I mean you’d never encounter the word written in hiragana.
Typing in kana only, checking your answer then rereading the sentence and seeing it as you you would in the wild, it’s definitely not the same as typing the reading then picking up the right kanji/vocab.
Producing the word from scratch and seeing your sentence at that exact moment reinforces, well, production, but also recognition and helps associating reading/vocab, because “picking up” becomes part of the exercice !
So yes, Bunpro is at first dedicated to grammar, but if it tackles vocab, it should do it in the most efficient, useful way.
@NickavGnaro NickavGnaro talked about the IME sabotaging the learning process. He’s right, but there are workarounds.
IMEs would be required to input the Kanji, but IMEs’ auto-complete features make it impossible to grade your answers without bias. […]
After writing the same grammar pattern a few times, autocomplete options based on your typing history start popping up, so if you start typing out the answer correctly, the full answer based on your typing history would promptly show up before you are finished. Therefore, you would only really be practicing the beginning of the pattern, rather than the full pattern.
-I don’t know about the implementation, but the android app Flaming Durtles (awesome wanikani app) deals with it perfectly. No predictions/ autocomplete, at all.
Correct Kanji are often independent from the correct reading, so allowing Kanji answers would produce unnecessary false positives (answers with incorrect readings but correct Kanji)
a) If you forget the reading but remember the Kanji compounds, you could write the Kanji out individually, in a disjoint manner (e.g.: なか + こころ instead of ちゅうしん（中心）).
b) There are many ways to unintentionally produce the correct Kanji, but with the wrong reading, no matter how hard you try to avoid this. (e.g.: のしたで instead of the correct のもと（下）で)
a) As you type the answer, if the Kanji don’t show up, you now know that you typed in the wrong reading, which gives you the ability to revise your answer instead of getting marked wrong and letting the SRS do its job.
-If you know you’re cheating, just don’t . I think I’d know it’s notした or しも in の下で. If I used these shortcuts to get the right kanji, I’d sabotage my learning process by myself, not the IME.
Same for なか + こころ instead of ちゅうしん（中心) , or revising my answer if the right kanji doesn’t show up. You do control the SRS behavior. I’m getting a bit too far but you could also say “remove the undo button”.
And If unintentional, I could still check the reading and just mark the answer wrong.
Maybe a simple switch button to display kanji/reading next to the answer field would do the trick better, or auto display the reading, then an auto-evaluation step to mark right or wrong.
Adding on to my old argument from 1.b), sometimes it’s not only easy to unintentionally produce wrong readings, but (nearly) impossible to avoid. Consider when the Kanji is directly attached to the noun, but the answer field is only the Kanji part (e.g.: N上、N下、N中). If the answer field only had the Kanji part, the user trying to input answers with Kanji would basically be forced to write out うえ、した、なか instead of the correct じょう、か、ちゅう/じゅう. So the user would in these cases have to intentionally write out the wrong thing to produce the correct Kanji.
-Not sure about this part for 上, 下 and 中 are definitely in the list when typing じょう、か or ちゅう.
Well, you get my point. I think it’s a missing feature that would be great and help a lot, at least for vocab learning.
Still have to say thank you for your work. I absolutely love Bunpro ! 