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 olemis@gmail.com designates
 209.85.212.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAHM0gni8GX_R7YJBG_MT=_UR6GkpNH7rgE-itYSFb_Zd+3JnBw@mail.gmail.com>
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>
Date: Thu, 22 Nov 2012 19:34:36 -0500
Message-ID: 
 <CAGMZAuO4izch9ANPMQn3k54zuyj1Y6yqbDGFpW1LT7U-fuayTw@mail.gmail.com>
Subject: Re: Improved Search Architecture - Query Results View and Resource
 Query (Was: Re: [Apache Bloodhound] Proposals/BEP-0004 added)
From: Olemis Lang <olemis@gmail.com>
To: bloodhound-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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 .

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 ...)

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 ?

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

>> Is there any other search engine considered as a reference ?
> jira and youtrack return kind of table fro free text-search result.
>

about YouTrack , I implemented a client once upon a time , and I
really liked what I saw . AFAICR it had an interesting query syntax .
Maybe something to take a look at .

.. [1] Clickable metadata
        (http://ebiinterfaces.files.wordpress.com/2010/08/webinar-designing-the-search-experience.pdf)

PS: I ask because I've been paying special attention to UI design
after theme work ... so I'm curious and interested in fleshing out UI
stuff ... and learn in the process . Hope you don't mind
;)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article: