Tiddlywiki5: [BUG] Advanced Search: Filter keyboard handling

[saqimtiaz]

I think the keyboard handling in Advanced Search: Filter needs further consideration.

If you type a filter into the input and hit the up or down arrow key, the filter is replaced in the input field with the selected title. This amounts to data loss, as some filters can be a fair bit of work to write. Furthermore, having the selected title name in the input serves no real purpose in this case.

@BurningTreeC can we avoid replacing the filter in the input?

[saqimtiaz]

OK the Escape key restores the filter in the input field but I don't know if that is something most users will realize.

[BurningTreeC]

@saqimtiaz - pressing escape resets the input field to the filter that was typed in.

I think we can avoid this behavior with a switch in the keyboard-driven-input macro, but don't know if we really want to? @Jermolene, @pmario, @allothers?

[BurningTreeC]

ups, allothers exists

[saqimtiaz]

@BurningTreeC I think the problem is that there isn't enough affordance for users to know that using the Escape key is even an option. It took me a while to realize and I've been following the development work.

So either we need to change the behaviour or add some affordance for the Escape key and what it does.

[BurningTreeC]

I'm in favor of adding some affordance for the Escape key, explaining what it does somewhere ... but I'd like to hear what others think about this

[Jermolene]

If I lost some text entry by typing cursor up or down, I guess experience with command line interfaces would make me expect that I could undo it by moving the cursor in the opposite direction. I guess conceptually there's a topmost entry in the dropdown that contains the text that I actually typed so far.

But equally, I suppose I wouldn't expect that cycling through the search results with the keyboard in this case would overwrite the search text at all. Is that possible?

[BurningTreeC]

So... should we find a way that the input field isn't updated while navigating up/down?

[saqimtiaz]

@BurningTreeC if you could investigate what it would take to make that possible, that would be highly appreciated. Thank you, I know the keyboard handling has been a lot of work.

[BurningTreeC]

@saqimtiaz - I'll investigate. Maybe I can also make it configurable ... (?)

[BurningTreeC]

I'll need some time for this

[saqimtiaz]

@BurningTreeC at your convenience please.

[Jermolene]

So... should we find a way that the input field isn't updated while navigating up/down?

I think so. I think it hasn't been a problem before because for the usual search inputs the search terms and search results are the same thing, whereas with filters they are distinct. But now I'm beginning to question the way that the other search inputs work as well, which may not be helpful!

[BurningTreeC]

But now I'm beginning to question the way that the other search inputs work as well, which may not be helpful!

:grin:

[BurningTreeC]

@Jermolene - one reason why I made it to update the input fields is, that dropdown lists can get very long and the selected item can get out of the viewport.

We could now make the selected item scroll into view, I tried that using the tm-scroll message with the selector param but that didn't work that well ... I can post a Demo to demonstrate what I mean.

Meanwhile I'm investigating the needed changes so that the inputs aren't updated anymore

[Jermolene]

Hi @BurningTreeC interesting, it would certainly be good to explore the option.

[saqimtiaz]

I am used to the search field changing to match the selected/autocompleted titles from other applications. My own Notation app in TW which I demoed on the hangout does the same. So this behaviour came intuitively to me.

However, the Filter tab is rather different in that what you type into the input can be drastically different than the search results.

So I am not against having the other search fields keep their current behaviour in principle, but we may want consistency across the board for every field using the keyboard driven input macro.

If we can adapt the macro to provide the option to disable this behaviour, we can do some testing to understand what makes better sense.

[BurningTreeC]

If we can adapt the macro to provide the option to disable this behaviour, we can do some testing to understand what makes better sense.

It's possible as I've now tested

[BurningTreeC]

keyboard-driven-input-testing.zip

@Jermolene @saqimtiaz,

In this Demo updating the input field is disabled. Actions on Enter and ctrl-Enter only work in the sidebar search input field (I haven't updated the other keyboard-driven-inputs). The keyboard-driven-input macro in this Demo also uses the tm-scroll message to navigate to the .tc-list-item-selected. See that it doesn't work that well

[kookma]

@BurningTreeC I have downloaded the demo to give a try!

A. Advanced search

1. Open Advanced Search
2. In the Standard search tab, I entered Core
3. I used down arrow and it nicely select the first tiddler found and then the next and so on
4. Then I used up arrow, I did not see the highlighted item, I see the page is going up BUT the highlighted item was hidden under top menu bar and this is confusing!

B. Sidebar Search bar

1. a word Nili as an example was entered in the standard search nothing was found
2. The ctrl+enter combination was pressed
3. A new tiddler with title Draft of 'undefined'
4. If you press the short cut combination 4 times you have Draft 5 of 'undefined'

Comments: If the tiddler is exist it should be listed in search result, if not shortcut shall create the missing tiddler, so Draft 5 is confusing!

[BurningTreeC]

@kookma in the demo I didn't include the handling for these cases in the sidebar search

[BurningTreeC]

@Jermolene the easiest thing would be to make the input field reset to what was typed when cycling through the list and reaching the top or bottom of the list. Still leaving the behavior of Escape as it is. That would mimic the behavior of the Facebook search field (if somebody here uses Facebook)

[BurningTreeC]

I imagine we could also add a box at the top of the search results that list all possible shortcuts, with a "don't show this message again" button

[BurningTreeC]

@Jermolene @saqimtiaz , I'll now post some Demos, first one that behaves like it did before but restores the typed input when we reach the top or bottom of the list:

keyboard_driven_input_1.zip

[BurningTreeC]

@Jermolene @saqimtiaz @pmario - I cannot do much more than in the Demo above, sorry.

[saqimtiaz]

@BurningTreeC apologies, some busy days this week. Expect some feedback by the end of the week. Thank you.

[BurningTreeC]

No problem @saqimtiaz

[pmario]

For me it would be OK that way. I think the "reset on Escape" should stay!

[saqimtiaz]

@BurningTreeC

@Jermolene @saqimtiaz , I'll now post some Demos, first one that behaves like it did before but restores the typed input when we reach the top or bottom of the list:

keyboard_driven_input_1.zip

I quite like this behaviour. As Jeremy mentioned earlier, my instinct when the input changes on keyboard down, is to press up to restore it and this works well. Having the escape key is great as well for when you are further down the list and want to reset the search input. Greater affordance for the Escape key would be nice in the future, but isn't as high of a priority anymore given that the up key reverses the action.

Is there any chance we can disable the keyboard up and down handling for the Filter tab, when there is only one result and it starts with "Filter error"?

[BurningTreeC]

@saqimtiaz thanks for your reply. I'll prepare a PR for this asap.

The handling of error messages is a bit more complicated since they can start with "Filter error", RegExp Error", "SyntaxError"... and depend on the language settings. I'll have a look if I can do that

[BurningTreeC]

@saqimtiaz - #5031 has been merged. Would you consider this issue as resolved?

[saqimtiaz]

@BurningTreeC yes, thank you.