Change back search results pages to 10 per page

RESOLVED FIXED in 2013Q1

Status

P3
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: rrosario, Assigned: willkg)

Tracking

unspecified
2013Q1

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: u=user c=search p=1 s=2013.2)

(Reporter)

Description

6 years ago
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
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

6 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
Just to be clear, the goal here is to reduce the page load time, right?
(Reporter)

Comment 4

6 years ago
Performance will improve. Also, less is more?
I think we should go ahead and do this, but also test both assumptions.
(Reporter)

Comment 6

6 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

6 years ago
Whiteboard: u=user c=search p=1 s=2012.22 → u=user c=search p=1 s=2012.23

Updated

6 years ago
Whiteboard: u=user c=search p=1 s=2012.23 → u=user c=search p=1 s=2012.24
Assignee: nobody → rdalal
(Reporter)

Comment 7

6 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)
This depends on the CTR data being backfilled for https requests. Either way, we should probably leave this for after the holidays.
Depends on: 823169
Flags: needinfo?(a.topal)
(Reporter)

Comment 9

6 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

6 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
(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.
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

6 years ago
Priority: P2 → P3
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?
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.
Oops--retroactively grabbing this one.
Assignee: nobody → willkg
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
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.