Inconsistent behavior of "Please re-phrase the search" popup
A universal P2P file sharing client for Windows
Brought to you by:
raspopov
Menu
▾
▴
#166 Inconsistent behavior of "Please re-phrase the search" popup
Some three-letter searches seem to trigger this while others do not, even when avoiding "mp3" and similarly. For example, "shw" triggers it but it will happily search for "mbw". This seems inconsistent; I don't see a reason why it shouldn't be possible to make (at least type-specific, e.g. "archive") searches for "shw" while simultaneously allowing "mbw".
I also don't like getting the software equivalent of a "naughty no-no" finger wagged in my face instead of the expected response in response to a) an action that doesn't seem unreasonable, b) an action performed in good faith, or c) an action substantially similar to one performed in the past without it resulting in any similar form of admonishment -- and this is all three at once.
If there are two or more search terms it should just search. If there is one search term of five or more letters it should just search. If it's three or four letters and not one of "zip", "mpg", "mpeg", "jpg", "jpeg", "mp3", or a handful of other very common file extensions, it should just search.
Even smarter, perhaps it should have separate search boxes for body and extension -- usually you're not looking for ".ferrari" files, nor for "creative commons mp3.jpg" for that matter. Then disallow leaving the body box blank. If you search "mp3" in the body box it looks for files named somethingmp3something.ext, but not .mp3 files. If you search "mp3" in the extension box with a blank body box it balks. If you fill both boxes the search is more specific than just "mp3 files". And the "non-matching files" filter can hide non-.mp3 files returned as hits for a query with "mp3" in the extension box, etc., whereas right now you can get say an icky "title.mp3.wma" return for a "title.mp3" search set as audio and neither that nor "bogus files" is likely to junk that hit, since .wma is an audio format and "title" and "mp3" are in the file name.
Classing this as "minor" as a) it's very infrequently encountered and b) there are workarounds (albeit awkward, tedious, and bandwidth-consuming, e.g. search for all of "shwa", "shwb", "shwc" ...).
Classing this as "Network" as it isn't just a simple UI defect, affecting searching as it does, but is also not specific to any particular protocol.
Feel free to comment if you think a separate enhancement request should be filed for the separate-body-and-extension-boxes idea.
Excluded only "well-known" 3 digit words for example all file extensions from Metadata Schemas i.e. all audios, videos, images etc. But there is also a minimal length condition.