Closed Bug 372841 Opened 17 years ago Closed 16 years ago

Bring back the advanced search options from v2 to Remora

Categories

(addons.mozilla.org Graveyard :: Public Pages, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: philip.chee, Assigned: cpollett)

References

Details

(Keywords: regression, uiwanted)

Attachments

(8 files, 5 obsolete files)

In v2 search, I could select the category, type, application, platform, date, sort order, and number of items returned per page. None of these options are available in Remora. This makes searching for stuff rather painful if not impossible.

Please get this fixed before v3 is (re)launched.
Whiteboard: [blocking‑remora‑launch]
Perhaps I should dup this to Bug 370494 (Allow viewing addons ordered by their rating, popularity etc).
That depends -- while it does similar things, it's not "advanced search". So maybe we should keep this bug, but how about you lower its severity?
Severity: major → normal
Depends on: 370494
Whiteboard: [blocking‑remora‑launch]
Target Milestone: --- → 3.x (triaged)
Target Milestone: 3.x (triaged) → 3.4
Blocks: 347202
No longer depends on: 347202
Target Milestone: 3.4 → 3.4.2
Attached image Advanced Search in V2
Assignee: nobody → cpollett
Assignee: cpollett → madhava
My first take on how we could do the advanced search UI.  Thoughts?

I know the search bar here doesn't look like it does on the actual site -- I'm doing some thinking about rearranging that too, now that we have a search button.  I'll open a separate bug about that -- this advanced search UI could be used either way, though.

The "Advanced" tag is pinned to the outside of the box rather than being text inside it partly because I've also been thinking about making that box not as tall as it is now.
Madhava, this looks good so far.

For Date: I don't think it's clear enough - does that mean date of last update? initial upload date? search for add-ons newer than date? earlier than date? What does the drop down choice include? Last week, last month, last year? Is it a date selector?

We also need a few more important parameters to search on.

- Most noteable is "compatibility range" (see https://addons.mozilla.org/en-US/firefox/pages/appversions for the full list of what AMO supports per app).
- We need a status or a checkbox for: experimental vs. public

I can imagine some other stuff like limit to add-on name vs. description but I think we can hold off on that until we improve the core search. We can add rating later as well.
Basil - OK.  This version basically just reinstated all of the search parameters from the v2 one.  I'll try adding the following:

- something for compatibility range... what is a person trying to do in this case?  See only things for a certain version? a range of versions?  only things newer than a certain version?
- a way to see or not see experimental

as for Date -- you're right, it's not particularly clear :)  What did the old version do?  Also, what _should_ it do?
For Date: I have no idea what the old one did but what I can imagine is wanting to find stuff recently modified/updated, so it would look something like http://www.google.com/advanced_search?hl=en (open up the Date section) and see the dropdown or http://search.yahoo.com/web/advanced?ei=UTF-8 (See the Updated field). We should clarify that this would include "New" add-ons that have been added since that time period. (so, choosing say Date="Last 7 days" means that you get all new add-ons newly uploaded within the last 7 days and those modified as well). If we decide to offer a "new" vs updated field, then the behavior needs to be different than described above

For Compat Range: First, this has to be dynamic and based on the App selected - that's why I pasted in the appversions link in comment 7. What typically people will want to do is either:

1) select a specific version of Firefox
   - only search those compatible with my specific version, e.g. I have Fx 2.0.0.14 so I only want those compatible with that. Note that most add-ons mark compatibility as 2.0.0.* and not specific versions, so there may need to be some intelligence here
   - I have Fx 2 and I want to see those compatible with Fx 3 as I consider an upgrade)

2) select a range
   - I'm on an early release of Firefox 3, I want to see the add-ons that are compatible between Fx 3.0a1 and Fx 3.0b5. This is especially useful with the whole "pre" shenanigans.
Hi madhava,

Is there any way you can make the magnifying glass look more like a button? Say by
raising it a bit (more 3d)? As it is, I wonder if we'd still get complaints that
people wouldn't know what to click to search. I like the UI for the advanced features you have above. Somehow though the up/down arrows on the default number of items per page (10) looks narrower than all the other up/down arrows.
(In reply to comment #10)

> Is there any way you can make the magnifying glass look more like a button? 

Yup.  That one was just a quick stand-in - I should have said.  I'll do a new version.
Assignee: madhava → cpollett
Attached image button possibility (obsolete) —
on the subject of the button, how about this?

an alternative would be the "next" button we use in the image viewer.
after mocking up a version of the button (last comment) in context, I started to wonder if this other layout might not be better (the "search" label, if it gets long in other languages, could really start to eat into our input space)
Here's my revised version
okay, unless there are any objections, I will try to code this. 

Let me just comment that on IRC it was determined that:

(1) Last updated box will have values:
"Any time," "Past day," "Past week," "Past month," "Past 3 months" "Past 6 months" and "Past year"

(2) Type: is addon type
Attached image minor layout adjustment
a minor layout alternative based on some comments I just noticed in IRC.  Either this or the previous works for me.
Target Milestone: 3.4.2 → 3.4.3
Hey Madhava,

Could you get me two transparent background versions of the button. push-down as well as released?
Thanks,
Chris
Attached image normal and depressed button states (obsolete) —
try these out
Attachment #320064 - Attachment is obsolete: true
revised.  I had to recreate the button because I didn't have the orginal vector version.  If this looks odd, we'll have to get one from Craig.
Attachment #321848 - Attachment is obsolete: true
okay, what are the sort-order people want?
We want at least the choices of sort orders that we had before.  This is what we had before March 2007, that was supposed to be improved, and instead was removed.

On the advanced search you had been able to select.
 
Category:  {*Any* | bookmarks | Developer Tools,...,Tabbed Browsing, ...}
Type:  {*Extensions* | Themes}
App:  {*Firefox* | Mozilla | Seabird | Thunderbird}
Platform:  {Any, All, BSD, Linus, MACOSX, Solaris, *Windows*}
Date:  {*Any* | Today | This Week | This Month | This Year}
Sort by:  {Newest | *Name* | Rating | Popularity }
Per page:  {10 | 25 | *50*}    <== and that stuck for simple searches 
                                   and I wanted say 200

Those marked within the asterisks are what I chose and then created a keyword shortcut so I could use the AMO advanced search from my location bar, or as a search engine.  (like with "Add to Search Bar" extension)  The implication is that we were using it regardless of what you see for access to the advanced search page.

In addition I would want control over verbosity of results
I always want to see  name, author, size, date changed, rating, download frequency,  version range, [{more in, only in} sandbox ,] description

Now that you have a sandbox,  I want the ability to include the sandbox without being logged in.   


I would like control over long/short description, 

What I wanted to also be able to pull in was the version range, none of this we know what version you are stuff now. 

Newest is not really defined, does that mean newest to AMO, or is it latest update.   So want that choice as well within sort or at least documented.

The only reason the advanced search was not real popular is because you had to go through a search before you had a choice and you could not bring up that page directly (though one could install as a search engine or install as a keyword shortcut).   The promise to improve the advanced search at addons was a hollow promise as it was removed March 2007.

Provide documentation. 

Obviously there are other things than could be chosen from hidden fields, but I for one do not know what is in hidden fields for addons.

Ideally, the search results should be guided by the same type of algorithm that we use for basic (non-advanced) search - see https://bugzilla.mozilla.org/show_bug.cgi?id=400986#c8 for some suggestions on changing the algo.

What algo/order does the current basic search use to display results? (What ever it is, we can likely stick with that)
I was mainly looking for this:
Sort by:  {Newest | *Name* | Rating | Popularity }

I think I can re-implement that. I will implement Newest as newest to AMO.
The search back-end needs a rewrite to get advance search back and I will add a link that explains how the query string api works. 
"Newest to AMO": Seems every March  the extensions start over again, fortunately not their numbering system. 

I expect these allowed multiple selections, but not sure
   App:  {*Firefox* | Mozilla | Seabird | Thunderbird}
and how times change,  now would be
   App:  {Firefox | SeaMonkey | Sunbird | Thunderbird }

I am seeing questions about what extensions can be be  run in  Thunderbird, or Firefox,  or both.   I notice that AMO  no longer shows symbols showing which applications an extension or theme  will work on.  Although that should be on the resulting listing,  it certainly affects the search and interpreting the results. 
 
Implementing advanced search involved coding two main things: the UI and the database interaction.

The UI involves the opening closing gadget for advanced search as well as the new arrow for the search button. The gadget was coded to work in both for both the Javascript (JS) and non-JS setting. It also renders correctly for right-to-left languages. I also tested that opening and closing still work after doing a search. If an advanced search is done the gadget remains open on the search results page, the values of selection gadgets for the search should retain their values. The new search element renders best in Firefox and Safari. In Opera and IE some of the rounding of corners is not done -- this is true of other elements on the page as well, so I assumed this was okay for now.

Since the search element appears on almost every page any component it relies on has to be specified in the corresponding controller or warnings will be generated. One new component I added was Pagination to get the built-in values for the different pagination numbers, so I had to test each possible controller which might use search to make make sure this component was present. In the process of doing this I also fixed a bug that if you gave a blank search to AMO it would generate a warning (if the error reporting is set, to not render warning, you would not see this).

Besides PerPage, the version range, addon type, and platform gadgets for advanced search are similarly populated by values from the database but do not involve using new components. Application could have been populated from the database, but instead was populated by the same list as used for other applications. This means that one cannot do a search for Mozilla applications (of which there were still a couple in the DB). My reasoning on this was that when you do a search on the Firefox page for Thunderbird extensions, the search results page looks somewhat confusing if its still displays the Firefox logo at the top. So instead, I redirect to the Thunderbird application page search result. Thus, you get a nice Thunderbird at the top of the page. Since Mozilla didn't correspond to an other application this would not work for this case.

The version ranges dynamically correspond to the application chosen. These are by default set to the lowest and highest versions for that application. This could not be done is JS-less case, so for that case rather than have selection gadgets I let the user enter version numbers in a text field. To do the dynamic switching of version numbers means sending all the versions to the client, making the page size larger. I do this in an JS array and try to minimize the performance penalty, but since the search element appears on every page one should be aware this will make every page larger (maybe ~2-4k). I am not sure if it would be better or worse to rewrite this using AJAX at some point.

The data sent from the search element for normal search will be the same as from before my patch; of course for advance search more form data is sent.

For the back end to advanced search, the AMO search controller and search component had to be extended a fair bit, since the extant code was only geared to basic search. I tried to ensure that search results from basic search remained unchanged (same query). This means the SQL for some advanced search queries is less elegant than it could be.

I also had to make some design decisions not spec'd out above:

(1) In calculating which addons to display I restrict to addons which have an addon version which have a minimum application version between the low and high value selected.

(2) The category value selected from basic search is still used; however, if this conflicts with the addon type selected, I let the addon type selected over-ride the category value.

(3) A platform search restricts to Addon's labeled ALL or selected platform. An "ALL" search restricts to addon's labeled ALL (this can probably be changed to something more inclusive using more code  later).

(4) The Last Update select chooses based on most recent addon version creation date.

(5) There is more than one orderby clause being used in the SQL so the sort by gadget does roughly what -- but not entirely what -- one would expect. For example, one orderby clause that is always applied is to order public before non-public addon's. If someone has chosen a sort-order I give the sort-order chosen higher precedence than this. Here is what the sort orders do roughly
Newest -- sorts by most recent addon version
Name -- this is actually tricky in terms of results because of l10n stuff, but should roughly sort by alphabetic name.
Rating -- sorts by average rating
Popularity -- sorts by average weekly downloads.
Attachment #322557 - Flags: review?(laura)
A little thing I noticed: When you click the "advanced" button, you are actually taken to yourcurrenturl+#, pretty sure you can avoid this by putting "return false" into the link's onclick attribute.

Regarding add-on types you should probably restrict it to extension types that are valid for the currently chosen app (there are no search engines for Sunbird, for example). Also, I don't think we currently have extension language packs available anywhere. At last, Plugins are currently a static page, so searches for them will turn up empty, so you might as well remove that choice in order not to confuse people.

Apart from that, I played with it a little and it seems to work quite well. Nicely done, Chris! I like how it changes to the right APP subpage depending on what you choose in your search.
> Since Mozilla
> didn't correspond to an other application this would not work for this case

I'm not sure what "Mozilla Application" means in this context but the old Mozilla Suite corresponds to SeaMonkey these days and both versions of the Suite didn't do any extension version checking (at least prior to SeaMonkey 2.0a) so most Suite extensions can install in SeaMonkey
This fixes the # in the URL and also deletes the plugins and language packs from the extension list. I would like to keep the extension list a select for the JS-less case and this would be somewhat awkward (doable but ugly) to do if we start being to clever about per application extension lists. I suggest that be spawned off as a separate bug.
Attachment #322557 - Attachment is obsolete: true
Attachment #322668 - Flags: review?(laura)
Attachment #322557 - Flags: review?(laura)
Attached patch fresher patch (obsolete) — Splinter Review
Attachment #322668 - Attachment is obsolete: true
Attachment #323122 - Flags: review?(laura)
Attachment #322668 - Flags: review?(laura)
Attachment #323122 - Attachment is obsolete: true
Attachment #323127 - Flags: review?(laura)
Attachment #323122 - Flags: review?(laura)
Attachment #323127 - Flags: review?(laura) → review+
Checked into r14452
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Keywords: push-needed
Blocks: 419057
Reopening since we backed this out in bug due 436975 to bug 437000.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #32)
> Reopening since we backed this out in bug due 436975 to bug 437000.

Typing is hard; backed it in bug 436975, due to bug 437000.
This patch brings back the views that were backed out because of the earlier bugs mentioned. (The problem was actually in the backend not the views).
Attachment #323619 - Flags: review?(clouserw)
Advanced Search after all the above operations can be seen here as well:

http://peano.mynetwork.org/mozilla/Bug372841p/site/en-US/firefox/
Chris, I think I figured out what's bothering me about the version number range. I think we want to have some "Any" entries there for both minVersion and maxVersion that way you don't feel like you need to absolutely be sure of the edge ranges that you are searching for.

Also, on peano, you should use the admin console to add "3.0" and "3.0.*" as acceptable versions (see https://addons.mozilla.org/en-US/firefox/pages/appversions)
Sorry, forgot to mention, so when an Fx2 user comes in their default range can be "Any" to "2.0.0.*" and an Fx3 user's default range is "Any to "3.0.*". Does that make sense?
Target Milestone: 3.4.3 → 3.4.4
(In reply to comment #36)
Certainly agree on adding "ANY" to both low and high version, shouldn't the
acceptable versions be automatically included, and if so why is 3.0, and 3.0.* in the acceptable versions (https://addons.mozilla.org/en-US/firefox/pages/appversions) but not in the test.

Would suggest adding a link for "Help" into the drop-down of the Advanced search for documentation, and  that help would include  Categories on the left, the simple search, and the advanced search features.   How to make options stick, if possible (like "Hits per page", &pp=100).  Along with syntax of the search in use  (AND, OR, +, -, hyphens etc  if applicable) because I know Google pretty well but have no idea on what to use for AMO and SUMO because of the lack of documentation.  


 


Comment on attachment 323619 [details] [diff] [review]
patch to bring back views now that 437000 has been fixed

The suggestions since this patch was uploaded are all good, but r+ on the main patch anyway.  Also, "MacOSX" should be "Mac OS X" and "Language Pack (Application)" is confusing, but good for now.
Attachment #323619 - Flags: review?(clouserw) → review+
okay. I checked this into r15186. I agree with the comments 36-38 above. Once this lands we could spin those into a separate bug to improve advance search. 
Status: REOPENED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → FIXED
This is looking pretty good; I did notice a couple things, though (the latter of which is fixed, according to Chris, over in bug 400986):

[1] Found bug 438508, for which Chris thinks he has a fix
[2] A flat (i.e. non-Advanced search) for BlueOrganizer yields its add-ons details page for Thunderbird, when it shouldn't (it doesn't on production): https://preview.addons.mozilla.org/en-US/thunderbird/search?q=blueorganizer&cat=all
I'm verifying this as FIXED, since those other two bugs are already spun-off.
Status: RESOLVED → VERIFIED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.