bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: Improved Search Architecture - Query Results View and Resource Query (Was: Re: [Apache Bloodhound] Proposals/BEP-0004 added)
Date Fri, 23 Nov 2012 04:45:50 GMT
On 11/22/12, Gary Martin <> wrote:
> On 23/11/12 00:34, Olemis Lang wrote:
>> Good answer , indeed !
>> :)
>> On 11/22/12, Andrej Golcov <> wrote:
>>>> 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.

Maybe , yes , if we take a straight look at it . However it seems to
me that ticket queries serve to a different purpose than free text
search . In that case it is also important to make results look
somehow like users want to . With mobile devices it is still possible
to e.g. hide columns ... until everything fits . That's not the goal
of free text search .

>> 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
> 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?

Like I mentioned before , even if queries and reports are yet another
kind of search engine , there is a difference between them and free
text search . For instance , reports and queries have some focus on
presentation , hence visible columns may be selected to satisfy some
information needs . Nonetheless in free text search findability is the
main goal over everything else . That's why the first point mentioned
above does not apply .

The second suggestion I made seems more appropriate for products ,
milestones , ... but in the case of tickets , for instance they may be
annotated (in a similar way to Google search results I mentioned
above) with # of comments , # of attachments , ... each pointing to
the specific section within ticket view .

To make myself clear , IMO none of them is suitable for query or
reports web UI , because that serves to slightly different purpose .



Blog ES:
Blog EN:

Featured article:

View raw message