search bar fixes

[andrei-a-papou]

I propose the following fixes to the search bar to improve the UX, especially in terms of keyboard navigation:

1. When there's no search query (empty search bar), the close button should be disabled and unclickable.
2. Both the help icon and the close buttons should be visually highlighted when tabbing through them. E. g. if I hit Ctrl + F to focus the search bar and find some todos, I need to navigate to them quickly. Currently I hit Tab a couple of times (is there a better way perhaps?) to get the todos in the list. While tabbing, the help and close buttons are "invisibly selected", which is confusing.
3. I would also hide the Add as todo button from the search bar when a user selects a saved search from the dropdown. Why would you want to add a saved search as a todo? And, it adds another (in this case, I think, unnecessary) button to tab through to get to the list of todo rows.
4. Under the saved searches, it seems the notification icon should not be a crossed-out one, as this means "no notifications". Instead, this icon seems to be the right one: https://mui.com/material-ui/material-icons/?query=Notifications&selected=Notifications
5. Speaking of the notification icon, should it be shown at all if the user has notifications disabled in Preferences? Personally, I don't currently use todo notifications, so the presence of the bell icon is a bit confusing. Does it override global notification preferences?

@ransome1 What do you think?

[ransome1]

Under the saved searches, it seems the notification icon should not be a crossed-out one, as this means "no notifications". Instead, this icon seems to be the right one: https://mui.com/material-ui/material-icons/?query=Notifications&selected=Notifications

There is a misconception on how this feature works. It is about suppressing notifications, which match a search filter: https://github.com/ransome1/sleek/wiki/Search-filters#suppressing-notifications

This was a low hanging fruit feature piggybacking the implementation of the search filter function. We can of course still change the logic behind it, since this little feature is not mission critical and most likely not heavily used yet.

I would also hide the Add as todo button from the search bar when a user selects a saved search from the dropdown. Why would you want to add a saved search as a todo? And, it adds another (in this case, I think, unnecessary) button to tab through to get to the list of todo rows.

No problem, should be available in the next release.

When there's no search query (empty search bar), the close button should be disabled and unclickable.

React MUI proposes hiding the element, instead of deactivating it. So I think we should comply to this. However I agree we don't need to leave it present and clickable if there is no content in the search field.

Both the help icon and the close buttons should be visually highlighted when tabbing through them. E. g. if I hit Ctrl + F to focus the search bar and find some todos, I need to navigate to them quickly. Currently I hit Tab a couple of times (is there a better way perhaps?) to get the todos in the list. While tabbing, the help and close buttons are "invisibly selected", which is confusing.

Highlighting on focus has simply been forgotten to implement on my side, should be available in the next release. About the question if there is a better way to do something, I am not sure what exactly you're trying to achieve. If you want to clear the search field, you can alternatively press escape key and if you want to then close/hide the search field, press escape key another time.

[andrei-a-papou]

@ransome1 Thanks for the detailed response!

About the question if there is a better way to do something, I am not sure what exactly you're trying to achieve.

I'm looking for a keyboard-driven way to focus the first todo row -- preferably from anywhere in the app. Right now the best way I've found is to hit Ctrl+F to focus search, then tab through to the first todo.

[ransome1]

@andrei-a-papou I think most of the issues should be covered by: https://github.com/ransome1/sleek/releases/tag/v2.0.9-rc.4

As for the tabbing issue (accessing the list without tabbing through the element between search field and list) I haven't found a proper solution yet. If you have a concrete proposal, feel free to open up a detailed feature request.

[andrei-a-papou]

There is a misconception on how this feature works. It is about suppressing notifications, which match a search filter:

OK, but as a user, I don't use sleek notifications at all. They are disabled under Preferences, so there should be nothing to suppress, correct? I think from a UX perspective, it's sort of confusing to suddenly discover a specific notification suppression option, when you have notifications generally off.

[andrei-a-papou]

As for the tabbing issue (accessing the list without tabbing through the element between search field and list) I haven't found a proper solution yet. If you have a concrete proposal, feel free to open up a detailed feature request.

IMHO, a good solution would be implementing #645 and exposing as many commands as possible to be bound to keys/key combos that users can choose. Unfortunately, I'm not skilled in React/Electron, or I would have done it myself.

Since sleek is a JS-based app, perhaps even custom JS could be bound to keyboard shortcuts then. This Thunderbird extension does exactly that: https://github.com/wshanks/tbkeys

After all, focusing a row simply means focusing a DOM element with a line of JS :) If we had a mechanism to bind it to a key combo, that'd be awesome.

[andrei-a-papou]

@andrei-a-papou I think most of the issues should be covered by: https://github.com/ransome1/sleek/releases/tag/v2.0.9-rc.4

Tested, seems to work! Thank you!