Feature Request
Filter Modal UI: Allow mouse-input as primary input method
phptek
At the moment, in order to filter by machine-name for example, I need to go from mouse / trackpad to keyboard to type it whereas using a bog-standard dropdown would be more efficient as I needn't move from mouse to keyboard.
At present it appears as if some whizzy client-side form-input is being used for no real gain (a loss I'd argue) when a standard dropdown would suffice. If improvement on standard O/S form-widgets were still required, then there are of course client-side dropdown libs that supply fields with keyboard-enabled filters e.g. "chosen" et al.
Raygun
John-Daniel Trask
Posted on
Apr 04 2016
Hi phptek,
Thanks for this :-) As some background, the reason it's not a bog standard drop down is because we can literally have hundreds of thousands of values at times, so we wanted to filter it back a bit (incidentally, we still fetch the values, but don't mind them, it's more an auto-complete box, so we still are doing all the work, but a normal drop down isn't very easily filtered).
Having said that, in general I'm not overly fond of how the interaction model works with that drop down either so it is something we'll look at making more user friendly. I can't promise when, but we are scheduled to look at filters in more detail soon. This could be part of that work.
I hope that helps,
John-Daniel Trask
phptek
Posted on
Apr 04 2016
Hi John-Danial and thanks :-)
For sure, I was going to say also that regardless of the UI solution you would always be having to pre-fetch the values (Doing it async might be annoying as it's another wait on top of the wait to generate the modal in the first place).
As for your comment " but a normal drop down isn't very easily filtered" true, hence my suggestion of using a combo-box from the "Chosen" lib for example which is primarily a dropdown (actually it's a bunch of <div>'s that replaces a standard <select>) and comes with a filter area as well so you get the best of both worlds.