Closed Bug 396739 Opened 17 years ago Closed 17 years ago

Implement search results page (DES-4)

Categories

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

Product:
addons.mozilla.org Graveyard
Component:
Public Pages
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: baz, Assigned: wenzel)

References

(
URL
)

Details

As specified in the AMO v3.2 PRD (Update:RequirementsV32) and the mockups (http://wiki.mozilla.org/Update:Remora_UI_Review/Mockups/Home_Page/2007-09-12_revisions/)
Blocks: 339162
Assignee: nobody → morgamic
The search results page and the category list page (http://mozilla.focalcurve.com/categorylist.html ) share a similar element, the "drop down" list for the number of add-ons to show.

The current mocks show only 5, 10 and 20. We need to expand this list to include: 5,10,20,50,All.

Thanks.
(In reply to comment #1)
> The current mocks show only 5, 10 and 20. We need to expand this list to
> include: 5,10,20,50,All.

And which one do you think should default? I'd vote for 10.
Sounds right to me. Default=10
I don't think "All" is a good idea; Depending on how big the result set is, that'd be a lot of data on one page (the API, however, should maybe offer this feature).
Frederic, the results page could indeed be huge but that's user's choice. I can't find the bug right now, but someone argued that once you perform a search, it's often faster to navigate the results and enter additional terms by using Find-As-You-Type.
(In reply to comment #5)
> Frederic, the results page could indeed be huge but that's user's choice.

I am not sure I agree on this: getting arbitrarily large result sets back is not a user's choice. I do see a reason for a reasonably big results page (50 items, for example). But making the search page run into the memory limit by picking a smart query with lots of results is not something I'd like to see.
Did we resolve this? Fred, if you believe that have an "All" choice would jeopardize the server, then let's go with 100 as the max.
Fred, we need your awesomeness -- can you pick this up skinning the search results page once I finish the review for the install button? :)

Skin is here:
http://mozilla.focalcurve.com/searchresults.html
Assignee: morgamic → fwenzel
(In reply to comment #1)
> The search results page and the category list page
> (http://mozilla.focalcurve.com/categorylist.html ) share a similar element, the
> "drop down" list for the number of add-ons to show.

Actually, when I did the search page redesign I noticed that the search results page does not have this dropdown:
http://mozilla.focalcurve.com/searchresults.html

Is that a mistake and do we need to add anything there?
Status: NEW → ASSIGNED
Just logging a couple issues I noticed in my pre-fixed testing :-)

stephend: wenzel: we're missing the small icons on https://remora-reskin.stage.mozilla.com/en-US/firefox/search?status=4&q=foxytunes&cat=all
stephend: wenzel: also, "no results found" is not centered on https://remora-reskin.stage.mozilla.com/en-US/firefox/search?status=4&q=&cat=all
(In reply to comment #10)
> stephend: wenzel: we're missing the small icons on
> https://remora-reskin.stage.mozilla.com/en-US/firefox/search?status=4&q=foxytunes&cat=all

I just fixed this: SVN r9824.

> stephend: wenzel: also, "no results found" is not centered on
> https://remora-reskin.stage.mozilla.com/en-US/firefox/search?status=4&q=&cat=all

I have asked madhava about this and will commit a fix as soon as he gets back to me.

I have fixed this too and added (en-US only) l10n strings that will hopefully be picked up by gettext soon. Marking this fixed for now; please let me know if additional issues arise.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
I'll find you on irc, Fred, and try to relay as many early issues as I can, from what I've found thus far.

Here are just a smattering:

[1] Load https://remora-reskin.stage.mozilla.com/en-US/firefox/search?status=4&q=%2525&cat=all and click on the "2" or the "NEXT >" link.  I think it's because the original query to get to this URL is "%25" (without quotes), which is the encoded "%" character; not sure what that does as an operator or query parameter on our server setup.

There, we go from 13 -> 2188 results :-)

[2] Similarly, try a query for "%22" (again, without the quotes), and then click the "2" or "NEXT >" link; you'll get "No Results Found", presumably because we don't then encode or decode that (never can get those straight) back; the query parameter gets lost, essentially. (Query of %20 yields similar results on "2" or "NEXT >" navigation.


Here, we go from 13 -> 0 results

[3] Although bug 339162 is marked as Resolved FIXED, I still don't see "Install" buttons; it's been too hectic around here lately, so I'm might be missing some heads-up that I read but have since forgotten :-)

[4] FoxyTunes has nothing to do with "Language Tools", but yields results for it when the dropdown filter is set to that or pretty much any of the category filters; probably a pretty big issue.

[5] Still no categories listed; if we're waiting on something to be implemented in order to show it on the search results page, could you note it here?

http://people.mozilla.com/~madhava/files/amo/2007-11-21/#SRP still has them listed, and I don't remember a decision to drop them.

[6] What happened to the number of reviews text/hyperlink?

[7] Can you implement TITLE for the ratings images?  Their filenames all correspond to their rating, so this should be pretty easy to map.  Maybe we should leave that to bug 409520 (or if it's easy and will fix it elsewhere, do it here?)

[8] I can think of a semi edge-case where someone searches with the default (i.e. null) search string, with either the all-inclusive "all add-ons" categories filter, or any of the others, and expects to see, respectively:

a) all add-ons listed, or at least a message telling them to choose a category (we should just run the flat category search for them here, methinks), -or-

b) ditto for each individual category; we should either just do a flat search/listing on the category, or message them to choose a category.

I think we should trigger these messages only for the cases in which the user hasn't entered any text.

Madhava, thoughts about the above?
 
Marco: do you have cycles to test this a bit, pre-whatever Fred lands to address these few issues, and again as we get closer to certification?  If so, here's the URL:

https://remora-reskin.stage.mozilla.com/en-US/firefox

More feedback/question in real-time in IRC, but I'll be busy with the 2.0.0.12 firedrill, so bear with me...Thanks!

(And sorry for the verbosity; you'd think English majors would write in terse prose, but that's only the technical-writing side.)
[9] http://mozilla.focalcurve.com/searchresults.html has the add-on's preview image--if it has one--link to its Detail page.

https://remora-reskin.stage.mozilla.com/en-US/firefox has this implemented, but these search results pages don't (such as https://remora-reskin.stage.mozilla.com/en-US/firefox/search?status=4&q=cats&cat=all)

[10] How should string literals be treated?  Are we case-sensitive, also?

i.e. if I search on "doWnLoAd" (with quotes to denote string literalness), I get different results from "download"

Compare:
a) "dOwNlOaD" - https://remora-reskin.stage.mozilla.com/en-US/firefox/search?status=4&q=dOwNlOaD&cat=all
b) "download" - https://remora-reskin.stage.mozilla.com/en-US/firefox/search?status=4&q=%22download%22&cat=all
I expect those two queries, above, to yield different results, but I really meant to connote that I wouldn't expect the first--as a string literal with a 15-year old n00b's lame typing style--to yield any results.

Also, and I really need to spin these off, I see, is that I also anticipate a difference between "download" and download, wrt results, but I see none thus far.
Okay, let's comment real quick (spin-off means we need a new bug for that):

[1]+[2]: spin-off
[3]: will add the install buttons next; I forgot the element
[4]: spin-off; we have to change the algorithm anyway, so it returns experimental add-ons along with public ones.
[5]: this will only be the case on the category listing page, not search results.
[6]: This still needs to be done but we are waiting for bug 408680 that provides the necessary data. spin-off, maybe.
[7]: Spin-off, along with [6] if you like
[8]: Spin-off
[9]: will fix this in a jiffy.
[10]: No, it's all case insensitive. I don't know why the different spelling led to different results. However, since we do binary matching only, many results have the same rating and therefore it's up to the DB to decide the actual order among them. This can only be fixed by a more sophisticated search algorithm, which is bug 400986.
Okay, [3] and [9] are fixed in r9843.
Blocks: 414896
The one thing that sticks out is the fact that the label for the "query" textbox, "Search for add-ons" is present on the homepage, but it vanishes on the search results page. The textbox is no longer labelled on the results page, the combobox is fine on both.
I can't confirm that: On the search results page, the search text box is filled with the current search terms. If you search for an empty string, the default label should reappear when you leave the textbox's focus, provided you have Javascript activated.
I'm verifying this bug, since I made it so darn unwieldy, and will be filing more spin-off bugs, including Marco's comment 18.

Filed:

Bug 414887, bug 414888, bug 414889, and bug 414892 to cover the earlier issues.
Status: RESOLVED → VERIFIED
(In reply to comment #13)
[...]
> [1] Load
> https://remora-reskin.stage.mozilla.com/en-US/firefox/search?status=4&q=%2525&cat=all
[...]

That URL is only accessible to MoCo emplyees and contractors. See https://bugzilla.mozilla.org/show_bug.cgi?id=414887#c1 for details.
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.