[jQuery] Re: [autocomplete] Search Page Replacement
On 5/8/09 3:36 PM, Logan Green logangr...@gmail.com wrote: This tab issue is driving me crazy. Has anyone found a hack/fix that will allow the tab to work as expected...where the user hits tab once, and moves to the next field? not that i am aware of. given the activity on this plugin (it's been nearly a year since 1.02) i'm pretty much resigned to coding my own. i think that will probably be easer than dealing with my own branch of the plugin, which is much more flexible (and therefore complex) than my requirements demand.
[jQuery] Re: [autocomplete] Search Page Replacement
Hi Tom, Thanks for your reply. I see what you mean about the tab key... I hope someone offers you some advice so you can use the plugin without branching. If you do find a solution I'd be glad to hear it too. Did you see my response re; 'selectFirst: false' ? I don't know if this would help your problem but it solved mine. Also I found a list of all the autocomplete options here: http://docs.jquery.com/Plugins/Autocomplete/autocomplete#url_or_dataoptions (Click the 'options' tab to the right of the 'overview' tab. The 'options' link further down goes somewhere else.) Regards, Matthew 2009/4/27 Tom Worster f...@thefsb.org On 4/26/09 9:12 AM, mattvick vickery.matt...@gmail.com wrote: I need the list of results to appear without any of them highlighted so hitting the return key submits the form without updating the text in the search field. I still need the search field to update, and the form submit, if any of the results in the list are highlighted and clicked manually. this is one of two counter-intuitive keyboard behaviors i'm aware of. the other is tab, which most users would expect to get them to the next form element. Will someone please point me in the right direction or even better post an example so others can also benefit. i don't know for sure but i suspect that in most cases, changing the autocomplete keystroke behaviors requires changing the plugin code. which is a bit of a problem. i'd really like to use autocomplete in my app but without support (the author hasn't answered any email about autocomplete this month, afaict), seems like making it behave in a way that users won't complain about is going to mean branching. -- Email: vickery.matt...@gmail.com Land line: +44 (0)20 8123 3798
[jQuery] Re: [autocomplete] Search Page Replacement
On 4/26/09 9:31 PM, Jordon Bedwell jor...@envygeeks.com wrote: this is one of two counter-intuitive keyboard behaviors i'm aware of. the other is tab, which most users would expect to get them to the next form element. I'm still scratching my head at how this is counter-intuitive? If you called it that, you must not understand the entire scope of tab, and the fact that it has no scope, it loops through the entire frame of the browser, including the address bar and links. With JavaScript you can prevent it from looping through links and the address bar by defining where it goes and what it does. YES, if it did infact stay within forms if you select a form element it would be counter-intuitive, but at this point, it is far from that based on logic. There are also more reasons to redine the default behaviour of tab. turning tab into a select, i..e making it work like enter, is counter- intuitive, to me. autocomplete does that. if you're in a form and the focus is on a text input and the form layout shows that the next form element is, say, another text element, you'd expect tab to get you to it. but with the autocomplete plugin, hit tab to move to the next input and what you typed gets over-written by a suggestion. that's not just unexpected, it's annoying.
[jQuery] Re: [autocomplete] Search Page Replacement
On 4/27/09 5:25 AM, Matthew Vickery vickery.matt...@gmail.com wrote: Thanks for your reply. I see what you mean about the tab key... I hope someone offers you some advice so you can use the plugin without branching. i already have an auto-completion of my own that i wrote a few years ago before i knew of jquery. it requires only about 10% of the locs that autocomplete plugin uses because it only does what i need and not all that other stuff too. rewriting my code for the new app (maybe using jq) is perhaps less work than maintaining my own version of the plugin. i'm willing to take a bet on jq being around and supported in future. i'm not sure about autocomplete. If you do find a solution I'd be glad to hear it too. Did you see my response re; 'selectFirst: false' ? I don't know if this would help your problem but it solved mine. it helps but it's not enough. for an example with selectFirst: false: 1. go to http://jquery.bassistance.de/autocomplete/demo/ 2. click in the Single Bird (remote): text input. 3. type, say, pal and wait for the suggestions to appear. 4. hit tab. in my browser, the Get Value button focuses for a moment then the focus moves back to the Single Bird (remote): text input. it takes two tabs to get the focus out of there. that really runs against user expectations and makes no sense. for people used to working fast through forms with the keyboard only, this behavior will be inexplicable and annoying.
[jQuery] Re: [autocomplete] Search Page Replacement
On 4/26/09 9:12 AM, mattvick vickery.matt...@gmail.com wrote: I need the list of results to appear without any of them highlighted so hitting the return key submits the form without updating the text in the search field. I still need the search field to update, and the form submit, if any of the results in the list are highlighted and clicked manually. this is one of two counter-intuitive keyboard behaviors i'm aware of. the other is tab, which most users would expect to get them to the next form element. Will someone please point me in the right direction or even better post an example so others can also benefit. i don't know for sure but i suspect that in most cases, changing the autocomplete keystroke behaviors requires changing the plugin code. which is a bit of a problem. i'd really like to use autocomplete in my app but without support (the author hasn't answered any email about autocomplete this month, afaict), seems like making it behave in a way that users won't complain about is going to mean branching.
[jQuery] Re: [autocomplete] Search Page Replacement
this is one of two counter-intuitive keyboard behaviors i'm aware of. the other is tab, which most users would expect to get them to the next form element. I'm still scratching my head at how this is counter-intuitive? If you called it that, you must not understand the entire scope of tab, and the fact that it has no scope, it loops through the entire frame of the browser, including the address bar and links. With JavaScript you can prevent it from looping through links and the address bar by defining where it goes and what it does. YES, if it did infact stay within forms if you select a form element it would be counter-intuitive, but at this point, it is far from that based on logic. There are also more reasons to redine the default behaviour of tab.
[jQuery] Re: [autocomplete] Search Page Replacement
I guess I should follow up and elaborate more why it's not counterintuitive: because the common user would expect it not to eventually hit the address bar, but loop through the form elements and keep looping through form elements, not land on some random link at the bottom of the page. Not all computer users understand the Shift+Tab concept. You are creating usability and simplicity. -Original Message- From: jquery-en@googlegroups.com [mailto:jquery...@googlegroups.com] On Behalf Of Jordon Bedwell Sent: Sunday, April 26, 2009 8:32 PM To: jquery-en@googlegroups.com Subject: [jQuery] Re: [autocomplete] Search Page Replacement this is one of two counter-intuitive keyboard behaviors i'm aware of. the other is tab, which most users would expect to get them to the next form element. I'm still scratching my head at how this is counter-intuitive? If you called it that, you must not understand the entire scope of tab, and the fact that it has no scope, it loops through the entire frame of the browser, including the address bar and links. With JavaScript you can prevent it from looping through links and the address bar by defining where it goes and what it does. YES, if it did infact stay within forms if you select a form element it would be counter-intuitive, but at this point, it is far from that based on logic. There are also more reasons to redine the default behaviour of tab.
