Closed
Bug 796987
Opened 13 years ago
Closed 12 years ago
Change back search results pages to 10 per page
Categories
(support.mozilla.org :: Search, defect, P3)
support.mozilla.org
Search
Tracking
(Not tracked)
RESOLVED
FIXED
2013Q1
People
(Reporter: rrosario, Assigned: willkg)
Details
(Whiteboard: u=user c=search p=1 s=2013.2)
When we were doing bucketed search, we moved changed our search pagination from 10 to 20 because we wanted to show 10 articles at the top. Now that we have unified search, we should switch back to 10 results. This will make the page load faster and will give less options to the user which will hopefully be a positive net result
Assignee | ||
Comment 1•13 years ago
|
||
I definitely agree we should do this at some point in the future, but we shouldn't do it until we feel confident that the top 10 results are solid for some definition/measure of "solid".
Reporter | ||
Comment 2•13 years ago
|
||
Assigning to a sprint so we can discuss it then.
Whiteboard: u=user c=search p=1 → u=user c=search p=1 s=2012.22
Comment 3•13 years ago
|
||
Just to be clear, the goal here is to reduce the page load time, right?
Reporter | ||
Comment 4•13 years ago
|
||
Performance will improve. Also, less is more?
Comment 5•13 years ago
|
||
I think we should go ahead and do this, but also test both assumptions.
Reporter | ||
Comment 6•13 years ago
|
||
(In reply to Kadir Topal [:atopal] from comment #5)
> I think we should go ahead and do this, but also test both assumptions.
I think this should be one of the last things we do. We need to be confident enough in our first 10 results to the point where we feel that showing more doesn't help.
Updated•13 years ago
|
Whiteboard: u=user c=search p=1 s=2012.22 → u=user c=search p=1 s=2012.23
Updated•13 years ago
|
Whiteboard: u=user c=search p=1 s=2012.23 → u=user c=search p=1 s=2012.24
Updated•13 years ago
|
Assignee: nobody → rdalal
Reporter | ||
Comment 7•13 years ago
|
||
I think we may need to hold off on this unless Kadir has a chance to do the CTR analysis before the Holidays?
Flags: needinfo?(a.topal)
Comment 8•13 years ago
|
||
This depends on the CTR data being backfilled for https requests. Either way, we should probably leave this for after the holidays.
Flags: needinfo?(a.topal)
Reporter | ||
Comment 9•13 years ago
|
||
(In reply to Kadir Topal [:atopal] from comment #8)
> This depends on the CTR data being backfilled for https requests. Either
> way, we should probably leave this for after the holidays.
Sounds good to me. Moving to next sprint.
Assignee: rdalal → nobody
Priority: -- → P2
Whiteboard: u=user c=search p=1 s=2012.24 → u=user c=search p=1 s=2013.1
Target Milestone: 2012Q4 → 2013Q1
Comment 10•13 years ago
|
||
Can we possibly have this number of results configurable (e.g. via a GET parameter: &results=20) if this change is being made?
Sometimes I do a search for posts by a specific user if I suspect that some replies need editing or otherwise action needs to be taken.
Also, I like to see as much results as possible when searching (I always set Google results to 100) if a question has been posted before and seeing more results makes it easier to pick out the ones that look promising before continuing to a next page of results.
Having to load more result pages and opening results that appear to be not helpful after all to me takes more time with less results per page.
cor-el
Assignee | ||
Comment 11•13 years ago
|
||
(In reply to Cor vL from comment #10)
> Can we possibly have this number of results configurable (e.g. via a GET
> parameter: &results=20) if this change is being made?
>
> Sometimes I do a search for posts by a specific user if I suspect that some
> replies need editing or otherwise action needs to be taken.
> Also, I like to see as much results as possible when searching (I always set
> Google results to 100) if a question has been posted before and seeing more
> results makes it easier to pick out the ones that look promising before
> continuing to a next page of results.
> Having to load more result pages and opening results that appear to be not
> helpful after all to me takes more time with less results per page.
>
> cor-el
You should write up a new bug for that enhancement request.
Comment 12•13 years ago
|
||
moving to next sprint as the results will only come in during the 2013.1 sprint.
Whiteboard: u=user c=search p=1 s=2013.1 → u=user c=search p=1 s=2013.2
Updated•12 years ago
|
Priority: P2 → P3
Assignee | ||
Comment 13•12 years ago
|
||
I just skimmed the comments and it seems like this bug is waiting on CTR analysis from Kadir before it's ok'd to move ahead.
Has that been done? Is it ok to do this, yet?
Comment 14•12 years ago
|
||
Yes, it was done and the results presented at the last monday meeting. We can go ahead and test this. I'll make sure to monitor the CTR and file a follow up bug if we see a decrease in the CTR.
Assignee | ||
Comment 15•12 years ago
|
||
Assignee | ||
Comment 17•12 years ago
|
||
Assignee | ||
Comment 18•12 years ago
|
||
Someone pushed this to production at some point in the last 12 hours or so.
Anyhow, I verified that production is now showing 10 results per page. Marking this one as FIXED.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•