Non technical users understand what a field is. All of them might however not 
know that they they can use them but It's easy for them to learn that name:john 
will search for john only in names.

Non technical users can learn to understand that logic and functionality can be 
specified in their queries. That + means boolean expression AND, that quoted 
text will match phrases.

It's however extremely hard for non technical users to understand that a field 
might be the placeholder of functionality such as phonetics. Users can learn 
that {name.phonetic:john} constitute a phonetic match the same way as 
{name:"john doe"} constitute a phrase match but they might just ask why it's 
not {name.phrase:john doe}. 

Anyone user can learn to use something no matter how cryptic and strange, they 
simply get used to it. But I would prefer if  it was more intuitive for non 
technical users to construct complex queries by them selfs.

To a non technical user a field is a field, it's not functionality. The field 
{name} is just the field {name}, not a whole bunch of fields with different 
settings that all of them actually contains the {name} analyzed in a variety of 
ways. Field to the left of the colon, matching rules to the right of the colon.


I'm not sure how it should look and what it should be able to do, but I think a 
more complex (for the developer, not for the user) query parser needs to be 
implemented that fix these problems for the users. Something in the lines of 
more strange control characters as when matching fuzzy and what not, but 
preferably something even better. Perhaps one need to reconsider the whole 
query parsing thing to get it really good.


Did anyone else spend time thinking along these lines?



                        karl
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org

Reply via email to