https://bugzilla.wikimedia.org/show_bug.cgi?id=23611
Helder <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #19 from Helder <[email protected]> 2010-06-23 10:59:55 BRT --- (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? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
