I guess my first stab at this a couple days ago did something wrong. As now it seems like code tracing reveals HTML input removal and add isn’t happening. A stable input field did not help. It seems it’s more the obvious: focus() calls when I comment them all out of glkote.js the problem clears up. Taking a break for now, will sit down later and focus on the focus().
Now seems like as good a time as any to point out that when I was testing Quixe/Parchment/GlkOte with screen reader software for the visually impaired (especially Voiceover for iOS) I was encountering similar mysterious bugs associated with the moving input field and appearing/disappearing keyboard.
I began to realize how rather unusual the traditional IF UI is; it’s a commonplace stdio application, but stdio is totally unheard of on the web. (If you don’t mind, I’ll copy and paste some of my findings here, because I suspect they’re relevant to this keyboard flicker conversation.)
[rant]Consider this bog standard IF transcript:
The feeling of play is conversational. You might imagine that the game is playing the role of a Dungeon Master in Dungeons and Dragons, where the player and game are taking turns speaking.
If I were coding a “conversational” game today, I’d probably take examples from chat-based apps like Slack, where there’s a fixed input box at the bottom of the screen, and a transcript of messages in the main part of the window.
But that is not at all how IF games work (not how they have ever worked historically). Instead of having a separate “input box” into which you type commands, there’s just one main window area, the “transcript.” The game prints messages into the transcript, then prints a prompt symbol (the “>” symbol) and lets the user type directly into the transcript.
To extend my Dungeons and Dragons metaphor, you might imagine the Dungeon Master writing something on a piece of paper, then handing that same piece of paper over to the player, who would write something at the bottom and then hand the paper back to the Dungeon Master, taking turns writing on the page.
This can be confusing to screen readers. One single rectangle is acting as both output and input. Inform/Quixe has handled this by marking the entire transcript area with “aria-live=polite,” meaning that any new text that appears in the window is automatically read aloud.
But the bigger problem has to do with the “focus” of the screen reader.
When it’s time for the user to type, the last line is an invisible input box, where the user types. When the user hits enter, the input box is removed and replaced with text that the user typed. Then the game says some response message, and finally a new invisible input box appears at the bottom of the screen.
Removing the currently focused UI element is very bad for screen readers. The screen reader software tries to guess where to focus next. It might try to focus the user on the top of the document (the very first line at the very beginning of the game), or it might focus on the top of the screen (probably a random moment a few turns back).
We can try to focus on the new input box, but focusing that box may interrupt the live ARIA reading of the game’s message.
An obvious thing to do here would be to abandon the idea that the user should type directly into the transcript, and instead offer the user a fixed box to type in, at the bottom of the screen. That would probably work, but it would break some existing games.
For example, a number of games like to provide the user with a custom prompt inline with the text. "Please enter the secret code: " That may not make sense when the input box appears at the bottom of the screen.
A few games even rely on the fact that the prompt is in the transcript to play games with the player. For example, “Taco Fiction” prints a fake prompt “>” into the transcript and then waits for the player to type any key. No matter what the user types, the game inserts a character of the author’s choosing, “forcing” players to type what the author wants them to type, letter by letter. I guess it’s more of a practical joke than a serious UI consideration, but needless to say that joke would not work with a fully separate input box.
(And what about menus?)[/rant]
tl;dr: Dang, do we really have to let the user type directly into the transcript? Wouldn’t a fixed position non-moving input box do as well or better?
Thank you for the thoughts.
I agree with the sentiment, and in Thunderword beta there currently are no less than 3 input fields you can enable (top of page, bottom of page where prompt typically is, and right at the classic prompt). Four if you count the remote web interface prompt 
The UI isn’t finished yet (rather unfriendly), but I felt that input technology should be rather detached from the classic terminal interface concept for mostly-text stories. Text Fiction also has some past-breaking concepts, and the author also developed a remote keyboard - multi-input system.
(And what about menus?)
That would be top of my list for a multi-IF standard. Numerically indexed menu systems that can be presented in various ways (localized) on the UI presentation. Same goes for single-key prompts for continue, or a few keys prompts like “H for help, Q to quit, space to continue” that I’ve seem multiple times. Many stories start out with difficult prompts for a newcomer to IF, and standardizing those prompts would be good for the community. Some standard means to present things like: age-related, screen-reader abilities, splash screen ‘continue’, ‘have you played IF before’ tutorials, etc.
As for screen-reading, profanity filters, and similar - I encourage all future front-end apps to build on top of RemGlk JSON technology (which GlkOte already supports). It uses standard operating system stdin stdout and allows a standard post-production stage to be added to the interchange. Imagine “plugins” between Glulx and the User Interface. RemGlk flattens all story I/O to frame/turns that make sense as a player and puts things in a standard data Unicode footing. It would also make-standard all the file I/O implementation and other aspects of Glk. The performance overhead of converting to JSON isn’t significant, even on mobile devices. I also believe going one layer higher up to RemGlk opens up to newer software developers.
So far, I can’t figure out with GlkOte is doing. I’ve disabled focus and blur in 8 or so places, and it’s still doing something. I thought I eliminated add/remove of HTML input element as a concern. Not sure if it’s something more complex interacting - or I overlooked something in the redraw cycle. When I tell keyboard to go away, the web app is still forcing back open.
I mentioned it way back, but the first thing I tried was commenting out all the focus() calls. That was before I commented out the two resize lines, but it appears it still doesn’t work after commenting those out, either.
@Dannii posted a fix on GitHub. Thank you. I’ve tested it and it seems to correct the looping keyboard open/close behavior. I’ve updated FictionRunner app APK to r11 with the new GlkOte code, download off GitHub:: github.com/WakeRealityDev/Scree … se_r11.apk - the minimized JavaScript version has not yet been updated.
I need to try some side-by-side comparisons with and without this Fix. as in Dead Cities I’m seeing some odd behavior on FictionRunner. I’ll report back.
EDIT: Reporting back. Dead Cities is better with this new fix. Without the fix, you could not enter text at all with the soft keyboard, it kept retracting. However, even with the fix there is an issue of player turn/frame that the keyboard goes away. 1. Activate soft keyboard, type “go west”, 2. keyboard retracts. You have to manually re-touch the input prompt to bring the keyboard back up.
2nd EDIT: It looks like maybe the soft keyboard isn’t actually working for entry at the “PRESS ANY KEY TO BEGIN” prompt of City of Secrets? If I use the hard keyboard I can press spacebar to continue. But spacebar on the soft keyboard seems to not actually be accepted as Glk input. Pretty tired, so maybe it’s the ape between chair and computer.
Can anyone confirm the soft keyboard spacebar is actually working at this “PRESS ANY KEY TO BEGIN” prompt in Chrome on Android?
Back to the topic of the player turns/frames of story and the keyboard disappearing/reappearing even briefly: I was thinking about this some more this morning and it really breaks typeahead - class VTxxx serial terminals had a type-ahead buffer you could start typing before the next prompt began. I assume a lot of the original Z-machine engines for Commodore 64, Apple II, MS/PC-DOS, etc had type-ahead buffering - because computers were pretty slow at the time. But I haven’t confirmed it on the actual original software. That said, i don’t have fully working typeahead in Thunderword yet, as logic relating to timer input competing with keyboard input creates a logic block to prevent it - you could start typing the next line input as long as you didn’t press [enter] to submit it. There needs to be added logic to buffer the lines until RemGlk is ready for the next turn/frame (RemGlk generation).
Tricky stories to run due to input line and keyboard activation / cursor in correct place: Dead Cities and Moments Out Of Time: RENEGADE Type
Another story example to consider, You Wake up Itching: ifdb.tads.org/viewgame?id=kxc7cih23ylk15ee
The opening page of this story has a “[ press any key to continue ]” prompt, that also has a couple newlines after the prompt. When the keyboard and cursor is retracted - it can be difficult to see exactly where the player needs to touch to get the HTML input field for the continue prompt. As a quick and dirty fix, perhaps a URL parameter to make the input field visible with CSS foreground/background color… which the player could activate for technically difficult stories like this one?