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.212.169 as permitted sender)
Message-ID: <50AECD86.1030006@wandisco.com>
Date: Fri, 23 Nov 2012 01:12:38 +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: Re: Improved Search Architecture - Query Results View and Resource
 Query (Was: Re: [Apache Bloodhound] Proposals/BEP-0004 added)
References: <20121122103257.3EA8580043@bloodhound-vm>
 <CAHM0gniZ8KN5S6omg7_m=tmLz8GBirQFPZSBrEEP9LsD0NB6RQ@mail.gmail.com>
 <50AE2119.8070100@wandisco.com>
 <CAKoya93HLqZ9N3mmjhGapizWxSCfeLwqDDF_=bbUFxcyQ5yXTA@mail.gmail.com>
 <CAGMZAuNtdWZb2cSSLOxdiR5wXUnri2XyJPpv0+Dgi832FKT3SQ@mail.gmail.com>
 <CAGMZAuMS8Gnzx6mDLaFTb++RjONdz3SX73U-BiyXkkzZBYiWqA@mail.gmail.com>
 <CAKoya90_MTZkJLCgSvGH1Ry7ehox_s8y+Y3AangJWk_t_1JXYw@mail.gmail.com>
 <CAJSKAsh05EsZ1BaNQEDUJHd96_aziUrBqzZX15OrhTGzrmdvwg@mail.gmail.com>
 <CAGMZAuOgNrR4dYbpjMXsYUCc2t38cvZp_hxMF4wiO0g81fo1hg@mail.gmail.com>
 <CAHM0gni8GX_R7YJBG_MT=_UR6GkpNH7rgE-itYSFb_Zd+3JnBw@mail.gmail.com>
 <CAGMZAuO4izch9ANPMQn3k54zuyj1Y6yqbDGFpW1LT7U-fuayTw@mail.gmail.com>
In-Reply-To: 
 <CAGMZAuO4izch9ANPMQn3k54zuyj1Y6yqbDGFpW1LT7U-fuayTw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 23/11/12 00:34, Olemis Lang wrote:
> Good answer , indeed !
> :)
>
> On 11/22/12, Andrej Golcov <andrej@digiverse.si> wrote:
>>> IMO when a user searches for something , (s)he might not know where
>>> exactly to find it but have a fuzzy idea . IMO we should consider
>>> having multiple selections via checkboxes rather than tabs .
>> If user does exactly know what resource (s)he is searching, "All" tab is
>> used where query can be edited to show only tickets and milestones.
>> IMHO, user usually knows what type (s)he needs (I believe, most of search
>> is for tickets) and ,IMO, tabs make things easier and less confusing.
>>
>> Each tab has it's own fields set. Combination of checkboxes and different
>> grids can confuse.
>>
> Ok . This is something that depends on the type of application and its
> users ... so no big deal about it .
>
> ;)
>
>>> what is the reason for using tables and columns to display search results
>> ?
>> The idea is that we combine free-text search and query. If we want to
>> provide readable query result it can be possible to represent it as
>> table.  It is aslo consistent to existing TracQuery result view.
>>
> I asked mainly because I've been taking a look at several search UX
> solutions for mobiles and it turns out that they all have no more than
> 3 columns ... and when they have the third one it's most of the time a
> checkbox , download indicator , ... i.e. something tiny .
Well, this is a problem that we would have to overcome for ticket 
queries anyway.

> Besides there is another fact . Free text search is a bit different to
> a ticket report . Especially highlighting means that maybe snippets of
> long text will be displayed to put the match in context . So in that
> view there will be basically two kinds of data
>
> 1. Highlighted excerpts of long texts (wiki page body ,
>      ticket description , custom textarea ticket field ...)
> 2. Relatively small (potentially tiny) text (i.e. ticket status,
>      ticket type, dates ...)

The highlighted excerpts approach would be a more natural fit for the 
'All' tab than for the ticket query results. It doesn't mean that the 
free text search should not be able to apply to those results.

 From the ticket query side, one of the enhancements this work could 
provide, if accepted, is this free text search. It seems a much simpler 
query to specify than having to state all the fields you might expect to 
find the text in!

> They all will have relatively equal relevance competing for horizontal
> space (i.e. width)
>
> I wander how will proposed solution (the user experience as a whole)
> look like using responsive layout or for smartphones and tablets ?
>
> Another question I have is related to the purpose of the content
> included in those columns ? What are they for ?

Talking of this, are we including a means to specify which fields are 
displayed in the tickets tab as part of the requirements?

> For the debate : What about having a single column (e.g. to the right)
> for any kinds of search results metadata displayed in the form of
> clickable metadata [1]_ and stack it under summary + full text hit
> snippets for tablets & smartphones ?
>
> OTOH , regarding meta-data , it'd be nice to have some other tags
> attached to search results in a way similar to what is displayed for
> Hadoop Common when performing this search
>
> https://www.google.com/search?client=opera&rls=en&q=jira+apache&sourceid=opera&ie=utf-8&oe=utf-8&channel=suggest

I guess that there are a number of possible solutions for display. Are 
any of these an approach that you would be advocating for the current 
ticket queries and reports? I think I'll reserve judgement until I play 
around with some ideas for a bit longer.

Cheers,
     Gary