Talk:Structured Data Across Wikimedia/Search Improvements

It is a bad ideea to make black the logos of the sister projects. The colored logos help the reader recognize them at a glance and also familiarize the reader with them (the color inconsistency could be confusing – somewhere you see the colored version, somewhere else you see the black logo).

Hi @NGC 54, thanks for reaching out. Is this happening on a wiki where search improvements have been deployed? I'll send this request to the team, and will let you know as soon as possible. Thanks!

@Sannita (WMF): It happens at ro.wikipedia.org (and probably other wikis), both when logged-in and logged-out; example: https://ro.wikipedia.org/w/index.php?fulltext=1&search=vidr%C4%83&title=Special:C%C4%83utare&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns100=1&ns101=1&ns102=1&ns103=1&ns108=1&ns109=1&ns110=1&ns111=1&ns460=1&ns461=1&ns710=1&ns711=1&ns828=1&ns829=1&ns2300=1&ns2301=1&ns2302=1&ns2303=1.

I see. There has been a request for this with this Phabricator ticket, and it has been done to respect WMF's internal guidelines on logos. You can ask to revert the decision commenting in the Phabricator ticket.

@NGC 54 Maybe you want to see what happens also in this Phabricator ticket, and express your opinion there.

I created a phabricator task about this.

Thank you @Lectrician1 for noticing us. Word of caution: I think we'll be evaluating this in mid-January at this point, because holidays are very near and we're wrapping up work for 2022. I'll keep you posted on this. Thanks again!

It took me a bit to figure out that the wireframe suggests taking the image from Wikidata instead of from Wikipedia. This is likely going to be a very controversial suggestion with many Wikipedians. Instead, of hiding it you should be explicit about it.

I personally, like using Wikidata images. When using Wikidata images I propose that instead of the current placeholder image, small logo or icon (P8972) of the truthy instance of (P31) claim gets shown. This leads for example to https://commons.wikimedia.org/wiki/File:Font_Awesome_5_solid_user.svg being shown as the placeholder for humans.

Given the previous experience with enwiki not liking using Wikidata item descriptions I would propose to use Wikidata items by default but allow Wikipedia to override the images if a particular Wikipedia prefers a different image. If that ability to override the default is build in from the beginning maybe we can prevent conflict from arrising.

When it comes to redirects as in this case, I would want in case the redirect has a sitelink to redirect from Wikidata and that Wikidata item has an image, that it's image gets preferred over the image of the Wikidata item that's linked to the article.

Hey @ChristianKl, if I understood correctly what you are referring to, actually images are not suggested via Wikidata. Images are suggested from Wikimedia Commons through MediaSearch, which also uses Wikidata as a source. Anyway, I guess we can mark more definitely where the images are coming from, to dissipate any doubt.

If you think my answer is not addressing your doubts, please let me know.

The icon for the Wizard of Oz article you see on the left side, comes on the current Wikipedia from the Wikipedia article. In the mockup it shows the image that's linked in Wikidata to the item that's linked to the article.

It seems the text says that the image comes from the "Go bar". Googling Wikimedia Go bar brings up this description as the first time it shows up in context. Can you link to some page that defines what the "Go bar" happens to mean?

How do editors change what image will be shown?

Hey, thanks for your clarifying message. The image in the mockup is just there to show how the function will work, the fact that it's taken from Wikidata it's a coincidence. The image that will be shown will be taken from the article, and will be chosen from the free-licensed medias that are present in the article.

The "Go bar" is another name for the search bar. If you use Vector, when you do a search there is a little thumbnail near the article, that is usually a free-licensed media from the article.

Lastly, editors will not be able to change the image shown, but there's no actual need to do it, since as I said, the image shown will be drawn from the existing ones in the article.

Hope this helps.

I comparison to the current search page, the wireframes suggest removing:

The page "The great and terrible" does not exist. You can create a draft and submit it for review, or you may create the page "The great and terrible" directly, but consider checking the search results below to see whether the topic is already covered.

This seems to me a very bad decision as I'm frequently using that functionality.

Hi @ChristianKl, we don't plan any more to change the message (either local or general) of Special:Search. We planned to do so, but we shelved the idea, because of negative community feedback on that. I hope this answers your question.

https://ro.wikipedia.org/w/index.php?fulltext=1&search=Lepus&title=Special:C%C4%83utare&ns0=1&searchToken=9mrd2tkxmyht9ctnxq3a3rvi: Here I see ro.wiktionary.org.

https://en.wikipedia.org/w/index.php?fulltext=1&search=Hare&title=Special:Search&ns0=1: Here I see Word definitions from Wiktionary.

Why?

Hey @NGC 54, sorry for taking this long to answer, but I was really busy in the last days. The difference depends on the fact that English Wikipedia overrides the default conditions to show what they want. An (interface) admin on Romanian Wikipedia can edit https://ro.wikipedia.org/w/index.php?title=MediaWiki:Search-interwiki-custom&action=edit and correct locally the messages, if needed.

Does Image search in-scope or out-of-scope for this project? Because I have issues with specifically image search result, in multiple projects: Commons, Wikipedia, and more recently Wikistories, which get the result from the Commons, albeit with some additional filters. One of them is lack of user participation in the result algorithm, where if the algorithm puts some images at the top but not suitable for the topic, users should be able to do something about them (vote them down for that keyword).

Having said that and wrote this, I guess the same could be implemented to (article) search result and user interaction, where users could vote up or vote down certain result for any given keywords.

• Article thumbnail: OK, but I do have some NSFW reservations, which might be solvable via T306246.
• Namespace tags: Not sure about this one. First of all. What is the tag for main ? Second.. it just feels cluttered... I see the challenge, but I'm not sure this is the right solution.
• Sister search: Sure
• Collapse Advanced search: Hmmm. perhaps this requires some more refinement. "Advanced search" seems rather archaic. Maybe we should rename? And I like for instance the Google method with their "Tools" button which drops down several tools into view. As a matter of fact, I don't think you can even find their "Advanced search" any longer. Lastly. Advanced Search was made by WMDE and I know they put in quite a bit of user research over the course of a year. That should be carefully reviewed before tinkering with this.
• Quick View: Like it. Though I have a bit of concern wrt to how this would function. Would it only show the first result ? Or the result you selected ? does that make picking a search result a two step process ? (click a result to open quickview, click something in quick view to navigate to actual result) ? That would seem less than ideal to me.
• Missing article: Not against it, but wouldn't that conflict with quick view then ?
• Did you mean: Sure

Hello @TheDJ, thanks a lot for your feedback!

We already know about T306246 and someone is already looking at that. Hopefully there will be good news in the future, though I cannot promise anything.

We are also already tweaking the feature in order to make it easier for users to hide the thumbnails, if needed. Also, we decided to take our time to re-evaluate our proposal on namespace tags, and not to proceed with collapsing advanced search.

Thank you also for your reply on QuickView. To answer your question, you would see a quick preview of the article you select, by clicking on the snippet, but you will be also able to go straight to the article as you would usually do. No two-step process (that would be indeed not ideal).

There should be a way to make easier to search categories and portals directly from the search widget, as they are relevant to the readers, too. Also, I like phab:T301812.

Hi, let me share some thoughts on the presented mockups:

• Article thumbnail: ok, but may be disturbing for experienced users that use the search for scanning the article text for syntax mistakes using insource and regexp search etc. As long as the thumbs are hideable by user css, it could be fine.
• Namespace tags: Please no, makes copying from the search results harder and breaks consistency. In the normal page title there are also no namespace tags, links are not displayed with namespace tags, ... Making it easier to distinguish between various page types may be somehow a global goal for MediaWiki, but I don't see why this should be forced only in the search results.
• Rearrange the sister search section: ok
• Collapse advance search: Please no. The advanced search is already collapsed, collapsing the collapsing switch again frees up just ~30px with almost no impact on the amount of search results shown as you can already see in the mockups. In expanded mode, it even takes more space as there is an additional collapsing toggle. It's unnecessary extra clicks and workflow interruption.
• Introduce a quick-view panel, Re-style metadata, New location for “create missing article”, Change the color of the “did you know” suggestion: ok

Hey @Hgzh, thank you very much for your feedback. I'll report your suggestions to the dev team right away!

Hello @Hgzh, I got a couple of questions for you from the dev team:

1. can you please explain what do you mean with "makes copying from the search results harder and breaks consistency" (re: namespace tags)? Our developers would like to know in particular what parts of the results are being copied and for what purposes.
2. can you please explain what do you mean with "using insource and regexp search etc." (re: article thumbnails)? This wasn't exactly clear as a use case, and our developers would like to know more.

This might be interesting to know for the development of this particular feature. Thanks a lot for your feedback, it is really useful!

Hi @Sannita (WMF), with copying I mean copying the page title of a search result to the clipboard for using it as a wikilink somewhere else, e.g. in discussions or on a project page. I assume that the namespace tags would break that. I hope that makes my concern more clear.

@Hgzh Thanks! I edited the message with another question coming from the devs, can you please look at it too? Thanks a lot!

When using the regexp search, I want to focus on mistakes etc. in the wikitext, the article that contains the wikitext is not relevant in this case (see :de:Benutzer:Hgzh/Kleinigkeiten for some regexp searches I perform every now and then). Then the image thumbnails would be distracting from my actual goal to scan the search result's wikitext.

8b is better than 8a. The computer cannot know what does the user meant. Also, please resolve minor issues, like the brackets [[ shown here: https://ro.wikipedia.org/w/index.php?title=Special:C%C4%83utare&limit=500&offset=500&ns0=1&search=r%C3%A2s.

Thank you for your feedback @NGC 54! I already reported your feedback to the dev team, and hopefully will get back at you soon for the minor issues.

And due to Wikidata, the search results sometimes show [*] (for example, până la moarte[*]​ Părinți Apollonius of Tarsus[*] at https://ro.wikipedia.org/w/index.php?title=Special:C%C4%83utare&limit=500&offset=500&ns0=1&search=r%C3%A2s).

Hey @NGC 54, as far as I can understand, it seems that the problem in visualising the data comes from the module you use for biographies. We don't know exactly how the module can be fixed, unfortunately, because no one on the team has experience with that module. One possibility could be to edit the module so that it doesn't get included in search results, but it should be a decision that the community should take, not us.