Hi everyone - posted about this in my regular thread, @Saimin suggested I create a stand-alone one.
I have long periods of Japanese inactivity, and I worry about my burned items rotting. I have a really hard time doing flashcards to start with, so I wrote this. It takes your burned items and composes a crossword with them:
Hiragana / Katakana entered directly through the IME cause some weird effects in flutter - the program uses a dart port of WaniKani’s own WanaKana library, so you can just type roman letters and you should get automatic conversion to whatever that square is looking for. (Digraphs such as きょ will be spilled to an adjacent square if possible.)
I have put it up here on Github Pages but it still has a lot of features I would like to add (and which I am unfortunately running out of time to do.) The two most important ones are:
Persisting the user’s token between sessions.
Being able to backspace properly, and keyboard based navigation generally.
Repository here. Bonus content includes me checking in an API token in the comments and then having to expire it.
I love crossword puzzles! I’m defo giving this app a try later! ^>^
A couple of suggestions:
-being able to restrict number of items fetched and so the size of the crossword puzzle
-being able to restrict from which levels, the items are fetched and so the difficulty of the crossword puzzle
But I really like it! ^>^
it seems that when you fill in intersecting words, the pointer continues onto the next one, erasing your previous answer, forcing you to retype. (i.e. moving from down → across, overwriting the previous answer here. The first character is erased, and when filling it in again, the marker moves to erase the next character)
Thanks @ekg - that’s good feedback! I’ll look into adding an options screen at some point.
For the intersecting words, yes, I think I see what you mean (the going “around the corner” problem). This is part of what I meant about wanting to redo some of the navigation. At the moment, navigation works like this:
The crossword has an internal travel direction that is “trying to go down” or “trying to go right”. It gets set when you click on a clue of the appropriate type.
Whenever you fill a square, it tries to move the cursor. The travel direction is only a preference, so if you are “trying to go down” but there is no square below, you will still go right if possible. Afterwards, the crossword will change its “trying to go” status to match whatever you just did.
Whenever you move in this way, you clear the square you’re landing in (so I can just type the whole word from beginning to end from the first position.)
As you’ve noticed, this creates a problem when you have something happen like this:
I’m spent a bit of time thinking about what the right behaviour should be, and I’ve now made some changes. The short version is, traversal should not scrub the square you arrive at if you got there by changing directions. Also, clicking in a cell should not clear it (or any other cells), but clicking on a clue should still clear the first cell for you to type into.
There are still some bugs. If you click directly into a cell, what happens after you type your next character might be different depending on what your travel direction was (from your previous play), as this will affect whether or not the program thinks you changed directions. But I think it is a bit of an improvement over the old navigation code, so I have pushed it to the live version - it took a bit of fiddling for Firefox to stop caching the old version, but it worked straight away in Chrome. Perhaps a cleaner solution would just be to select the contents of the square whenever it becomes focused. Or I just really need to get arrow-key navigation up and running.
(edit: 30 seconds after sending it live - it kills digraph propagation, groan - you’ll have to type your きょs with ki + xyo. fixed, I think)
@Tantivy - thank you! @sakuchu - please, feel free - the code is MIT licensed, so feel free to make changes, make your own version, or make suggestions. I’m a git novice, but I’ll eventually work out how to e.g. accept pull requests.
Pretty cool! It would be nice for the selected square to stand out a bit (a coloured outline, different colour background, anything to make it easier to find), and also to have a button to “finish” (show the answers for any not already filled out).
But overall great work!
yeah, moving around with keys would be nice i think even if nothing else, being able to backspace delete would be great
minor thing but is it possible to make the crossword itself fit the screen? i’m okay with scrolling through clues if that’s the compromise
i agree with @ekg on the restrictions of size too, it’s nice having so many burned items to review at once, but i can also see it being too many sometimes and being able to limit it would force me to do them all in the time i have, rather than just doing the ones i know and skipping the rest
is there a way of showing when you’ve got a word (in)correct rather than the score? like highlighted in some way, or a colour change? i can see it being difficult to work out which one you’ve got wrong sometimes otherwise
other than those minor things (most of which are just personal preference), it’s great! very helpful, and i see myself using this in the future!
I’ve built something sort-of-similar - a toggle that shows the correct answers beneath the text entry area (almost like anti-Furigana). Combined with the selection highlight, it looks like this:
This required a fairly fundamental change to the way the program works, so I am going to hold these changes a tiny bit longer for testing.
(I agree about the other two things as well.) Forcing the crossword not to spill off the bottom of the screen (is that what you mean?) should be possible - a screenshot would help me be sure I’m understanding correctly. In terms of tagging incorrect letters (tagging the whole word, or the clue, would require a lot more rerigging), yes, something like this:
I will try and push this at the same time as the other two changes.
Ouch. Currently the clue list is shuffled and cut down to 250 items maximum - the way this works at the moment is that you might get a different 250 items in each re-flow of the puzzle (and it never manages to get all 250 onto the grid anyway, which is sized to twice the length of the longest answer + 1). But in light of this, I will need to cut it down during the initial request. If I add a puzzle size parameter x, we attempt to fetch 4x random items from the burnlist, randomly select 1/4 of them, and attempt to fit them.
Unfortunately I still haven’t been able to get this to behave the way I’d like (layout is confusing), but I have pushed out the following changes:
amber highlight for the currently focused square;
incorrect answers filled with pink instead of being cleared (move focus through them to set them back to normal);
a “hint mode” toggle (the “?” icon on the top bar);
login screen now also prompts you for a “puzzle scale.”
Explanation of what Puzzle Scale does
Your generated crossword will never have more than “Puzzle Scale” questions on it.
Puzzle Scale also affects how the program talks to the API. When you log in, the program gets a list of ID numbers for all of your burned items. This information comes back from the API fairly quickly even if you have lots of burned items, but it doesn’t include the item characters / readings / meaning.
After this list is retrieved, the program randomises its order and then picks Puzzle Scale * 4 items to get detailed information for. The detailed information can be retrieved 100 items at a time. Not all the items are kept - if the reading is only one or two characters long it is discarded.
So if your Puzzle Scale is 20, when you enter your API key the program will attempt to get detailed information for 80 items. These are shuffled and fit to the grid until nothing more can be fit on, or 20 items are placed. The program keeps doing this over and over again for 600ms, finally giving you the result that had the most items placed on the board / the most intersections.
Hopefully this won’t cause any weird behaviour because a lot changed, but if it does, let me know.
it also works with 8000 burned items now, thanks! ^^
I was a bit surprised that I had to click on “Layout puzzle” when it still said “Requesting your burned items”, but no biggie.
Sometimes parts of font glyphs are cut off.
Not sure if that’s due to my setup (Chrome/Win, though I’ve never seen it elsewhere), and it mostly doesn’t matter much, though on some kanji it can make it hard to read. (not the above though)
Sometimes it corrected itself by hovering over the text, though not here.
This may be the last update for a little while, but I have updated this to 0.01:
an attempt at keyboard navigation (arrow keys plus backspace). Delete-and-move-to-previous (delete on an empty square) is reliant on knowing which way it thinks you are going, so it might not know what to do (and do nothing) if you click into a corner instead of getting there by typing or the question menu.
moving into a square now selects it instead of clearing it, so you don’t have to commit to retyping the whole word.
rewrote a lot of the guts in the hope of being able to make the UI stateless but wasn’t quite able to close the deal on the last few parts.
some long sequences of romaji necessary to express sutegana may hit the box character limit (stuff like happyou for はっぴょう). It may be easier in the short term just to type these as e.g. “haxtupyou”. You’ll work it out.
version number is now up in the page title, so if yours doesn’t look like this you may need to refresh it:
A bunch of the new keyboard navigation stuff may behave weirdly in the English “loading puzzles” or if you use an IME to enter your Japanese - there are some tricky bits about handling input in this framework (as it is optimised more towards just writing stuff than looking at it keypress by keypress). By using its built in converter, it means that it will always know when you’re changing a square. It all seems to work properly on the main, Japanese, part of the puzzles.