Extension talk:AdvancedSearch

Jump to navigation Jump to search

About this board

Discussion page for technical answers around the Extension AdvancedSearch.

Suggestion: Add ascending order (first to last) as sortable options

3
Summary by 197.235.204.181
197.235.68.39 (talkcontribs)

As a user, I'd like to be able to sort search results by last edited dates by ascending order.

As a user, I'd like to be able to sort page creation dates by ascending order, so that I can read the most recent pages about a topic.

As a user, I'd like to be able to sort page creation dates by ascending order, so that I can view the recent files / images (from the file namespace) matching my interests.


Christoph Jauera (WMDE) (talkcontribs)

Hey and thanks for your question! If you uses the AdvancedSearch interface you already can set the sort order as described. Just chose "Edit date - current on top" or "Creation date - current on top" in the "Sorting order" drop-down in the expanded interface.

197.235.59.131 (talkcontribs)

Well, the current sort is based on last to first, compare descending edits (starting from 13 August 2019 -> 1 October 2012) - www.mediawiki.org/w/index.php?title=Special:Search/monkey&sort=last_edit_desc while www.mediawiki.org/w/index.php?title=Special:Search/monkey&sort=last_edit_asc shows results in the ascending direction (from 12 October 2012 to 13 August 2019 ).

The same applies to creation date. So if the current dropdown options are to be followed, it would need two extra items namely "Edit date - current at bottom" or "Creation date - current at bottom", or something like that.

Reply to "Suggestion: Add ascending order (first to last) as sortable options"

Suggestion: Consider adding preset file dimensions (width and height)

2
Summary by Christoph Jauera (WMDE)
197.235.52.125 (talkcontribs)

As a user, I'd like to quickly search for images of certain sizes to add to a page or use externally.

Proposed solution

  1. Add standard preset options of dimensions, e.g.:
    1. large: >= 1024 x 724
    2. medium : between 1024 x 724 and 640 x 480
    3. small: < 640 x 480

This would make it easier for the average person who may not even know about dimensions to search for files. For example, someone just wants a random cat image to add as a background to their devices like mobile, desktop, etc.

Christoph Jauera (WMDE) (talkcontribs)
Reply to "Suggestion: Consider adding preset file dimensions (width and height)"

Suggestion: Implement ability to search for files by size

2
Summary by Christoph Jauera (WMDE)
197.235.52.125 (talkcontribs)

As a user, I'd like to search files by size, so that I can find files of certain quality or simply a sample files.


Proposed solution

Implement the filesize filter that applies to all files.

Christoph Jauera (WMDE) (talkcontribs)
Reply to "Suggestion: Implement ability to search for files by size"

Suggestion: Add ability to sort items by alphabetical order

9
Leyo (talkcontribs)

In addition to the three sorting order options (relevance, edit date, creation date) I'd like to propose a forth one: alphabetical order.

Trilotat (talkcontribs)

I second this recommendation.

Michael Schönitzer (WMDE) (talkcontribs)

Thank you for your feedback! AdvancedSearch can only support the search options that the search back-end provides. So unfortunately we can't fulfill this currently. To get alphabetical order supported by the back-end please report your needs and usecase to the Team Wikimedia Search Platform who are developing the back-end.

Leyo (talkcontribs)

To its talk page, even though it is currently still red?

Michael Schönitzer (WMDE) (talkcontribs)
Leyo (talkcontribs)

I am not on IRC. I would prefer to communicate using the talk pages. Otherwise, could you please put forward my suggestion?

197.235.200.232 (talkcontribs)

Alphabetic sort was deliberately deactivated, so it is unlikely it will be enabled for wikimedia wikis. See gerrit.wikimedia.org/r/#/q/I745b2c463681cb68c16b9b18a07f79f3ba392d92 .

Leyo (talkcontribs)

Well, that was in May 2018, i.e. long before the AdvancedSearch extension was activated.

197.235.59.131 (talkcontribs)

Advancedsearch is just a "cute" way of interacting with the search engine, and its backend. If it is not supported by the backend, then this extension can't do anything about it.


Also, you're wrong about the timeline. Advancedsearch has been active longer than that ( 2017) as a beta feature.

Reply to "Suggestion: Add ability to sort items by alphabetical order"

Issue: Sortable search results inconsistency

7
197.235.236.246 (talkcontribs)

Apparently it is now possible to sort search results using this GUI. However it has the following issues:

  • Sort direction- it isn't clear of it is ascending or descending
  • when sorting by creation timestamp - the timestamp shown is last edited date, this makes the results confusing because creation date is expected.
  • cirrus sort options- the label changes to a system message when one uses sort options that cirrus supports but this extension doesn't, e.g. "sort=incoming_links_asc" or last edit ascending.
Michael Schönitzer (WMDE) (talkcontribs)

Hi, Thank you for your feedback. About the first question: the text in the option-field should say that the current edited/created are on top – isn't that the case for you or did you not find that understandable? About the last point: there is no keyword for this feature by the backend, would you want those? If so for what for? If not I probably misunderstood you, could you please explain more?

197.235.74.147 (talkcontribs)

Question 1: It is not clear. Or understandable.


Question 3: it is supported by the api and backend, see sort orders .

197.235.55.190 (talkcontribs)

> About the last point: there is no keyword for this feature by the backend, would you want those?

I realized I didn't answer this question. It is simple, the current Graphical User Interface (AdvancedSearch) only shows the sort order in one direction. It should support both ascending and descending order, as the cirrussearch backend does, compare e.g.:

Note: Currently, for whatever reason creation doesn't work on this wiki. It works elsewhere : Topic:V4egn7g6uoxtxokg

197.235.55.190 (talkcontribs)

It is also pretty simple to add other sort orders considering that it is easy enough to just change the URL manually, so there doesn't seem to be any reason why one would exclude them. Maybe they would be made less prominent to avoid confusing the average reader who may not know what they mean.

Michael Schönitzer (WMDE) (talkcontribs)

One more question: What language do you use the interface in?

197.235.68.39 (talkcontribs)

>One more question: What language do you use the interface in?

English ...

Reply to "Issue: Sortable search results inconsistency"
Trilotat (talkcontribs)

When clicking on the "i" button for information, the Sorting Order, Description says, "Change the sorting order of results. The standard is that most relevant pagest..."


"pagest" should be "pages."


Also, could "title" be an option?

Michael Schönitzer (WMDE) (talkcontribs)

Thanks! I reported it to the developers: T229216

Reply to "typo in the Sorting Order info"
Pretor~nowiki (talkcontribs)

Is it possible to remove the namespace pane (force it not to load) and keep the advanced search pane?

Gabriel Birke (WMDE) (talkcontribs)

At the moment there is no setting. It should be relatively simple to implement, maybe you can propose such a setting on Phabricator?

As a workaround for your own installation, you can edit the file modules/ext.advancedSearch.init.js and remove/comment out the lines

$advancedSearch.append( buildNamespacesPaneElement(
   state,
   headerContainer,
   namespacePresets,
   namespaceSelection,
   searchableNamespaces
) );

That will disable the namespaces without ill effects.

Reply to "Remove namespace pane"

Suggestion: Add ability to search for items near me

5
Summary by Thiemo Kreuz (WMDE)
197.218.94.223 (talkcontribs)

Use case:

As a user, I'd like to find items or pages near me (near my coordinates).

Background:

It is often the case that when someone makes a general search they want to find items that relate to them or their location. For example, if one searches for "museum", they may be interested in finding museums closest to them, like this . However, this requires knowledge of cryptic and complicated syntax.

Proposed solution:

When the user clicks a "search items near me" checkbox and then searches, retrieve their location and search or items located near their coordinate:

  1. Determine the user's likely location using the their IP address or request the location using browser or device location (much like Special:Nearby)
  2. Make it possible to override (in a text box or map) the location in case the coordinates are just wrong, using either coordinates or location name
  3. Use Cirrussearch's Geo Search, e.g. "museum nearcoord:37.77666667,-122.39"
Thiemo Kreuz (WMDE) (talkcontribs)

Thanks for the suggestion! This feature exists in various places already. The probably easiest is to visit en:Special:Nearby. A link to this page can be added to one of the messages on top of Special:Search. This is up to the community, and can be done by an administrator. Another possibility is – as you said – the keyword nearcoord:. But this is keyword is not really meant to be memorized and typed manually. Therefor it does not really belong to the AdvancedSearch interface, as one of the goals of this interface is to teach people these keywords. However, the feature exists as a button in all mobile apps. Additionally, the WMF was once running an experiment with a "nearby" button, see Beta Features/Nearby Pages.

197.218.94.223 (talkcontribs)

Special:Nearby, isn't really a good substitute because it is a simple list of pages with no way to filter them, or indeed even sort them in any manner whatsoever. In any case, even if goal is to help people remember the keywords, there's neartitle: as well, and that's simple enough to be memorized, much like "intitle" or potentially even "boost-neartitle:" (favour items near this page). It would probably work exactly like "intitle", heck developers could easily just change the keyword "intitle" to "neartitle" and most of their work would be done.

Also, the argument seems slightly counter intuitive. If something has few cases of being typed, then it is a greater reason to implement an intuitive user interface, Extension:Cirrussearch could theoretically support a simpler "nearby:yes" keyword but there is simply no valid reason why it would ever support that when it can and should be provided by the user interface in the form of coordinates (e.g. "coord:xxx, xxx").

197.218.94.223 (talkcontribs)

Arguably a better interface for neartitle would probably be the same one as "hastemplate". The best interface would probably be a real map search with the ability to click titles to select them, much like how Extension:Kartographer works.


But the latter alternative is probably more work than needed.

Gabriel Birke (WMDE) (talkcontribs)
Reply to "Suggestion: Add ability to search for items near me"

Hide namespace options

2
Summary by Thiemo Kreuz (WMDE)
Pretor~nowiki (talkcontribs)

How can I hide the options for selecting namespaces and only show the advanced options drop-down?

Pretor~nowiki (talkcontribs)

Ok, so I see that it is an ongoing discussion on the namespace-field options.


But I would really like to use the AdvancedSearch extension like it was before; without the namespace-field. On my wiki it's not needed to choose a namespace to search, becouse everything needed to be searched for is in the main namespace (68.000 articles).


So how can I hide/dissable the namespace-field and options and still have the advanced search option?

Reply to "Hide namespace options"
Summary by Thiemo Kreuz (WMDE)
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.