21 Aug 2021, 03:30
I split @sHagen's post from the Files app 0.2.0 releast post into a new topic, as it's an important request. Considering the issues in the original post, I have now spent time optimizing filter input for the forthcoming Files app 0.3.0 release. Below I have highlighted changes to filtering:
:heavy_check_mark: Live input filter debounce [250 - 750 ms]
Most importantly, there is now a "debounce" on keyboard input, which delays the filter from processing until 250 ms (0.25 seconds) has passed without keyboard input. Technically, this means that as a user inputs "abc", the filter may trigger only once (after "abc") instead of unnecessarily triggering with "a", "ab" and "abc". As the amount of files in the list increases, the debounce delay will increase up to 750 ms (0.75 seconds) to minimize unnecessary filtering in larger lists. The delay (in milliseconds) is proportional to the amount of files, but set at minimum 250 ms (< 250 files) and maximum 750 ms (>750 files). With a minimum 250 ms debounce, filter input still feels instant, while minimizing unnecessary processing and "layout thrashing" also on small lists. Upper limit 750 ms still feels sufficiently snappy, but borders on the maximum time user is willing to wait for instant input filtering to remain satisfying and useful. Debounce values > 750 ms seem pointless, as the delay will compound with the delay of the actual filter process, making "instant input filter" unintutive and unproductive. In such case, it would be better to instead disable the new filter_live option entirely.
:heavy_check_mark: Live input filter DISABLED on MOBILE
After much testing, I decided to disable live input filtering on mobile devices. Instead, mobile devices will filter on SEARCH/DONE/CLOSE from the mobile popup keyboard that appears on screen. This was an easy choice, considering mobile devices may struggle with live input filtering caused by relatively slow keyboard input and less powerful CPU. Besides, it's more intuitive to filter from the "search" or "done" buttons that appear in the keyboard on mobile devices. Furthermore, since the keyboard often covers upto half the screen on mobile devices, live input filtering is less useful anyway.
:heavy_check_mark: New [filter_live] option
If live input filter seems ineffective and/or you have massive folders, you might consider disabling it by setting the filter_live option to false. When disabled, filter will only trigger on keyboard RETURN or input field BLUR (tabbing or clicking away from the filter input). This allows the filter to trigger only once initiated by the user.
:no_entry_sign: Minimum character input
I originally did some testing with "minimum character input", which would logically be set to something like "3". However, I found that this feature was a bit clumsy when combined with live input. For example, when inputting "ab" nothing happens, until I add a third character "abc" and a filter results suddenly appear. Then I BACKSPACE to "ab" and the entire filter has to be removed again (so technically, it would need to re-filter anyway) ... of course, we can't suddenly show filter results for "ab" just because we removed a character. Furthermore, one would need to notify the visitor somehow that a minimum amount of chars is required to trigger the filter, while some users may want to filter for file types or numbering like "01" or "jp". In conclusion, this feature seems pointless when there is an option to disable filter_live.
:heavy_check_mark: New [filter_props] option
New filter_props option allows you to assign what features to filter from, with default values 'name, filetype, mime, features'. The less properties, the faster the filter, although it doesn't seem to have too much impact on performance.
Performance notes
In conslusion, the above features hould make filtering more effective to use across all devices. Keep in mind, once a filter does trigger, it will take as much time as the system (CPU) requires to render the result from the amount of items in the list.
Looking forward to Files app 0.3.0!