1073591 - Get a fast UI for some basic filters into Super Search (like Advanced Search has)

Status: RESOLVED FIXED

(Socorro :: Webapp, task, P1)

Description

[Robert Kaiser]

The main reason I still use Advanced Search nowadays is because it has a UI to incredibly fast add some basic search filters, esp. product and version (which are even prefilled when you click on the Advanced Search link while being on a TCBS report), sometimes I also use OS and Process Type (would be nice to be able to check both browser and content processes though).
I don't use the others too much, but there might be some other people who use some of them.

Comment 1

[[DEACTIVATED] Adrian Gaudebert]

Attachment: simple-search-preview.png

Based on an idea from :lonnen, here is a proposal for a simple UI for Super Search. It is a separate page from the current, more complex UI, but there is a link at the top to get to it (called "Super Search", which I dislike, but I thought calling it "Advanced Search" would be very very confusing. I am open to suggestions for a better name here. Maybe just "Super Search" would work? ). 

I am not sure what the workflow should be. Where does a user land when he/she clicks the Super Search link at the top? The complex or this simple UI?

Comment 2

[Robert Kaiser]

Comment on attachment 8504531 [details]
simple-search-preview.png

So, on that, the Platform selector is something I rarely use actually, the Process type is super important to be there - do both have values you can chose by point-and click and support multiple values?
Can we also have all those fields pre-filled (product/version with what is selected in the overall page selectors at the top, platform with all our platforms, and process type with "browser"/the-empty-one and "content")?

Otherwise, I like the basic direction this is going, but not sure if we want to have it present for all SuperSearch queries (we might, I haven't fully throught through of when it would be in the way).

Comment 3

[[DEACTIVATED] Adrian Gaudebert]

(In reply to Robert Kaiser (:[e-mail]) from comment #2)
> So, on that, the Platform selector is something I rarely use actually, the
> Process type is super important to be there - do both have values you can
> chose by point-and click and support multiple values?

Yes, they all can have multiple values, and once you have clicked the input box, it shows the list of options and you can choose as many options as you want without the list closing off.

> Can we also have all those fields pre-filled (product/version with what is
> selected in the overall page selectors at the top, platform with all our
> platforms, and process type with "browser"/the-empty-one and "content")?

Yes, that will be part of the patch. Product and version will be filled with the default context. I also intend to make sure the current content of the form is kept throughout Super Search pages (if you switch to the complete search from the simple one, for example).

> Otherwise, I like the basic direction this is going, but not sure if we want
> to have it present for all SuperSearch queries (we might, I haven't fully
> throught through of when it would be in the way).

That's my main question. When do we want to link to this simplified UI? Maybe we can have two links in the header, like we have now, but replacing "Advanced Search" with something like "Simple Search"?

Comment 4

[Robert Kaiser]

(In reply to Adrian Gaudebert [:adrian] from comment #3)
> (In reply to Robert Kaiser (:[e-mail]) from comment #2)
> > So, on that, the Platform selector is something I rarely use actually, the
> > Process type is super important to be there - do both have values you can
> > chose by point-and click and support multiple values?
> 
> Yes, they all can have multiple values, and once you have clicked the input
> box, it shows the list of options and you can choose as many options as you
> want without the list closing off.

Awesome.

> > Can we also have all those fields pre-filled (product/version with what is
> > selected in the overall page selectors at the top, platform with all our
> > platforms, and process type with "browser"/the-empty-one and "content")?
> 
> Yes, that will be part of the patch. Product and version will be filled with
> the default context. I also intend to make sure the current content of the
> form is kept throughout Super Search pages (if you switch to the complete
> search from the simple one, for example).

That sounds very good. Just to confirm, that is also true for the process type default I asked for?

> > Otherwise, I like the basic direction this is going, but not sure if we want
> > to have it present for all SuperSearch queries (we might, I haven't fully
> > throught through of when it would be in the way).
> 
> That's my main question. When do we want to link to this simplified UI?
> Maybe we can have two links in the header, like we have now, but replacing
> "Advanced Search" with something like "Simple Search"?

I think I'd actually prefer an on/off switch for this line on the One True Search Form™ or something like that.

Comment 5

[Wayne Mery (:wsmwk)]

> I think I'd actually prefer an on/off switch for this line on the One True Search Form™ or something like that.

I also like this.  And the general idea of the bug.

One field I would add is "Crash Signature".  99% of the time I use it.

Comment 6

[[DEACTIVATED] Adrian Gaudebert]

Attachment: "Advanced" UI mode for Super Search

Comment 7

[[DEACTIVATED] Adrian Gaudebert]

Attachment: Simple UI mode for Super Search

Comment 8

[[DEACTIVATED] Adrian Gaudebert]

Pull request: https://github.com/mozilla/socorro/pull/2488

I did not include the signature field for various reasons: 

1. It takes some space in that UI and I want to keep it simple
2. It makes little sense to have the signature field without the operator choice (and if I start adding the operator, it's no simple UI anymore)
3. That field will soon be easily used via the top-right input box.

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to Adrian Gaudebert [:adrian] from comment #8)
> Pull request: https://github.com/mozilla/socorro/pull/2488
> 
> I did not include the signature field for various reasons: 
> 
> 1. It takes some space in that UI and I want to keep it simple
> 2. It makes little sense to have the signature field without the operator
> choice (and if I start adding the operator, it's no simple UI anymore)
> 3. That field will soon be easily used via the top-right input box.

I can't fault simplicity, but I disagree with #2 or #3.  re: #2, the other fields default an operator, and either operator "contains" or "is" would suffice.  "re:" #3, signature alone doesn't accomplish what's needed, unless I misunderstand what you plan. Lastly, the other fields you are accomodating need not be so wide.

However, that said, I'd perhaps be happier with an alternative solution, of persistent custom default advanced search fields. That way I don't need to add the same fields every time I want to search. Is there a bug report for such capability?

Comment 10

[[github robot]]

Commits pushed to master at https://github.com/mozilla/socorro

https://github.com/mozilla/socorro/commit/43522a3a91cb5a1d460b60669afb1c6f82bb557b
Fixes bug 1073591 - Added a simplified UI to Super Search.

https://github.com/mozilla/socorro/commit/b00d5574f5d8a35aa7fd5409f73f293fc722d464
Merge pull request #2488 from AdrianGaudebert/1073591-simple-search

Fixes bug 1073591 - Added a simplified UI to Super Search.

Comment 11

[Wayne Mery (:wsmwk)]

(In reply to Wayne Mery (:wsmwk) from comment #9)
> (In reply to Adrian Gaudebert [:adrian] from comment #8)
> > Pull request: https://github.com/mozilla/socorro/pull/2488
> > 
> > I did not include the signature field for various reasons: 
> > 
> > 1. It takes some space in that UI and I want to keep it simple
> > 2. It makes little sense to have the signature field without the operator
> > choice (and if I start adding the operator, it's no simple UI anymore)
> > 3. That field will soon be easily used via the top-right input box.
> 
> I can't fault simplicity, but I disagree with #2 or #3.  re: #2, the other
> fields default an operator, and either operator "contains" or "is" would
> suffice.  "re:" #3, signature alone doesn't accomplish what's needed, unless
> I misunderstand what you plan. Lastly, the other fields you are accomodating
> need not be so wide.
> 
> However, that said, I'd perhaps be happier with an alternative solution, of
> persistent custom default advanced search fields. That way I don't need to
> add the same fields every time I want to search. Is there a bug report for
> such capability?

Comment 12

[[DEACTIVATED] Adrian Gaudebert]

(In reply to Wayne Mery (:wsmwk) from comment #9)
> I can't fault simplicity, but I disagree with #2 or #3.  re: #2, the other
> fields default an operator, and either operator "contains" or "is" would
> suffice.  "re:" #3, signature alone doesn't accomplish what's needed, unless
> I misunderstand what you plan. Lastly, the other fields you are accomodating
> need not be so wide.

I'm still not sure how to include that in the UI is a clean way. Anyway, this bug is closed, do you mind filing a bug for that specifically, so we can discuss it further there? 

> However, that said, I'd perhaps be happier with an alternative solution, of
> persistent custom default advanced search fields. That way I don't need to
> add the same fields every time I want to search. Is there a bug report for
> such capability?

Nope, but that's a thought I had and I'd be happy if you could file a bug for it! :)