528962 - improve bugzilla quicksearch summary on results page (hard to parse, takes up too much space)

Status: NEW

(Bugzilla :: Query/Bug List, defect)

Description

[Thomas D. (:thomas8)]

Attachment: Screenshot: bmo quicksearch summary gone wild

Nice try! We now have a summary on quicksearch results (thank you, that's nice), but the current layout just adds confusion instead of adding information.

STR

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=Thunderbird+search%20words%20substring

Actual result: search summary on top of search has a no-line-breaks version of this:

    *   Status:  REOPENED, NEW, ASSIGNED, UNCONFIRMED
    * Product: Thunderbird
    * Component: Thunderbird
    * Summary: Thunderbird
    * Whiteboard: Thunderbird
    * Product: search
    * Component: search
    * Summary: search
    * Whiteboard: search
    * Product: words
    * Component: words
    * Summary: words
    * Whiteboard: words
    * Product: substring
    * Component: substring
    * Summary: substring
    * Whiteboard: substring

I'm sorry, but this is really nonsense. We're wasting a lot of screen real estate and this is way to hard for humans to parse without adding any value.

Expected result (at least for all kinds of quicksearch):

* Status:  REOPENED, NEW, ASSIGNED, UNCONFIRMED
* Product, Component, Summary, or Whiteboard: Thunderbird, search, words, substrings

Comment 2

[Max Kanat-Alexander]

Actually, I'd rather keep this as a separate bug. For QuickSearch searches, we should just show what was input into QuickSearch as the whole summary.

Comment 3

[Thomas D. (:thomas8)]

(In reply to comment #2)
> Actually, I'd rather keep this as a separate bug. For QuickSearch searches, we
> should just show what was input into QuickSearch as the whole summary.

I think it might be helpful to show the Status fields that are searched, as we are skipping e.g. duplicates and fixed. It took me a long time to understand what quicksearch actually does and does not search. I also think it helps to know which fields are searched. E.g. apparently we're not doing a fulltext search. A better understanding of how quicksearch works will be helpful for getting the right results, which in turn will make bmo more efficient.

To reduce visual clutter, consider hiding the fields and status in links which show a tooltip or div pane on hover or click, similar to this:

Quicksearch for: *My, search, words*
in _these fields v_ of bugs with _this status v_
                                 | UNCONFIRMED |
                                 | NEW         |
                                 | REOPENED    |
                                 | ASSIGNED    |
                                 +-------------+

Comment 4

[Max Kanat-Alexander]

(In reply to comment #3)
> in _these fields v_ of bugs with _this status v_

  Yeah, that would be nice, and is theoretically possible, though we may have to be helpful in a slightly more limited sense based on our current architecture.

Comment 6

[Frédéric Buclin]

Bugzilla 3.4 is now restricted to security bugs. We will retarget this bug (to 3.6 or later) when it's fixed.

Comment 7

[charan]

exucted TC 66(Reference TC document 3.4) & found the bug

Comment 8

[Thomas D. (:thomas8)]

Max, can you provide a mxr reference to the source file(s) and position (line number) where the summary is generated?

For someone who knows the code and has the time, fixing this should be a matter of minutes, and would eliminate an outstanding functional ui annyoance for all quicksearches (supposedly a LOT).

Proposed Fix:

Instead of adding the search word values after each search field name, just add the search fields only, and the original search string value in full, like this (simplified from comment 3 's proposal):

Quicksearch for: *My, search, words*
*Search fields:* product, component, summary, whiteboard
*Status:* REOPENED, NEW, ASSIGNED, UNCONFIRMED

Comment 9

[Max Kanat-Alexander]

  Sure. It's in template/en/default/list/list.html.tmpl.

Comment 10

[Thomas D. (:thomas8)]

Attachment: Proposed layout for better yet informative default quicksearch summary

Max, could you review the proposed layout of a better default quicksearch summary at the top of result pages? This incorporates your points from comment 2 (show full search string in summary), and comment 4 (keep it simple), while providing valuable information in a condensed format.

Comment 11

[Max Kanat-Alexander]

Comment on attachment 462019 [details]
Proposed layout for better yet informative default quicksearch summary

I think that for quicksearches, instead what we'd do is we'd collapse everything into "Quicksearch: the search terms" and then (maybe) make it expandable to the full search description.

Comment 12

[Thomas D. (:thomas8)]

Attachment: Proposed layout V.2: Simple quicksearch summary in google-style input box to modify search terms (bug 365086)

(In reply to comment #11)
> Comment on attachment 462019 [details]
> Proposed layout for better yet informative default quicksearch summary
> 
> I think that for quicksearches, instead what we'd do is we'd collapse
> everything into "Quicksearch: the search terms" and then (maybe) make it
> expandable to the full search description.

Max, for your review, here's a new ASCII mockup based on your comment 11, and including fix for bug 365086: Instead of just showing static quick search string as text, put it into a google-style input box so that user can refine/ modify the search terms in-place and search again, which will make this just so much more efficient.

Comment 13

[Thomas D. (:thomas8)]

Comment on attachment 462724 [details]
Proposed layout V.2: Simple quicksearch summary in google-style input box to modify search terms (bug 365086)

(In reply to comment #11)
> Comment on attachment 462019 [details]
> Proposed layout for better yet informative default quicksearch summary
> 
> I think that for quicksearches, instead what we'd do is we'd collapse
> everything into "Quicksearch: the search terms" and then (maybe) make it
> expandable to the full search description.

Max, for your review, here's a new ASCII mockup based on your comment 11, and
including fix for bug 365086: Instead of just showing static quick search
string as text, put it into a google-style input box so that user can refine/
modify the search terms in-place and search again, which will make this just so
much more efficient.

Comment 14

[Max Kanat-Alexander]

Comment on attachment 462724 [details]
Proposed layout V.2: Simple quicksearch summary in google-style input box to modify search terms (bug 365086)

Hmm. Well, the search terms are already in the Quicksearch box in the header--I don't think I want to duplicate the search box again on the search page. However, hiding the search description entirely unless you click on something, when a quicksearch is done, might be workable.

Comment 15

[Thomas D. (:thomas8)]

(In reply to comment #14)
> Comment on attachment 462724 [details]
> Proposed layout V.2: Simple quicksearch summary in google-style input box to
> modify search terms (bug 365086)
> 
> Hmm. Well, the search terms are already in the Quicksearch box in the header

Are they? Not in bmo's version of bugzilla. Enter a search term in the quicksearch box in the header, press enter, results page shows and quicksearch box is cleared - hence bug 365086. Do you have a version where terms stay in the header's qs box? That would be a great step ahead.

> I don't think I want to duplicate the search box again on the search page.

I see. Will think on that.

> However, hiding the search description entirely unless you click on something,
> when a quicksearch is done, might be workable.

Must be my lucky day... :)

Comment 16

[Max Kanat-Alexander]

(In reply to comment #15)
> > Hmm. Well, the search terms are already in the Quicksearch box in the header
> 
> Are they? Not in bmo's version of bugzilla. 

  Ah, that fix is in 4.0.