I already addressed some potential Search Box improvement ideas in my general feedback thread
(a much needed boolean NOT operator, etc.), but I believe this one is worth considering as well. The suggestion is to enhance the search box syntax with abbreviated capitalized shorthand alternatives to the regular search modifiers (title:, artist: album:, etc.). E.g.:genre:Rock = G:Rock = GE:Rock
albumartist:Aerosmith = AA:Aerosmith
artist:Jovi title:Always = A:Jovi T:Always = AR:Jovi TI:AlwaysRationale:
speeding up searches considerably at very low development cost.Notes:
the only development requirement here is an added case check to the search box parser, to differentiate capitalized modifiers like A: from regular searches like "a:". Same idea as my boolean operators suggestion (OR=operator, or=search term "or"). As for the shortcuts themselves, single-letter shortcuts would be ideal, but the problem is that something like A: can stand for both Artist: and Album:. The workaround I'd go with (since I made something similar once and know it works) is to use two-letter abbreviations for all (AR[tist], AL[bum], TI[tle], GE[nre], YE[ar], etc.) and additional single-letter ones that default to the most commonly used fields (A[rtist], T[itle]) or those that only have one field for that letter (B[it depth], [W]ork, Y[ear]). The rule for abbreviating is very intuitive: if it's one word, it's the first two letters; if it's multiple words, it's the first letter of each. So: title: = TI: = T:
Artist: = AR: = A:
year: = YE: = Y:
Album: = AL:
OriginalAlbum = OA:
AlbumArtist = AA:
Etc.Potential objection #1: "The average user may get confused"
, etc. The ever-present "average" user doesn't have to use it, and I highly doubt that even the slowest of the slow won't understand the mechanics behind A: (and AR:) = artist: and AL: = album: . Potential objection #2: "There are too many similar fields for 2-letter searches! What about Sort Album and Sort Album Artist? We should only use 3 letters or none at all!"
I like uniformity in design as well, but not at the cost of speed and functionality. The chances that someone will be searching for Sort Album Artist (can you even search for them by typing now? What is it, SortAlbumArtist:?) are infinitely lower than those for Artist: or Title:. In this particular case, I'd go with SA: for SortAlbum: and SAA: for SortAlbumArtist:. It's not THAT confusing, especially to anyone willing to take a single look at the documentation or even make an educated guess based on the common abbreviation rules they can see from other fields. If Custom1: = C1: and Custom2: = C2, it won't take a genius to figure out that Custom12: = C12: . Besides, you can always go back to using full sortalbumartist: if optional SAA: too hard for you to figure out.Potential objection #3: "We need new features, not some optional tweaks of the already working ones. Don't waste a single dev's limited resources on a whim!"
First, just because you don't need faster searches doesn't mean that no one else does. I'm in the middle of organizing an enormous, badly formatted library, and I use close to a hundred of searches per session–which would translate in enormous time savings with this. More importantly, it's a VERY low cost suggestion. 99% of the code is already there. All that is needed is to literally add support for an uppercase check in the parser (very easy, if it's not there already), add the new keywords to the same parsing function (which is as simple as changing [if "title:"...] to [if "title:" || "T:" || "TI:"...]), and update the documentation page.