Open Bug 490549 Opened 15 years ago Updated 12 years ago

Combine QuickSearch and Full-text Search

Categories

(Bugzilla :: Query/Bug List, enhancement, P1)

Product:
Bugzilla
Component:
Query/Bug List
Type:
enhancement

Tracking

()

People

(Reporter: mkanat, Unassigned)

References

Details

There shouldn't be two "simple search" boxes, there should only be one. The quicksearch box should use fulltext to search, and the fulltext box should support the quicksearch syntax.

This may involve simplifying quicksearch. Please forgive me if I remove features that are used by 0.001% of all Bugzilla users. :-)
Priority: -- → P1
Depends on: 490551
Before you do anything, I would like to know what you plan to remove. You have no idea which QS features advanced users are using.
(In reply to comment #1)
> Before you do anything, I would like to know what you plan to remove. You have
> no idea which QS features advanced users are using.

 Well, the "+" operator will have to be removed, because that actually has a meaning for fulltext. If there's a - operator, it will also go away for that same reason. Also, the part that recognizes URLs is kind of strange and just more likely to cause trouble than anything. QS should just always search the URL field or not search it at all. Also, I'll probably pass unknown field values through as normal search terms, with a warning message instead of an error.
I don't see why you need to remove them. The "+" character is removed by QS. It's just here to determine which fields to look at.
(In reply to comment #3)
> I don't see why you need to remove them. The "+" character is removed by QS.
> It's just here to determine which fields to look at.

  Because people want to be able to use "+" as part of their fulltext searches. That is, we don't *want* it to remove +. Also, things like "#" might genuinely appear in a search for terms in a bug-tracker, and the vast majority of people (say, 99.99%) aren't even going to know that it exists and just be confused as to why they can't search for a literal "#1" by just typing "#1". pyrzak's research at both NASA and with his students backs all this up--that's one of the reasons I'm doing this combining of the two search types, too.
I know Jesse is a big QuickSearch user. So CC'ing him to keep him informed (and eventually to get his feedback).
(In reply to comment #5)
> I know Jesse is a big QuickSearch user. So CC'ing him to keep him informed (and
> eventually to get his feedback).

  Okay, but keep in mind that we have actual user data from real research, so the opinions of individuals aren't going to matter as much.
I'm worried that including comments by default will make QuickSearch slower.  I'm even more worried that it will make searches return too many irrelevant results.  In fact, these are the two main problems with "find a specific bug" today.  This change would hurt a lot more often than it would help.

I'm fine with removing the "shortcut for field name" prefixes so that fewer literal searches require quotes.  But the "-" prefix should stay, because it's important for many searches and well known (even Google supports it).
(In reply to comment #7)
> I'm worried that including comments by default will make QuickSearch slower.

  It actually already does search comments by default, and it does it with an incredibly slow substring search.
 
> I'm fine with removing the "shortcut for field name" prefixes so that fewer
> literal searches require quotes.

  Yeah, that's mostly what will go away, most likely.

>  But the "-" prefix should stay, because it's
> important for many searches and well known (even Google supports it).

  Oh, actually, the - and + prefixes don't work right now, they do something magical instead. Combining these two search methods will actually make - and + work in the way that you would think they would.
(In reply to comment #6)
>   Okay, but keep in mind that we have actual user data from real research

user data from real research? You mean what pyrzak did or some other data?
(In reply to comment #9)
> user data from real research? You mean what pyrzak did or some other data?

  What pyrzak did. Combining these is part of a larger project to improve search based on various issues discovered by pyrzak's students and also during pyrzak's research on NASA users.
Blocks: bz-hci2008
So to be clear here is what happened with our users, most of which are not at all familiar with how quicksearch works, or but many of which do understand google's site search capabilities.

Also please note that most of our data is stored in custom fields, not in comments.

Here is basically how it went every time repeatedly, and somewhat embarrassingly.

User does a search for a term in a custom field, in the quick search. Nothing or few things appear.

User says, Oh, I'll click on search and change it. User sees simple search and figures, oh hey, I did this one already, I must go to the advanced search. User goes to the advanced search page, and types in their term in the big text box, they see (it's just for summary) and click search, because none of the other boxes are what they are looking for either. (one user actually used the boolean charts, 1 in 10)

Hey my result didn't appear. I guess your search is broken. We tell users to try the simple search. They find what they are looking for. Everyone feels like an idiot. Yay...

Now this is a bit different because we use lots more fields here and most of the important data is captured in fields. However, the way we store the search criteria, it might as well be comments.

The point is, it is weird that we have 3 searches that result in 3 different search results based on what you type into the "big text box". 

Ideally the quick search is just there all the time, it's a syntax we use, but we simplify it a bit. Simple search just has a few simple fields that users use a lot, it would be super hot if it was admin configurable (admin has 3 slots that they can fill with whatever fields they want). Plus the thunderbird/finder add more terms thing.

The advanced page is the advanced page except instead of that huge box being just for the summery, it's the quick search again, and users can use the advanced page as a page that has a lot more stuff than just the simple search with more terms thingie.

Imagine that a natural progression of how things work that will only narrow your results not give you completely different ones every time! that's the research and changes we did.
Depends on: 503806
Depends on: 518024
Depends on: 518459
We no longer accept new features for Bugzilla 3.6. Retargetting to 3.8.
Target Milestone: Bugzilla 3.6 → Bugzilla 3.8
(In reply to comment #11)
> The advanced page is the advanced page except instead of that huge box being
> just for the summary, it's the quick search again

Oh, I like this idea! :) And the summary box would be moved close to the comment/URL/whiteboard boxes, so that we can still look for strings in the summary only.

And why not also hide the QS box in the header/footer when accessing query.cgi or index.cgi, so that we don't have tons of search boxes around? Or would this be more confusing to users? My feeling is that people may guess that the search box in the header/footer aren't display because it's already in the main body of the page, and so would associate them as all being one same feature.
That is an interesting idea, if we were limiting ourselves to the currently-existing search functionality.

However, my current plan is to leave the Advanced Search exactly like it is (and I can tell you that, at least for me, making the Summary box into a QuickSearch box would be inconvenient), and develop an entirely new Simple Search as part of bug 450301 (which has a UI description in it now).

It's still a possibility to make the "top search box" the same on every page.
Well, re-reading pyrzak's comment, I think it would be OK to make the top box on Advanced also be a QuickSearch. That would give us total and complete consistency. Then we'd just have to add a Summary box to the current free-text fields.
This was mostly completed in 4.0, except that the Simple Search box isn't a Quicksearch box, yet.
Target Milestone: Bugzilla 4.0 → Bugzilla 4.2
Target Milestone: Bugzilla 4.2 → Bugzilla 5.0
We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.
Target Milestone: Bugzilla 4.4 → ---
You need to log in before you can comment on or make changes to this bug.