LaurensWeyn
commented
6 years ago Rikai mode has been a planned feature for a while now, but I feel there are some things that need to be done before I get to it.
Regarding accidental game input: This is something I often struggle with too. Spark Reader can be set to take focus which is needed for some games, and just recently I added an experimental feature that would let you keep Spark Reader focussed but still advance text in the unfocused game. Other options are keeping SR just out of the window, either just above or just below (or on a seperate screen as some apparently do)
So you suggest that, as an optional Rikai mode feature, splits could be purely visual? Seems like a good idea.
Regarding the things needed for Rikai mode:
- Keyboard controls. I've got the groundwork for this done, but I have yet to make a proper key mapping system and UI. Rikai mode may need this for things like decreasing the length of the parsed section. (Though this may be rare enough that the current manual splits could work for this too)
- Option to display all definitions below each other instead of seperate pages. This is because scrolling on the main bar should scroll the text, but with Rikai mode, a word is always selected, scrolling on a selected word scrolls through the definitions. -Possibly further work on how Pages/words are currently managed, as right now it assumes everything is parsed beforehand. Perhaps I could have Page as an interface, implemented by ParsedPage and UnparsedPage or something, to keep the code seperate. UnparsedPage could temporarily run the parser (it's not that expensive an operation) if the text needs those visual splits.
Options are currently becoming a bit messy. I have ideas to make game-specific profiles that would inherit changes of a main profile, and perhaps presets or some sort of batch option changes, like those reccomended for beginners, Rikai mode, normal vs dropshadow mode, or even preset UI themes. I could easily do all that by making a simple settings.txt-like file with "option=overriddenValue" that you could apply, but I need to figure out how that would work in a UI and still be user friendly...
Though yes, some sort of startup tutorial is a good idea. With JMDict supporting 'senses' in other languages, asking the user to select languages they speak during startup is planned, as well as asking to import the words they know, add and prioritise extra dictionaries and other features they may want to setup.
One of the main drawbacks of Spark Reader is the fact that you need to click the interface to interact with the dictionary or word splitter. * A second drawback is that the word splitter acts as a default interpretation rather than as a guide, which is more notable with the Kuromoji branch.
*This is actually really annoying with certain games that use focus logic and raw input to determine whether they received an input event rather than the WM's input bubbling system, so clicking spark reader's overlay might bubble through to the VN and make it advance to the next text box.
The way to handle the first is relatively simple, just add a way for mousing over words to bring up the dropdown menu, and make it work on a character level instead of a word level if word splitting is disabled, basically rikai emulation. I know this is against SR's curren't UX philosophy, but it's something to consider.
A way to handle the second is a new idea. Instead of the word splits being actual word splits, they would just be a visual indicator of where the word splitter (or kuromoji) thinks the word boundaries are. This has three advantages:
One, it would make it easier for people inexperienced with Japanese to realize that there are some mistakes the parser can't not make.
Two, you would no longer have to click to interact with the word splitter, but people new to japanese that are just outright confused by whatever they're reading would still be able to rely on the word splitter or segmenter for help in splitting up long strings of hiragana.
Three, the kuromoji branch could run without any of the word recognition code needed by the "guided rikai" parsing model. Segments would just be wherever kuromoji puts segmentations between words, and things like 彼がいない would appear like 彼|が|い|ない instead of 彼|がい|ない, without having to rely on any weird heuristics or blacklists at all. The parser would make fewer mistakes, because it's doing less work, or none of its own work at all, just using a segmenter.
I think that a real rikai emulation mode is a necessary feature for Spark Reader to be adopted by certain communities, because rikai's UX has a very optimal feel for people who know a lot of japanese. Combining that with segmentation that's only visual would also make it easier for other people to recommend SR, because they wouldn't have to worry about people getting confused by the parser at all as long as they use certain settings.
Finally, it might be a good idea for SR to prompt for the UX style that the user wants the first time it boots (then tell them that they can change it through the options, of course).