Last modified: 2014-10-28 06:59:01 UTC
Created attachment 15621 [details] Example This is an issue in the new ("ooMenu" based) suggester. This usage pattern doesn't work any more: Start typing, e.g. "wikida". The suggester dropdown shows up with "Wikidata" at the top. The autocompleted suffix "ta" is selected (orange in my example screenshot) so I can continue typing. If the suggestion is what I want I can simply hit tab and be done. This doesn't work any more. I need to use the mouse or cursor down to select the first element in the list. This especially doesn't make much sense if there is only one item in the list. Why not autocomplete it?
Actually, that was removed by intention on the basis of discussions some time ago. How can you be sure that the user does not want to enter "wikida" but "Wikidata"? Although I prefer the ease of using auto-completing, it can be dangerous to make assumptions here. For using the method of auto-completing we had, the suggestion system should be flawless which is not the case and we cannot influence the system directly; even more when a Wikibase instance should link to non-MediaWiki sites. As to MediaWiki, for example: Try adding a German site link to "Allegro". You get "Allegro Film" as first suggestion although there is an article "Allegro". Unless such edge cases are not filtered out specifically, the user would need to erase the auto-completed " Film" before saving. With having to consider a big pool of languages, there are most likely problems and edge cases we are not even aware of. In addition to just presenting suggestions, auto-completing adds to the assumption that only the suggested values are valid values. If we want to have auto-completion again, I would favour a more unobtrusive implementation, like Google does with instant search where the user needs to dedicatedly press the right arrow key to auto-complete. But is saving one keypress worth the effort at the moment? Auto-completion is quite a technical burden and had flaws in the previous implementation. It would be no big deal to re-implement the old behaviour (we have jQuery.autocompletestring), but I would refrain from that.
(In reply to Henning from comment #1) > How can you be sure that the user does not want to enter "wikida" If the user knows "wikida" is in the list, he can type "wikida" and nothing bad will happen, with or without auto-completion. If "wikida" is not in the list, what's more common? 1. A user typing "wikida", hitting enter and expecting to get an error message, which is currently the case and what I find useless and confusing ("The specified article could not be found on the corresponding site. Details: The external client site did not provide page information"). 2. A user typing "wikida", hitting enter and expecting the first match (which is "Wikidata") to be saved? I know that there is an argument for _not_ having auto-completion, but I consider the arguments for having it much stronger. > You get "Allegro Film" as first suggestion although there is an article > "Allegro". Which is an issue I would happily fix. > auto-completing adds to the assumption that only the suggested values > are valid values. Which is always the case. > But is saving one keypress worth the effort It's not only about saving key presses, it's about what the users expect.
So, which authority is going to make a decision, finally? I can identify three options: - no auto-completion (current state) - "hard" auto-completion (old state) Auto-completed suffix characters are inserted as selected text into the input box, tabbing/clicking out of the box involves automatic auto-completion. In order to prevent auto-completion, the "delete" key needs to be pressed. - "soft" auto-completion Auto-completed characters are underlayed with a light colour but are not actual text in the input box. Tabbing/clicking out of the input box does not auto-complete, only dedicatedly pressing the "right arrow" key does.
