@Brave-foot I agree that WaniKani deserves credit for its content and the years of work behind it. Wanilog depends on that foundation. I also recognise that community tools are unofficial. Keeping Wanilog working is my responsibility, which was something I wanted to make clear in the opening post.
I do think “skins” understates what community tools contribute, though. They offer dedicated mobile apps, offline study, typo correction and different ways to practise. Those features change how users can study, beyond changing how WaniKani looks. Several subscribers here have explained how much they matter to their everyday use of WK.
WaniKani is a paid service, so requests to improve that experience are within its scope, including where community tools currently fill a gap. The team won’t agree with every request, but there’s also the question of what happens after feedback gets “passed along”. For recurring requests, it would help to know whether anything is being considered, or why the team has decided against a change.
On the API, WaniKani has encouraged community development for years. The API v2 announcement made reliability across updates one of its stated goals. When API v1 was retired, devs were given nearly six months’ notice to adapt. That kind of communication helps us maintain our apps and could save both sides time dealing with problems afterwards.
I understand that offering an API creates work. But I don’t think requests for better communication are, in themselves, an argument against offering one. We’re asking how we can make something useful work better for everyone involved. I’d welcome the team’s perspective on what’s realistic and where the difficulties lie.
Hopefully we can keep discussing specific experiences and improvements, with room to disagree. I’d hate for the thread to end up locked before we’ve had a chance to hear from the team.