Enhancement Request: Focus on Search Field When Actions Sheet Appears

When inserting a new action and the Actions sheet slides up, it would be nice if the search field were already focused.

Presently the topmost action is focused, which is advantageous only if one intends to add that particular action (by hitting return). But more often than not (statistically) the user will be looking for one of the other ~280 actions. As such, focusing the search bar would save the user keystrokes or clicks (especially when doing this dozens of times in a session). :blush:

Thanks.

Hey @soundsgood,

You mean search field?

Tab takes you right into it.

-Chris

Thanks. I'm aware of that. It's still an unnecessary keystroke.

In your opinion, and that's fine – but tell it to Peter...

To be sure he sees your post be sure to tag it with his user name.

Attention: @peternlewis

-Chris

Actually, it's not just my opinion; it's a fact, which I proved in my original post.

You may not mind the extra keystroke to focus the search fieldβ€”and that's fine. But it's a fact that the keystroke is unnecessary, because (oversimplified) 279 times out of 280, the user will need to search for the desired action. Therefore, upon summoning the Actions list, the search field should be focused. :blush:

Thanks for explaining how to get something to Peter's attention. I was unaware of the method for doing so (and it makes sense that he doesn't have time to read everything), so that was very helpful. Thanks again!

Still your opinion – positing a reason does not constitute proof.

That said I don't especially disagree with you.

However – I misunderstood your original issue.

Don't use Show Actions to bring up the Actions Sheet.

Use Insert Action by Name: βŒƒβŒ˜A

Then your problem is moot.

-Chris

I didn't post a reason. I posted proof.

If I didn't prove that having to hit a keystroke to focus the search field is unnecessary, please refute it by providing proof that it's necessary.

Thanks.

I agree with you.

I see little advantage to having the top most action selected, whereas having the focus in the Search box has obvious advantages.

Why not just write a simple macro to make KM behave the way you want?

1 Like

If the All Actions category is selected, then you can use type-ahead to select an action, so it's not clear that searching is more beneficial to everyone.

In any event, if efficiency is your goal, then the Insert Action by Name (βŒ˜βŒƒA) facility is generally better. The Action Category selector is more useful for browsing than searching.

1 Like

It should be very obvious that the Search box is much more beneficial, but I know it is difficult to put yourself in the place of newer users.

The "type-ahead" will only select if you type exactly the starting characters of the Action name, whereas the Search box will find text in other words and in synonyms. Test it for yourself. Try typing "image" or "browser" in both locations. The "type-ahead" finds NOTHING.

So typing in the Search box will find everything that typing in the list will find, but NOT vice versa.

What advantages do you see with the current behavior?

It can be very useful to newer users to see the list of Actions, while at the same time being able to search for them. From the Search box, a TAB will set focus to the Action Categories, where up/down arrows work well to show the actions in each category.
Another TAB sets focus to the Action list, where a RETURN on a selected Action adds it to the Macro.

Using the "Insert Action by Name" is very useful, and what I use most of the time. But it is only useful if you have a good guess of the Action Name.

1 Like

Still, it would take about 30 seconds to make a macro that will focus the Search box (in addition to bringing up the Actions sheet), and it will be ready to use immediately, doing exactly what you are requesting. Why have Peter spend time and energy on such a customization?

1 Like

@thoffman666, you only need to make your point one time.

Not everyone has the same view as you do. I've done lots of app UI design, and setting the default field for a window/form/etc is extremely easy, so it is NBD.

Similarly, not everyone has your view about what the default behavior of KM should be. So, even if it's easy for Peter to do, why have him change it to your personal preference when one of the many great things about KM is that it can be used to customize KM itself?

There's no point in beating a dead horse. Both opinions and requests have been clearly stated. I'll not engage further on this topic.

I'm not one to demand the last word.