incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrej Golcov <and...@digiverse.si>
Subject Re: Improved Search Architecture - Query Results View and Resource Query (Was: Re: [Apache Bloodhound] Proposals/BEP-0004 added)
Date Fri, 23 Nov 2012 11:26:22 GMT
> Talking of this, are we including a means to specify which fields are
> displayed in the tickets tab as part of the requirements?
Resource Query should definitely support specifying which fields to return.
In BEP it is covered by "it is a superset of TracQuery functionality". So,
Query Result view can give possibility to user to select wich fileds to
query.

> 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.
Agreed. I suggest that we concentrate on Resource Query functionality and
provide minimalistic search result rendering, similar to existing search
and then play around it to see what is the best presentation approach. Any
way, that should be done it in pluggable way ;)

Regards, Andrej

On 23 November 2012 02:12, Gary Martin <gary.martin@wandisco.com> wrote:

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

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