Streamline item pane navigation

[simon]

two-field autocomplete appears to work fine as long as one presses return, but when the right arrow is pressed, the entire string is inserted into the first field.

[stakats]

Is clicking the right arrow ever expected user behavior?

[dstillman]

No, but it shouldn't do what it does now.

[ajlyon]

It also doesn't work to press tab after arrow-ing down to the desired completion, although the behavior is different (the typed text is used, and the completion is discarded). If the behavior is ever revisited, it would be good to cover this as well.

On Twitter (​http://twitter.com/#!/windloochie/status/98468929923592193 and previous-- responses by yours truly not included):
"@Zotero your auto-fill feature sucks. You need to learn to play better with Mac. My bib is filled with halves of names."
"@ajlyon @Zotero They are the halves of names I type in. I think I've selected the highlighted item, and move on, only to find I have not."
"Some of us are used to tabbing through things and not using the mouse. If it's highlighted, it should be selected."

[simon]

In the Awesomebar and Firefox search box:

• Return opens the selected URL/performs the selected search in the autocomplete box
• Right arrow enters the equivalent text in the box
• Tab is equivalent to the down arrow; it moves to the next item in the list

In Finder search:

• Return selects and searches
• Right arrow elicits no reaction
• Tab closes the menu without modifying the search

In Google:

• Return selects and searches
• Right arrow = "I'm Feeling Lucky"
• Tab enters the selected search string in the field, and changes the autocomplete popup to reflect completions for the new selected string.

I guess this user wants to use tab because that's what you would otherwise use to navigate through the item pane, which makes sense, but it seems like keyboard navigation for autocomplete is highly inconsistent. I suggest the following:

• Return should be equivalent to tab throughout the item pane instead of saving the field without selecting the next field, as it does now. Abstract and Extra would be exceptions.
• Both return and tab should enter the selected author and move to the next field. For creator autocomplete, if only a last name is selected in autocomplete, the next field is the first name. If a full name is selected, the next field is the field below.
• The right arrow should enter the text from autocomplete without moving to the next field.
• Clicking someplace in the item pane that isn't a field should deselect the currently selected field. (Currently, this only seems to work if you click the label next to the field itself.)
• Clicking another field should select that field. Currently, this appears to work when the currently selected field contains a string, but not when it's empty or contains a number.

[dstillman]

Replying to simon:

I suggest the following:

• Return should be equivalent to tab throughout the item pane instead of saving the field without selecting the next field, as it does now. Abstract and Extra would be exceptions.

Not sure about this. It would be a pretty major change from how things work now, and Tab seems like the right key for this. Otherwise you'd have to start editing a field you didn't actually want to edit and hit Escape (I assume) to get out of editing mode.

• Both return and tab should enter the selected author and move to the next field. For creator autocomplete, if only a last name is selected in autocomplete, the next field is the first name. If a full name is selected, the next field is the field below.

Yes, tab should enter the selected author and move to the next field. Return should do whatever it normally does, but, as above, I'm not convinced it should move to the next field. I don't see a problem with the current behavior. Agreed on last/full name behavior.

• The right arrow should enter the text from autocomplete without moving to the next field.

Agreed.

• Clicking someplace in the item pane that isn't a field should deselect the currently selected field. (Currently, this only seems to work if you click the label next to the field itself.)

Agreed.

• Clicking another field should select that field. Currently, this appears to work when the currently selected field contains a string, but not when it's empty or contains a number.

Are you sure it's that? If so, I can't reproduce. I think it's just when the field hasn't been modified from its current value.