It is deployed in live en.wikipedia now, too and the problem persists there.

SimpleSearch used to have a feature similar to mwsuggest where navigating to a suggestion with the arrow keys would put that suggestion in the search box. This feature was deliberately disabled for reasons I don't remember. CCing Naoko and Adam, who can hopefully shed some light on this.

In addition to adding info after the slash to "Special:PrefixIndex", which is useful only to advanced users, here's a more common scenario for putting the suggestion into the box:

When i edit an article, i need to decide whether to add an internal link to it or not. If the target article exists, i shall probably add the link. To check whether the target article exists, i can start typing its name in the search box, then go down to it with the arrow and then copy its exact title to the editing field.

This is also useful for more general purposes - for quick checking of the spelling of some name. (Of course the spelling may actually be wrong and the suggested title may be a redirect to the correct title, but that's something i can take responsibility for.)

(In reply to comment #3)

When i edit an article, i need to decide whether to add an internal link to it
or not. If the target article exists, i shall probably add the link. To check
whether the target article exists, i can start typing its name in the search
box, then go down to it with the arrow and then copy its exact title to the
editing field.

This use case is not very realistic in a Vector environment: the link dialog (link button in toolbar) has title suggestions as well.

(In reply to comment #4)

(In reply to comment #3)

When i edit an article, i need to decide whether to add an internal link to it
or not. If the target article exists, i shall probably add the link. To check
whether the target article exists, i can start typing its name in the search
box, then go down to it with the arrow and then copy its exact title to the
editing field.

This use case is not very realistic in a Vector environment: the link dialog
(link button in toolbar) has title suggestions as well.

Lovely! I didn't notice it. (I'm probably too used to typing the brackets and the pipe myself.)

But as i wrote, this is useful not just for links.

veryfurryfur wrote:

More background on Bug 23949, especially Adam's comment, number 4.

The root of the problem is that a new feature ("containing...") has been introduced, and that is currently incompatible with (=breaks) the standard behavior we are all used to (=arrow keys selection populates the text box).

In that bug there are also a few suggestions for work-arounds. In my opinion we should just pull this additional feature that we survived without for a long time, until we can figure out a way of integrating it with existing functionality without breaking it.

I am very hesitant to consider "the standard behavior we are all used to" as a mark of design quality. As we conduct research analyzing user behavior I am constantly amazed by the number of poorly designed and flimsily constructed elements in our software that people have "gotten used to" and now consider not only acceptable, but "standard behavior". For the Wikimedia Foundation's projects to succeed, we must attract new users, especially those who do not have the kind of tolerance for pain as our existing users have been shown to have.

That said, we have no evidence that there is any increase in usability by changing the text in the text-box as the user arrows through the suggestions. The decision we made has to do with this being a unique control, so comparing it to the suggestions software that Google uses on it's home page is inappropriate. Given the qualities of the control, I still believe that we have chosen the right approach.

veryfurryfur wrote:

"we have no evidence that there is any increase in usability by
changing the text in the text-box as the user arrows through the suggestions"

Please re-read the Description of this bug. This is still a problem, and therefore I am reopening this bug.
It explains fairly clearly that by having the text box auto-populated when the user arrows through the suggestions can save a non-negligible amount of keystrokes (6 in this particular case).
This is still a problem, and therefore I am reopening this bug.

I don't think comparisons to Google (and Firefox, and Windows Explorer, and Internet Explorer) can be shrugged off like this.
I don't see how this control needs to be unique (= include a "containing..." item) when other more standard GUI solutions are available, and especially when introducing that item decreases usability of other aspects/responsibilities of the control.

Incidentally, I just noticed that IE7 offers the same functionality in a backwards-compatible way. The way they do it is similar to one of the suggestions in Bug 23949:

"
we could come up with a special "Search:" or "Containing:" namespace and just put
"Search:foo" or "Containing:foo" in the text box when "containing..." is
reached (by keyboard).
"

I don't really see much of a problem with the "Containing" option here. If you type in, say, "Tur", you would get a list of stuff like "Turkey", "Turkish March", ... , "Containing Tur". As you arrow down over "Turkey", that text would be put in the textbox, but "Containing Tur" would stay put and not change to "Containing Turkey". Then when you arrow down over "Containing Tur", we'd put "Tur" back into the textbox. This sounds like a perfectly intuitive workflow to me, and it wouldn't be hard to tweak the code so it works the way I described.

Another consideration: do we expect that novice users will use the arrow down key much, if at all? I personally expect most people to just use their mouse and forget about the arrow keys. Just this weekend, I observed someone trying to search for "Guy Fawkes movie" by typing "Guy" and clicking the suggestion for "Guy Fawkes", which to her surprise took her to the Guy Fawkes article, even though she was already on that page, having gotten there in exactly the same way. This shows that the behavior of going to the page when clicking a suggestion is perceived as intuitive or unintuitive depending on what you want it to do at the time :D but also that Jane Visitor just uses the mouse and doesn't think about the arrow keys.

veryfurryfur wrote:

That's one possible way out, but it's not as transparent as it could be.
The IE7 solution is transparent, because when you arrow to the last "Search" item (equivalent to "Containing" in our case), the bar is auto-filled with "Search Tur", and if you type "Search Tur" directly in the bar and hit enter you get exactly the same behavior.

It's probably an acceptable solution, but I wouldn't be surprised if it came back and haunt us under the guise of another unexpected behaviour/bug. If you go ahead with this, I'd be happy to test it - please let me know where.

"This shows [...] that Jane Visitor just uses the mouse and doesn't think about the arrow keys."

No, it doesn't. It shows that one person prefers to use the mouse.
It may be true that currently most people prefer using the mouse in this instance or in general, but years of usability and accessibility studies have demonstrated that Keyboard is King and that it should be treated with respect.

http://www.webaim.org/techniques/keyboard/

For 1 person you observe, there have been 10000 that went through the motion and helped UI controls evolve into what we use every day. Sure there must be innovation, but it really surprises me how many failed attempts at reinventing the wheel we are still going through, and how many of these flashy (pun intended) but failed attempts are accepted to the expense of usability and accessibility by minorities.

Finally, but this is speculation, I believe we are still in a phase of low literacy. In one generation or so, people will wake up to the fact that keyboard + keyboard-supportive application = dramatically increased productivity.

... And here's another usage scenario: go to WikiSource and start typing "1911 En". The suggestions will show "1911 Encyclopædia Britannica", "1911 Encyclopædia Britannica/Infinitesimal Calculus", etc. I want to check whether "1911 Encyclopædia Britannica/Seymour, Thomas Day" exists. In Monobook i would use the arrow to go to "1911 Encyclopædia Britannica", add "/Seymour, T" and see the suggestions. With SimpleSearch i can't do that and i'm badly frustrated.

I am not exaggerating when i'm saying that something like this happens to me every 5 minutes.

We're working on a fix for this, see http://prototype.wikimedia.org/sandbox.3/ for a prototype.

veryfurryfur wrote:

Thank you!
On the whole it looks fine.

A couple of relatively minor comments, possibly not related to this change:

1. Auto-expanding/animated search bar is annoying, non-standard and it's a bad idea from an accessibility perspective. I understand why it was done, but let's face it, it's really a bandage on a bad design. It boils down to the fact that the place is crammed and the search bar does not belong there. "Page", "Discussion", "Read", "Edit", "View History"... all actions performed on the page/article currently displayed. Search? Action performed on the site that takes you somewhere else. I am not of the "OMG SEARCH BAR BACK TO THE LEFT!!1!" camp, but it just does not belong where it is now, logically. I would put it above "Page" and "Discussion" tab, on the right of the logo.

Anyway, if you must expand it, did you consider auto-expanding it only when necessary?

2. Auto-expansion is triggered every time I re-visit the page (in Firefox, just switch to another tab and switch back, you get the annoying animation again).

3. The caret disappears sometimes, although the focus remains on the search box and I can type and move around. I cannot say how to reproduce it but just play around a little. It happens more often than not.

4. The half-second delay that the bar takes to de-emphasize the search string within the suggestion list as you delete characters feels unnatural because one expects it to be a very quick calculation and it should be near-instantaneous. Same for emphasizing when you type new characters. I know that there is a remote data-fetch and it cannot be as quick as it is in a local application (e.g. Firefox address bar), but just to let you know that it's noticeable.

5. As previously discussed, if you hit ENTER when a selection that was reached via the mouse (and not via the keyboard) is active ignores the typed text and goes after the selection. This still seems wrong to me. I cannot come up with a realistic scenario that would annoy someone, but I would not be surprised of hearing one later on.

Thanks again for the fix.

veryfurryfur wrote:

Another less intrusive option for the expansion of the search bar could be expanding/contracting it only upon explicit user request (click-on-icon, like for the vertical menus on the left).

Please let me know if there is a better forum for the discussion of these residual points.

Thanks.

amiller1 wrote:

What browser are you seeing number 5 in? I can't replicate this one.

The field expansion is a separate module that I developed as a test. Thanks for your feedback on it, but I'm not sure it will end up being used. I'm not a huge fan of it personally :)

Number 3 seems to be triggered by something in the expanding field code. When I disable it, I can't replicate the disappearing caret.

I dont see number 4 as a problem. Google.com has the delay as I'd assume most other search engines that do suggestions would. We cache results to ensure it's as fast as possible.

veryfurryfur wrote:

I'm using Firefox 3.6.3, but I'm sure that the problem is in my explanation. Let's try again.

Let's assume you want to search for "Pablo".
You type "Pablo".
For some reason (insert your realistic scenario here), the mouse gets moved and it ends up selecting "Pablo Picasso". The text box keeps showing "Pablo", which is expected and correct.
Now you hit ENTER, intending to search for "Pablo". However, the text box suddenly changes to "Pablo Picasso" from under your feet, and that's where you end up. This is in my opinion not expected and not correct.

Although admittedly probably not catastrophic, it doesn't look like a difficult one to fix: Enter = always go where the text box says, ignore drop-down selection.
Note that if user selects a suggestion via keyboard up/down keys, it will still work as expected.

Thanks

amiller1 wrote:

No I understood what you were saying. Not sure why I couldn't replicate it before. Just committed a fix for this in r68298.

veryfurryfur wrote:

Cool, please let me know when it's available for testing.

From the diff, it looks like you opted for adding code instead of removing it, which is probably for a good reason, but I'd just like to make sure that you understand my proposed fix.

Current code with your fix (my interpretation): when ENTER is hit, if there is a selection, work out whether it was achieved through mouse or keyboard. If via mouse, ignore selection. If via keyboard, fill in the text with the selection and search it.

My proposed fix (equivalent behaviour): when ENTER is hit, ignore any suggestion selection and always search for whatever is currently in the text box. If the selection was done via keyboard, the text box will already contain the correct string.

Less code = less potential bugs, but it's probably me who is missing something...

Thanks

(In reply to comment #4)

(In reply to comment #3)

When i edit an article, i need to decide whether to add an internal link to it
or not. If the target article exists, i shall probably add the link. To check
whether the target article exists, i can start typing its name in the search
box, then go down to it with the arrow and then copy its exact title to the
editing field.

This use case is not very realistic in a Vector environment: the link dialog
(link button in toolbar) has title suggestions as well.

And it doesn't autocomplete the field when we use down arrow either... So

1. It doesn't solve the problem
2. It consider a link like "Special:PrefixIndex/a" as invalid

(In reply to comment #7)

That said, we have no evidence that there is any increase in usability by
changing the text in the text-box as the user arrows through the suggestions.
The decision we made has to do with this being a unique control, so comparing
it to the suggestions software that Google uses on it's home page is
inappropriate. Given the qualities of the control, I still believe that we have
chosen the right approach.

Not only Google have this feature, but also the search box of Firefox, and the navigation bar of Chrome and Firefox (I don't know about IE). So, it is really annoying...

(In reply to comment #11)

I am not exaggerating when i'm saying that something like this happens to me
every 5 minutes.

Me neither...

(In reply to comment #13)

2. Auto-expansion is triggered every time I re-visit the page (in Firefox, just

switch to another tab and switch back, you get the annoying animation again).

Agreed...

3. The caret disappears sometimes, although the focus remains on the search box

and I can type and move around. I cannot say how to reproduce it but just play
around a little. It happens more often than not.

4. The half-second delay that the bar takes to de-emphasize the search string

within the suggestion list as you delete characters feels unnatural because one
expects it to be a very quick calculation and it should be near-instantaneous.
Same for emphasizing when you type new characters. I know that there is a
remote data-fetch and it cannot be as quick as it is in a local application
(e.g. Firefox address bar), but just to let you know that it's noticeable.

5. As previously discussed, if you hit ENTER when a selection that was reached

via the mouse (and not via the keyboard) is active ignores the typed text and
goes after the selection. This still seems wrong to me. I cannot come up with a
realistic scenario that would annoy someone, but I would not be surprised of
hearing one later on.

Thanks again for the fix.

At prototype.wikimedia.org the search is case sensitive. Is it supposed to be different from en.wikipedia, where it is case insensitive?

(In reply to comment #19)

And it doesn't autocomplete the field when we use down arrow either... So

1. It doesn't solve the problem

We can solve that: if we can add this behavior to the search box, adding it to the link dialog should be trivial.

2. It consider a link like "Special:PrefixIndex/a" as invalid

Yeah it's not very helpful for special page links, but that's a separate bug.

Not only Google have this feature, but also the search box of Firefox, and the
navigation bar of Chrome and Firefox (I don't know about IE). So, it is really
annoying...

(In reply to comment #11)

I am not exaggerating when i'm saying that something like this happens to me
every 5 minutes.

Me neither...

Since we're now going to implement this feature, we don't need to be convinced of its need any more.

(In reply to comment #13)

2. Auto-expansion is triggered every time I re-visit the page (in Firefox, just

switch to another tab and switch back, you get the annoying animation again).

Agreed...

We're taking autoexpansion out because it annoys people and no one seems to actually have a positive opinion about it.

At prototype.wikimedia.org the search is case sensitive. Is it supposed to be
different from en.wikipedia, where it is case insensitive?

The search box on enwiki is case-insensitive due to the TitleKey extension, which is apparently not installed on prototype (I thought it was). Rest assured this won't break on Wikipedia.

(In reply to comment #20)

(In reply to comment #19)

And it doesn't autocomplete the field when we use down arrow either... So

1. It doesn't solve the problem

We can solve that: if we can add this behavior to the search box, adding it to
the link dialog should be trivial.

Is there a bug request for this?

2. It consider a link like "Special:PrefixIndex/a" as invalid

Yeah it's not very helpful for special page links, but that's a separate bug.

Not only Google have this feature, but also the search box of Firefox, and the
navigation bar of Chrome and Firefox (I don't know about IE). So, it is really
annoying...

(In reply to comment #11)

I am not exaggerating when i'm saying that something like this happens to me
every 5 minutes.

Me neither...

Since we're now going to implement this feature, we don't need to be convinced
of its need any more.

Sorry for that... =P

(In reply to comment #13)

2. Auto-expansion is triggered every time I re-visit the page (in Firefox, just

switch to another tab and switch back, you get the annoying animation again).

Agreed...

We're taking autoexpansion out because it annoys people and no one seems to
actually have a positive opinion about it.

At prototype.wikimedia.org the search is case sensitive. Is it supposed to be
different from en.wikipedia, where it is case insensitive?

The search box on enwiki is case-insensitive due to the TitleKey extension,
which is apparently not installed on prototype (I thought it was). Rest assured
this won't break on Wikipedia.

(In reply to comment #21)

(In reply to comment #20)

(In reply to comment #19)

And it doesn't autocomplete the field when we use down arrow either... So

1. It doesn't solve the problem

We can solve that: if we can add this behavior to the search box, adding it to
the link dialog should be trivial.

Is there a bug request for this?

No, but I think it'll be fine to include it in this bug since it'll probably just be flipping a switch.

veryfurryfur wrote:

I just tested the fix in the prototype and it looks good.
When is this going to make it to Wikipedia? People are in pain. Thanks.

veryfurryfur wrote:

When I say "the fix" I mean "both fixes", since there seem to have been two changes related to this bug.

veryfurryfur wrote:

http://en.wikipedia.org/wiki/Wikipedia:User_experience_feedback/search_box#Mouse_hover_over_autosuggestions_causing_unwanted_results

The fixes are now live.