Help talk:Extension:AdvancedSearch

Jump to navigation Jump to search

About this board

Feedback and discussion page for the AdvancedSearch feature.

would be nice to support negatives, hastemplate

12
קיפודנחש (talkcontribs)

specifically, for "incategory" and "deepcategory" (i.e., pages _not in_ category X)

also, would be nice to support "hastemplate"

often times, you want to find pages in category X which do not include template Y and vice versa.

as a side: we tried to build the "poor man's version" of this feature in hewiki years ago, and it didn't take. this implementation is way more usable, and i believe many users will find it very helpful. kudos!

peace.

Billinghurst (talkcontribs)

Good points. For the Wikisources where we more broadly utilise namespaces for content, and prescribe various templates for each namespace, this would be most useful.

For instance I was looking to identify pages in the Author: namespace that did not have the s:en:Template:Author, or not categorised into s:en:Category:Authors by alphabetical order. One would think that would be a reasonably easy query, I didn't find it so. [Yes, search is often more designed for reading and finding, not maintenance, that I understand.]

Birgit Müller (WMDE) (talkcontribs)
Birgit Müller (WMDE) (talkcontribs)

Hi @קיפודנחש, thank you very much for the encouraging feedback :-) Regarding your suggestion: Generally, we wanted to provide an interface that is not overloaded to make it easy to use. Especially representing both + and - in a way that the interface stays clean is quite tricky, though it sounds like a use case people would often have. During the beta feature phase, we hope to learn more about the searches people are especially interested in, and we might look into supporting negatives later in the course of the beta phase. Nethertheless, you can still use all specific search options by typing them manually into the search field - I hope that helps for now! Best, Birgit

Colin M (talkcontribs)

Not sure I follow this line of reasoning. The negation operators (-, ! and NOT) already exist and work with most search terms. Help:CirrusSearch says Truth-logic understands - or ! prefixed to a term to invert the usual meaning of the term from "match" to "exclude". and later A filter can have multiple instances, and negated instances. I would argue that making these operators work for deepcat and hastemplate makes search less complex, not more. There's less cognitive overhead in learning "I can put - before a search term to invert it" vs. "I can put - before most search terms to invert them, except for terms using the deepcat, and hastemplate filters".

קיפודנחש (talkcontribs)

thanks. i've been using the manual typing thing for a while now, and will probably continue to do so. one down-side of doing it manually is you miss cool new un-advertised features, like "deepcat", which i wanted for the longest time, and was not aware it was added (was it advertised somewhere, when i wasn't looking?)

peace.

Birgit Müller (WMDE) (talkcontribs)

Hi @קיפודנחש, you're right, that helps a lot to make the existing options more visible. Out of the same reason, we wanted to have info boxes next to the search fields, so that people can learn about the search syntax, and can find the Cirrus search help page for more information. About deepcategory: It is a fairly new keyword and still work in progress, this is why it only got announced via the discovery mailinglist. I think it would make sense to advertise it more broadly once more work is done, or announce it via the AdvancedSearch updates. About the work in progress: Not all category trees in the different wikis are indexed yet. That means that the "pages in these categories" field works for deep category searches on enWP, heWP, deWP ... among others, thereas it works like "incategory" on others. Category trees of more wikis are planned to be indexed soon, so that they can be searched within the given limits in more wikis (a hint about that will be added to the infobox for the keyword on AdvancedSearch with next week's software update). Regarding supporting negatives: I filed phabricator tickets so that we have it on our radar: T194449 and T194448. Thanks again for the suggestion :-)

קיפודנחש (talkcontribs)

one confusing term people often use is "category tree". the categorytree extension is nice and useful, but really, there is nothing in wiki categories that stipulates a tree structure. i'm not talking about the fact that people use the ward "tree" when they really mean DAG ("directional acyclic graph"), but about the fact that it's not even a DAG: there is no reason to assume the category graph is acyclic. directed cycles can, and sometimes do exist in the category directional graph.

peace.

This post was hidden by ToBeFree (history)
Colin M (talkcontribs)

Just to clarify, I want to point out that, contrary to the original post, negation does work for the incategory: filter. For example, on enWP incategory:"Musicals" -incategory:"Lists of musicals" correctly returns the 5 articles which are in category "Musicals" but not in category "Lists of musicals". Not sure if original poster was mistaken about this, or if it's been fixed in the 2 years since.

קיפודנחש (talkcontribs)

Thanks. to clarify: the request was to add the negation (which, as you noted, exists in the search logic itself) to the "advanced-search" feature. the advanced search is a gui, or "menu driven" tool that lets you use dialog boxes and menus to build the search pattern. this interface does not support the "not" modifier.

IOW, click on the magnifying glass icon, and then open the "advance-search" drop down. this request is to add support for "not" logic to this interface.

i think your statement "contrary to the original post", points to misunderstanding of the original post.

(btw: if you read the original request, you'll note that i asked, in addition to the "not" logic, to also add the "hastemplate" magic-search-phrase. note that this part of the request _was_ fulfilled, i believe long time ago).

peace.

Colin M (talkcontribs)

Ah, okay, yeah, in that case I totally misunderstood this post. I encountered an issue where negating a deepcat query (directly via the query syntax) wasn't working, and came across this thread when searching phabricator for related issues. Though after some more experimentation, it seems to be less an issue of "negation isn't working with deepcat" and more "deepcat is generally broken". I filed task T238686 with some examples.

Reply to "would be nice to support negatives, hastemplate"

I like the older Advanced Search feature better

13
George Ho (talkcontribs)

I see that the newer Advanced Search feature will become default to many other wikis on November 28. However, 18,000+ enwiki users enabling the feature is not tremendous as another Beta Feature enabled by 80,000+ enwiki users. Also, the namespace selection window in the newer version is very small, making the scrolling more time-consuming than the older one. Moreover, I can simply type any -word OR something NOT anything, so I guess I'm a bit more advanced user than others probably.

Can the "Hide the improved version of the Advanced Search" be made please? Or what about asking the communities whether to enable the feature by default?

TheDJ (talkcontribs)

You can organise a vote in advance and create a ticket linking to consensus that you dont want it. As always.

George Ho (talkcontribs)

At en-WP's Village Pump, right? Or what about meta-wiki's central forum? Or where else?

Wargo (talkcontribs)

If for one wiki only - locally.

George Ho (talkcontribs)

However, the change would affect most users of all of the local wikis, so I was thinking every wiki.

Wargo (talkcontribs)

If you want to start discussion to affect only on enwiki you can start it on enwiki.

Wargo (talkcontribs)

Yes, communities will kill developers after they notice the change! And what Tech Ambassadors should say then? Will be possible to restore old interface in individual preferences?

Michael Schönitzer (WMDE) (talkcontribs)

Hi George Ho! Thank you for your feedback to this extension. The feature can be very useful for new or not so tech-savvy users, which is something that test with users and feedback has shown repeatedly. But we understand that some more experienced users would prefer the previous interface. That’s why there will be an option to allow every user to disable the feature in their settings. Beside that the new interface also allows to use keywords in the main search-bar as before.

George Ho (talkcontribs)

I see the option "Don’t show the Advanced Search interface". I find it somewhat confusing or misleading; there is the "Advanced" button when the feature is opted-out. Can it be rephrased or something?

Michael Schönitzer (WMDE) (talkcontribs)

We are considering alternative names for the option, but are not sure yet about what it could be called. If you have ideas feel free to share with us.

George Ho (talkcontribs)

How about either "Hide the improved version of the Advanced Search interface" (similar to other "Hide the improved version of..." options) or "Revert back to old version of the Advanced Search interface"?

Michael Schönitzer (WMDE) (talkcontribs)

I created a phabricator-task for that: T213274 – this way it's on our radar.

This post was hidden by Michael Schönitzer (WMDE) (history)
Reply to "I like the older Advanced Search feature better"
YBG (talkcontribs)

it is really hard to select namespaces. Two ideas for improvement:

  1. Put the [x] box on the left hand side of the namespace. That way, if you want to delete a consecutive bunch of namespaces, it is just a matter of clicking multiple times in the same position.
  2. Change the drop-down into a two-column table format so that all of the talk pages are on the same line as their non-talk partner. Then you could scan the list much easier.

Thanks for considering!

Gryllida (talkcontribs)

I like the second idea. It is really helpful.

MichaelSchoenitzer (talkcontribs)

I realised this by adding the following CSS to my common.css:

.mw-advancedSearch-ui-itemMenuOptionWidget {
    display: inline-block;
    width: 46%;
    border-top: none;
    border-bottom: 1px solid #c8ccd1;
}
Michael Schönitzer (WMDE) (talkcontribs)

Thank you for this feedback – it's very valuable for us! We will investigate possible improvements of the namespace-selector. Are there some combinations of namespaces that you use very often?

YBG (talkcontribs)

Can't think of any namespace combos. But I did think of another feature - it would be really nice to be able to exclude subpages, either in all selected namespaces or perhaps on a namespace-by-namespace basis. There may be a way to do it now, but I haven't been able to figure out how.

Michael Schönitzer (WMDE) (talkcontribs)

I think it's currently not possible to exclude subpages. You can propose this to the Wikimedia Search Platform. They build the search, we just build the user-interface.

Reply to "Hard to select namespaces"

Issue:Temporary flash of search text

1
197.218.86.173 (talkcontribs)

Issue

It seems the advancedsearch temporarily stores its search text in the text area and then quickly removes it. This creates a jarring experience.

Steps to reproduce:

  1. Go to https://www.mediawiki.org/w/index.php?search=booo+intitle%3Atest&title=Special%3ASearch&profile=advanced&fulltext=1&advancedSearch-current=%7B%22options%22%3A%7B%22intitle%22%3A%22test%22%7D%2C%22namespaces%22%3A%5B12%2C100%2C102%2C104%2C106%2C0%5D%7D&ns12=1&ns100=1&ns102=1&ns104=1&ns106=1&ns0=1

Actual

Note that just before it loads the advanced search interface it shows "bots intitle:test" temporarily. Then a few seconds later the intitle part is hidden. See, https://imgur.com/a/Jad6qd0 .

Expected

It just shows "bots" within the input box.


Notes

This may yet be another drawback of not implementing a critical interface using html, and building it using javascript. Aside from the "jumpy" nature of the loading, it also feels as if pushes the text from the input box to the "advanced parameters" area.

Reply to "Issue:Temporary flash of search text"
Summary by Michael Schönitzer (WMDE)

Hi, thank you for the proposal. I created a phabricator-task for it, so that we have all proposed improvements in one place: https://phabricator.wikimedia.org/T213260

Wargo (talkcontribs)

Add possibility to clear namespace selection to start selecting from scratch. Current method: click "All" to select all, then again to select none.

Issue: Exact this search does not match exact string

5
197.218.80.183 (talkcontribs)

Issue:

Searching for "exact this text" doesn't find only the exact string

Steps to reproduce:

  1. Search for "brand of popcorn in North America" -> https://en.wikipedia.org/w/index.php?search=%22brand+of+popcorn+in+North+America%22&title=Special%3ASearch&profile=default&fulltext=1
  2. Search it using advanced search : https://en.wikipedia.org/w/index.php?search=brand+of+popcorn+in+North+America&title=Special%3ASearch&profile=advanced&fulltext=1&advancedSearch-current=%7B%22options%22%3A%7B%22phrase%22%3A%22brand+of+popcorn+in+North+America%22%7D%2C%22namespaces%22%3A%5B0%2C6%5D%7D&ns0=1&ns6=1

Expected

Step 2 above matches step 1, e.g. it only finds words that exactly contain "brand of popcorn in North America". Exactly in that order.

Actual

It currently also finds strings like:

Popcorn (popped corn, popcorns or pop-corn) is a variety of corn kernel, which expands and puffs up when heated. A popcorn kernel's strong hull contains

https://en.wikipedia.org/w/index.php?title=Popcorn&oldid=870872258

Proposed solution:

  1. Either make the "exact text" match the string exactly with no further words, e.g. step 1 above;
  2. Or create a separate input box for an "exact match" if it is working as expected.
197.218.80.183 (talkcontribs)

Basically it seems to be doing an OR search, e.g. "brand" OR "of" OR "popcorn" OR "in" OR "North America", which is unexpected.

197.218.80.183 (talkcontribs)

Hmm, just noticed that the tooltip help claims that it must always have quotations marks. This makes no sense whatsoever. If the user has to add quotation marks, then they can just type directly in the main search box, rather than use "advanced search".

Having also tried the suggested syntax, it also doesn't seem remotely sensible, https://en.wikipedia.org/w/index.php?search=%22brand+of+popcorn%22%2C%22in+North+America%22&title=Special:Search&profile=advanced&fulltext=1&advancedSearch-current=%7B%22options%22%3A%7B%22phrase%22%3A%22%5C%22brand+of+popcorn%5C%22%2C%5C%22in+North+America%5C%22%22%7D%2C%22namespaces%22%3A%5B0%2C6%5D%7D&ns0=1&ns6=1 .

It finds the page https://en.wikipedia.org/wiki/Comma, probably because the search string contains a comma.

TheDJ (talkcontribs)

I agree that this seems unintuitive

Michael Schönitzer (WMDE) (talkcontribs)

Hey, thanks to both of you for your input! The usability of this field turned out to be more tricky than one might think. Our tests confirm that while the current version works better than previous attempts it still is not very intuitive. So we are aware that it's still not great yet. There's also a ticket about this.

Reply to "Issue: Exact this search does not match exact string"
اميرة الضلال (talkcontribs)

ان الواجهة الجديدة جميلة جدا

Michael Schönitzer (WMDE) (talkcontribs)

شكرا

Why is the generated query hidden?

4
TJones (WMF) (talkcontribs)

I just tried the extension on English Wikipedia, and after searching, I saw my query flash in the query box for a moment, but then it disappeared. I recently suggested the extension to someone who wants to learn more of the advanced syntax, but didn't realize the constructed query was hidden. Some users would rather type their queries, and could use the extension as a learning tool (and/or to remember a keyword you haven't used in months), but hiding the query makes that harder.

Michael Schönitzer (WMDE) (talkcontribs)

Hi, there should not be any query flashing at all. This probably was an already fixed bug. We considered the behavior you suggested for the same reasons as you did but decided against for technical and UX reasons. We still want to help the users to learn the keywords with our extension. That is why we have the info-icons next to each search option, when hovering the option is explained including how this can be used by keyword.

TJones (WMF) (talkcontribs)

Would it be possible to have a URL parameter or developer setting or some other way to display the generated query? In discussion of exact search it's not at all clear what's happening (though it seems likely to be either "term1" OR "term2" or "term1" "term2"), and seeing the generated query would make it clear what is happening, so we could have a more well-informed discussion about what should be happening, or how it should be described so people interpret it correctly.

Michael Schönitzer (WMDE) (talkcontribs)

Hey, thank you for the proposal. I created a Ticket for this to have it on our list of potential improvements.

Reply to "Why is the generated query hidden?"
Summary by Michael Schönitzer (WMDE)

An option to disable the feature has been added.

Tacsipacsi (talkcontribs)

How can I get rid of this “feature”? When it was in beta, I turned it on, and then turned off within a minute. It may be useful for beginners, but not for power users like me. It takes up half of the screen by showing options and checkboxes I will hardly ever use. It loads for seconds after the full page load (meaning I will click on a completely different link if I’m unlucky enough), because it uses JavaScript for a purpose for which static HTML-based version could be a solution. I will simply not use its fancy tools, because typing the appropriate prefix is much faster, and I don’t want to waste my resources for it.

Stjn (talkcontribs)

Bad loading speed of this tool was raised before without any real resolution from the team working on the tool. It doesn’t matter, though: yet again, Wikimedia Germany ignores any concerns from non-German users and pushes through their wishes without asking other communities.

Igel B TyMaHe (talkcontribs)

Same question. How to turn it off when it will have implemented?

Kyykaarme (talkcontribs)

I can't find a way to turn it off in de-wiki so that's not a good sign. The mass message was sent about 24 hours ago and it was unclear because it just said it will be "default", but so are compact language links and the new recent changes and I don't use those either. Could we please get an answer on if or not this can be turned off by individual users? My home wiki currently has 128 users who are using this in beta and I would like to inform everyone else if there's anything they can do about it after Thursday.

Abiyoyo (talkcontribs)

1. Very slow loading speed. Why use heavy js where simple html form is an obvious option? 2. Selecting namespaces is tricky and time consuming. The old html form with checkboxes was a faster and more convenient way. 3. The idea to give less experienced users a more friendly interface to search syntax is great. But the implementation turned out to be inconvenient. Please give an option to turn this feature off.

Michael Schönitzer (WMDE) (talkcontribs)

Thank you all for your feedback to this extension. The feature can be very useful for new or not so tech-savvy users, which is something that feedback has shown repeatedly. But we understand that some more experienced users would prefer the previous interface. That’s why there will be an option to allow every user to disable the feature in their settings. Beside that the new interface also allows to use keywords in the main search-bar as before.

Hasty deployment process. Hold on

8
Summary by Michael Schönitzer (WMDE)

An option to opt-out does exist in the user preferences.

Abiyoyo (talkcontribs)

I will be especially grateful if the deployment process is revised according to good old Wikipedia principles: "Any changes to the software must be gradual and reversible. We need to make sure that any changes contribute positively to the community, ... in full consultation with the community consensus".

In ru-wiki we had a notice posted only two days before planned deployment without any option to object. It is anything but 'gradual deployment in full community consensus'. Please revise the deployment process to a more friendly to communities, get the feedback before deployment in a sensible manner with an appropriate time to discuss. Please hold on the deployment in ru-wiki (and maybe some other projects) and get the community feedback first.

Mike Novikoff (talkcontribs)

I second that. It is obvious that many users (in ruwiki, at the very least) will be upset about the update, they already are, and would like to opt out. So please don't deploy it yet, it should be discussed and most likely made optional.

TheDJ (talkcontribs)

Users are always upset. It's the single thing you can count on whenever a change is being made. Is there a reason why they can't bear the interface for 7 days while they vote to get it disabled ?

Mike Novikoff (talkcontribs)

Where the voting takes place?

TheDJ (talkcontribs)

Wherever you want, it's your own community.

Michael Schönitzer (WMDE) (talkcontribs)

Thank you for your feedback, we try to work as community centered as possible, doing multiple feedback rounds, user testings and a long beta phase. The extension was a beta feature for about a year, to give everyone the opportunity for feedback before the feature becomes default. We also deployed Advanced Search gradually: First on a handful of wikis to rule out any bigger blockers. Now more wikis will follow.

The feature can be very useful for new or not so tech-savvy users, which is something that feedback has shown repeatedly. But we understand that some more experienced users would prefer the previous interface. That’s why there will be an option to allow every user to disable the feature in their settings.

Mike Novikoff (talkcontribs)

Thank you for good news, it will be much less of a problem then.

Abiyoyo (talkcontribs)

Thank you very much, Michael. An option in the settings is ok for me. There would have been be less questions and bothering if the cross-wiki announce emphasized it. Thank you.