Last modified: 2013-08-29 17:10:34 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.
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.
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!
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.
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.
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.
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.
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.
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.
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
Resolving WORKSFORME
(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.
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).
(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).
