Laying QuickSearch to rest

[Andreas Franke]

> >Quicksearch does this.
> >
> Ah, sorry, didn't realize that (probably because 
> the help page doesn't mention it).

No problem.  It's probably the single most serious bug 
in the current documentation of quicksearch that the 
only way to discover the advanced part (i.e. 
quicksearchhack.html) is through a tiny link at the 
top of the basic help page (quicksearch.html) which
is easy to miss.  I should have submitted a two-line fix 
for this problem years ago.  Maybe it's time to reopen 
bug 76392 for some of the most serious bugs in the docs.

>>> product:Browser/Foo,Bar,Baz
>> product:Browser :Foo,Bar,Baz
> Except that using a colon to separate the product from 
> the components overloads its meaning as a field/value 
> separator.
(This is a misunderstanding: note the space. The colon ":"
is just short for the "product,component:" prefix, i.e. if 
the prefix field is empty, it defaults to "product,component".)
I find your special syntax using "/" quite intuitive indeed,
because it suggest that a component is basically a subdir
of a product directory.

> We should simplify this by requiring the status: prefix.  

Possibly. We should at least allow the status prefix.

> One of the reasons the current syntax is arcane is that there 
> are multiple ways of specifying criteria that most searches 
> don't use, complicating the learning process while optimizing 
> unnecessarily.  Rarely used functions don't need such extreme 
> shortcuts, even if a small minority of users benefit from them, 
> especially if they prevent the larger pool of potential power 
> users from learning and using the feature set.

You're right, this effect must be avoided.  E.g. 
   os:win AND sev:enh,tri AND pri:3,4,5 
instead of just
   win AND enh,tri AND p3-5 
certainly makes sense: the prefixes are short and the conditions
are used infrequently, so that the savings in typing speed are
minimal and are far from compensating the disadvantage of the 
added complexity.

On the other hand, I don't see anything non-intuitive in
allowing some abbreviated field names as alternative prefixes,
as long as the basic idea of using the full field names
as prefixes is taught first.  Allowing "sev:triv" in 
addition to "severity:triv" and "pri:1" in addition to
"priority:1" may even improve the usability of the textbox, 
especially if its size is not too large.  I would assume
that hiding the abbreviations on an "advanced features"
documentation page and moving the cryptic ones (like "@" for
"owner:", "!" for "keyword:", or ":" for "product,component:")
to an even more advanced "undocumented hacks" page ;) would go 
a long way in making the design easier to learn and work with.

> We just need Search.pm to scan the content field for 
> prefixes and convert them to their corresponding criteria.
I'm afraid that this might not be sufficient.  There 
should at least be a story about the OR operator and
exclusion of words (NOT), and possibly some other subtleties.

But maybe we can move this discussion to Bugzilla now. I have
filed bug 234464 about the task of designing an intuitive
syntax for useful quicksearch features, and I hope that I'll
find some time this week to file sub-bugs for the specific
issues.  (And I have reactivated my bugmail.)

Andreas