Page MenuHomePhabricator

[M] Media Search: Surfacing the result count
Closed, ResolvedPublic

Description

We have had a couple requests for showing the result count in media search. I don't think this is a critical ask but do see its usefulness for gauging the success of your query and what to expect.

I think we have plenty of space to show it to the right off filters on desktop like this:

concept_chips_arrow.jpg (1×1 px, 450 KB)

On mobile web, it's a different story in regards to our real estate. I don't think it's worth creating a whole new line and pushing the results even farther down the page. I would be fine hiding it on mobile.

The only alternative I can think of is placing it at the beginning or end of filter row. The beginning would push filter usage to be more hidden and less used and putting it at the end would be nearly undiscoverable.

Event Timeline

CBogen renamed this task from Media Search: Surfacing the result count to [S] Media Search: Surfacing the result count.Dec 16 2020, 5:24 PM

Blocked by T270381 (which is actual implementation as a result of resolving T263841)

It looks like we can now do this by adding gsrinfo=totalhits to the API requests we make to search, is that correct? This exposes an integer value for the total count in query.searchinfo.totalhits in the response data.

Also, I'm seeing complaints locally (in Vagrant) about Unrecognized parameter: mediasearch – should we also go ahead and remove the &mediasearch=true params?

The mediasearch query param must remain until T262271 is resolved.
The api emits a warning that it's an unrecognized parameter (it's not an actively supported API param), but it is required to allow the mediasearch profile to be used until it becomes enabled by default.
Dropping the query param from the request would result in old (non-mediasearch) search profiles being used. That warning can simply be ignored until we can drop the query param from the request.

The mediasearch query param must remain until T262271 is resolved.
The api emits a warning that it's an unrecognized parameter (it's not an actively supported API param), but it is required to allow the mediasearch profile to be used until it becomes enabled by default.
Dropping the query param from the request would result in old (non-mediasearch) search profiles being used. That warning can simply be ignored until we can drop the query param from the request.

Good to know, thanks!

@mwilliams I have a design question about this feature as well. How do you want things to work on mobile? Placing the hits count in the filters bar to the far right may be hard for users to find on small devices, because the item won't be visible until the user scrolls to the right:

Screen Shot 2021-01-26 at 12.37.59 PM.png (1×786 px, 521 KB)

@egardner On mobile web, I don't think it's worth creating a whole new line and pushing the results even farther down just to add this feature, the top section is already getting pretty tall. Any other strategy would include fixed elements / major rearrangements which also doesn't seem worth it.

It's not ideal but I think hiding this on mobile web is totally fine for now and still solves the pain point for more experienced users on desktop.

Change 658694 had a related patch set uploaded (by Anne Tomasevich; owner: Anne Tomasevich):
[mediawiki/extensions/WikibaseMediaInfo@master] Add the results count

https://gerrit.wikimedia.org/r/658694

Chatted with @AnneT about this and we are going to leave the result count at the end of filters to keep it more similar to desktop, even if it's well hidden and seen infrequently.

egardner renamed this task from [S] Media Search: Surfacing the result count to [M] Media Search: Surfacing the result count.Jan 27 2021, 12:45 AM

Change 658694 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Add the results count

https://gerrit.wikimedia.org/r/658694

Etonkovidova added a subscriber: Etonkovidova.

Checked on commons wmf.30 ( version wmf.29 was skipped). No issues.