Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MusicHawk]

The change in behavior of a multi-value field/picklist seems to have a bug, or be partially implemented.

When tabbing into or clicking such a field, such as Keywords, it is confusing where the focus is. If any key is pressed, that is treated as input to the field, replacing any value(s)  already in the field. However, the list selection highlight is also functional, so hovering over it moves to a desired keyword which can be clicked. But the visibility of the list selection highlight doesn't make clear that the list is behaving only partially "normal". It can be clicked, but not navigated any other way. So, the edit field has 100% focus and the list has 50% focus (more or less).

Pressing Tab again "moves" focus and changes behavior. It turns off the field editing, and instead gives 100% focus to the list. Pressing a key, instead of being treated as a text change to the field, is treated as a jump key in the list. This ability is wonderful with a long list (most of mine are long and would otherwise requires lots of scrolling).

However, the only clue to this change in behavior is the disappearance of the cursor from the edit field, a sort of negative user hint. The list itself always looks the same, whether it has 50% focus/behavior or 100% focus. Even if a list value is selected or clicked, then the pointer moved back to the edit field (which then reactivates), the selection bar remains in the list -- so it is easy to not recognize the change in behavior, and again try to jump, only to discover the keypress replaces all data in the field. Oops!

The confusion of "where's the focus" is compounded because behavior differs between mouse and keyboard. The mouse can always be used to click on the field or a list value, or scroll the list. But the keyboard is either field input OR list jump, not both, with no visible list differentiation.

So, it takes some careful staring to realize what the next keystroke will do. The consequences of missing the cursor in the edit field is that the next key can wipe out whatever date was in the field -- a bunch of values selected from the list, zapped away.

It might seem that the cursor being in this field wouldn't be overlooked, but since the list's appearance does not change, and a user might be looking at the list deciding what to select, I think there's a real risk of deleting data when the desire was to jump in the list.

One solution is to return to the prior behavior. But if the change is desirable for some other reason (not yet evident to me, frankly) then there needs to be a better way to indicate whether the list has partial or full focus and different behavior. The LACK of a cursor in another place -- the edit field -- doesn't seem like sufficient "notice".