Currently (local time just before 3PM Friday) hanging out at an outdoor table at the cafeteria, one floor below the registration table.

(Around 4PM): In the room where lunch was—lots of free chairs at the moment! Come tell me your search woes!

Got kicked out of the lunch room—but the good news is that snacks and coffee have been delivered and we should be allowed back in there soon.

Thank you for hosting your session at WMHack! If you have any notes or slides please add them to the task and then make sure to close the task when there are no more actions. :)

The results are in!

The best recurring theme was that search is pretty good, which was good to hear—though I was hoping for more ideas about where we could improve it, especially for non-English and non-Wikipedia wikis.

Another recurring theme was that we don’t do a great job letting people know what features are available. I showed one person the intitle keyword and another how to use regexes with insource. Someone else told me they had just learned about regexes with insource a couple of weeks ago. One possible solution suggested is a brief “search tip” displayed on the Special:Search page, with a link to the documentation, like “Did you know you can search just in titles?” with a link to the relevant documentation. Another idea is that the upcoming Advanced Search extension will make a lot of search options more obvious to users.

Other suggestions/complaints:

• Our old friend spelling correction came up, which is on our list of potential NLP projects. The amusing example was barack omaba → barack omaha on enwiki. Sigh.
• Another candidate for “wrong keyboard” correction is QWERTY to AZERTY or vice versa. The differences there are a little more subtle than, say, Russian/American or Hebrew/American keyboard layouts, but it might be doable.
  • Amir also pointed out that Hebrew Wikipedia has a gadget that detects poorly performing completion suggester input (< 10 results) and converts American keyboard input to Hebrew Keyboard input. It’s called Dwim.js—DWIM is a hilarious name!
• Someone suggested that search.wikimedia.org, which is an API endpoint, should do something better than give an error at the top level—offer a search box, roll over to the Wikipedia portal—something useful.
• A UI suggestion for the wikipedia.org portal page is that once someone starts typing in the search box, it should automatically scroll to the top of the screen—otherwise the suggestions show up “below the fold”, especially on small screens.
• We had a request for adding recommended pages to the bottom of desktop article pages for Wikipedia, like we have in the Wikipedia app, to encourage people to fall down the “wikihole”.
  • Obviously if it were configurable, different Wikipedias (or other projects) could enable it if they wanted it.
  • I am disappointed that wikihole is on Urban Dictionary, but not Wiktionary.
• One person noted that ranking on Meta is not very good. There weren’t any specific examples given, but I’m not shocked, since it’s a wiki we don’t pay much attention to from SearchLand.
• Commons—ah, Commons. There were a few Commons-related suggestions:
  • index text-based files, like PDFs, better. I didn’t get anything more specific on that, and a quick test of searching for specific content in a PDF shows that it is found. My guess is that ranking is the problem.
  • A UI suggestion: perhaps the metadata shown with the results is not the most useful. There was some debate over whether image resolution was useful, and last edit date didn’t seem great to those of us discussing it (though someone somewhere surely loves it), but the lack of license information is sorely missed.
  • A related UI suggestion: instead of showing any metadata at all, show much larger images—at least twice as big in each dimension, maybe bigger—and maybe show metadata like resolution and license on mouse over.
  • An interesting ranking suggestion was to have properties of images—not their metadata or descriptions—affect ranking. The claim is that commercial search engines do this by measuring engagement with images and then noting features that predict engagement—like, say, more colorful images get more clicks. This is a bit far afield from our usual search work, but an interesting idea.
• A sophisticated power-user feature request was to be able to specifically search TemplateData by key, particularly in the description field.

brief “search tip” displayed on the Special:Search page, with a link to the documentation

There's the help link. As for popup-like suggestions, well, of course there are trade-offs.

In T189791#4226676, @Nemo_bis wrote:

There's the help link.

That's pretty much what I said! The person who suggested the search tip idea replied, "but almost no one looks at the help for search," which sounds plausible, especially in terms of looking for advanced search keywords when you don't have a specific problem to solve. For me, finding out that regexes are available, for example, let me go looking for problems I hadn't even considered trying to solve before.

I wasn't imagining a pop-up, just a short line of not-too-obtrusive text with the tip and a link, but the details don't matter too much right now. Designing the best way to present the information, what information to display, what user and community options are available (like turning them off) all come after deciding that having any search tips at all is a good idea. I'm leaning toward waiting until the advanced search feature (now in beta everywhere, I believe) comes online. That should point a lot of people toward features and ways of creating queries that they didn't know about. Anyone who wants to pursue search tips before that can open a new ticket and begin those more in-depth discussions.

Someone suggested that search.wikimedia.org, which is an API endpoint, should do something better than give an error at the top level—offer a search box, roll over to the Wikipedia portal—something useful.

This has been added as T195436 .

Thanks, @Gryllida!