Dash should highlight item activated on Enter

[Denis Washington]

Currently, it is not obvious which Dash item is activated when you press Enter while the search field has focus. Many users might not even know that they can activate the first search result by pressing Enter in the dash, and think they need to always navigate to it with the arrow keys or the mouse.

For this reason, it would be nice if the first item in the Dash would be visually highlighted somehow, to make clear that pressing Enter will activate it right from the search field.

[John Lea (johnlea)]

@hikiko; thanks for looking into this!

At 0:58 in the attached youtube video there is a brief moment when both the category header and the first search result are both highlighted at the same time. We have an issue in that there should only every be one item highlighted at any one time. When we looked at this issue before we couldn't find a clean way around this issue and that is why the first search result is not currently highlighted by default.

If the first search result is highlighted by default, obvious solution to this problem (when the user presses the down arrow, the highlight moves up) would be confusing because the focus would be going the the opposite direction from the key press. Jumping the first category header would also be inconsistent.

See if you can find a clean solution around the problem given that A) there can only be one focused item at any one time B) when the user presses the down arrow for the first time they expect the focus to go one step downwards from the text entry box they were typing in. The current implementation in 13.10 is the best solution we could find to this problem, but there may be a better solution and we are open to suggestions.

[Denis Washington (dwashington)]

I suspect that users primarily want to navigate to tiles with the keyboard, not to category headers. If this is the case, a possible consistent solution would be to only select headers on *upwards* navigation, not on *downwards navigation, so that:

* Pressing the down arrow key in the search box moves directly to the first item of the first scope.

* Moving down from the last row of a scope moves directly to the first row of the next scope.

* Moving up from the first row of a scope moves to the category header. (Thus, moving up is the only way to select a header.)

This behavior may seem unintuitive at first, but I think it actually is better in line with the use cases of the keyboard navigation:

* If you type into the search box and see what you are looking for, navigating downwards to the corresponding tile is quickly because the category headers (which you don't need if your search result is already there) are skipped.

* If the result you are looking for isn't there yet, you are more likely to type more letters than to navigate down to a header and expand it.

* If you really want to navigate to a header and find out that pressing the down key doesn't select it, the natural reaction is to try again by pressing the up key, at which point the header *is* selected. After very few such occassions, the navigation rule will be obvioius to most people, so the created confusion should be minimal.

[John Lea (johnlea)]

@dwashington; thanks for your proposal ;-)

Your proposed solution is based on the assumption that people only expand categories rarely, and use text search and further refinement of text search to narrow down to the result they are looking for. From user testing we have found this is a very common usage pattern, especially in younger age groups. However a still significant portion of users use text search less, and rely more on browsing which involves expanding the category header.

Your proposal would benefit the first group of users, but would be detrimental to the second group. The other issue is that it breaks the absolute spatial model we user for keyboard/remote control based navigation, where pressing a direction key/button moves the focus to the next item in the direction pressed.

For these reasons I don't think your proposal is a direction we should go in, however thank you for taking the time to look into this problem.

Balancing functionality to cater for the wide range of different users and usage patterns have is a difficult problem, optimising design for one user or one set of users is easy, striking the best balance and compromise for the overall benefit of all different types of users is much harder. Also having an absolute spatial model for all focus driven navigation is a principle we have had for quite a while and it is also applied elsewhere, so I'm reluctant to break it for this one case. Also braking the spatial model as described in your proposal might be confusing to users.

[Eleni Maria Stea (hikiko)]

After getting some feedback from the designers' team, I turned this bug into a question.

[Arthur Tan (artgtan)]

I know this is a major change but how about moving the category header below the first row of icons in the dash? Then, the first icon can be highlighted so there is some indication of what happens when you press Enter.

If the user doesn't find the icon he's looking for, they just need to down-arrow once to get to the category header.