Skip to content
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

Closed
qc00 opened this issue Apr 30, 2012 · 4 comments
Closed

Usability problem regarding autoAccept #66

qc00 opened this issue Apr 30, 2012 · 4 comments

Comments

@qc00
Copy link

qc00 commented Apr 30, 2012

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.)

@Mottie
Copy link
Owner

Mottie commented May 6, 2012

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.

@qc00
Copy link
Author

qc00 commented Jun 1, 2012

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.

@Mottie
Copy link
Owner

Mottie commented Jun 18, 2012

Hi billccn!

In the latest version 1.9.19, I've added a bit of code which adds a class name ui-keyboard-autoaccepted to the input if its contents had been auto-accepted. If the user clicks the accept button or uses shift-enter, this class will not be applied.

Hopefully this will help?

@Mottie
Copy link
Owner

Mottie commented Mar 7, 2015

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.

@Mottie Mottie closed this as completed Mar 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants