Page MenuHomePhabricator

Implement haswbstatement:P<depicts>=Q<your term> autocomplete suggestions
Closed, ResolvedPublic

Description

We have this:
There's a wealth of media with depicts statements describing what's in the image.
It's even possible to search them, provided you know the syntax (haswbstatement:P1=Q1) and the ids of the thing you're searching for.
But most people - especially casual visitors - don't know about this at all, and even those who do need to look up ids.

We want this:
It would be pretty neat if the search autocomplete also suggested items, which would then take you to the relevant haswbstatement:P1=Q1 result page.
It would make searching for media by their content ("depicts statement") a lot more convenient.

Acceptance Criteria:

  • Search autocomplete suggests items, which will take you to the relevant haswbstatement:P1=Q1 result page
  • It is possible to turn this off for those who just aren't interested in any of this (user preference?)

Event Timeline

Change 540579 had a related patch set uploaded (by Matthias Mullie; owner: Matthias Mullie):
[mediawiki/extensions/WikibaseMediaInfo@master] Add haswbstatement search suggestions for default statement(s)

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

So... @Ramsey-WMF/@PDrouin-WMF: here's a few screenshots of how I've implemented this thus far.
Let me know if we need to change things, or if this is ok as-is & we can move on with code review.

This is a pretty simple thing that would simply inject Wikidata items into the main search autosuggest thingy, at the top of every page.
The idea is that clicking one of these results takes you directly to the search results page with haswbstatement:P180=Q???, so that people don't have to memorize this syntax, or look up ids.
So one would simply search for cat, click house cat under these depicts results, and be taken to the search results page for all files with depicts=cat.

results.jpg (1×844 px, 585 KB)

I've added a subtle x that would let users get rid of these suggestions if they don't want them.
Clicking it will open this confirmation prompt:

confirm.png (346×674 px, 35 KB)

When confirmed, it'll update their preferences to disable this feature.
They can always re-enable it later on via Special:Preferences, though:

preferences.png (394×1 px, 90 KB)

I like this a lot!

Three things:

  • We should add an information icon next to depicts in the autosuggest dropdown to give a little more information about what this does
    • Something like "These search terms show results related to an item or concept."
    • Would be good to link "depicting" to this https://commons.wikimedia.org/wiki/Commons:Depicts, which probably needs updating with an explanation about what the concept of depicts is, and that you will be able to search for it without using a complicated search syntax (@Keegan should know about this, maybe there is someone he can ask to head up?)
  • In the confirmation prompt, we should add text indicating that this search feature can be added back in Preferences
    • Something like "Are you sure you want to remove autocomplete suggestions based on structured data? (This setting can be changed in Preferences.)"
  • In Preferences, we should link the phrase "structured data" to an informational page
    • Something like a community-written informational page, either about structured data on Commons or the depicts page, that way people can find more information about what this means.

That copy change in the confirmation dialog is a great idea, I'll go make that change.


Link in preferences: can do, but I'll wait for the link as that'll determine how to go about it.
If it's a generic link (about the project), I can add it in the default message.
If it's a specific link (about "depicts", or how SDC is used specifically on Commons), we may want to ship with the current message & override it only on Commons.


I won't add a link to the preferences page just yet, but I can override that message (with a link) on Commons once this is deployed (since the link likely won't be relevant on non-Commons wikis)

As for the information icon:

Due to how this hooks into the suggestions, any click inside that box will cause the suggestions to go away.
That's ok for clicking the actual things (you intend to navigate away to the results) or close (you want the thing to disappear anyway), but might not be ideal for something like an information icon/button. Maybe we could have a tooltip that appears on hover instead of an icon that needs to be clicked?

However! Any depicts-specific or wiki-specific things (descriptions, links) is also quite tricky, because we have this thing on multiple wikis, in multiple different configurations and hard-coding things for a 'depicts/production commons' configuration is not ideal (not impossible, just "let's make sure we *really* need this")

I'm also slightly worried about polluting this thing too much - adding more links and icons/buttons is only going to distract and make it more intimidating/complex, IMO (and "These search terms show results related to an item or concept" only confuses me even more :p)

So in short:

  • do we really need depicts/commons-specific information at all? and if we do need more info - can it be as generic as possible (e.g. not mention "depict", but "structured data") while still being informative & useful?
  • if we do, how about stuffing the info in a standard tooltip rather than icons/links?

However! Any depicts-specific or wiki-specific things (descriptions, links) is also quite tricky, because we have this thing on multiple wikis, in multiple different configurations and hard-coding things for a 'depicts/production commons' configuration is not ideal (not impossible, just "let's make sure we *really* need this")

What other wikis have structured data enabled? 😃

What other wikis have structured data enabled? 😃

Well, there's currently at least federated-commons (labs), betacommons, test-commons, production commons and everyone's local setups. Theoretically also 3rd parties.
And other projects may build on (parts of) this eventually.

Referencing "structured data" from within this project is not an issue, though. Making things specific to "depicts" is.
Hardcoding things for "some page" on "another wiki" that is not even in our control is bound to be problematic.
We can't hardcode things like that, but we can come up with ways that won't make it all fall over in other configurations.
But they take time, are often messy workarounds, and make things harder to configure and repurpose.
We've already had multiple depicts-specific assumptions to work around when we got to other statements & datatypes.

So, yes, we can absolutely come up with solutions if we *really* need more depicts-specific text - I just want to point out there's a not significant cost associated with it.

FYI, in above screenshot, the title above those suggestions says "depicts" - that's not hardcoded nor tied to depicts specifically, that's just "the label of the default property". A bit of a hack already, but at least it works in all scenarios and isn't tied to something outside our control.

Patch has been updated:

  • the titles now says "files depicting..." instead of "depicts" (the P180 label)
    • as discussed in meetings, there's sufficient added value to being more descriptive that we'll take the tech debt for making this depicts-specific
    • @PDrouin-WMF: LMK if you want the text to say something different (this can be any text now, can get as specific as it needs to be)
  • the "close" confirmation window now includes "(This setting can be changed in Preferences.)" (with a link to Preferences)
  • I've also included the aliases (if any) that matched the search, to make it more obvious why a certain term was matched (in exactly the same way it's already being done in other Wikidata/MediaInfo entity autocompletes)
    • results now look like this: "label (alias) description..." when the search term matches an item's alias
    • E.g. "Air China (CA) flag carrier of the People's Republic..." when searching for "ca"
  • copy on Preferences page has not yet been updated to include a link to Structured data/depicts documentation (what page should it link to?)
    • we can change this later, will be a Commons-specific override anyway

I believe the patch is now good to go - LMK if we want further copy tweaks (maybe for "files depicting..."?), but we can easily change these later on.

Last question: how do we want to roll this out? Default opt-in, or default opt-out?
I'm in favor of enabling by default, given how straightforward it is to disable, and how most casual users would not even know how to enable (and anons wouldn't even be able to, given they have no preferences)

Opt-out should be fine; autocomplete is an expected standard in search behavior these days on-wiki.

Change 540579 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Add haswbstatement search suggestions for default statement(s)

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

Works on desktop, but not present on mobile. Let's chat about this on Dec.16

This works. I'll make a new ticket to explore enabling it on mobile.