Last modified: 2013-08-29 17:10:34 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 19484 - Provide clean interface for new-page template selection as on Wiktionary (was: Remove MediaWiki:noexactmatch usage.)
Provide clean interface for new-page template selection as on Wiktionary (was...
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Search (Other open bugs)
unspecified
All All
: Normal normal with 7 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 577
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-02 19:40 UTC by Stepro
Modified: 2013-08-29 17:10 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Stepro 2009-07-02 19:40:26 UTC
Communities in de-wiktionary and de-wikiquote don't want this tiny new search site. In wiktionary and wikiquote we had two pages, one for each search method (GO and SEARCH). Result page of GO was a site for choosing a template, result page of SEARCH was the old search site. This change breaks every wiki that used templates for preformated entries and *a lot* did that. The very most new articels in de-wikt and de-wikiquote have been created with the template site. I don't know about the other projects. But it has been a very good way all the time to give the decision about such things the local communities.

We want to have this back as soon as possible, because it's an easy way to create new sites and the current situation is confusing our users. All we want is to implement an invisible Mediawiki-message for &go, so wikis can choose if they want to put something on &go and not on &fulltext. Using "MediaWiki:searchmenu-new" for the templates isn't a good idea because then the fulltext search also shows them.
Comment 1 Derk-Jan Hartman 2009-07-03 21:01:21 UTC
This is due to the lack of inclusion of MediaWiki:noexactmatch it seems.

I realize that this is something that the usability project wants to do, but the wiktionaries are relying on this for their "pre-filled" article creation wizard. Other projects are likely also affected. I propose the the noexactmatch stuff is reverted until a clear alternative is drawn out or the projects themselves find an alternative location for the wizards. To simply jank it out like this does not seem very considerate and is catching people off guard. It was also not really visible in the demo's of the prototype site, what effect this would have for other projects. A more clear announcement seems warranted.
Comment 2 Moilleadóir 2009-07-06 03:50:03 UTC
This change has put a huge spanner in the works for regular contributors to the Irish Wiktionary.  We rely *enormously* on the page templates accessed through Noexactmatch.  Please revert this ASAP!
Comment 3 Robert Stojnic 2009-07-06 08:50:03 UTC
I see two issues here:

1) templates are gone - yes, the old message is no longer in use, so the get stuff to properly show copy your old content from MediaWiki:Noexactmatch to  MediaWiki:Searchmenu-new. Please make it as concise as possible and avoid templates that take up half a screen. 

2) there is no special "go" message. I prefer it staying this way. New users don't understand very well the distinction between Go and Search (although it is a useful one), and are confused by things sometimes turning up, other times don't. There is no reason why a person doing a Go should be offered to make an article, but someone doing Search not. If your templates are annoying and take up too much space trim them down. 
Comment 4 Moilleadóir 2009-07-06 09:36:43 UTC
Being kind to new users is a Good Thing (TM), but that's no reason to be nasty to old users.

Many of the *Wiktionaries* rely on this way of working to simplify the process of adding new content that adheres to a standard.  The difference between Go and Search is not only well understood, but relied upon and used to improve users' experience of adding content.  If you don't like it that's fine, but why force your opinions on well-established projects?

There is one perfectly good reason why a person using Go should be offered the option of creating and article and that's because it's been done that way and that's what older users and help pages will recommend!  Maybe it makes no sense for a Wikipedia, but it certainly does for a Wiktionary.

Lastly, Robert it's really none of your business what text any project puts on that page or how much room it takes up.  That has *nothing* to do with MediaWiki and is rightly a matter for the individual projects to decide.
Comment 5 Robert Stojnic 2009-07-06 10:07:18 UTC
The usability of the search page is of my business. The old Go (aka article creation wizard) and Search (aka normal search) model is a neat idea but in practice doesn't work. I know lots of old users are used to it and that it makes sense to them, but remember that majority of views come from readers, and that in the end we want this project to be useful for readers and provide information. 

This is what typically happens. User gets to your favorite wmf project, sees the search box and types in somethings. He presses enter since it is the easiest and because he's in doubt what go&search means. Where there is no exact match, Special:Search is shown. User sees a bunch of buttons and warnings, on lower resolutions might not even see a single search results. He gives the page a quick glance, concludes that there are no search results and closes the tab/windows. There have been numerous complains about this, and from personal communication from Trevor Pascal I also know the usability study found the same. 

The search UI sucked, and it is partly the communities fault by putting unnecessary information up, it is also partly developers fault for not giving them the tools to do it differently and for neglecting it for so long that people used to it. Having some kind of an intermediate page with those templates would be IMHO much nicer, or just compressing them so that they are there for the experienced user but not interfere with anonymous user navigation. 
Comment 6 Derk-Jan Hartman 2009-07-06 10:13:54 UTC
I think the problem here is more that the behaviour has changed overnight, without communities having been able to prepare for it. Breaking major functionality for primarily the wiktionaries.
Comment 7 Robert Stojnic 2009-07-06 10:24:10 UTC
Someone made the same comment a couple of days on IRC. We probably didn't think enough about what kind of implications would it have for all projects, and I certainly didn't expect such a strong opposition from wiktionaries. However, this has been in stock for months, it was enabled on test.wp for even longer and in my initial redesign I removed the message sometime around December last year. The only way to stay on top of these things is to have someone from the community be involved or at least follow what's going on with development. I remember that a couple of years back there was a person that was on top of things for wiktionaries and who tested and was a voice of community before things were finally deployed, I don't know if there is a person like that now and but we really need one. 
Comment 8 Brion Vibber 2009-07-19 18:24:19 UTC
Could someone maybe give an example of what these templates look like and how you expect to use them? Most likely there's a better way to implement this that won't interfere with search results, but it's hard for us to comment when we're not familiar with the results-page hack that was used to display the template.
Comment 9 Robert Stojnic 2009-07-19 18:32:54 UTC
Apparently people re-added these templates using the new message:

http://en.wiktionary.org/w/index.php?title=Special%3ASearch&search=a+new+word&go=Go
Comment 10 Brion Vibber 2009-07-19 18:40:14 UTC
Resolving WORKSFORME
Comment 11 spacebirdy 2009-07-19 19:00:15 UTC
(In reply to comment #10)
> Resolving WORKSFORME
> 

What do You mean, closing this as "Worksforme" is not a resolution to the problem described.
They implemented the templates at http://en.wiktionary.org/wiki/MediaWiki:Searchmenu-new where they should not be, because then they will also be shown at the full text search, where we don't want them, which is why this bug was opened.

Please give us a message, it can be an empty one!, which is only implemented in the search in ...&go but not in ...&fulltext

Many thanks in advance, best regards.
Comment 12 Brion Vibber 2009-07-19 19:06:41 UTC
Ok then I guess you aren't happy with current state. No way to tell when it seems to have already been reimplemented without further comment. :)


Trevor, can you guys follow up on this in your consideration of the search box UI redesign?

Spacebirdy, note that we're planning to phase out the separate "go" button entirely. Perhaps what would be best here would be to have the "create a page" link optionally take you to a form/wizard page which can provide the predefined template text options.

Adding a "create page 'Blah'" item into the dropdown to take the place of the planned 'Go to page "Blah"' when Blah doesn't exist may also help here, as it'd allow for a sensible keyboard workflow that's only slightly different from the current one (type, down arrow, hit enter).

Added some details to summary and hitched to bug 577 (go vs search confusion).
Comment 13 Nemo 2013-08-29 17:10:34 UTC
(In reply to comment #12)
> Spacebirdy, note that we're planning to phase out the separate "go" button
> entirely. [...]

This already happened in 2010 with Vector and the entry creators have been moved to searchmenu-new as noted above, so it's clear the original request will not be fulfilled. Please split clear use cases to separate bug(s).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links