On 23/11/12 00:34, Olemis Lang wrote:
Good answer , indeed !
:)
On 11/22/12, Andrej Golcov <[email protected]> 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
