Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: error (nike.apache.org: local policy)
From: Karl Wettin <karl.wettin@kodapan.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: A couple of thoughts on non technical users and query parsers.
Date: Fri, 31 May 2013 01:26:36 +0200
Message-Id: <8DBB5BC5-9C1E-431B-A287-FE47DF9613A1@kodapan.se>
To: java-user@lucene.apache.org
Mime-Version: 1.0 (Apple Message framework v1283)

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}.=20

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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org