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: [email protected]
For additional commands, e-mail: [email protected]
