Last modified: 2014-05-22 11:15:20 UTC
Transmitting a feature request from some german wikipedians: They suggest to place the cursor in the search field when the page loads.
fully supported by Wikinaut (pushy as always....)
Committing myself to implement this.
I committed a working implementation of this to HEAD, there are some problems with it: It doesn't work for skins other than monobook (by design), this is because we don't want this for all skins as it has the effect of moving the view down to the box in question, which is bad in skins like CologneBlue and nostalgia which have the search box at the bottom, We'd like this for classic however. For some reason it didn't work when I backported it to REL1_4, probably some error of mine.
I've reverted my patch in HEAD and am marking this as WONTFIX, unless someone can provide a better implementation of this than the one I made it'll probably stay that way. Autofocusing should not be done lightly, and autofocusing on an input box has some implications one would not expect at first. In a page where the input box is not the main function of the page but merely serves to compliment it those implications are mostly negative, for example, when entering a page which automatically focuses on a textbox contained in it and pressing the up/down arrow keys or presses page-down will activate the autocompletion feature of most browsers rather than moving the scrollbar, so to achieve the desired effect the user will first have move the focus from the input box by clicking on the main body of the page and then proceed to scroll down. So, a design decision, which to we want users to be able to do more easily? Search, or read the current page? I for one prefer the latter.
*** Bug 2010 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > So, a design decision, which to we want users to be able to do more easily? > Search, or read the current page? I for one prefer the latter. I completely agree with you that this decision should not be taken light-heartedly, because of the severe implications. But I would stick with my suggestion of having it on the Main_Page, since this page is not too long and may not be in need of immediate scrolling, and, further more but most important, it is the starting point to the encyclopedia, and most accesses I think start with the search box. For pages other than Main_Page, I would suggest to keep the current behaviour, having the focus on the first content link. If you are worried about the scroll key navigation even on the Main_Page, then you could only use the 'tabindex="1"' solution, since this will first need a hit on the tab key, and therefore scroll keys are associated with normal page scrolling.
People probably want to scroll the Main Page too, but the tabindex idea could be implemented if: * It doesn't change [user] -> [password] to [user] -> [search] -> [password] on Special:Userlogin * It doesn't take priority on action=edit pages.
(In reply to comment #7) > People probably want to scroll the Main Page too, Well, yes, I don't argue that (and they are still able to scroll, since the scroll wheel stays connected with normal scroll bars, and for arrow keys scrolling they would first need to click in the text area), but I think that the amount of people using the search box on Main_Page is bigger than the amount of people who want to scroll on Main_Page. > but the tabindex idea could be > implemented if: > > * It doesn't change [user] -> [password] to [user] -> [search] -> [password] on > Special:Userlogin I just checked the Special:Userlogin page, and there are 'tabindex'es used indeed, starting with '1' up to '10'. This would of course cause troubles then, but since it should only be implemented on the Main_Page, this shouldn't disturb any other pages. Of course, if it should get implemented on every page, a sitewide policy must be installed, which assigns the search box tabindex a constant value which does not interfere with all other possible uses of tabindex. I.e., one must reserve a special number for the search box, which is big enough to not interfere with pages like Special:Userlogin. > * It doesn't take priority on action=edit pages. Of course, the edit pages make use of 'tabindex' as well, up to index 6. But this problem simply reduces to the first one above. I am not really familiar with the wiki code, but I guess there is some special logic needed for the Main_Page anyway, so it would not be too big a problem to add the 'tabindex' attribute there, or maybe even the ECMAScript portion. Otherwise, we might of course run into troubles, unless a sitewide solution is being applied.
Maybe the user needs a new option in the preferences if he/she wants to use "setFocus()"...
If the Search box is focused it is not possible to scroll the page with the arrow keys and page up/down keys.
Please don't implement this change as the default -- it will break expected behaviour. When I press the space bar, my browser scrolls down a page unless I've deliberately placed the cursor in a text box. The only pages where I expect this behaviour to be different is pages that are designed purely to take text input. If someone wants to come to a page that is designed for an instant search, they should bookmark and use http://en.wikipedia.org/wiki/Special:Search?search=&fulltext=Search -- I would see no issue with implementing this functionality on this page.
Even on Special:Search the focus is not automatically set to the search box
*** Bug 5227 has been marked as a duplicate of this bug. ***
*** Bug 5319 has been marked as a duplicate of this bug. ***
*** Bug 6165 has been marked as a duplicate of this bug. ***
This may be crazy-talk; but how about a page that has BOTH content AND is meant to be a search page? So it looks like http://en.wikipedia.org/wiki/Special:Search?search=&fulltext=Search yet has all the content of http://en.wikipedia.org/wiki/Main_Page beneath that. What I'm imagining is something akin to what google does with their homepage, http://www.google.com/ig (except they use fancy widgets). It would be nice to at least have a page that is like http://www.wikipedia.org (that you can immediately search from) and like http://en.wikipedia.org/wiki/Main_Page (that has content relevant to the current day/events/etc).
*** Bug 6733 has been marked as a duplicate of this bug. ***
*** Bug 7600 has been marked as a duplicate of this bug. ***
I think it is time to revisit this issue and finally get it fixed. Step one should be to research actual usage patterns for Wikipedia pages and implement changes to suit the most common patterns. Someone should suggest some good ways of doing this. As there may well be a range of common patterns, user preferences, as provided by most search engines, should be provided. This is all known technology used routinely on thousands of other prominent websites. From experience developing other websites, my guess about home page usage is that most users first click in the search box and then type a search phrase. I would also guess that few even know you can use the arrow keys for scrolling and that even fewer are as mouse phobic as appears to be the case for some of those who have commented above. Personally I think that scrolling is what the mouse wheel is for.
(In reply to comment #19) > Personally I think that scrolling is what the mouse > wheel is for. Personally, I think that I'd prefer it if pages didn't jump around upon load, especially when that will obscure my view of the top of the page, which is where details about the site would appear as introduction text. Leaping down to half-way through the content harms usability and means new visitors have to do more work to find out what Wikipedia, or any other wiki running MediaWiki, is all about.
The focus *is* in the search box on the entry portal at http://www.wikipedia.org/ . On content pages, which is the entire wiki, isn't not and it never ever ever should be nor will be.
I'm tossing in my agreement with Brion Vibber. The purpose of the wiki is reading the information on the current page... I think it's reasonable the way it currently is.
How about adding a JavaScript method for the body.onkeypress. That way users can hit, say, "F" and it would put the cursor into the search box. We could even put a "Hit 'F' to search" message just underneath the search box so users will be alerted of the feature.
The search box already has an accesskey, F. Use Alt-F or Shift-Alt-F or Shift-Esc-F or Ctrl-F or whatever combination your browser uses.
*** Bug 8743 has been marked as a duplicate of this bug. ***
*** Bug 9224 has been marked as a duplicate of this bug. ***
*** Bug 10790 has been marked as a duplicate of this bug. ***
*** Bug 10896 has been marked as a duplicate of this bug. ***
There's a solution for this issue through the gadgets extension now, see http://www.mediawiki.org/wiki/Extension:Gadgets and http://en.wikipedia.org/wiki/MediaWiki:Gadget-searchFocus.js (changing to worksforme therefore)
(In reply to comment #6) > (In reply to comment #4) >> So, a design decision, which to we want users to be able to do more easily? >> Search, or read the current page? I for one prefer the latter. > > If you are worried about the scroll key navigation even on the Main_Page, then > you could only use the 'tabindex="1"' solution, since this will first need a hit > on the tab key, and therefore scroll keys are associated with normal page scrolling. This looks like the best idea, since it does not change the order of any other <input> fields, and makes it extremely easy to get to the Search field with a single keystroke. At present, there are no other tabindex settings on the Main Page, so this should do little damage. This is in fact the reason I came to Bugzilla in the first place, to suggest adding tabindex=1 on search field of the Main Page. -drt
Open a new bug.
*** Bug 14158 has been marked as a duplicate of this bug. ***
Thank you all for working on this, sharing thoughts and technical solutions. I am the author of Bug 14158 (just above). I've just now read over the comments here. If I may, let me comment that some parts of this thread seem to imply that the suggestion being made is to make the cursor active AND to shift the webpage to focus on the search box. I may have misunderstood these comments, but I can say that the suggestion as I understand it does not include the latter issue of refocusing the webpage. I must also admit a failure to properly appreciate technical issues. I design the architecture of websites but leave the coding to my colleagues. All of our websites have active cursors and our users strongly appreciate this. My limited usage of the web suggests that leading websites tend to use this as their default if they have search boxes. Think google, merriam-webster, google maps -- indeed, it seems as if web-design protocol has moved to have active search cursors as the modern standard. I had never encountered any webpage navigation problems in all these years, with my websites or the general web, and so was quite puzzled with many of the other comments above that spoke of technical issues which would result from activating the cursor on Wikipedia. But that is my ignorance -- I guess in all these years I have just used these sites to do the search I wanted and have never seriously navigated around them. I just now went to some of these sites and yes, the navigation is buggy! I am amazed, chastened, humbled, and appreciative of the learning experience. Having said that, I return to the problem. On one level there is the debate between the (apparently) unknown numbers of those who want to start off with navigation and those who want to start off with a search. The implication is that if sufficient numbers want to navigate, that they should be accommodated and that the searchers should just learn to live with the problem. I'm all for accommodation. Let me also suggest another level to the discussion. Even if there are very few searchers, even if the standard will be to guarantee full navigation to the navigators -- still, the technical issues should be overcome. Perhaps, if answers do not yet exist in the technical realm, then the solution would be to create a google-like simple search screen with a link to the traditional home page, and then with a link back to the simple screen. Of the tabs that open when I open my browser, I'd quickly change from the current Wikipedia page to the new one. I suspect many others would, too. I am quite often reminded of my great thankfulness to all the folks who create the daily content on the existing homepage. This whole debate, to some degree, may seem to call into question the commitment to steer users to that content and therefore the worth of that content. It would be a shame if this were the case. There is no doubt of its value. Indeed, to think that it needs to have people steered to it in order to gain users is disrespectful of its value. No, any solution should preserve that content and its navigation, while allowing searchers to somehow also be able to search more easily, or bypass the content. Thanks.
(In reply to comment #33) > If I may, let me comment that some parts of this thread seem to imply that the > suggestion being made is to make the cursor active AND to shift the webpage to > focus on the search box. When focus is given to an element using JavaScript, my understanding is that the browser will always ensure that the element is visible. I may be wrong. > Perhaps, if answers do not yet exist in the technical realm, then the solution > would be to create a google-like simple search screen with a link to the > traditional home page, and then with a link back to the simple screen. Of the > tabs that open when I open my browser, I'd quickly change from the current > Wikipedia page to the new one. I suspect many others would, too. Try http://www.wikipedia.org/, or [[Special:Search]].
Simetrical's comments are most welcome. The [[Special:Search]] option was mentioned previously in the thread. It unfortunately seems to produce a list of wikipages rather than taking you to the search result. A good show, but still requires the extra click to then open the search result from the list. The http://www.wikipedia.org option -- why didn't I notice the search option there before? -- is an excellent one. Going to it from your link, or just typing the URL in from the browser, takes you there with an active search box, i.e., the cursor active in the search box. The key thing seems to be that the need for navigation is less important here -- something I've noticed with other websites that have active search boxes -- and so the folks who program that page seem to have decided to leave the navigation issues bugged (which they are!) in order to give an active search. This seemingly solves the problem, at least for me, but I note a small added bug. When I replaced the old Wikipedia homepage with this search page in my list of tabs to open upon starting up Firefox, the search page came up but the search box was NOT ACTIVE. Amazing. Tried it several times. I was, however, able to debug, at least on a rough level, whatever conflict there is between Firefox and that wikipage: if you put the tab as the first to open, then the search box remains active. So, at least for me (and anyone else coming to this thread), this is solved. The wikipedia.org page even has a link (the English link) to the Wikipedia homepage, so that I can read the daily content as I like to do. Best wishes to everyone.
*** Bug 15922 has been marked as a duplicate of this bug. ***
Two immediate things: 1) This keeps getting put up as a bug; like me, seemd people have a hard time searching bugs/requests and end up duplicate reporting/requesting it. 2) This keeps getting put up, so must be quite a few users want it, more than those that have put in the effort to request. I saw the 2 different web pages given as substitutes, not bad, but no wonder noone knows about them: <B>I couldn't find a link to either of them</B>. I see the problem with setting focus to a text box: up/down, pgup/dn, backspace don't work like normal. But, a main page should not be larger than a typical screen therfore not require scrolling. And most (all?) times when you go to an encyclopedia, you're looking something up, not going to the table of contents. Take all that crap off the main page, or at least make it custimizable. And I never understood listing all those languages on the left side, some of which are unrepresentable. And all those commands too. On every page. Why? Put them on a single selection page, or at least collapse the list. There's like 3 or 4 hundred. That would shorten the main page to prevent the need to scroll. And the tabs are not even set well, first tab goes to the address bar (just got to the page, why you want to leave?), second goes to donate (like that is a daily click), third goes to the picture on the right side of the page (the larger picture is not usually larger). not useful, any of them. So I don't think this should be closed, the navigation is so clutzy.
Why don't we use some JS to trap alphanumeric keystrokes and automatically give focus to the search form if those are hit, say? That might be worth opening a new bug on, since this one is awfully cluttered.
I commented on this bug some months ago. My final work-around was to set my open-tab-at-start-of-browser setting from the page with the daily article over to the page with the search box activated <http://www.wikipedia.org/>. As I mentioned previously, I design websites for a digital library, and I have all similar pages set so that search boxes have the cursor activated into them. I have never had any complaints about the navigation controls not working because, as other have said, the reason for going to one of my search pages is to search. Same with wikipedia. And I agree that if the wikipedia homepage requires navigation, then it is probably too big and should be simplified.
*** Bug 16593 has been marked as a duplicate of this bug. ***
I'm going to go ahead and reopen this and adjust the summary a little bit so it's easier to find. (WONTFIXes don't show up in a default search, so you have to jump through hoops to find it before filing a dupe bug report.) A couple things to consider... First is that it may be useful for local wiki admins designing their local wiki main pages to add a more prominent search box, which could in fact *be* focused by default. This could be done with a slight addition to the inputbox extension to add a focus trigger. It would be up to the local wiki communities to create main page designs which make use of this, or not. The other is that in general we probably want to move the search box at some point up nearer to the top on general principle; as a side affect this would allow for setting a sensible tab index. (If it were forced now, it could make things kind of icky by having the first tab put you into the search field, and the next run you through a hojillion sidebar links before you get back to page content. Bleah!) (In reply to comment #38) > Why don't we use some JS to trap alphanumeric keystrokes and automatically give > focus to the search form if those are hit, say? That might be worth opening a > new bug on, since this one is awfully cluttered. I don't think I'd recommend that; at best it may not work reliably, and it will interfere with for instance in-page type-ahead search in some browsers. More generally it just violates general interface behavior conventions, in that the box isn't actually highlighted yet, so lots of stuff wouldn't work in it, like say pasting text, leading to confusing behavior and annoyed users.
*** Bug 17065 has been marked as a duplicate of this bug. ***
*** Bug 17306 has been marked as a duplicate of this bug. ***
In my opinion it is not necessary to apply the focused seach bar for all users. Just enabling it as a personal preference option for registered users should be fine. I believe that the focused search bar is something of interest only to those who frequently use the search function on sites like wikipedia. I'm not sure if this is easy to accomplish, but if it is I hope it is something to consider.
This is available as a preference on the English Wikipedia: under Gadgets, "Focus the cursor in the search bar on loading the Main Page." I'm not sure whether it needs to be a preference in the core software.
Re:"In my opinion it is not necessary to apply the focused seach bar for all users. Just enabling it as a personal preference option for registered users should be fine. I believe that the focused search bar is something of interest only to those who frequently use the search function on sites like wikipedia." This makes no sense whatever. Everyone comes to wiki to search. Not one single soul has ever come to read about the random filler that makes the front page. Not even the author's own mother. That would be like saying people come to the Encyclopedia Britannica to open to one page randomly and then put it back on the shelf. Doesn't happen. You clowns have spent easily a hundred times more effort trying to get out of this simple bug fix than doing it. Just fix it already. It's a bug!
I suppose I was a bit selfish when I wrote that reply the last time. I'm registered, and I get the search bar focused, so I'm happy. I still think this should be implemented as the default choice. Here is why (summary of some arguments in this discussion): ** Majority uses wikipedia to search. As noted in the previous comment, and several more further up, the majority come to wikipedia to look something up. All these would benefit with the automatic focus. ** Mouse scrollers Among the users who actually want to scroll, most probably use the scroll wheel on the mouse. This works just fine even if the seach bar is focused. ** Key scrollers For those who wish to scroll the Main_Page with the arrow keys, have the luxury of clicking anywhere on the main page or just hitting the tab key for the scroll to work as they wish. In addition I just want to point out that this most likely is a very marginal group. My guess is probably less than 1%, and yet these are the ones we favour. I just skimmed over the comments that have been written so far, and the only argument against was the one I just adressed. I had my search bar focused through my wikipedia account since February, and I am very happy with the result. It was getting quite annoying to have to click on the tiny seach bar every time I wanted to make a search (which often is several times a day).
How about this: make the focus the default, but allow people the option of turning it off?
(In reply to comment #46) > Re:"In my opinion it is not necessary to apply the focused seach bar for all > users. > Just enabling it as a personal preference option for registered users should be > fine. > > I believe that the focused search bar is something of interest only to those > who frequently use the search function on sites like wikipedia." > > This makes no sense whatever. Everyone comes to wiki to search. > Not one single soul has ever come to read about the random filler that makes > the front page. > Not even the author's own mother. That would be like saying people come to the > Encyclopedia Britannica to open to one page randomly and then put it back on > the shelf. Doesn't happen. > Don't claim to know the habits of other users. I for one would be greatly annoyed at having my cursor auto-focused on the search box _EVERYTIME_ I happen to load the main page. > You clowns have spent easily a hundred times more effort trying to get out of > this simple bug fix than doing it. > Just fix it already. It's a bug! > If you can't be helpful, go away. (In reply to comment #48) > How about this: make the focus the default, but allow people the option of > turning it off? > This is actually a pretty decent suggestion, if this indeed becomes a userpref.
Re: "If you can't be helpful, go away." Take your own advice. I've been helpful for years on the topic. Years. And still this minor bug remains "as a feature". What other reference volume site does this? Dictionaries? Other cyclopaedias? Not to my knowledge, just Wiki. If you really want to know if it's a feature, just fix it and see if anyone complains. My guess is they won't. End of problem.
One other point: If you want to know what is the "Main Page" of wiki for English speakers, I suggest you go to the aptly-named http://en.wikipedia.org/wiki/Main_Page Now push the tab marked Main Page. Or the "navagation" link marked Main Page Or click on the world logo That's the wiki's own definiton of Main Page.
Speaking purely theoretically here, but it would be nice if could have a JavaScript that does the following: 1) By default focus the search box on every page 2) If user presses any of the arrows/page up/page down send those back to the browser when the _search box is empty_ I wonder how viable is 2), anyone has an idea?
(In reply to comment #52) > 1) By default focus the search box on every page > 2) If user presses any of the arrows/page up/page down send those back to the > browser when the _search box is empty_ > > I wonder how viable is 2), anyone has an idea? > http://en.wikipedia.org/wiki/User:Splarka/softfocus.js Pretty easy in FF as it turns out. Not sure about other browsers (needs testing). Still hate the idea though (but not so bad with an opt-out).
(In reply to comment #52) > Speaking purely theoretically here, but it would be nice if could have a > JavaScript that does the following: > > 1) By default focus the search box on every page > 2) If user presses any of the arrows/page up/page down send those back to the > browser when the _search box is empty_ > > I wonder how viable is 2), anyone has an idea? What about if they use other platform-specific conventions for scrolling? Aren't there some Ctrl combinations for Mac, for instance? What about "search as you type"? Looking at some other sites: * dictionary.com auto-focuses search, but its front page doesn't need scrolling on typical desktop resolutions. * tfd.com auto-focuses search, and its front page does need scrolling (although not for the most interesting content, of course). * britannica.com doesn't auto-focus search. * encyclopedia.com auto-focuses search, and requires scrolling. * knol.google.com does not auto-focus search. * encarta.msn.com does auto-focus search, and requires scrolling. Well, if enwiki would just cut down the front page to half its current size, we'd have a really easy solution: there wouldn't be enough content on the main page to be worth scrolling. :) Do we have statistics on what percentage of visitors to the Main Page go on to search for something? Presumably a lot of searchers use, e.g., the Firefox search box, which is a lot faster (one less page load). Also, I wonder how many users look at the front page content before scrolling. Trevor, does the usability team have any opinion on this?
I tested on Mac, and Safari passes "scroll-like" events in textfields regardless of this Javascript. FF would need it however I guess. It does however scroll the page to the "focused" element if the element is out of view. (no problem on the Main page if we have Vector, otherwise might be annoying).
Just want to drop a note that on the German Wiktionary we already have implemented this feature quite some months ago, at [[wikt:de:MediaWiki:Common.js]], [[MediaWiki:Monobook.js]] (called "Suchfeldfokus"). You may test it. Live. It skips password pages; isn't executed if a page is going to be scrolled etc. Ideas for other improvements are much appreciated, of course.
This looks good, from my quick testing looks like it works in most browsers (Firefox 3, IE6, Safari 4, Opera 9.6 all for windows/linux) except in Chrome. Would be good to test on Mac as well. I think this is a good feature to have in core, although possibly with an opt-out config switch.
It does work for Google Chrome, too. Like for Safari and Konqueror ;-) Chrome is just buggy. With my Win XP installation I discovered it not working properly right after an update to the latest version, it only worked when the page was not accessed by a click (so, just by URL bar or reload etc.). After a restart it worked perfectly well. @Opt-out: The easiest thing would be to have global/core gadgets :-)
*** Bug 27778 has been marked as a duplicate of this bug. ***
