-
Notifications
You must be signed in to change notification settings - Fork 723
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Usability problem regarding autoAccept #66
Comments
Hmm, I've been thinking about this... what if we just add another button to the keyboard that instead of "Accept" we use "Save" or something to let the user know that it's saving their progress, or something. I guess I could also add an auto-accept flag, but I'd have to make it persistent in case you need to check it again later... something to indicate if the last entry was auto-accepted and not validated... LOL it just gets more complicated from there. |
Hi, sorry for the delay in responding. I was occupied by other stuff. I think both the save button (if autoAccpet can be configured to be autoSave) and the extra flag are good solutions to this. However, I believe the former is simpler to implement and it does not require you to test a flag in the event handler code which is quite nice. If you can also add a separated event handler for save, it would be even better. |
Hi billccn! In the latest version 1.9.19, I've added a bit of code which adds a class name Hopefully this will help? |
I'm guessing this issue has been resolved, so I'm going to close it. If you continue to have problems, please feel free to continue this discussion. |
In the design of my app the keyboard plug-in should act like an real keyboard, so the user should be able to type something into a field, click something else and come back to the field to fill the rest.
To emulate this, I have to enable autoAccept, but that will fire the accept handler even if the user is only half done. This prevents me from doing useful things in the accept handler and must provide a separated button for the user to confirm the input.
This approach confused some users during internal testing as they don't understand why they have pressed "Accept" multiple times and still have to press the submit button.
I think an extra event handler flag is necessary to inducate whether the accept is autoAccept or not.
(I have a local work around for this, so this isn't a critical bug for me. Sorry I wasn't able to post this issue with the previous two.)
The text was updated successfully, but these errors were encountered: