Improve Advanced Search form UI to include other "advanced" features
OpenPublic

Assigned To
None
Priority
Normal
Author
Tgr
Subscribers
demon, Schnark, TheDJ and 6 others
Projects
Tokens
"Like" token, awarded by Nemo_bis.
Reference
bz21988
Description

Every popular search interface has an "Advanced Search" page, where the user can make use of those search features which are rarely needed but then very important: title search, expression search, similarity search etc. MediaWiki supports these features and some more, but offers no help to the user to actually find them. If he is lucky, the wiki has a help page on searching which is linked from the search page, and he only has to read three or four pages of text to find out that which would be obvious on the first blink in a well designed form. If he is out of luck (such as in the case of trying to search the English Wikipedia), he will probably find Google (which has an easy to discover advanced search page, with domain restriction options) more useful, which is a bit of a shame.

In other words, the current implementation of advanced search (which is just a namespace selection) sucks horribly. It should have text fields like "search for pages with this words in the title" and "search for this expression", and everything that cannot be easily formulated as an additional text field (such as the * wildcard) should be explained in the search interface in an easily disoverable and understandable way.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=38395

bzimport added a project: MediaWiki-Search.Via ConduitNov 21 2014, 10:49 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz21988.
Tgr created this task.Via LegacyJan 1 2010, 4:52 PM
Unknown Object (User) added a comment.Via ConduitSep 11 2011, 12:29 AM

Search and search functionality are such an important feature to ensure information can be correctly disseminated, we wonder why it is still (1.17, 1.18) not possible in the advanced search screen to have some predefined input boxes that

  • Allow to choose syntax options via dropdown box such as "intitle:", "incategory:", "prefix:" or
  • Allow to initiate OR and AND compound search

An advanced option field is already in existence but only allows to select/un-select namespaces to be searched, defining additional options can surely by implemented through a Mediawiki:AdvancedSearchOption page which stores options available.

Aside storing and handling of data, the second most needed functionality for a wiki is the search. Having only one input field for handling such an important task might solve the need for a majority (handling a simple search term) but certainly is a challenge for more advanced users trying to find what they are looking for.

Any larger website (EBSCO, ProQuest etc.) that handles certain amount of information has advanced search input features. A user can choose to limit the search term not by remembering a specific search syntax but by selecting options that allow a fine grained search functionality.

Extensions like SphinxSearch or Lucene could use those inputs to direct the search and hopefully increase usability for the user and accuracy of the search result.

Spinningspark added a comment.Via ConduitJan 28 2012, 10:55 AM

Wikisource badly needs an "inauthor" search parameter, a standard feature on most document databases. Ability to make efficient searches is so important to knowledge stores that I am in favour of upgrading the importance of this issue from "low". I have moved it to "normal" - hope I am not acting out of turn, imo it should be even higher.

Bawolff added a comment.Via ConduitJan 28 2012, 5:02 PM

(In reply to comment #2)

Wikisource badly needs an "inauthor" search parameter, a standard feature on
most document databases. Ability to make efficient searches is so important to
knowledge stores that I am in favour of upgrading the importance of this issue
from "low". I have moved it to "normal" - hope I am not acting out of turn,
imo it should be even higher.

Note, for requesting an inauthor: search parameter, you should probably open a new bug. This bug is more about making user friendly input boxes on the advanced search page for the search options that already exist. (if you do file a new bug, be sure to be clear on how you define the "author" of a document - I imagine you are not referring to the wikiuser who created the page)

Spinningspark added a comment.Via ConduitJan 28 2012, 7:27 PM

(In reply to comment #3)

(In reply to comment #2)
> Wikisource badly needs an "inauthor" search parameter, a standard feature on
> most document databases. Ability to make efficient searches is so important to
> knowledge stores that I am in favour of upgrading the importance of this issue
> from "low". I have moved it to "normal" - hope I am not acting out of turn,
> imo it should be even higher.

Note, for requesting an inauthor: search parameter, you should probably open a
new bug. This bug is more about making user friendly input boxes on the
advanced search page for the search options that already exist. (if you do file
a new bug, be sure to be clear on how you define the "author" of a document - I
imagine you are not referring to the wikiuser who created the page)

Opened bug 34011

TheDJ added a comment.Via ConduitDec 10 2013, 3:38 PM

Some other advanced search forms:
http://www.ebay.com/sch/ebayadvsearch/?rt=nc
https://www.google.com/advanced_search?q=wikipedia

Much can already be done with the existing functionality. It's little more than a query builder I guess.

Current capabilities: https://en.wikipedia.org/wiki/Help:Searching and future capabilities https://www.mediawiki.org/wiki/Search/CirrusSearchFeatures

Nemo_bis awarded a token.Via WebDec 12 2014, 8:04 AM
Schnark added a subscriber: Schnark.Via WebJan 19 2015, 10:09 AM
mwjames added a comment.Via WebJan 29 2015, 2:59 PM

By coincidence, I just came across the SpecialSearchPowerBox hook (for the advanced profile) which allows to add additional custom query fields to the "$showSections" but it soon becomes clear that this doesn't help much because once you click on the prev/next (+20, +50) link all options declared by an additional form field are gone ("$opts" hook parameter is immutable and one has no access to the "extraParams" array) making any option invalid for usage by a wider search radius.

This has been open for quite some time and I don't think we will see any improvements on this topic anytime soon (more precisely never).

demon added a subscriber: demon.Via WebJan 29 2015, 3:04 PM

The whole search UI needs a rethink.

Tgr added a comment.Via WebJan 29 2015, 8:10 PM

By coincidence, I just came across the SpecialSearchPowerBox hook (for the advanced profile) which allows to add additional custom query fields to the "$showSections" but it soon becomes clear that this doesn't help much because once you click on the prev/next (+20, +50) link all options declared by an additional form field are gone ("$opts" hook parameter is immutable and one has no access to the "extraParams" array) making any option invalid for usage by a wider search radius.

Sounds like a separate bug ticket? If a hook is known not to work, and no one is interested in fixing it, it should at least be deprecated.

Bawolff added a comment.Via WebMar 4 2015, 5:00 PM

I made a basic js prototype for a commons specific advanced advanced search feature (somewhat limited by what Cirrus currently supports) at https://commons.wikimedia.org/wiki/User:Bawolff/search.js

Spinningspark removed a subscriber: Spinningspark.Via WebApr 5 2015, 11:04 PM

Add Comment