Rails spinoffs - Aug 2005 - Fwd: Re: disable ''tab'' key wish for incremental autocomplete of textareas

Hi Tim,

Thanks for the commentary, you bring a good point to
light:  I think the asynchronous nature of AJAX needs
to be looked at more carefully in our UI assumptions.

The key difference between AJAX auto-complete and any
other browser/OS autocomplete is that we can''t
guarantee having the results ready by the time the
user wants to hit TAB.  In the old days we used to
have everything ready exactly when the user expected
it, today we can only hope the AJAX request makes it
back in time.

That raises a big problem for user expectations.  The
problem quickly raises it''s ugly head with users that
already know the first 2-3 letters of an address that
they''ve auto-completed before and just want to hit TAB
to have the address completed for them.

What do they get using Ajax auto complete?  Well, if
they hit TAB to quickly they get launched out of the
text field, even if there are valid auto-complete
suggestions available.   I''m sure you''ll agree that
this isn''t consistent and is be pretty startling for a
poor user who expects the name they know to be
completed for them.

Use case:

Email address auto complete.  Our user ''Mary'' starts
typing in the first three characters of her husband''s
name ''Geo'' (for George) and then hits the TAB key to
complete the name and retrieve the email address.  She
knows George''s email address is in the address book
because she''s mails him every day and put it there
months ago.

If the AJAX autocomplete request hasn''t returned in
time when she hits TAB (to get the rest of George''s
name), the current scriptaculous behavior will launch
her out of the textfield.

This isn''t what she expected, she expected to see his
name in the text field (George Scriptaculous
<george@scriptaulous.com>)- instead she just sees
''Geo'' and even worse, when she goes back to do it
again sometimes hitting TAB works, and sometimes it
doesn''t (depending on how quickly she hits TAB and how
slow the AJAX response is).  So she''s quickly
frustrated by inconsistent behavior.

So I think controlling TAB behavior is not only
justified but required in this case.

Equeally well when using TEXTAREA''s that look like
this:

http://www.fckeditor.net/

You never want TAB to launch you out of the TEXTAREA.

So in short, unlike old auto-complete systems that
immediately had all possible answers ready,
Asynchronous auto-complete raises a whole new an of
worms to tackle and give the user a ''Least Surprising''
answer.

To restate my wish: a flag for Autocompleter to
prevent the TAB key from causing a user to leave the
current text field.

-San


--- Tim Lucas <t.lucas@toolmantim.com> wrote:
> On 02/08/2005, at 11:16 AM, sanzbox@yahoo.com wrote:
>
>> I''m absolutely in love with the incremental
>> autocomplete feature in the new scriptaculous.
>>
>> My one wish would be for some way of disabling the
> TAB
>> key to prevent users from being able to tab out of
> an
>> autocompleting textarea.  (If they''re using TAB to
>> select the autocomplete choice they end up tabbing
>> straight out of the input field if autocomplete
>> doesn''t find any options).
>
> Have you looked at the behaviour of autocompleting
> text fields in the
> various OS''s?
>
> On OSX pressing tab accepts the currently
> highlighted autocomplete
> suggestion and goes to the next input field.
>
>> use case:
>>
>> User needs to enter N email addresses (N >= 10 or
> so)
>> into a textarea.
>
> A valid but not overly common usecase.
>
>> User starts typing, autocomplete suggestions pop
> up,
>> user moves cursor via arrow keys and hits TAB to
>> select autocomplete suggestion.
>
> Why would they use the tab key to select the
> suggestion?
>
> The two uses of tab i''m aware of is indentation and
> moving between
> fields.
>
>> If the user mistakenly hits TAB again, they end up
> at
>> the next UI input control.
>
> Have you actually seen somebody doing this or are
> you supposing what
> they may do? The two often paint very different
> pictures.
>
> - tim lucas
>
>


		



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

On 03/08/2005, at 2:34 AM, sanzbox@yahoo.com wrote:
> The key difference between AJAX auto-complete and any
> other browser/OS autocomplete is that we can''t
> guarantee having the results ready by the time the
> user wants to hit TAB.  In the old days we used to
> have everything ready exactly when the user expected
> it, today we can only hope the AJAX request makes it
> back in time.
All interfaces, including desktop apps, take some time to lookup 
autocomplete matches -- whether its from memory or disk.

If you''re dealing with a static address book (of reasonable size) then 
maybe you should be making an AJAX call "onload" and prepopulating the
address book into memory, rather than making an AJAX call. You''ll still
need some way of indexing it in memory for efficient lookup, as the JS 
will block the browser (unlike ajax and unlike desktop apps which have 
the option to do this in another thread).
> That raises a big problem for user expectations.  The
> problem quickly raises it''s ugly head with users that
> already know the first 2-3 letters of an address that
> they''ve auto-completed before and just want to hit TAB
> to have the address completed for them.
So what you''re saying is if there is only a single match in the 
autocomplete and they tab out of the field then we should use the 
suggestion?

I think that''s reasonable, though I don''t think this would
work if
multiple matches were found.
> What do they get using Ajax auto complete?  Well, if
> they hit TAB to quickly they get launched out of the
> text field, even if there are valid auto-complete
> suggestions available.   I''m sure you''ll agree that
> this isn''t consistent
Consistent with what?

On OS X''s mail program if you type a few letters and push tab, before 
the application has a chance to return matches, all you get is the few 
letters you typed -- exactly how the current functionality works.

How could the app possibly know which of the matches you actually 
wanted, unless, as we mentioned, there was only one match?

- tim lucas

Hi,
> > That raises a big problem for user expectations.  The
> > problem quickly raises it''s ugly head with users that
> > already know the first 2-3 letters of an address that
> > they''ve auto-completed before and just want to hit TAB
> > to have the address completed for them.
> 
> So what you''re saying is if there is only a single match in the
> autocomplete and they tab out of the field then we should use the
> suggestion?
Surely the only reasonable behaviour for the tab key is the one it''s
always had in a browser form - moving to the next field.

I''m using scriptaculous within an application that requires lots of
data entry (and autocompleter is great for this!), and people who do
regular data entry definitely know that they can tab from field to
field :-)

I think that if tab is used whilst an option is highlighted then the
option should be selected, but I also think the default behavior of
moving to the next field should also occur.

If there is only one option, this could be highlighted automatically,
allowing the user to tab to the next element with only one keypress,
thus ''choosing'' the only option and moving to the next field.

Multiple fields could work in a similar way, with auto highlighting of
the first (and most likely to be correct?)  field. The user can tab to
select this option and move to the next field, or cursor through the
options, pressing tab to select and move to the next field, or
return/click to select the option and leave the focus where it is.


-- 
Rob Sharp

  email/jabber: rob@sharp.id.au
  web: http://sharp.id.au
  pgp: 0E2C C63B BA04 DEB4 7CC0 84FD 17E3 6AA4 87FB 62DF

On 03/08/2005, at 11:40 AM, Rob Sharp wrote:
> I think that if tab is used whilst an option is highlighted then the
> option should be selected, but I also think the default behavior of
> moving to the next field should also occur.
>
> If there is only one option, this could be highlighted automatically,
> allowing the user to tab to the next element with only one keypress,
> thus ''choosing'' the only option and moving to the next
field.
Thanks for clarifying. That was what I was suggesting that San actually 
wanted, rather than disabling the tab key.

The tab still operates as normal, though if only a single match is 
returned for a pending autocomplete we use that single result, even if 
the field no longer has focus. I''m not sure this is perfect, but
I''d
interested to see some user tests to see if this increases efficiency.

- tim lucas

On 8/3/05, Tim Lucas <t.lucas@toolmantim.com>
wrote:
> On 03/08/2005, at 11:40 AM, Rob Sharp wrote:
> > I think that if tab is used whilst an option is highlighted then the
> > option should be selected, but I also think the default behavior of
> > moving to the next field should also occur.
> >
> > If there is only one option, this could be highlighted automatically,
> > allowing the user to tab to the next element with only one keypress,
> > thus ''choosing'' the only option and moving to the
next field.
> 
> Thanks for clarifying. That was what I was suggesting that San actually
> wanted, rather than disabling the tab key.
> 
> The tab still operates as normal, though if only a single match is
> returned for a pending autocomplete we use that single result, even if
> the field no longer has focus. I''m not sure this is perfect, but
I''d
> interested to see some user tests to see if this increases efficiency.
My gut instinct is that initially there will be little or no benefit,
as it''s quite unusual behaviour, especially for a web app. I suspect
users won''t realise that they can move on to the next field. Once
users ''get it'' it could well be beneficial, espcially for mass
data
entry. I''m looking at using that functionality for an app, so
it''ll be
interesting to see how it goes...

Rob.
> 
> - tim lucas
> 
> 

-- 
Rob Sharp

  email/jabber: rob@sharp.id.au
  web: http://sharp.id.au
  pgp: 0E2C C63B BA04 DEB4 7CC0 84FD 17E3 6AA4 87FB 62DF