Hint dialog can show up during answer input and interrupt the user's experience

[BenHenning]

Needs investigating.

This issue was reported during initial user studies. Sometimes, when the learner is typing an answer, the hint bar shows up and this causes the keyboard to disappear, which is a bad experience for the learner.

[BenHenning]

I tested this locally: the problem is that the hint bar showing OR changing causes the keyboard to immediately dismiss. That's a pretty bad experience (especially considering that learners may keep the keyboard open while they're thinking through an answer), so I'll look into seeing how we might go about fixing this.

[BenHenning]

Okay, I'm 90% sure this is caused by #171 not being implemented yet (which causes a bunch of other problems). I'm not sure I'll have time to try and tackle this before the user study (and it's a bit risky), but I might give it a shot.

[PratyushSingh07]

@BenHenning can you shed some light on what the issue is and how I can reproduce that locally

[seanlip]

Product note: the fix for this should probably be to adjust the hint activation logic to wait until 2 seconds (say) after the keyboard is closed (or an answer is submitted), before showing a hint.

I.e. a "background state change" like the one described in this issue should not occur when the learner is actively in the process of submitting an answer using the keyboard.

[adhiamboperes]

ThIs is probably linked to #5037

[nikitaevg]

Hi there!

I explored this problem a bit. My current idea of the fix is to show the hint even with an open keyboard, but we don't hide the keyboard. So I looked in that direction - how to do it, why the keyboard hides after all. In my understanding here's what happens:

1. Once the hint timer alarms, it causes the EphemeralState to change
2. It causes the itemList to be unconditionally changed
3. When it is changed, the RecyclerView redraws everything.
4. When it is redrawn, the EditText is deleted and it looses the focus, causing the keyboard to hide.

It would be fixed by #171, but we have a simpler situation here - nothing has changed in the layout, but we update it.

I suggest the following approach. It will prevent redrawing when the content is the same. It's also simple to implement then the whole #171 fix and it might help with the #171 as well. We will need to implement the areContentsTheSame for all the ViewModels.

Here's the demo of the approach. I changed the hint logic a bit so it appears after 5s unconditionally, for the demo purpose.

[nikitaevg]

@adhiamboperes WDYT of the approach above?

[adhiamboperes]

@adhiamboperes WDYT of the approach above?

Hey @nikitaevg, I think this approach is worth exploring. I'm assigning the issue to you.

[adhiamboperes]

Hi @nikitaevg, are you still working on this issue? If you're blocked, please raise a question.