bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Dreimann <>
Subject Re: Improved Search Architecture - Query Results View and Resource Query (Was: Re: [Apache Bloodhound] Proposals/BEP-0004 added)
Date Thu, 22 Nov 2012 17:33:57 GMT
On 22 November 2012 12:56, Gary Martin <> wrote:

> Next a few comments on the Query Result view and Resource Query sections:
> 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.**<>>
>> wrote:
>>  Page "Proposals/BEP-0004" was added by andrej
>>> Content:
>>> -------8<------8<------8<-----**-8<------8<------8<------8<---**
>>> ---8<--------
>>> = BEP 4 : Improved search architecture #overview
>> [snip]
>>> === Query Result view
>>> Query Result view represents consistent view of query result for
>>> different
>>> resources. Result may be represented as
>>>    - All resources result tab - default, common for all resources columns
>>> e.g. name and description
>>>    - Resource result tabs - resource specific fields are shown e.g. id,
>>> status, summary for ticket.
>>>    - Query Result view can be instructed to limit result to specific
>>> resource type e.g. show only tickets in result. In this case, resource
>>> tabs
>>> can be omitted.
> Presumably, this would be a part of the new query syntax so that it can be
> relatively easy to filter before getting to this page.
>> User can refine search conditions either by editing query or by using
>>> Query Builder.
> I would like to see others comment on the mockup for the query builder.
> Consistency with other views suggest that there may be space on the right
> hand side, replacing the activity area - I assume that we will not be
> displying activity on any search/query screen.

I like that suggestion, replacing the activity area with a query builder in
the UI. I've raised ticket #272 to create a mockup for this.

>  User can specify what fields should be selected and in what results order
>>> should be applied. A new order type is introduced for free-text search:
>>> score
>>> Query Result view should support facets (
>>>  for example:
>>>    - All resources result tab can show facets for resource type and
>>> product
>>>    - Ticket result tab can show facets for products and ticket status
> Facets seem to me to be a very important enhancement.

I agree. This would be a great feature to have and build upon.

>>> Other nice to have features in no particular order:
>>>    - Possibility to save a query for specific user and sharing of saved
>>> queries
>>>    - Search highlighting
> Saved/stored queries have been discussed in the mailing list before a few
> times so I think this is probably an expectation beyond the ability to put
> a search macro on a wiki page. I think that this should probably be
> considered separately of this solution but we should make sure that such
> stored queries support any implementation that arises from this.

#230 is the suggestion for Custom Queries to show recent queries. There was
also a suggestion to be able to save queries. Just thought it may be
relevant here to mention it.

> Search highlighting might also be worth separating out so that we make
> sure that we focus on getting searches done correctly, even if it turns out
> it is just a small enhancement on top. I assume that this is referring to
> terms being highlighted when you click on a link result here so it is
> probably out of scope of the Query result view section anyway.
>  === Resource Query
>>> New Resource Query should provide the following functionality:
>>>    - free-text search support
>>>    - facet support
>>>    - it is a superset of TracQuery functionality
>> So we can embed TracQuery syntax within the new queries?
>>    - basic query expressions AND, OR, NOT, search by specific field,
>>> search
>>> [FROM TO] - TBD (can be similar to SQL or lucene/solr like)
> I think that this could also be considered from the point of view of a set
> operation syntax which could be interesting. Not sure if it is worth it of
> course. Anyway, in addition to logical operators, we do need to be able to
> express a grouping syntax to build more advanced expressions from the
> basics.
> It would also be nice if we were able to express these queries relatively
> easily in a query string so that it is possible to just write your query
> directly in a link and be understandable.
>>    - search through different resources not only tickets: wiki,
>>> milestones,
>>> changesets and other pluggable resources
>>>    - search through all resource fields
>>>    - search through attachments, history and comments
>>>    - multi-product aware - apply security context etc
>>>    - order by free-text score. Score calculation can be configured, for
>>> example if found in summary: id: score:100, score*10, in keywords:
>>> score*5,
>>> in components: score*3 …
> I would probably suggest that we keep configurability of scores in mind
> but don't provide the interface to change it until a bit later. A bit of
> clarification might be helpful here too. Presumably term found in summary
> would be score*=100 rather than just assigned 100. In addition, we could
> consider modifying the score based on the date. There is a further
> possibility of including fairly simple "favour [something]" (e.g. "newer",
> "older", etc) radio boxes to adjust the scoring dynamically as I am not
> convinced that users should be expected to adjust these values for
> themselves at the moment.
>  Nice to have features
>>>    - Support search in attachments of specific types e.g word, exel etc.
>> I seem to remember that you get this in solr for free but I am not so
> sure about the others.
> Cheers,
>     Gary

Joe Dreimann
UX Designer | WANdisco <>
*Transform your software development department. Register for a free SVN
HealthCheck <> *

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message