Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of gary.martin@wandisco.com
 designates 209.85.215.47 as permitted sender)
Message-ID: <50AE140D.5020003@wandisco.com>
Date: Thu, 22 Nov 2012 12:01:17 +0000
From: Gary Martin <gary.martin@wandisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: bloodhound-dev@incubator.apache.org
Subject: Improved Search Architecture - Quick Search Box (Was: Re: [Apache
 Bloodhound] Proposals/BEP-0004 added)
References: <20121122103257.3EA8580043@bloodhound-vm>
 <CAHM0gniZ8KN5S6omg7_m=tmLz8GBirQFPZSBrEEP9LsD0NB6RQ@mail.gmail.com>
In-Reply-To: 
 <CAHM0gniZ8KN5S6omg7_m=tmLz8GBirQFPZSBrEEP9LsD0NB6RQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Andrej,

Thanks for this. There are plenty of good ideas here but I will go 
through it in parts creating different threads. Hope that is good for 
everyone.

On 22/11/12 11:08, Andrej Golcov wrote:
> Hi all,
>
> I've just added first draft of proposal for search improvements. So, let's
> discuss it :)
>
> I suggest that we agree on functional requirements and then pass to
> possible implementation.
>
> Regards, Andrej
>
>
> On 22 November 2012 11:32, Apache Bloodhound <
> bloodhound-dev@incubator.apache.org> wrote:
>
>> Page "Proposals/BEP-0004" was added by andrej
>> Content:
>> -------8<------8<------8<------8<------8<------8<------8<------8<--------
>>
>> = BEP 4 : Improved search architecture #overview
[snipped]
>>
>> === Quick search box
>>
>> Quick search box should be just frontend for adhoc query. For example, if
>> user searches for �bla� string, user receives Search Result view with the
>> following query:  text~=�bla�. User can refine query in Query Result view.
Quick search should probably maintain all the syntax that a query 
results view search box provides. The main reason for providing a 
different search box would be that you can construct a larger text query 
and keep it in view, which seems quite nice. It would also solve the 
current problem of attempting to refine the search in the quick search 
field resulting in the dropping of the filters (though this could be 
solved by adding the filters to the quick search query.)

On a technical note, is there any reason to specify text~= for a general 
text query? I would have thought that we could distinguish free text (as 
perhaps suggested below in the examples below.)

>>
>> Search box should accept the following search types:
>>    - free-text search: �bla�
>>    - free-text + query: bla status!=closed
>>    - query only: status!=closed

This looks good. At the moment the quick search requires 
"query:status!=closed" for the last of those and to include the 
free-text search you would need to query a whole set of fields to see if 
they contain the text. This is clearly not as quick and intuitive. 
Obviously, as soon as you bring field queries into the problem you are 
automatically focusing on resources that have that field available 
(possibly relaxed when there is an OR operator involved - think "bla OR 
status!=closed")
>>
>> Other nice to have features:
>>    - Did you mean...
>>    - Suggestions during typing

The second is probably more useful than the former but these are 
probably worth considering later.

Cheers,
     Gary